CVE-2026-41851

What it actually does

This vulnerability affects applications that evaluate user-supplied Spring Expression Language (SpEL) expressions using affected Spring Framework versions. By submitting many crafted, unique expressions, an unauthenticated network attacker can cause unbounded internal cache growth during expression evaluation. The result is increasing memory consumption, excessive garbage collection, degraded application responsiveness, and potentially process termination from Java heap exhaustion. The flaw impacts availability only; it does not directly provide confidentiality or integrity compromise.

Why it matters to the business

A vulnerable application can be made slow or unavailable by remote requests if it exposes functionality that evaluates user-controlled SpEL expressions. This can disrupt customer-facing services, APIs, background processing, and dependent business workflows. The issue is not currently listed in CISA KEV, has low and stable EPSS, and has no known public exploit maturity in the provided data, but it has been public for 64 days and affects widely used Spring Framework release lines, so remediation should be included in normal patch cycles and prioritized for internet-facing systems.

How an attack unfolds

An attacker first identifies an application endpoint or feature that accepts input later interpreted as a SpEL expression, such as dynamic rules, filters, templates, conditions, or configurable expressions. The attacker then repeatedly submits many distinct expressions that are syntactically valid enough to trigger SpEL evaluation. In affected Spring Framework versions, evaluating these unique expressions can populate internal caches without an effective bound. As requests continue, memory use grows, garbage collection becomes more frequent, response times increase, and the Java process may eventually throw out-of-memory errors or be restarted by the platform. Because the vulnerability requires the application to evaluate user-supplied SpEL, Spring-based applications that do not expose such behavior are not directly exploitable through this issue.

How to fix it

Upgrade Spring Framework to a vendor-fixed release outside the affected ranges. The affected ranges are 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 patched versions are not yet defined in internal package metadata, track the official Spring advisory and move to the next patched release for the active supported branch as soon as available. In addition, avoid evaluating raw user-supplied SpEL expressions. Where expression support is required, restrict accepted syntax, use allowlists, impose request size and rate limits, require authentication and authorization, isolate expression evaluation, and monitor memory usage. For end-of-life or unsupported branches, migrate to a supported Spring Framework line rather than relying on compensating controls alone.

How to confirm the fix worked

Confirm dependency versions using build manifests, software composition analysis, container image scans, and runtime classpath inspection. Verify that no deployed application uses Spring Framework versions in the affected ranges. Review application code and configuration for SpEL parsers, expression evaluators, dynamic rule engines, template evaluation, or user-controlled fields passed into SpEL APIs. In staging, test representative expression-heavy requests and confirm heap usage, garbage collection, and SpEL-related cache behavior remain bounded after upgrading. For exposed endpoints, confirm input validation, authentication, rate limiting, and monitoring are in place. Re-scan artifacts after rebuild and redeployment to ensure vulnerable Spring Framework libraries are no longer present.

Typical attack path

1. Identify a Spring-based application endpoint that accepts user-controlled expression-like input.
2. Confirm that submitted input is evaluated as Spring Expression Language rather than treated as plain text.
3. Generate a high volume of unique SpEL expressions to maximize cache growth.
4. Send the expressions repeatedly over the network, potentially without authentication if the affected endpoint is public.
5. Cause JVM heap growth, elevated garbage collection, application latency, failed requests, or process crashes.
6. Repeat traffic after restarts to sustain a denial-of-service condition.

How to detect it

Look for evidence of availability-focused exploitation rather than data theft. Review web server, reverse proxy, WAF, and application logs for bursts of requests containing SpEL-like syntax, especially many unique values in the same parameter or request body field from one source or a small set of sources. Useful patterns include '#{', '${', 'T(', 'new ', method calls, projections, selections, and complex nested expressions in user-controlled parameters. Correlate suspicious requests with JVM telemetry showing rapid heap growth, increased garbage collection pause time, high allocation rates, HTTP 5xx responses, pod/container restarts, or Java out-of-memory events. Review application logs and APM traces for SpEL parse or evaluation exceptions occurring in high volume. Because no specific public exploit or threat actor is identified in the provided data, detection should focus on behavioral indicators: high-cardinality expression input followed by memory pressure and service degradation.

• #{
• ${
• T(
• new
• .?[
• .![
• SpelEvaluationException
• SpelParseException
• org.springframework.expression
• org.springframework.expression.spel
• java.lang.OutOfMemoryError: Java heap space
• java.lang.OutOfMemoryError: GC overhead limit exceeded
• GC overhead limit exceeded
• OutOfMemoryError
• SpEL

What your security team should do

• Inventory all applications and services using Spring Framework, prioritizing internet-facing APIs and systems that process dynamic expressions, rules, filters, templates, or user-defined conditions.
• Upgrade affected Spring Framework versions to patched releases outside 7.0.0-7.0.7, 6.2.0-6.2.18, 6.1.0-6.1.27, and 5.3.0-5.3.48.
• Ask application teams to identify any feature that evaluates user-supplied SpEL and remove, restrict, or strongly validate that capability.
• Apply compensating controls for exposed endpoints, including authentication, rate limiting, request body limits, WAF rules for suspicious expression syntax, and JVM memory/GC alerting.
• Review historical logs and monitoring data for unexplained spikes in unique expression-like request parameters, heap usage, garbage collection, out-of-memory errors, or application restarts.
• Add dependency checks to CI/CD pipelines so vulnerable Spring Framework versions cannot be reintroduced.
• Because this issue is not in KEV and EPSS is low and stable, handle it as a prioritized availability-risk patch rather than an emergency unless critical exposed applications evaluate user-controlled SpEL.