Withdrawn by the publisher.

Affected: CleanStart: solr

Package solr version 10.0.0-r6 fixes 4 vulnerabilities: CVE-2026-8384, CVE-2026-6790, CVE-2026-10051, CVE-2026-10050

In Eclipse Jetty, the Digest authentication server-side component uses ISO-8859-1 to encode the password as bytes.

This was done because the initial specification for HTTP did not specify explicitly a charset, and it was assumed to be ISO-8859-1 for historical reasons.

If the password contains characters that cannot be represented in ISO-8859-1, they are silently replaced by `?`. This happens with passwords that contain Chinese, Cyrillic or Greek characters, for example: `αβ123` converts to `??123`.

An attacker can send a request with a digest `Authorization` header crafted with a password made of only `?` characters; the server would match any password of the same length that contains non-ISO-8859-1 characters.

Recent HTTP Digest [RFC-7616](https://datatracker.ietf.org/doc/html/rfc7616) supports a `charset` parameters that defaults to UTF-8 that allows for correct encoding/decoding of passwords.

Affected: Maven: org.eclipse.jetty:jetty-security, Maven: org.eclipse.jetty.ee8:jetty-ee8-security, Maven: org.eclipse.jetty.ee9:jetty-ee9-security

### Summary The `DigestAuthentication.apply()` method in Jetty's HTTP client uses `getBytes(StandardCharsets.ISO_8859_1)` at three locations (lines 171, 179, 196) to compute Digest auth response hashes. ISO-8859-1 silently replaces any character above U+00FF (Chinese, Japanese, Cyrillic, Arabic, Emoji, etc.) with 0x3F (`?`), causing all such characters to produce identical hash contributions. An attacker who knows a victim's username can bypass Digest authentication by replacing all non-Latin-1 characters in the password with `?` characters, since the collision password produces the same MD5-based Digest response hash as the original password.

### Details ### Root Cause

In `jetty-core/jetty-client/src/main/java/org/eclipse/jetty/client/DigestAuthentication.java`, the `apply()` method computes the three Digest auth hashes (H(A1), H(A2), and the final response) using ISO-8859-1 character encoding:

```java // Line 171 — H(A1) String hashA1 = toHexString(digester.digest(a1.getBytes(StandardCharsets.ISO_8859_1)));

// Line 179 — H(A2) String hashA2 = toHexString(digester.digest(a2.getBytes(StandardCharsets.ISO_8859_1)));

// Line 196 — Final response hash final String hashA3 = toHexString(digester.digest(a3.getBytes(StandardCharsets.ISO_8859_1))); ```

ISO-8859-1 (Latin-1) can only encode characters in the range U+0000–U+00FF. Any character outside this range — including all CJK, Cyrillic, Arabic, Greek, Hangul, and emoji characters — is silently replaced with the byte `0x3F`…

jetty-annotations-9.4.58-5.1 on GA media

netty: netty-codec-http2: Netty MadeYouReset HTTP/2 DDoS Vulnerability curl: curl: Insecure connection establishment due to TLS configuration mismatch shell-quote: shell-quote: Arbitrary code execution via command injection due to unescaped line terminators curl: curl: Man-in-the-middle attack via SSH host key bypass org.eclipse.parsson/parsson: Eclipse Parsson: Denial of Service via uncontrolled resource consumption in JSON parsing jetty-security: Eclipse Jetty: Authentication bypass via Digest authentication encoding collision jetty: Eclipse Jetty: Information disclosure due to retained HTTP/1.1 trailers across connections form-data: form-data: Form field override via CRLF injection undici: undici: Denial of Service due to unbounded memory growth via WebSocket frames brace-expansion: Brace-expansion: Denial of Service due to exponential-time complexity vertx-core: Eclipse Vert.x: Information disclosure via improper handling of HTTP 30x redirects io.vertx/vertx-web: Eclipse Vert.x Web Client: Information disclosure via improper cookie domain validation golang.org/x/net/html: golang: golang.org/x/net/html: Cross-Site Scripting via HTML parsing bypass github.com/go-jose/go-jose/v3: github.com/go-jose/go-jose/v4: Go JOSE: Denial of Service via crafted JSON Web Encryption (JWE) object net/mail: golang: Go net/mail: Denial of Service via crafted email inputs golang.org/x/crypto/ssh: golang.org/x/crypto/ssh: Security key bypass due to missing user presence check golang.org/x/cryp…

Affected: Ubuntu:16.04:LTS: jetty9, Ubuntu:18.04:LTS: jetty9, Ubuntu:20.04:LTS: jetty9, Ubuntu:22.04:LTS: jetty9, Ubuntu:24.04:LTS: jetty9, Ubuntu:26.04:LTS: jetty12, Ubuntu:26.04:LTS: jetty9

In Eclipse Jetty, the Digest authentication server-side component uses ISO-8859-1 to encode the password as bytes. This was done because the initial specification for HTTP did not specify explicitly a charset, and it was assumed to be ISO-8859-1 for historical reasons. If the password contains characters that cannot be represented in ISO-8859-1, they are silently replaced by `?`. This happens with passwords that contain Chinese, Cyrillic or Greek characters, for example: `αβ123` converts to `??123`. An attacker can send a request with a digest `Authorization` header crafted with a password made of only `?` characters; the server would match any password of the same length that contains non-ISO-8859-1 characters. Recent HTTP Digest [RFC-7616](https://datatracker.ietf.org/doc/html/rfc7616) supports a `charset` parameters that defaults to UTF-8 that allows for correct encoding/decoding of passwords.

Ein entfernter, anonymer Angreifer kann mehrere Schwachstellen in Eclipse Jetty ausnutzen, um einen Denial of Service Angriff durchzuführen, Sicherheitsmaßnahmen zu umgehen und vertrauliche Informationen offenzulegen.