Every developer wants to secure their endpoints. But what if your favorite security framework makes it easy to get it wrong? That’s what happened with CVE-2023-34034, where a small decision in your WebFlux configuration could open the gates to attackers—without you ever knowing.

What’s Actually Happening?

When configuring Spring Security for a WebFlux application, many developers naturally use double asterisks (<b>) in their security rules. It feels logical; it’s the same as in Spring MVC, right?<br><br>But in WebFlux, under the hood, there’s a subtle but critical disagreement between how Spring Security interprets patterns and how WebFlux understands them.** The end result? URLs that should be protected can end up unguarded.

Let’s look at a typical config

@Bean
public SecurityWebFilterChain springSecurityFilterChain(ServerHttpSecurity http) {
    http
      .authorizeExchange()
        .pathMatchers("/admin/**").authenticated()
        .anyExchange().permitAll()
      .and()
      .httpBasic();
    return http.build();
}

You might think this means any URL under /admin/ (like /admin/panel, /admin/config/x) requires authentication. That’s how it works in Spring MVC.

But in WebFlux, when you request something funky like /admin//something (notice the double slash), or /admin;/config (using path parameters), the two frameworks disagree on whether this matches /admin/</b>.**

How Does the Bypass Work?

An attacker can craft URLs that Spring Security *thinks* don't match /admin/**—but WebFlux *does*. The security check gets skipped. The endpoint runs as if it’s public.

Exploit Example

Suppose you have a web app at https://yourbank.com/admin/config. It should be protected.

Try a weird URL:  
https://yourbank.com/admin//config

Or this:  
https://yourbank.com/admin;/config

If your configuration uses the </b> pattern, and is vulnerable, these odd paths will bypass your security filter. They’ll directly reach your handler.** It becomes possible to access "protected" endpoints without authentication.

Make sure you use Spring WebFlux (not MVC).

2. Check if you have pathMatchers("/admin/**") or similar in your security filter.

Spring Security and WebFlux each have their own URL pattern matching logic.

- When you specify /admin/**, you expect both to treat it the same.

Official References

- NVD CVE-2023-34034 Details
- Spring Security Advisory
- Spring Blog Post

Temporary Mitigation

- Use exact path matchers where possible (.pathMatchers("/admin") instead of "/admin/**").

Here’s a safer way after the fix

@Bean public SecurityWebFilterChain springSecurityFilterChain(ServerHttpSecurity http) { http .authorizeExchange() .pathMatchers("/admin", "/admin/*", "/admin/**").authenticated() .anyExchange().permitAll() .and() .httpBasic(); return http.build(); }

Final Thoughts

This bug is a classic: same pattern, different meaning leads to security bypass. Always read release notes and advisories, especially when your frameworks evolve or support multiple stacks.

If you rely on WebFlux and Spring Security, audit your configs and upgrade immediately!

Avoid ** unless you’re on a patched version.

- Always check for security advisories (Spring Security Feed).

Summary Table

| Config Pattern | Normal Path Protected? | Double Slash Protected? | Semicolon Protected? |
|----------------|-----------------------|------------------------|----------------------|
| /admin/<b> (old) | ✅ | ❌ | ❌ |<br>| /admin/</b> (patched) | ✅ | ✅ | ✅ |
| Exact match | ✅ | ✅ | ✅ |


Don’t let this one slip through the cracks! A double asterisk shouldn’t be a gaping hole. Stay secure, stay updated.


(If you want to dive deeper, check Spring’s Github fix PR for CVE-2023-34034.)

Timeline

Published on: 07/19/2023 15:15:00 UTC
Last modified on: 08/14/2023 19:15:00 UTC