CVE-2026-41848

Overview

Spring Framework is the foundational application framework for the Java platform, providing core support for dependency injection, web applications, data access, and a large library of general-purpose utilities used throughout the Spring ecosystem. One of those utilities is org.springframework.util.AntPathMatcher, an Ant-style path pattern matcher in the spring-core module that compiles glob-and-template patterns into Java regular expressions and matches request paths and other strings against them.

A low-severity vulnerability (CVE-2026-41848) has been identified in AntPathMatcher. An application may be vulnerable to a Regular Expression Denial of Service (ReDoS) attack if an attacker is able to provide a pattern that is then directly or indirectly supplied to one of the methods match(String pattern, String path), matchStart(String pattern, String path), or extractUriTemplateVariables(String pattern, String path). The abused input is the pattern argument, not the path being matched, so the risk applies to applications that build Ant patterns out of untrusted input rather than to applications whose patterns are entirely developer-defined.

Per OWASP, a Regular expression Denial of Service (ReDoS) is a Denial of Service attack that exploits the fact that most regular-expression implementations may reach extreme situations that cause them to work very slowly (exponentially related to input size); an attacker can cause a program using a regular expression to enter these extreme situations and then hang for a very long time. In AntPathMatcher, a crafted pattern is compiled into a backtracking java.util.regex.Pattern that can take super-linear time to evaluate against a suitable input, tying up the matching thread.

The CVSS v3.1 base score for this vulnerability is Low with vector AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L. The attack vector is Network because a crafted pattern can arrive over the network in applications that derive patterns from request data, attack complexity is High because the attacker must both craft a pathological pattern and arrange for it to reach one of the affected methods, and no privileges or user interaction are required. The impact is Availability-only and Low (a single matching operation is slowed or hangs); there is no confidentiality or integrity impact because the matcher only evaluates the pattern, it does not expose or modify data.

This issue affects Spring Framework >=4.3.0 <=4.3.30, >=5.3.0 <=5.3.48, >=6.1.0 <=6.1.27, >=6.2.0 <=6.2.18, and >=7.0.0 <=7.0.7.

‍

Details

Module Info

• Product: Spring Framework
• Affected packages: spring-core
• Affected versions: >=4.3.0 <=4.3.30, >=5.3.0 <=5.3.48, >=6.1.0 <=6.1.27, >=6.2.0 <=6.2.18, >=7.0.0 <=7.0.7
• GitHub repository: https://github.com/spring-projects/spring-framework
• Published packages: https://central.sonatype.com/artifact/org.springframework/spring-core
• Package manager: Maven
• Fixed in:
• NES for Spring Framework 4.3.x, 5.3.x, 6.1.x
• Spring Framework 6.2.19, 7.0.8 (OSS)

Vulnerability Info

The vulnerability lives in the AntPathStringMatcher inner class of AntPathMatcher in the spring-core module. When a pattern segment contains a URI template variable with an embedded regular expression, for example a {name:<regex>} token, the matcher splices that caller-supplied regex literally into a larger java.util.regex.Pattern. The glob compiler is driven by a fixed glob pattern that is identical across the affected lines. For a single-character wildcard token the compiler appends a dot, for a multi-character wildcard token it appends a dot-star, and for a bare {name} token it appends the default variable pattern, while a {name:<regex>} token contributes the embedded regex verbatim. Because the resulting Pattern is evaluated by Java's backtracking regex engine, a pattern crafted to induce catastrophic backtracking (for example overlapping quantifiers in the embedded regex or many wildcard segments) can make the match consume CPU for a very long time on a suitable input.

Pre-fix, matchStrings ran the compiled pattern against the raw input string with no bound on how long matching could take:

public boolean matchStrings(String str, @Nullable Map<String, String> uriTemplateVariables) {
    if (this.exactMatch) {
        return this.caseSensitive ? this.rawPattern.equals(str) : this.rawPattern.equalsIgnoreCase(str);
    }
    else if (this.pattern != null) {
        Matcher matcher = this.pattern.matcher(str);
        if (matcher.matches()) {
            // ... populate URI template variables ...
            return true;
        }
    }
    return false;
}

AntPathMatcher is one of the oldest utilities in spring-core and the URI-template-variable compilation path that produces the backtrackable regex has existed across the 3.x, 4.x, 5.x, and 6.x lines. The advisory's listed range starting at 5.3.0 reflects Spring's currently-supported scope; older lines, including the lines covered by NES support, contain the same unbounded matching code and are also affected.

‍

Steps To Reproduce

1. In an application that uses AntPathMatcher, arrange for attacker-controlled input to reach the pattern argument of one of the affected methods. The simplest standalone reproduction calls the matcher directly:

   import org.springframework.util.AntPathMatcher;

   AntPathMatcher matcher = new AntPathMatcher();
   // A pattern crafted to induce catastrophic backtracking in the
   // compiled java.util.regex.Pattern (embedded regex with overlapping
   // quantifiers), supplied as the *pattern* argument:
   String maliciousPattern = "/{x:(a+)+$}";
   String path = "/" + "a".repeat(60) + "!"; // input that forces backtracking
   matcher.match(maliciousPattern, path);

‍
2. Observe that the call to match (or matchStart, or extractUriTemplateVariables) does not return promptly: the compiled regex backtracks for a long time on the supplied input, consuming a CPU core. With enough such requests an attacker can exhaust the application's request-handling threads, producing a denial of service.

3. After upgrading to a fixed version (6.2.19, 7.0.8, or a HeroDevs NES build), repeat the call. Once the regex engine performs more than 1,000,000 character accesses on the input, matching aborts with an IllegalStateException ("Too many character access attempts encountered during pattern matching") instead of hanging.

‍

Mitigation

Only recent versions of Spring Framework receive community support and updates. The 6.1.x and 5.3.x lines are past their open-source support window, so there is no public OSS fix for those lines. Older lines, including 4.3.x, have no publicly available fixes for this vulnerability.

Users of the affected components should apply one of the following mitigations:

• Upgrade to a currently supported version of Spring Framework. The OSS fix ships in Spring Framework 6.2.19 (6.2.x line) and 7.0.8 (7.0.x line).
• As an interim hardening step, avoid constructing AntPathMatcher patterns from untrusted input. Ensure that the pattern arguments passed to match, matchStart, and extractUriTemplateVariables are developer-defined constants rather than values derived from request data.
• Leverage a commercial support partner like HeroDevs for post-EOL security support through Never-Ending Support (NES) for Spring Framework.

‍

Credits

• This issue was discovered internally by the Spring team.