SURIQ
Quarkus shipped emergency releases on June 17 to close its second authorization bypass in about six weeks, and the repeat is the real story. In May the framework patched a flaw where a bare semicolon in a URL let a request walk past path-based access rules (CVE-2026-39852). The new one, CVE-2026-50559, does the same trick with the URL-encoded versions of those characters. If you protect Quarkus routes or static files by their path, an unauthenticated request can now reach them, and the patch you applied in May does not stop it.
Upgrade today. Quarkus released fixes across every supported stream: 3.20.6.2, 3.27.4.1, 3.27.5, 3.33.2.1, 3.33.3, 3.36.3, and 3.37.0. The fastest path is to update the Quarkus command-line tool and run quarkus update. Red Hat ships the fix as Red Hat build of Quarkus 3.20.6.SP2.
What CVE-2026-50559 actually does
Quarkus lets you guard endpoints by URL path, for example a rule that says everything under /api/admin requires a role. The bug is that two parts of the framework disagree about what the path in a request really is. The security check reads one version of the path; the router and the static-file handler read another. An attacker lives in that gap.
There are two ways in. The first abuses a matrix parameter, the part of a URL that follows a semicolon (as in /page;key=value). An encoded semicolon, written %3B, slips past the security check because the check only looks for a plain ;. The router then decodes it and still sends the request to the protected method. A call to /api/admin%3Banything can clear a policy meant for /api/admin while landing on the real handler.
The second way targets static files. The handler that serves files fully decodes percent-encoded characters, while the security layer only partially decodes them. Encoded slashes (%2F) and backslashes (%5C) let an attacker describe a path the security layer never recognizes as protected, then have the file server resolve it back to the real, guarded resource. The result is unauthorized read access and information disclosure.
Why the May patch missed it
This is the part worth sitting with. CVE-2026-39852, fixed on May 4, removed the literal semicolon. It did nothing about %3B, and nothing about encoded slashes at all. The root cause, per Quarkus's advisory, is that the routine meant to strip matrix parameters searches for a plain ; and never sees the encoded form. So the first fix closed one spelling of the attack and left the others wide open.
Path-normalization bugs reward this kind of one-character patching with a steady supply of sequels. When your authorization filter and your router do not agree on a single canonical form of the path, every encoding becomes a fresh bypass: the literal character, the percent-encoded character, double encoding, mixed case, overlong forms. Fixing them one glyph at a time is a losing trade. The durable fix is architectural: decode and normalize the path once, to a single canonical form, before either the security layer or the router is allowed to read it. Until that happens, assume more of these are coming.
The static-file vector is the sleeper
Most teams reason hard about who can call their interfaces and forget that the same path policies often guard served files. Build artifacts, internal dashboards, exported config, and backup blobs all tend to sit behind a path rule rather than a code-level check. An information-disclosure rating sounds mild right up until the file it exposes is a configuration dump with a database password in it.
One detail softens the blow. The encoded slash and backslash vectors do not defeat annotation-based security such as @RolesAllowed on a method. If your sensitive endpoints are protected in code rather than only by a path rule, those keep holding. That is also the lesson: defense that rides on the URL string is fragile, because the URL string is exactly what an attacker controls and what every layer parses a little differently.
What to do now
- Patch. Move to the fixed release in your stream, or run
quarkus update. Do not assume the May update covered you, because it did not. - Hunt your access logs. Look for requests whose path contains
%3B,%2F,%5C, or a stray literal;aimed at admin or static paths, especially any that returned a 200. That pattern against a route that should demand a login is worth a closer look. - Re-test your path rules. For every path-based policy, replay the protected request with an encoded semicolon and an encoded slash appended, then confirm it is now refused.
- Move what matters into code. Where a route truly must not be reached without a role, back the path rule with an annotation-based check so a normalization slip cannot quietly open it.
CVE-2026-50559 carries a CVSS score of 7.5, all of it confidentiality, with no integrity or availability impact. Read-only does not mean low stakes here. An unauthenticated read against an admin route or a protected file is precisely how credentials and internal data leak in the first place. We have watched the same path-confusion pattern surface in unauthenticated Joomla compromises, in pre-auth Splunk exposure, and in token bypasses like the Perry JWT expiry flaw. The framework changes. The gap between what one layer checks and what another executes does not.