Apache CXF CVE-2026-71575

The relying party MUST configure the OIDC client (OidcClientCodeRequestFilter) with setMaxAgeOffset to enforce an authentication-freshness / max_age policy; without that setting the bug has no effect. The limiting factor is therefore this non-default, opt-in configuration - only CXF-based OIDC relying parties that actively depend on step-up/re-authentication are exposed. There is no attacker-side authentication requirement (PR:N), but exploitation value exists only where a re-authentication policy was expected to protect a sensitive operation, meaning impact is scoped to applications that intended to use max_age in the first place.

The input assigns CVSS 9.1 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N), which treats this as a remote, unauthenticated, low-complexity authentication bypass. However, the signals conflict with that severity. EPSS is very low at 0.23% (12th percentile), there is no CISA KEV listing, and no public exploit was referenced - so this is no public exploit identified at time of analysis, not active exploitation. More importantly, the description establishes that the flaw ONLY manifests for relying parties that explicitly call setMaxAgeOffset to enforce step-up/re-authentication; against default CXF OIDC deployments that do not use max_age there is no exposure. That configuration dependency contradicts the AC:L rating and argues for higher attack complexity, so the real-world priority is lower than the 9.1 headline suggests. This is a genuine security-control failure (silent bypass of a re-authentication policy) but its blast radius is gated by a non-default, opt-in setting - treat it as a targeted correctness/hardening fix rather than a mass-exploitable RCE-class emergency. Verify your own deployment: only CXF-based OIDC relying parties invoking setMaxAgeOffset are affected.

An application uses Apache CXF's OIDC client filter with setMaxAgeOffset to force users to re-authenticate before sensitive actions (step-up auth). Because the max_age freshness check is inoperative, an attacker reusing or riding an old, still-valid authentication session is silently accepted as freshly authenticated, letting them reach protected operations that should have demanded a fresh login. No public exploit code is required - the control simply never fires.