CVE-2026-62662 · Package
NO FIX YET · SEE WHAT TO DO
Pocket ID, an OIDC login provider, copies a client-chosen resource value into the audience claim of access tokens it signs, without checking it. Any authenticated OIDC client can obtain a Pocket ID-signed token addressed to another client or arbitrary audience, which can be used to access services that trust those tokens.
first public Jul 13, 2026 · 1 source
Check it with your coding agent
It checks your repository and tells you if you’re affected, with the fix.
Pocket ID deployments from 1.11.0 before 2.10.0 are exposed, and the impact is real only where downstream resource servers trust Pocket ID access tokens for service-to-service authorization by audience. Deployments that use Pocket ID only for user login, without relying on these tokens to authorize access to other services, have no immediate exploitable impact per the advisory.
Not affected if no-token-based-resource-authorization, version-2.10.0-or-later
Who cares oidc, pocket-id, self-hosted, service-to-service
1.11.0 up to but not including 2.10.0.aud claim checks)./api/oidc/introspect endpoint is used to decide token activity.2.10.0.Pocket ID is an OIDC provider that allows users to authenticate with their passkeys to services. From 1.11.0 until 2.10.0, createTokenFromClientCredentials in backend/internal/service/oidc_service.go accepts the client-controlled resource parameter and embeds it directly in the access token aud claim without validating that the audience is registered or that the requesting client may access it. Any authenticated OIDC client can therefore obtain a Pocket ID-signed token naming another client or an arbitrary audience. The /api/oidc/introspect endpoint cannot distinguish the unauthorized token because it treats a token as active when the introspecting client's identifier matches the attacker-selected audience. In deployments where resource servers trust Pocket ID access tokens for service-to-service authorization, this bypasses audience-based access controls and can permit unauthorized data access or actions; deployments that do not use these tokens for resource-server authorization have no immediate exploitable impact. This issue is fixed in version 2.10.0.
Are you affected?
Tell InfraStack what you run. It checks this one, and every next one, against your stack.
Ask from here. InfraStack checks the affected versions against your stack and answers in your inbox.
InfraStack checks the affected versions against your stack and answers in Slack, with the evidence and the fix.
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.