CVE-2026-10050: Jetty Digest Authentication Bypass (ISO-8859-1)

On July 13, 2026, the Eclipse Jetty project (via maintainer Simone Bordet) published advisory GHSA-2fvj-hgj9-j2gr, disclosing CVE-2026-10050, a High-severity Digest authentication bypass in Jetty's HTTP client. GitHub's advisory scores it 8.7 on CVSS v4 (CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N). The flaw (CWE-173, incomplete character encoding, alongside CWE-303) lives in Jetty's DigestAuthentication.apply(), which computes Digest response hashes using ISO-8859-1. Any password character above U+00FF is silently replaced with ? (byte 0x3F), so an attacker who knows a victim's username can authenticate with a collision password that hashes identically to the real one. Jetty 12.0.36 and 12.1.10 carry the OSS fix. The end-of-life 9.4, 10, and 11 lines have no OSS fix available.

Affected and unsupported? See NES for Jetty.

‍

What is CVE-2026-10050?

CVE-2026-10050 is an authentication bypass caused by lossy character encoding (CWE-173, Improper Handling of Alternate Encoding), with a secondary weakness of incorrect implementation of an authentication algorithm (CWE-303). It affects the client-side Digest authentication support in Jetty, specifically the DigestAuthentication class in jetty-client and the associated security modules (jetty-security, and on Jetty 12 the jetty-ee8-security and jetty-ee9-security modules).

Digest authentication (RFC 7616 and its predecessors) never sends the password over the wire. Instead, both client and server independently compute an MD5-based hash chain over the username, realm, password, nonce, and request details, then compare the results. The security of the scheme depends on both sides deriving the exact same bytes from the exact same password. CVE-2026-10050 breaks that assumption: Jetty's client derives its bytes through an encoding that throws information away, so two different passwords can collapse to the same hash input.

‍

Root cause: ISO-8859-1 maps everything above U+00FF to a single byte

Jetty's DigestAuthentication.apply() computes the three Digest hashes (H(A1), H(A2), and the final response) by calling getBytes(StandardCharsets.ISO_8859_1) on the input strings. In jetty-client/src/main/java/org/eclipse/jetty/client/DigestAuthentication.java, this happens at three points: the H(A1) hash, the H(A2) hash, and the final response hash.

ISO-8859-1 (Latin-1) can only represent code points in the range U+0000 to U+00FF. When Java's String.getBytes(ISO_8859_1) encounters any character outside that range, it does not throw an exception or warn. It silently substitutes the byte 0x3F, which is the ASCII ?. Every character above U+00FF becomes the same byte.

That covers a large fraction of the world's characters: Chinese, Japanese, and Korean scripts, Cyrillic, Arabic, Greek, the accented Latin Extended range, and emoji all fall above U+00FF. For any of those, the password the user typed and a string of ? placeholders produce byte-for-byte identical input to the MD5 digest, and therefore identical Digest response hashes.

The advisory demonstrates the collision directly. A password of 我爱Java!密码123★ and a collision string that replaces each non-Latin-1 character with ? both encode to the same 31 bytes under ISO-8859-1 and produce the identical H(A1) hash d60ddc903d71913bcc3ab4a94f7fc239. The advisory further shows that Chinese, Korean, Cyrillic, and Greek passwords sharing the same Latin-1 tail all collapse to the same hash, as does an all-? attacker string.

‍

Severity and exploit conditions

NVD has not yet published its own analysis of CVE-2026-10050, so the authoritative score at time of writing is the CNA's (GitHub/Jetty) CVSS v4 base score of 8.7, High.

PR:N is the key metric here: the attack requires no credentials. The only prerequisites are that the target service uses Jetty for Digest authentication, that the victim account has a password containing at least one character above U+00FF, and that the attacker knows the victim's username. Usernames are routinely public or guessable (email addresses, login handles), so the practical barrier is low for any deployment where non-Latin-1 passwords are common.

‍

Exploitation status

The advisory itself contains a proof of concept: a multi-language demonstration showing that several distinct passwords, and an all-? attacker string, all produce the same MD5 H(A1) hash under ISO-8859-1. That is a working collision demonstration, not a full exploit script against a live server, but it removes any doubt about the underlying mechanism.

As of this writing, CVE-2026-10050 is not listed in CISA's Known Exploited Vulnerabilities catalog, and there are no public reports of active exploitation. The CVE was disclosed on July 13, 2026 and has not yet been indexed by NVD or OSV, so aggregator coverage is still catching up. This is a newly disclosed, publicly documented flaw with a demonstrated collision, which is exactly the window in which affected teams should be assessing exposure rather than waiting for exploitation-in-the-wild signals.

We do not publish weaponized exploit code. The mechanism above is sufficient to understand and remediate the issue.

‍

What an attacker can do

The primary impact is a full authentication bypass:

• Log in as a targeted user. If a Jetty-backed service authenticates a user whose password contains any character above U+00FF, an attacker who knows that username can authenticate as them by submitting a collision password, replacing each non-Latin-1 character with ?. The advisory's worked example turns the password 我爱Java!密码123★ into the collision ??Java!??123?, and both authenticate successfully. Once authenticated, the attacker inherits that user's confidentiality boundary, which is why the vector scores VC:H.
• Reduce the effective password entropy. Even where a full collision is not trivial to construct, every non-Latin-1 character in a password contributes zero distinguishing entropy to the Digest hash, because all of them map to the same byte. A password that looks strong to the user is materially weaker against this flaw.

There is also a correctness and availability side effect the advisory calls out as a second scenario: most modern applications store password hashes derived from UTF-8. When Jetty's client derives its bytes from ISO-8859-1 instead, the bytes differ for any non-ASCII password, so a legitimate user with a non-Latin-1 password can never authenticate through Jetty's Digest client. The same bug that lets an attacker in can lock the real user out.

‍

Who is affected?

The vulnerable code path is in Jetty's client-side Digest authentication, present across the 9.4, 10, 11, 12.0, and 12.1 release lines. Per the advisory, the maintained 12.0 line is affected at 12.0.35 and fixed in 12.0.36, and the 12.1 line is affected from 12.1.0 through 12.1.9 and fixed in 12.1.10. Teams on the 9, 10, and 11 lines have no public OSS release to upgrade to.

Jetty 9.4, 10, and 11 all reached end of life before this CVE was disclosed. For a full breakdown of Jetty support timelines, see the Jetty end-of-life dates guide.

‍

Mitigation guidance

The clean resolution for supported lines is the point release. For EOL lines, there is no free upgrade target, which is the gap NES for Jetty closes: a remediated build on the version you already run, without a migration.

‍

Related CVEs

• CVE-2026-5795: a separate Jetty authentication bypass and privilege escalation in the JaspiAuthenticator. Read the full deep-dive on CVE-2026-5795. Both flaws sit in Jetty's authentication layer and both leave EOL lines without an OSS remediation path.

‍

Taking action

CVE-2026-10050 is straightforward to resolve if you are on a maintained line: upgrade to Jetty 12.0.36 or 12.1.10. The harder case is the large installed base still running Jetty 9.4, 10, or 11. Those lines are all end of life, no public OSS fix exists for them, and the authentication bypass is unauthenticated and network-reachable.

That is the exact scenario NES for Jetty is built for. HeroDevs maintains NES for Jetty in partnership with Webtide, the team behind Jetty and CometD, which means remediated releases for EOL lines come from the same maintainers who fix the supported ones. You get a drop-in patched build for the version you already run, with no forced migration to Jetty 12.

If you are running an EOL Jetty line and cannot upgrade on this timeline, see NES for Jetty or get in touch to scope coverage.