Pocket ID Flaw Lets Users Verify Emails They Never Own, Enabling Account-Linking Takeover

A newly published GitHub Security Advisory (GHSA-rm8c-2cv8-jwf6, CVE-2026-115770, CVSS 9.6) describes a logic flaw in Pocket ID, an OIDC identity provider, that lets an ordinary authenticated user get an arbitrary, unowned email address marked as verified.

What was reported

According to the advisory, Pocket ID's email-verification tokens are bound only to a user ID, not to the specific email address they were issued for, and changing a user's email does not invalidate outstanding tokens. An attacker can request a verification token while their account email is one they control, change the account's email to a victim's address, and then redeem the old token. Pocket ID marks the new (unverified) address as verified and subsequently emits it in OIDC claims with email_verified: true. The report includes a reproduction via the API and an executable Go regression test validated against a specific commit, with no admin privilege or victim interaction required. A public proof of concept is noted (exploit status: poc-public).

Why it matters for defenders

This is an authentication-integrity failure in an identity provider, not just the application itself. Per the advisory, the real-world impact depends on downstream relying parties: any service that trusts Pocket ID's email_verified claim to auto-link or provision accounts by email address could have an attacker's Pocket ID identity linked to a victim's existing account, resulting in account takeover and exposure of whatever that account can access. Relying parties that key solely off the stable OIDC sub claim are described as unaffected by this downstream risk. Any organization self-hosting Pocket ID as an SSO/OIDC provider should treat this as high priority given the 9.6 CVSS and public PoC.

What defenders should watch for or do now

• Identify whether Pocket ID is deployed in your environment and whether any relying applications link or provision accounts based on verified email rather than the OIDC sub claim.
• Review Pocket ID update/patch guidance from the maintainers and apply fixes as they become available; the advisory outlines remediation directions including binding verification tokens to the target address and invalidating tokens on email change.
• As a hunting angle, review audit/application logs for accounts that changed their email address shortly before an email-verification event, or for verification tokens redeemed against an address different from the one they were originally sent to.
• Where feasible, treat email-based account linking from any OIDC provider as a lower-trust signal until confirmed patched, and prefer the immutable sub claim for identity matching.

Developing situation

This is fresh, net-new intelligence published the same day as this post, based solely on the GitHub Security Advisory. Details on vendor patch availability and real-world exploitation are not yet confirmed here — consult the original advisory for updates: GHSA-rm8c-2cv8-jwf6.