CVE-2026-41852

What it actually does

The flaw allows Spring Expression Language (SpEL) expressions to invoke arbitrary zero-argument methods even when the expression is evaluated in a restricted or read-only context. Exploitation requires an application-specific path where attacker-controlled input is evaluated as SpEL and where useful no-argument methods are reachable from the evaluation context. The direct impact is unintended method execution within the application’s existing privileges, which may trigger side effects such as state changes, cache or session manipulation, workflow actions, or availability-impacting behavior, depending on the exposed object graph.

Why it matters to the business

Organizations using affected Spring Framework versions may have applications where user-supplied expressions can trigger unintended business logic. The practical risk is application-specific and currently appears low based on the low EPSS score, lack of known public exploit maturity, and no KEV listing, but internet-exposed applications that evaluate user-controlled SpEL should still be reviewed because exploitation could disrupt application behavior or trigger unauthorized operations.

How an attack unfolds

An attacker first identifies an application endpoint, template, rule engine, search/filter feature, configuration interface, or data-binding path that causes user-controlled content to be evaluated as a SpEL expression. The attacker then crafts expressions that reference objects available in the evaluation context and attempts to call zero-argument methods using syntax such as methodName(). In vulnerable Spring Framework versions, those method calls may be permitted even when the application intended the expression context to be read-only or restricted. If a reachable no-argument method performs useful side effects, the attacker can repeatedly invoke it to trigger unintended application behavior. Exploitation is highly dependent on the application’s exposed SpEL sink, reachable objects, and available methods, which is why the attack complexity is high and generic exploitation is unlikely without application-specific knowledge.

How to fix it

Upgrade Spring Framework to a version outside the affected ranges: 7.0.0 through 7.0.7, 6.2.0 through 6.2.18, 6.1.0 through 6.1.27, and 5.3.0 through 5.3.48. If exact fixed versions are not yet standardized in package inventories, track VMware/Spring advisories and move to the first patched release newer than the affected branch in use. As defense in depth, avoid evaluating user-controlled input as SpEL, use SimpleEvaluationContext where appropriate, explicitly restrict accessible types/properties/methods, remove application objects with side-effecting methods from expression contexts, and add server-side allowlists for any expression features that must remain user-configurable.

How to confirm the fix worked

Inventory applications and dependencies to identify Spring Framework versions in the affected ranges, including transitive dependencies pulled by Spring Boot or other frameworks. Confirm the deployed artifact uses a patched Spring Framework version by inspecting dependency lockfiles, SBOMs, Maven/Gradle dependency trees, container image package metadata, and runtime library versions. Test known SpEL-consuming features with a safe zero-argument method call in a non-production environment to verify that restricted or read-only contexts do not permit unintended method invocation. Review application code for SpEL parsers, EvaluationContext usage, custom property accessors, method resolvers, and any endpoint that passes request-controlled data into SpEL evaluation.

Typical attack path

1. Find a Spring-based application feature that accepts user-controllable input later evaluated as SpEL.
2. Probe the input with benign SpEL syntax to confirm expression evaluation behavior.
3. Enumerate or infer objects and properties available in the SpEL evaluation context.
4. Craft expressions that invoke reachable zero-argument methods despite read-only or restricted evaluation settings.
5. Trigger no-argument methods that cause side effects, such as clearing state, starting or stopping workflows, invalidating data, or disrupting service behavior.
6. Repeat or automate requests if the invoked method produces an availability or operational impact.

How to detect it

There are no universal indicators of exploitation because successful abuse depends on the application-specific SpEL sink and the objects exposed to it. Review web access logs, API gateway logs, WAF events, application logs, and error traces for user-supplied values containing SpEL expression syntax and zero-argument method calls, especially repeated probes against parameters used by search, filtering, rules, workflow, template, or configuration features. Look for Spring Expression Language parsing or evaluation exceptions near suspicious requests, unexpected no-argument method execution, abnormal workflow transitions, unexpected cache/session invalidation, or unexplained service disruption. Since there are no known public exploits, KEV listing, ransomware association, or named threat actors in the provided intelligence, treat matches as leads requiring application-context validation rather than definitive compromise evidence.

• #{
• ${
• T(
• ()
• org.springframework.expression.spel.SpelEvaluationException
• org.springframework.expression.ExpressionParser
• org.springframework.expression.spel.standard.SpelExpressionParser
• org.springframework.expression.spel.support.StandardEvaluationContext
• org.springframework.expression.spel.support.SimpleEvaluationContext
• org.springframework.expression.spel.ast.MethodReference
• org.springframework.expression.spel.support.ReflectiveMethodExecutor
• EL1004E: Method call

What your security team should do

• Prioritize inventory of internet-facing and externally reachable Spring applications that evaluate user-supplied expressions, rules, filters, templates, or configuration values.
• Upgrade affected Spring Framework deployments to patched versions as soon as available for the deployed release line.
• For applications that cannot be upgraded immediately, disable or tightly restrict user-controlled SpEL evaluation and remove side-effecting objects from expression contexts.
• Ask development teams to review SpEL usage for StandardEvaluationContext, custom MethodResolver implementations, and any read-only assumptions around expression evaluation.
• Add logging around expression evaluation failures and suspicious expression syntax in request parameters, headers, bodies, and configuration inputs.
• Monitor vendor advisories for exact fixed release numbers and update dependency constraints to prevent reintroduction of affected versions.
• Because this is not currently KEV-listed and EPSS is low and flat, handle as a targeted hardening issue unless the application exposes SpEL evaluation to untrusted users.