Goobi viewer EUVD-2026-109063

Requires a deployment that has (1) opted into OpenID authentication with at least one configured provider, and (2) shares that IdP/issuer with one or more OTHER relying parties (a multi-RP setup). The attacker must possess a JWT that is signed by the configured IdP, carries the matching iss, and has a SINGLE-STRING aud claim equal to the viewer's client ID but was issued for a different RP. Exploitation is additionally limited by the viewer's per-login nonce and state binding - the replayed token must satisfy the in-flight session nonce - which the vendor states makes the attack narrow in practice. Limiting/fail-safe factors: array-valued aud claims fail closed (not exploitable), and single-RP deployments are described by the vendor as not practically exploitable.

This is a medium-to-high severity authentication bypass (CVSS 7.4) rather than a mass-exploitation emergency. The CVSS vector (AV:N/AC:H/PR:N/UI:N/C:H/I:H/A:N) captures the key tension: it is network-reachable and requires no prior authentication to the viewer (PR:N), but AC:H reflects substantial preconditions. The vendor advisory is explicit that exploitation is narrow - it applies only to opt-in deployments that have configured at least one OpenID provider AND share that IdP/issuer with one or more other relying parties, and the replayed token must additionally satisfy the viewer's in-flight per-login nonce and state binding. No EPSS score, KEV listing, or SSVC automatable/technical-impact breakdown was supplied, so those signals cannot be weighed; the only priority signal provided is the vuln.today 'this_week' decision label, which is consistent with a real but non-emergency, deployment-dependent flaw. Exploitation status: no public exploit identified at time of analysis (the three references are the GHSA advisory, the fix commit, and the v26.05 release - none is a PoC). Authentication requirement per CVSS PR:N is 'unauthenticated' against the viewer, but note the attacker must already possess a valid IdP-signed JWT issued for a different relying party, which is a meaningful real-world constraint not visible in the raw PR:N metric. Net: a genuine account-takeover bug worth patching promptly in multi-RP OpenID deployments, but not a drop-everything issue - single-RP deployments are described by the vendor as not practically exploitable and array-valued aud claims fail closed.

In a deployment where the Goobi viewer shares an OpenID IdP/issuer with other relying parties, an attacker who holds a JWT legitimately issued for a different RP - but whose single-string aud happens to equal the viewer's client ID - replays that token to the viewer's OpenID login flow. Because the verifier does not pin the audience and the manual aud check only compares a single string, the token passes and the attacker is authenticated as the token's sub. No public exploit code exists, and the attack is further constrained by having to satisfy the viewer's in-flight session nonce.