CVE-2026-115770 in Pocket ID
Summary
by MITRE • 11/05/2026
Pocket ID is an OIDC provider that allows users to authenticate with their passkeys to services. From 2.2.0 until 2.12.0, SendEmailVerification uses the token model in backend/internal/model/email_verification_token.go to bind an email-verification token only to the user's identifier, while UpdateUser can change the account email without invalidating the outstanding token and VerifyEmail marks the current address as verified. An ordinary user can request a token for an address they control, change the account to an arbitrary unused address, and redeem the old token so Pocket ID publishes the new address with email_verified set to true. The default affected configuration uses emailsVerified=false and allowOwnAccountEdit=true; the target address must not already belong to another Pocket ID user. A relying application that trusts a verified email for automatic account matching or provisioning can link the attacker's identity to another user's account, while applications that rely exclusively on the stable OIDC sub claim are not affected by that downstream consequence. This issue is fixed in version 2.12.0.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 11/05/2026
The vulnerability identified in Pocket ID versions ranging from 2.2.0 through 2.12.0 represents a critical identity management flaw rooted in the improper handling of email verification tokens during account modification operations. As an OpenID Connect provider facilitating authentication via passkeys, Pocket ID relies on accurate user attributes to ensure secure and reliable service integration for relying parties. The core technical deficiency lies within the backend logic governing email verification token lifecycle and user profile updates. Specifically, when a SendEmailVerification request is processed, the system generates a unique token bound exclusively to the user's internal identifier rather than binding it strictly to the specific email address being verified. This design choice creates a state inconsistency because subsequent calls to UpdateUser allow an authenticated account holder to change their registered email address without invalidating any outstanding verification tokens associated with previous addresses. Consequently, when VerifyEmail is invoked using a token generated for an old or alternative address, the system incorrectly marks the newly set current email address as verified rather than validating the original intent of the token.
This logic error enables an account takeover-like scenario where an attacker can manipulate their identity attributes within the Pocket ID ecosystem to impersonate another user's verified status. The exploitation path begins with a legitimate user who controls one email address requesting a verification token for that address. Before redeeming this token, the attacker utilizes the UpdateUser functionality to change their account's primary email address to a different, arbitrary unused address belonging to or controlled by them. Because the system fails to invalidate the pending verification token tied to the original identifier and old email context, the user can then submit the VerifyEmail request using that stale token. The application processes this request successfully, setting the emailsVerified flag to true for the newly assigned email address. This effectively allows an attacker to claim ownership of a verified status on an account they do not originally own, provided the target address is not already associated with another Pocket ID user and the default configuration settings remain active, specifically where emailsVerified defaults to false and allowOwnAccountEdit is enabled.
The operational impact of this vulnerability extends beyond the identity provider itself into the broader ecosystem of relying applications that depend on Pocket ID for authentication and user provisioning. Many enterprise or consumer services utilize email addresses as a primary key for automatic account matching or linking existing local accounts with federated identities. If such an application trusts the verified_email claim from the OIDC token without additional cross-referencing, it may incorrectly associate the attacker's session with another user's profile based on the manipulated email attribute. This can lead to unauthorized access to sensitive data, privilege escalation within the relying party's system, or corruption of user-specific records. However, applications that rely exclusively on the stable OIDC subject claim (sub) for identity resolution remain unaffected by this specific downstream consequence, as the sub identifier remains constant regardless of email changes and is not susceptible to this token binding flaw.
To mitigate this vulnerability, organizations running affected versions must immediately upgrade Pocket ID to version 2.12.0 or later, where the logic has been corrected to ensure that verification tokens are strictly bound to specific email addresses and invalidated upon account modification. For environments unable to patch immediately due to dependency constraints, administrators should consider disabling the allowOwnAccountEdit feature if business requirements permit, thereby preventing users from changing their registered email addresses without undergoing a full re-verification process involving new token generation. Additionally, relying parties should implement defense-in-depth strategies by validating that the email address presented in the OIDC ID Token matches any previously established association for that user or requiring multi-factor authentication before performing sensitive account linking operations. This vulnerability is categorized under CWE-284 Improper Access Control and aligns with MITRE ATT&CK techniques related to Account Manipulation, specifically T1098.003 which involves SSH Authorized Key Modification, though in this context it applies more broadly to identity attribute manipulation within federated systems.