XWiki OIDC Authenticator CVE-2025-49594

Three concrete prerequisites must hold: (1) the XWiki OIDC authenticator contrib extension (maven org.xwiki.contrib.oidc:oidc-authenticator) version >= 2.17.1 and < 2.18.2 must be installed; (2) the instance must be explicitly configured to allow token authentication - this is the decisive non-default gating condition stated in the advisory, and disabling token access is the sole workaround; and (3) the attacker must have VIEW access to the target user's profile, which per the advisory is commonly available to any registered user (and in some configurations to guests). The decisive limiting factor is the token-authentication setting: without it enabled, the token can be created but cannot be used to authenticate. Impact scales to full administrator takeover when an admin profile is viewable.

Signals conflict in an instructive way. The vendor CVSS 4.0 score of 9.2 (Critical) reflects the worst case - network vector (AV:N), low complexity (AC:L), no privileges in the vector (PR:N), and full High impact to confidentiality, integrity, and availability (VC:H/VI:H/VA:H) because a successful attack yields authentication as ANY user, including administrators (full account takeover). However, two attenuating signals are present: (1) the 4.0 vector itself carries AT:P (Attack Requirements: Present), encoding that exploitation depends on the instance being configured to allow token authentication - a non-default precondition; and (2) exploitation-likelihood telemetry is low - EPSS is 0.44% (36th percentile), there is no CISA KEV listing, and no public exploit code was identified in the provided references (the two Vicarius posts are detection/mitigation guidance, not weaponized PoCs). The description also qualifies the PR:N claim: an attacker needs VIEW access to the target profile, which is 'very commonly viewable, at least to other registered users' - implying realistic exploitation usually requires a low-privilege account rather than pure anonymity. Net assessment: this is a genuinely high-impact authorization flaw (impersonation to admin) but its real-world priority is gated by a non-default configuration (token auth enabled) and typically by holding a registered account, and there is no evidence of active or widespread exploitation. Treat as HIGH priority for XWiki instances that have token authentication enabled; materially lower priority where token auth is disabled.

On an XWiki instance running the OIDC authenticator (2.17.1-2.18.1) with token authentication enabled, a logged-in low-privilege user browses to an administrator's user profile - which registered users can normally view - and uses the exposed token-management function to mint an OIDC token for that administrator. They then authenticate with that token and operate as the administrator. No public exploit code was identified at time of analysis, but the flaw is conceptually simple and the fixing commit reveals the exact missing authorization check.