Spring Framework EUVD-2026-67172

Exploitation requires a specific application-side pattern: the target application must (1) evaluate attacker-influenced input as a SpEL expression, (2) do so via SimpleEvaluationContext, and (3) have the SpEL expression compiler active (SpelCompilerMode set to IMMEDIATE or MIXED rather than the default OFF/interpreted). These are the exact conditions named in the advisory ('using SimpleEvaluationContext' and 'when the SpEL expression compiler is active'). Limiting factors: the compiler is not enabled by default, and applications that never route untrusted input into SpEL, or that use the full StandardEvaluationContext knowingly, are outside this specific bypass. The CVSS vector's AC:L/PR:N/UI:N applies only once an application meeting these preconditions exposes the evaluation endpoint remotely.

Signals are mixed and warrant nuance. The CVSS 3.1 base is 9.1 (AV:N/AC:L/PR:N/UI:N, C:N/I:H/A:H) - network, unauthenticated, low complexity - but that score assumes an application already exposes SpEL evaluation of untrusted input via SimpleEvaluationContext with the compiler enabled, which is a specific and non-default coding/configuration pattern rather than an out-of-the-box condition. EPSS is only 0.16% (5th percentile) and there is no KEV listing and no public exploit identified, so no evidence of active or widespread exploitation exists yet. The realistic priority therefore depends heavily on whether your codebase actually evaluates externally influenced SpEL through SimpleEvaluationContext with compilation on; where it does, treat this as critical given the I:H/A:H and unauthenticated network vector, and where it does not, real exposure is low despite the 9.1 headline. Note a mild inconsistency worth verifying with the vendor: CVSS marks C:N while a guard bypass enabling method invocation would typically also risk confidentiality - the low-complexity/no-privilege metrics likely reflect the worst-case app that already feeds untrusted expressions to the engine.

An application evaluates a user-supplied value (for example a query filter, template field, or rule expression) as SpEL using SimpleEvaluationContext, believing it is sandboxed, and has the SpEL compiler enabled for performance. An attacker submits a crafted expression over the network that, under the compiled path, escapes the intended data-binding-only restrictions to invoke unintended methods, corrupting application state or disrupting availability. No public exploit is identified at time of analysis, and success depends on the application already exposing this evaluation pattern.