Summary
This advisory describes a hypothetical attack scenario.
There is no evidence of 1Password infrastructure, domain, or service compromise.
The issue would only have been exploitable if an attacker had already independently compromised a separate web property used for marketing or brand content, which did not occur.
An improvement has been deployed to the 1Password browser extension out of an abundance of caution. No customer action is required beyond keeping the extension up to date.
We thank Guy Fischman for the report through our HackerOne program and for working with us on a coordinated disclosure.
Background
When the 1Password browser extension is unlocked, the “Automatic sign-in to 1Password.com” setting allows a user to sign in to 1Password.com without requiring them to re-enter their account password. To make that work, the domain that initiates sign-in requests authentication details from the installed extension through a browser messaging primitive. The extension accepts those messages only when the request originates from one of a fixed list of 1Password-controlled hostnames: 1Password.com, 1Password.ca, and 1Password.eu.
By necessity, this design provides authentication details to the page completing the sign-in flow. Our original threat model had extended that trust to any page served on a 1Password-controlled domain (*.1password.com/.ca/eu), treating the 1Password domain itself as the trust boundary. That was broader than the strict functional minimum of the specific sign-in surfaces needed to participate in unlock. This was a deliberate architectural choice consistent with where we had drawn the trust line at the time.
Observation
The researcher’s analysis showed that the trust boundary as drawn was wider than necessary in two ways:
- The extension’s check accepted messages from any 1Password-controlled hostname in the allowlist, including staging environments and subdomains that don’t host the sign-in flow.
- Some hostnames on the allowlist served content from third-party platforms used for marketing and brand content. While 1Password retained control of those hostnames at the DNS level, the page contents are authored on platforms outside of our primary application infrastructure, which is a different trust profile than pages served by our application stack.
For this scenario to result in any exposure of authentication details, an attacker would have first needed to independently compromise one of those third-party content properties. The researcher’s proof of concept relied on content they authored within their own controlled environment, not on any real-world compromise.
The issue the researcher observed does not break 1Password’s cryptography, authentication model, or vault design. It is scoped to the conditions under which the browser extension accepts an unlock request from a 1Password.com website.
Resolution
Out of an abundance of caution, we have released improvements that narrow the trust boundary for this feature in two directions:
- Client side: The browser extension now has a narrower scope for which 1Password-controlled hostnames may complete an unlock. The domains are now only the specific sign-in surfaces that need to participate in the flow for a given account, rather than the broader domain. This shipped in the 1Password extension version 8.12.21.
- Server side: Server-side validation has been added as a defense-in-depth layer so that delegated sessions can only be issued for the intended sign-in surface, independent of the client-side check.
We have also conducted a broader review of the hostnames associated with our domains to make sure that hostnames serving third-party-authored content are not on any allowlist that confers trust within our application stack.
Recommended action
Keep your 1Password browser extension up to date. You can verify your version and update at our browser extension downloads page.
No password rotation, Secret Key rotation, or other customer action is required.
Our position
The clearest lesson from this finding is that “1Password-controlled” and “trusted to participate in unlock” should not be treated as the same set. They are related, but the second is much smaller than the first, and we have updated both our extension and our domain governance to reflect that distinction.
We’re grateful to the security research community for the time and care that goes into work like this. Disclosures like this one let us harden our designs before a real-world condition for exploitation could exist, which is exactly the value a strong research relationship is meant to deliver.
We encourage researchers to contribute to our bug bounty program so we can continue to reward those who help fortify our defenses on behalf of our customers.