Description

Pocket ID is an OIDC provider that allows users to authenticate with their passkeys to services. From 2.6.0 until 2.9.0, frontend/src/routes/authorize/+page.ts reads the redirect_uri query parameter and frontend/src/routes/authorize/+page.svelte uses the raw callbackURL in redirectWithError when prompt=none cannot complete silent authorization. The client-side path only blocks javascript and data schemes and does not invoke the backend callback allow-list validation, so an unauthenticated attacker who knows a valid client_id can redirect a victim browser to an arbitrary HTTP or HTTPS origin for phishing or OIDC error and state smuggling. This issue is fixed in version 2.9.0.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "4.3",
  "pubDate": "2026-08-28T20:18:30.030Z",
  "pubdate": "2026-08-28T20:18:30.030Z",
  "executiveSummary": "Pocket ID versions 2.6.0 through 2.9.0 contain an Open Redirect vulnerability within the OIDC authorization flow. The vulnerability stems from insufficient validation of the 'redirect_uri' parameter when processing silent authorization failures.\nThis flaw allows an unauthenticated remote attacker to craft malicious URLs that redirect authenticated user sessions to arbitrary HTTP or HTTPS domains. By leveraging this redirection, an attacker can conduct phishing campaigns, facilitate OIDC state smuggling, or deceive users into disclosing sensitive information by masquerading as the trusted OIDC provider.\nThe risk is significant as it bypasses intended authorization allow-lists, effectively turning the authentication server into an open redirector. Exploitation requires only knowledge of a valid 'client_id' and the ability to convince a target to visit a specifically crafted link. This issue was resolved in version 2.9.0 by ensuring proper server-side validation of callback URLs.",
  "technicalDetails": "The vulnerability resides within the frontend OIDC authorization handling logic, specifically in 'frontend/src/routes/authorize/+page.ts' and 'frontend/src/routes/authorize/+page.svelte'. The root cause is the improper handling of the 'redirect_uri' query parameter during the silent authorization process.\nWhen a user triggers an OIDC flow with 'prompt=none' and the silent authorization fails, the application utilizes the 'redirectWithError' function. This function references the 'callbackURL' derived directly from the 'redirect_uri' parameter provided in the initial request. While the client-side implementation attempts to mitigate risks by blocking 'javascript:' and 'data:' URI schemes, it fails to perform a robust validation against a backend-managed allow-list of authorized redirect URIs.\nThe attack flow proceeds as follows: An attacker identifies a valid 'client_id' registered with the Pocket ID instance. The attacker then constructs a malicious OIDC authorization URL, injecting an arbitrary 'redirect_uri' pointing to a domain controlled by the attacker (e.g., 'https://attacker.com'). The attacker lures a victim—who maintains an active session with the Pocket ID provider—to navigate to this crafted URL.\nUpon landing on the authorization page, the system initiates a silent authorization attempt ('prompt=none'). Because this attempt fails, the application routes the user to the 'redirectWithError' logic. Because the client-side component does not invoke backend validation, the 'redirect_uri' is treated as trusted. The browser is subsequently redirected to the attacker-supplied URL, potentially carrying sensitive state information or OIDC error parameters.\nThis exposure enables phishing, as the user is moved from a legitimate OIDC provider to a malicious destination, or state smuggling, where the redirection environment is manipulated to compromise the integrity of the authentication flow. Since this logic resides in the client-side files, it is accessible to any unauthenticated actor capable of reaching the authorization endpoint over the network. The vulnerability impacts all Pocket ID deployments between versions 2.6.0 and 2.9.0 where the frontend is configured to handle the specified authorization routes."
}