WAF Bypass: How a URL Path Trick Got Researchers Past the Firewall to Two Automakers' ForgeRock Admin Console, and How to Test Your Own

Researchers have published how they got past a web application firewall (WAF) protecting two automakers' login servers, just by writing a web address in an unusual way. The firewall blocked the admin pages it was told to block, but the server behind it read the same address differently. That gap let them reach an admin console that should never have been reachable from the internet, and any business that hides admin pages behind firewall rules can have the same blind spot.

We covered the default password and the car access side of this research in ForgeRock Default Password: admin:admin Let Researchers Into Two Automakers' Login Systems. This post covers the step before that: why the firewall did not stop them, and how to check whether your own WAF or reverse proxy has the same gap.

What happened, in short

Security researchers Shubham Shah and Sam Curry published their write-up on November 7, 2026. It describes two automakers, left unnamed at the automakers' request, whose customer logins ran on ForgeRock Access Management and ForgeRock Identity Management (OpenIDM). Admin paths such as /system/console and /openidm/managed/user were blocked at the edge. The researchers write that repeated attempts "caused our IP to be denied on those administrative paths."

So on paper, the edge was doing its job. The problem was deciding which requests counted as the same path.

How the WAF bypass worked

The researchers concluded that "the edge was matching dangerous path patterns before the Java application finished interpreting them." They then tested addresses that the edge and the Java server would read differently:

• /static%2f..%2fopenidm/info/ping was refused with a 403 from an AWS load balancer.
• /static%2f..;/openidm/info/ping got past the edge and reached the application, which answered 401 (login required).
• /static%2f..;/system%2fconsole;/bundles/.json reached the Apache Felix Web Console.

Three tricks work together here. %2f is an encoded forward slash. .. means go up one folder. A semicolon adds a path parameter, which many Java servers strip out. To the edge, the address started with /static, so it looked like a request for a harmless file. The Jetty server behind it decoded the slashes, dropped the semicolon parts and resolved the .., which turned the address into /system/console/bundles/.json. The console then answered the request.

This kind of problem is usually called path confusion or a URL normalization mismatch. Two systems in a chain disagree about what an address means, and the security check runs in the one that reads it wrong.

What is confirmed and what is not

Confirmed by the researchers' write-up:

• The WAF bypass, the exact paths above, and the 403 and 401 responses.
• The Felix console was reachable. It was running Felix 7.0.1 and listed 361 bundles.
• From there, the chain led to code execution on production identity servers and to remote vehicle commands, as described in our earlier post.
• Both automakers fixed the chain about two hours after the report and rotated the affected credentials.
• The full chain was tested only with US accounts and vehicles, although the systems served customers in multiple regions.

Confirmed by the vendor's documentation: The IDM security guide, now published by Ping Identity as PingIDM, says: "Before you deploy IDM in production, remove or protect development and debug tools." It also says that authentication for the Felix console "is not integrated with authentication for IDM," and its sample configuration sets the console username and password to admin by default.

Not known:

• Which automakers were involved, and which ForgeRock versions they ran.
• Which WAF product sat at the edge. The write-up names only an AWS load balancer.
• Whether anyone else found this route before the researchers did. Neither source lists a CVE. The write-up describes a deployment problem, not a published flaw in ForgeRock's code.

Why this matters for a business website or network

Most businesses put something in front of their web apps: a WAF, a cloud load balancer, a CDN rule, or a reverse proxy with a list of blocked paths. That layer is useful. But a block list at the edge only works if the edge reads every address exactly the way the application behind it does. Encoded characters, double encoding, dot segments and semicolons are where the two often disagree.

The deeper problem is that the console had only two protections: an edge rule and a default password. Once the rule was bypassed, the default password was all that was left. Any admin page that can be reached from the internet, even behind a WAF, is one parsing quirk away from being exposed.

This goes well beyond identity servers and cars. It applies to customer portals, online store back ends, internal dashboards and Java app servers with management consoles. If an admin page is protected only because the firewall blocks its address, treat that protection as unproven until someone tests it.

What to do this week

If your edge or proxy can reject encoded slashes and semicolons in paths that never need them, ask whether that setting is on. Refusing odd addresses outright is safer than guessing how the server behind will read them.

For how admin access fits into a wider plan, see security hardening. If you run your own servers, see self-hosting infrastructure.

WAF bypass questions people are asking

What is a WAF bypass?

A WAF bypass is any request that reaches the application without being stopped by the rules a web application firewall is meant to enforce. In this case, the researchers wrote the address in a form the firewall did not recognize but the server did.

What is path confusion or URL normalization?

Normalization is how a server cleans up an address before using it: decoding characters, resolving .. and dropping extras like semicolon parameters. Path confusion happens when two systems clean up the same address differently.

Was this a ForgeRock vulnerability?

Neither the researchers' write-up nor the news coverage lists a CVE. The write-up describes a deployment problem: an exposed debug console with a default password, behind an edge rule that could be bypassed. The vendor's guide already says to remove or protect that console in production.

Is it fixed?

Yes. According to the researchers, both automakers fixed it about two hours after the report and rotated the affected credentials.

Does my WAF protect my admin pages?

It helps, but do not rely on it alone. Keep admin pages off the public internet and require a real login in the application itself.

Which automakers were affected?

The researchers did not name them, at the automakers' request.

The bigger lesson

A firewall rule is a filter, not a lock. The researchers did not break the WAF. They wrote an address that the WAF read one way and the server read another. Anything sensitive should either be unreachable from the internet or protected by the application itself, with no default passwords. Then a missed rule is an inconvenience, not a breach.

See how we harden sites and servers at security hardening, or get a quote for a review of yours.

Get security alerts by email, with the free checklist, at security alerts.

Sources: Shubham Shah and Sam Curry, Hacking Two Automakers: ForgeRock Path Confusion, RCE, and Remote Vehicle Access; Ping Identity, Remove or protect development and debug tools.