Jetty auth bypass CVE-2026-10050: non-ASCII passwords collapse to ?

Jetty, the Java web server, has a flaw that lets a login through without properly checking the password. The Eclipse Foundation disclosed it on August 4, 2026. The tracking number is CVE-2026-10050, rated 8.7 out of 10.

What it affects is accounts whose passwords contain characters outside basic Latin. The vendor advisory names Chinese, Japanese, Cyrillic, Arabic and emoji among the affected sets. If a password is written in any of those, every one of those characters collapses to "?", and a string of nothing but "?" of the same length will log you in.

Before anyone panics, check the condition. This only opens up where Digest authentication is in use, a legacy scheme that very few modern deployments enable. Most people are out of scope. There are no reports of exploitation and no public exploit code.

There is one awkward part if you are in scope. Of the versions the advisory lists as fixed, only the Jetty 12 line is available for free. If you are on 9, 10 or 11, the numbers written in the advisory do not exist in the public repository. Here is the whole thing in order.

What actually happens

Jetty is a server for running Java web applications. Beyond standalone use, it is very frequently embedded inside other software — the Solr search engine, the Spark data platform, the Maven build tool — so plenty of people run it without ever thinking about the name.

The flaw sits in how Jetty converts a password into bytes. It used ISO-8859-1, an old character encoding that can only represent Western European languages. Japanese, Chinese and Cyrillic have no place in it.

When that conversion meets a character it cannot represent, it raises no error and silently substitutes "?". In the advisory's own example, the Greek-containing password αβ123 becomes ??123. A password written in Japanese collapses into a row of question marks entirely.

Here is where it turns into a vulnerability. An attacker does not need to know the real password; they send a string of nothing but "?". On the server side the genuine password has also collapsed into "?" characters, so as long as the length matches, the two are identical. Whatever the original characters were is no longer distinguishable.

Which means the people hit by this are the ones who thought they were being safer by using their own script. Passwords made only of ASCII letters and digits are represented correctly in ISO-8859-1 and are not affected. The precaution is what causes the exposure.

CVE-2026-10050 at a glance

What pushes the score up is that the attack works over the network, needs no prior privilege, and needs nothing from the user. All an attacker prepares is one request full of question marks. No tooling required.

On the other side, the official CVE record rates the impact as confidentiality only — High there, None for integrity and availability. What an attacker can do once inside depends on the application, so the score is best read as covering the breach of the front door and no further.

Who would target this, and why

Anyone who can reach the login screen can use this. That means an internal admin panel exposed to the internet, or an attacker already inside the corporate network. No special skill is required; the only prerequisite is knowing a username.

The work is trying a few logins with a password made only of question marks. Since matching the length is enough, a few dozen attempts varying the length by one character each will do. No guessing of the actual password is needed, so the complexity of the real password buys nothing.

What is lost past that door is whatever the account can see: internal document systems, data held in a search platform, configuration values on an admin screen. For the operator, an area they believed was behind authentication was effectively open. That said, the Digest authentication requirement keeps the set of affected organisations small. The next section is for working out whether you are in it.

Are you affected?

You are affected only when all three conditions overlap. Miss any one of them and this does not touch you.

Condition 2 does most of the filtering. Digest authentication sends a computed value rather than the password itself, a design from the era before encrypted transport. With HTTPS now standard and login forms or external identity providers the norm, very few deployments deliberately turn it on. If you cannot find a DIGEST setting anywhere in your configuration, treat this as not applying to you.

Condition 3 matters too. A password of ASCII letters, digits and symbols is represented correctly in ISO-8859-1 and does not collapse. Only accounts mixing in other scripts are exposed.

One caveat: because Jetty is so often embedded in other software, "we do not run Jetty" is frequently wrong. If you operate Java applications, it is worth checking your dependency tree once for org.eclipse.jetty. The same kind of sweep is covered in our piece on finding vulnerable components across your dependencies.

For older Jetty, the fix is not free

This is the part that does not add up. The advisory lists affected ranges and fixes as follows.

Checking Maven Central, the public repository for Java components, none of 11.0.31, 10.0.31 or 9.4.63 can be found. Nor, for that matter, can 11.0.30, 10.0.30 or 9.4.62 — the upper bounds the advisory gives as affected. Meanwhile 12.0.36 and 12.1.10 sit there without issue.

The reason is end of life. According to the announcement from Webtide, the company that has funded Jetty's development, publishing Jetty 9, 10 and 11 releases to Maven Central stopped on January 1, 2026. Fixes for those lines now reach only customers holding a paid extended-support contract.

So 9.4.63, 10.0.31 and 11.0.31 are not fictitious numbers. They are numbers that only paying customers receive. On the free path, this vulnerability will not be closed on those lines.

If you are still on an older line, there are three routes: move to Jetty 12, buy extended support, or stop using Digest authentication. The third costs nothing and requires no migration, which makes it the first one to consider if condition 2 applies to you.

