CVE-2026-41848

What it actually does

This vulnerability is a Regular Expression Denial of Service condition in Spring Framework's AntPathMatcher when attacker-controlled pattern input is passed directly or indirectly to match(String pattern, String path), matchStart(String pattern, String path), or extractUriTemplateVariables(String pattern, String path). A specially crafted pattern can trigger excessive backtracking or otherwise expensive matching behavior, consuming CPU in the Java process and slowing or temporarily degrading request handling. The issue affects Spring Framework 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. Confidentiality and integrity are not directly impacted; the primary technical impact is reduced availability.

Why it matters to the business

Successful exploitation can make affected application endpoints slow, unresponsive, or intermittently unavailable, especially if public interfaces allow users to submit route, path, glob, or template patterns that are later evaluated by Spring's AntPathMatcher. The CVSS score is low and EPSS is currently very low and flat over 30 days, with no known CISA KEV listing or ransomware association, so broad active exploitation is not currently indicated. However, Spring Framework is widely used across Java applications, so organizations should still inventory exposure and patch during the next appropriate maintenance window, prioritizing internet-facing services and systems where users can influence path-matching patterns.

How an attack unfolds

An attacker first identifies an application feature that accepts a pattern-like input, such as a path expression, route selector, template, glob, allowlist rule, or similar user-controlled value. If the application passes that value as the pattern argument to AntPathMatcher.match, matchStart, or extractUriTemplateVariables, the attacker submits a crafted pattern designed to cause computationally expensive matching. The application attempts to process the pattern against a path value, tying up CPU in the Java worker thread. Repeated requests or concurrent submissions can increase CPU saturation, extend response times, exhaust request-handling capacity, and cause partial service degradation. Exploitation does not require authentication in applications exposing such functionality to unauthenticated users, but exploitability is application-specific and depends on attacker control of the pattern input, not merely the path being matched.

How to fix it

Upgrade Spring Framework to a non-affected version for the branch in use. 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; use the vendor advisory and dependency management tooling to move to a release newer than the affected range for the selected supported branch. Where immediate upgrade is not possible, prevent untrusted users from controlling AntPathMatcher pattern arguments, validate and constrain accepted pattern syntax and length, reject nested or complex wildcard constructs, apply request size and rate limits, enforce application-layer timeouts, and consider replacing dynamic AntPathMatcher use with safer fixed mappings or pre-validated allowlists. Also review transitive framework dependencies in Maven or Gradle because Spring Framework may be included indirectly through Spring Boot or other libraries.

How to confirm the fix worked

Confirm all deployed artifacts resolve to Spring Framework versions outside the affected ranges by checking Maven dependency trees, Gradle dependency insight output, software composition analysis results, SBOMs, and packaged JAR manifests. Search code for calls to AntPathMatcher.match, AntPathMatcher.matchStart, and AntPathMatcher.extractUriTemplateVariables, then verify that the pattern argument is not attacker-controlled or is strictly validated. Perform negative testing with oversized or complex pattern inputs against relevant endpoints in a controlled environment and confirm requests are rejected quickly, rate-limited, or processed without abnormal CPU consumption. In production, validate that CPU, request latency, thread pool utilization, and timeout rates remain normal after patching or mitigation.

Typical attack path

1. Identify a Spring-based application or endpoint that accepts user-supplied path, route, glob, template, or pattern input.
2. Test whether submitted pattern values influence server-side matching behavior rather than being treated as plain text.
3. Submit crafted Ant-style path patterns that cause expensive matching behavior in AntPathMatcher.
4. Repeat requests or run concurrent submissions to tie up Java request-processing threads and increase CPU utilization.
5. Observe degraded response times, request timeouts, elevated error rates, or temporary unavailability of affected application functions.

How to detect it

Look for evidence of availability-focused probing or abuse rather than data theft. Relevant sources include web access logs, API gateway logs, WAF events, application logs, Java thread dumps, APM traces, CPU metrics, garbage collection logs, and container or host resource telemetry. Focus on periods with sudden CPU saturation, increased request latency, thread pool exhaustion, or timeouts that correlate with repeated requests carrying unusually long or complex path-pattern values. In thread dumps or profiler output, look for many request threads spending time in Spring AntPathMatcher methods or Java regular expression matching. Search logs for repeated 4xx/5xx responses, 408/429/499/500/502/503/504 spikes, and parameters containing Ant-style wildcards or URI template syntax. There are no public exploit-specific payloads or actor-specific indicators provided, so detection should be behavior-based and correlated with application routes that accept user-supplied patterns.

• org.springframework.util.AntPathMatcher.match
• org.springframework.util.AntPathMatcher.matchStart
• org.springframework.util.AntPathMatcher.extractUriTemplateVariables
• org.springframework.util.AntPathMatcher.doMatch
• org.springframework.util.AntPathMatcher$AntPathStringMatcher.matchStrings
• java.util.regex.Pattern.matcher
• java.util.regex.Matcher.matches
• HTTP 408
• HTTP 429
• HTTP 499
• HTTP 502
• HTTP 503
• HTTP 504
• **/**/**
• {*
• }
• ?pattern=
• pattern=
• pathPattern=
• antPattern=

What your security team should do

• Inventory applications using Spring Framework versions 7.0.0-7.0.7, 6.2.0-6.2.18, 6.1.0-6.1.27, or 5.3.0-5.3.48, including transitive dependencies.
• Prioritize internet-facing and unauthenticated services that allow users to submit path patterns, route expressions, template variables, globs, or matching rules.
• Upgrade to a vendor-supported Spring Framework release outside the affected ranges, using Spring Boot dependency management where applicable.
• Add input validation so untrusted users cannot submit arbitrary Ant-style patterns; restrict length, wildcard count, and allowed characters.
• Apply compensating controls such as rate limiting, request timeouts, WAF rules for abusive repeated pattern submissions, and CPU/thread-pool monitoring until upgrades are complete.
• Review application logs and APM telemetry for unexplained CPU spikes, long-running requests, and repeated requests containing complex path-pattern metacharacters.
• Because the vulnerability is not currently in KEV, has no known exploit maturity, and has very low EPSS, handle as risk-based patching unless local exposure analysis shows attacker-controlled patterns on critical services.