CVE-2023-34034 is an authorization bypass in Spring Security for reactive (WebFlux) applications, caused by a mismatch in how Spring Security and Spring WebFlux interpret the ** wildcard pattern — an attacker can craft a URL that Spring Security thinks it is protecting but WebFlux routes somewhere else. The result is that requests you believe require authentication can reach protected handlers without it. Spring rated the underlying flaw high severity, and NVD scored it 9.8.
If you run reactive Spring services and configured any security rule with a double-wildcard pattern, this one is worth understanding precisely, because the fix is a version bump but the risk is silent — nothing crashes, requests just quietly bypass your rules.
What actually goes wrong
Spring has two pattern-matching engines. Spring Security decides which requests a rule applies to, and Spring WebFlux decides which handler serves a request. Both understand Ant-style patterns like /admin/**. The problem in CVE-2023-34034 is that when the ** wildcard is not prefixed with a leading path segment — used in an unusual, un-prefixed way — the two engines disagree about which URLs match.
When the security engine's match set and the routing engine's match set diverge, you get a gap: a URL that WebFlux happily routes to a protected handler, but that Spring Security's pattern did not recognize as belonging to the protected rule. Because Security did not match it, the authorization check that should have fired never did. The request lands on your protected endpoint unauthenticated.
The critical detail is that this is not a bug in your rule syntax — it is a genuine mismatch between two components that were supposed to agree on what a pattern means.
Am I affected?
The vulnerable ranges are:
- Spring Security 5.6.0 through 5.6.11
- Spring Security 5.7.0 through 5.7.9
- Spring Security 5.8.0 through 5.8.4
- Spring Security 6.0.0 through 6.0.4
- Spring Security 6.1.0 through 6.1.1
You are only exposed if all of these are true: you use Spring WebFlux (the reactive stack, not the servlet MVC stack), you use Spring Security's WebFlux integration, and your security configuration uses ** as a pattern. Servlet-based Spring MVC applications are not affected by this specific issue.
Because the exposure hinges on your own configuration, do not assume you are clear just because you never wrote /admin/** yourself. Framework defaults and copied security config from tutorials frequently include double-wildcard patterns. Grep your security configuration:
# Find double-wildcard usage in reactive security config
grep -rn '"\*\*"\|pathMatchers.*\*\*\|/\*\*' \
--include=*.java --include=*.kt src/main
The fix
Upgrade Spring Security to a patched release. The fixed versions are:
- 5.6.12 or later
- 5.7.10 or later
- 5.8.5 or later
- 6.0.5 or later
- 6.1.2 or later
There is an important dependency: the fixed Spring Security releases require correspondingly patched Spring Framework versions — 5.2.25+, 5.3.29+, or 6.0.11+ depending on your line. Bumping Spring Security without also bringing Spring Framework up to a compatible version can leave you with an incomplete fix or a runtime mismatch. Update them together.
<!-- Maven: bump both, together -->
<dependency>
<groupId>org.springframework.security</groupId>
<artifactId>spring-security-web</artifactId>
<version>6.1.2</version>
</dependency>
After upgrading, run your integration tests against the security-sensitive routes. The whole point of this class of bug is that it does not throw an error, so a passing build does not prove the bypass is closed — you need a test that asserts an unauthenticated request to a protected reactive endpoint gets rejected.
Interim mitigation if you cannot upgrade immediately
If a version bump is blocked by a release freeze, you can reduce exposure by rewriting security matchers to avoid the ambiguous un-prefixed ** construction and use more explicit path patterns. This is a stopgap, not a fix — the underlying mismatch remains and edge cases are easy to miss. Prioritize the upgrade.
Why version-matching tools flag this transitively
CVE-2023-34034 is a good example of why manual dependency tracking fails. Spring Security is rarely a direct dependency you pin by hand — it arrives through spring-boot-starter-security, which pins it for you, often several layers down. A developer looking at pom.xml may not even see a Spring Security version number.
This is precisely the case that software composition analysis handles. An SCA tool resolves the full dependency tree, finds the exact Spring Security version your build actually uses, and matches it against the vulnerable ranges — including when it is pulled in transitively by a starter. A platform such as Safeguard can also tell you which of your services carry the vulnerable version so you are not upgrading blind across a fleet. If you want the general mechanics, our dependency scanner guide covers how that matching works.
FAQ
Is CVE-2023-34034 remotely exploitable without authentication?
Yes — that is the entire point of the vulnerability. It allows an unauthenticated attacker to reach endpoints your security configuration was supposed to protect, by exploiting the pattern-matching mismatch. NVD scored it CVSS 9.8, reflecting network attack vector and no privileges required.
Does this affect Spring MVC (servlet) applications?
No. CVE-2023-34034 is specific to Spring WebFlux, the reactive stack. Servlet-based Spring MVC applications use a different matching path and are not affected by this particular CVE, though they should of course stay patched for other issues.
Do I have to upgrade Spring Framework too, or just Spring Security?
Both. The patched Spring Security releases depend on patched Spring Framework versions (5.2.25+, 5.3.29+, or 6.0.11+). Upgrade them as a pair; a Spring Security bump alone may not fully resolve the issue and can cause version-compatibility problems.
How do I know if my double-wildcard usage is actually vulnerable?
The safest assumption is that any ** pattern in a WebFlux security configuration on an affected version is at risk. Rather than reasoning about each pattern, upgrade to a fixed version and add an integration test that confirms unauthenticated requests to protected reactive routes are rejected.