How to fix it

On Jetty 12, move to 12.0.36 or 12.1.10 or later and you are done. As of writing the newest published are 12.0.37 and 12.1.11, so simply going to the latest is quickest. The fixed builds started shipping on June 2, 2026, two months ago; if you keep dependencies current, this may already be behind you.

If you cannot migrate off an older line quickly, turning off Digest authentication is the surest workaround. Remove the DIGEST setting and switch to form or basic authentication over HTTPS, or to an external identity provider. Given encrypted transport, there is little reason left to keep Digest.

If Digest genuinely has to stay, a stopgap is to change passwords to ASCII letters, digits and symbols only. Characters that ISO-8859-1 can represent do not collapse, which takes you out of the condition. This is not a real fix — the next user who sets a non-Latin password reopens the hole — so treat it as a bridge until migration.

The technical view

Two classifications are attached: CWE-173 (improper handling of alternate encoding) and CWE-303 (incorrect implementation of authentication algorithm). The cause is that the Digest hash computation converted the password with getBytes(StandardCharsets.ISO_8859_1). That conversion in Java maps anything unrepresentable to the substitution byte 0x3F — "?" — rather than throwing. Everything above U+00FF collapses to the same byte, so different passwords produce colliding hashes.

The CVSS 4.0 vector is AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N. No attack requirements, no prior privilege, no user interaction, and impact confined to confidentiality. Integrity and availability sit at None because the flaw itself only guarantees getting past authentication; what follows is up to each application's authorisation design.

Underneath is a historical accident: the original HTTP specification never stated a charset, and ISO-8859-1 was the tacit assumption. RFC 7616 introduced a charset parameter defaulting to UTF-8, which handles this correctly, but implementations lagged behind. A developer testing only with ASCII passwords would never surface this. It took the reporter, hrykx-zy, trying non-Latin characters.

This shape — an outdated encoding assumption left in place — recurs across the Java ecosystem. As with the Fastjson flaw in another staple Java component, or the Tomcat case in a peer servlet container, the more widely a component is embedded, the harder it becomes to know your own exposure.

Common questions

Q. Should I stop using non-Latin characters in passwords?

A. As a general rule, no — there is nothing inherently unsafe about them. This is a problem with one specific implementation, Jetty's Digest authentication. That said, systems that do not handle them well will mangle or reject them, so for business systems, long ASCII passwords remain the reliable choice.

Q. I do not know whether I use Digest authentication.

A. It is not on unless you configured it. Jetty requires it to be specified explicitly, so if nothing rings a bell you are almost certainly out of scope. To confirm, search your configuration and code for the string DIGEST.

Q. Is this being exploited?

A. Not as of writing. No exploit code has been published, and it does not appear on the US government's catalog of vulnerabilities known to be exploited. Jetty has never appeared on that list.

Q. I use Tomcat. Does this affect me?

A. This is specific to Jetty's implementation; Tomcat is not in scope. It does also offer Digest authentication, so if you use that, checking each product's own advisories is sensible. We cover how Tomcat vulnerabilities get rated separately.

Q. Are authentication bypasses unusual?

A. Not at all. There was a batch of five in a mobile core network platform, and one in a firewall product. A small mismatch in implementation assumptions, as here, is among the most typical causes.

Wrapping up

CVE-2026-10050 in Jetty collapses non-Latin passwords into "?" during an old encoding conversion, so sending the same number of "?" characters logs you in. The 8.7 rating is high, but it requires two things at once — Digest authentication in use and a non-ASCII password — which keeps the affected population small. No exploitation has been reported and no exploit code exists publicly.

The action is simple. On Jetty 12, move to 12.0.36 or 12.1.10 or later. That is the whole job, and since the fix has been shipping since June 2, keeping dependencies current may have handled it already.

The part most likely to be missed concerns the older lines. The advisory names 9.4.63, 10.0.31 and 11.0.31 as fixed versions, and none of them are in the public repository. Publishing Jetty 9, 10 and 11 to Maven Central ended on January 1, 2026, and those builds now reach only extended-support customers. Reading the numbers alone and assuming an update will fix it means hunting for a version that will never appear. On the free path, the choice is migrating to 12 or turning Digest authentication off.

Sources

• ▸Eclipse Jetty Security Advisory GHSA-2fvj-hgj9-j2gr
• ▸CVE Record - CVE-2026-10050 (assigned by the Eclipse Foundation)
• ▸NVD - CVE-2026-10050 Detail
• ▸Webtide - End of Life: Changes to Eclipse Jetty and CometD (end of Maven Central publishing for Jetty 9, 10, 11)
• ▸Maven Central - org.eclipse.jetty:jetty-security (version availability check)
• ▸RFC 7616 - HTTP Digest Access Authentication