Pocket ID's small web footprint still needs identity inventory
Pocket ID is an OIDC provider built around passkey authentication. CVE-2026-115770 lets an authenticated user reuse an email-verification token after changing the account address. The result can be an email_verified: true claim for an address the user never controlled. Affected versions are 2.2.0 through 2.12.0; version 2.12.0 contains the fix.
Identity providers are often deployed behind a private hostname, an access proxy, or a VPN. A public search may therefore show a small population. That makes exact interpretation important. A low count is a description of the indexed surface, not evidence that the product is absent from the organization.
I ran two count-only ZoomEye queries on November 13, 2026, at about 06:49 China Standard Time. Both used sub_type=all, page 1, and page size 1. The query app="Pocket ID" returned 0 matches. The query title="Pocket ID" returned 3 matches.
The zero app result does not establish that no Pocket ID servers exist. It may mean ZoomEye does not have a fingerprint for this version, the visible page does not expose the expected marker, or the deployment sits behind a proxy. The three title matches are a useful discovery signal with a very small population.
Search internally first
Start with the identity team's application inventory and single sign-on configuration. List every Pocket ID environment, including development, staging, production, and disaster recovery. Record the version, public hostname, upstream proxy, relying parties, and support owner.
Then compare the internal list with external observations. A public match that has no internal owner needs investigation. An internal deployment that has no public match is not necessarily a problem, especially when the design requires private access.
Review relying parties that use the email_verified claim for account linking. The provider patch prevents the tested token reuse path, but applications still need a safe linking policy. A verified address can be one signal; it should not automatically grant access to an existing account with a different provider subject.
Preserve evidence from a small sample
For each public match, record the observed title, URL, response metadata, and collection time. Do not attempt to authenticate to an unrelated system or test account-linking behavior without written authorization. The external observation should remain a lead.
Internally, review email-change events followed by verification and account-linking activity. Force a fresh authentication event after a suspicious change. Confirm the linked subject and the address that was tested. If the relying party has no audit trail for this sequence, add one before the next identity-provider review.
The completion check has two layers. The identity team confirms all Pocket ID deployments are on 2.12.0 or later and recent address changes were reviewed. The application owners confirm that sensitive links require a second binding signal. The small count from ZoomEye is useful because it forces a complete internal inventory instead of offering a false sense of coverage.
Top comments (0)