Most recent entries from all

EUVD-2026-361460

2026-10-06T15:44:23.821352+00:00

EUVD-2026-361460

fkie_cve-2026-55834

2026-10-06T15:44:23.821386+00:00

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.

GHSA-2wvm-8mvp-22qv — Pocket-ID has an Open Redirect on the OIDC /authorize page via unvalidated redirect_uri with prompt=none

2026-10-06T15:44:23.821419+00:00

Affected: Go: github.com/pocket-id/pocket-id/backend

### Summary The OIDC authorization page in the pocket-id frontend redirects the browser to an attacker-controlled URL without consulting the backend redirect_uri allow-list when the request uses prompt=none. An attacker who knows a valid client_id can craft an /authorize link that sends a victim (or a victim's browser doing a silent re-auth) to any external https URL, enabling phishing and OAuth response smuggling. The backend allow-list validation that protects the normal authenticated flow is bypassed because this path is handled entirely client-side.

### Details For an OIDC authorization request with prompt=none, the SvelteKit frontend short-circuits the flow before the backend ever validates the redirect_uri against the client's registered callback list.

File: frontend/src/routes/authorize/+page.ts (line 14) parses the raw redirect_uri query parameter from the incoming URL.

File: frontend/src/routes/authorize/+page.svelte - in onMount(), when the request carries prompt=none and the user cannot be silently authorized (for example the visitor is not logged in, so login_required must be returned), the page builds the callback URL from the raw redirect_uri and performs:

window.location.href = `${callbackURL}?error=login_required...`

The callbackURL is taken directly from the user-supplied redirect_uri. The only filtering applied is a scheme check that blocks javascript: and data: URLs; any http: or https: origin passes through. The backend allow-list validator GetCa…