CVE-2026-10050: 
Java vulnerability analysis and mitigation

CVE-2026-10050 is an authentication bypass vulnerability in Eclipse Jetty's HTTP Digest authentication implementation, caused by lossy ISO-8859-1 character encoding in the DigestAuthentication.apply() method. Any character above U+00FF (e.g., Chinese, Japanese, Cyrillic, Arabic, emoji) is silently replaced with 0x3F (?), allowing an attacker who knows a victim's username to authenticate using a "collision password" where all non-Latin-1 characters are replaced with ?. The vulnerability affects org.eclipse.jetty:jetty-security versions 9.4.0.v20161208 through 9.4.58.v20250814, 10.0.0–10.0.26, 11.0.0–11.0.26, and 12.0.0–12.0.35 / 12.1.0–12.1.9, as well as the corresponding EE8 and EE9 artifacts. It was published to the GitHub Advisory Database on July 22, 2026, and carries a CVSS v4.0 base score of 8.7 (High) (GitHub Advisory).

The root cause is classified as CWE-173 (Improper Handling of Alternate Encoding) and CWE-303 (Incorrect Implementation of Authentication Algorithm). In DigestAuthentication.java, the apply() method calls getBytes(StandardCharsets.ISO_8859_1) at three points — computing H(A1) (line 171), H(A2) (line 179), and the final response hash (line 196) — to derive the MD5-based Digest auth response. Java's String.getBytes(ISO_8859_1) silently maps any character outside U+0000–U+00FF to the byte 0x3F, meaning passwords containing CJK, Cyrillic, Arabic, Greek, Hangul, or emoji characters all produce the same byte sequence as a password where those characters are replaced with ?. The attack requires no privileges and no user interaction; the attacker only needs to know the victim's username and that the password contains at least one non-Latin-1 character (GitHub Advisory, Jetty Commit).

Successful exploitation allows an unauthenticated network attacker to bypass HTTP Digest authentication and gain access to any resource protected by it, provided the victim's password contains characters above U+00FF. The confidentiality impact is high — the attacker authenticates as the victim and can access all data and functionality available to that account. Additionally, legitimate users whose passwords contain non-Latin-1 characters are permanently unable to authenticate via Digest auth (a functional denial-of-service), because Jetty's ISO-8859-1 encoding produces a hash that differs from what the server computed using UTF-8 (GitHub Advisory).

1. Reconnaissance: Identify services using Eclipse Jetty with HTTP Digest authentication enabled. Confirm the target version falls within the affected range (e.g., jetty-security 9.4.x–12.1.9). Tools like Shodan, Censys, or HTTP fingerprinting can identify Jetty deployments.
2. Identify target user: Obtain or enumerate a valid username for the target service. The attack requires knowing the username but not the actual password.
3. Determine password character set: Infer or guess that the victim's password contains non-Latin-1 characters (e.g., the user is known to use a non-European language). This can sometimes be inferred from organizational context.
4. Craft collision password: Replace all non-Latin-1 characters (any character > U+00FF) in the guessed password with ? (0x3F). For example, if the password is suspected to be 密码123, the collision password is ??123.
5. Send Digest authentication request: Initiate an HTTP request to the Digest-protected endpoint. When challenged with a WWW-Authenticate: Digest header, compute the MD5-based response using the collision password. Because Jetty encodes both the original and collision passwords identically under ISO-8859-1, the computed hashes match.
6. Achieve authentication: The server accepts the Digest response computed from the collision password, granting the attacker access as the victim user (GitHub Advisory).

• Network: HTTP requests to Digest-authenticated endpoints from unexpected source IPs, particularly where the Authorization: Digest header contains a username value associated with a non-European-language account but the client IP is inconsistent with the user's normal location.
• Logs: Jetty access logs showing successful 200 OK responses to Digest-protected resources for accounts that historically fail authentication or have not logged in recently; repeated 401 challenges followed by a successful authentication in a single session from an unfamiliar client.
• Behavioral: Successful authentication events for accounts whose passwords are known to contain non-Latin-1 characters, originating from clients or user agents not previously associated with those accounts.

Eclipse Jetty has released patched versions that replace the lossy ISO-8859-1 encoding with a strict encoder (strictEncode()) that uses the charset negotiated with the server (defaulting to ISO-8859-1 for legacy servers, UTF-8 when the server advertises it), and throws an exception rather than silently substituting characters. Upgrade to the following fixed versions: jetty-security 9.4.63, 10.0.31, 11.0.31, 12.0.36, or 12.1.10; jetty-ee8-security and jetty-ee9-security 12.0.36 or 12.1.10. As an interim workaround, require users with non-Latin-1 characters in their passwords to change to Latin-1-only passwords, and consider adding network-level access controls or switching to a stronger authentication mechanism (e.g., Bearer tokens or mutual TLS) until patching is complete (GitHub Advisory, Jetty Commit).

HeroDevs published a vulnerability directory entry and blog post covering CVE-2026-10050, providing additional context for organizations using end-of-life Jetty versions (HeroDevs Blog). The fix was contributed by Jetty core maintainer Simone Bordet (sbordet) and reviewed by multiple Jetty contributors before merging, reflecting a standard coordinated disclosure and patch process (Jetty PR #15160). Community reaction has been limited, with no significant social media amplification or major media coverage observed at the time of this report.