<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://cve.radiocsirt.org</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Fri, 02 Oct 2026 10:43:15 +0000</lastBuildDate>
    <item>
      <title>certfr-2026-avi-1094 — De multiples vulnérabilités ont été découvertes dans les produits IBM. Certaines d'entre elles permettent à un attaquan…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2026-avi-1094</link>
      <description>certfr-2026-avi-1094</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2026-avi-1094</guid>
    </item>
    <item>
      <title>Withdrawn: CLEANSTART-2026-AB17721 — Security fixes in solr 10.0.0-r6</title>
      <link>https://cve.radiocsirt.org/vuln/cleanstart-2026-ab17721</link>
      <description>&lt;p&gt;&lt;strong&gt;Withdrawn by the publisher.&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; CleanStart: solr&lt;/p&gt;
&lt;p&gt;Package solr version 10.0.0-r6 fixes 4 vulnerabilities: CVE-2026-8384, CVE-2026-6790, CVE-2026-10051, CVE-2026-10050&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Withdrawn by the publisher.&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; CleanStart: solr&lt;/p&gt;
&lt;p&gt;Package solr version 10.0.0-r6 fixes 4 vulnerabilities: CVE-2026-8384, CVE-2026-6790, CVE-2026-10051, CVE-2026-10050&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/cleanstart-2026-ab17721</guid>
    </item>
    <item>
      <title>EUVD-2026-344046</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-344046</link>
      <description>EUVD-2026-344046</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-344046</guid>
    </item>
    <item>
      <title>fkie_cve-2026-10050</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-10050</link>
      <description>&lt;p&gt;In Eclipse Jetty, the Digest authentication server-side component uses ISO-8859-1 to encode the password as bytes.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;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`.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;In Eclipse Jetty, the Digest authentication server-side component uses ISO-8859-1 to encode the password as bytes.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;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`.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-10050</guid>
    </item>
    <item>
      <title>GHSA-2fvj-hgj9-j2gr — Eclipse Jetty Digest Authentication: ISO-8859-1 lossy encoding allows authentication bypass via character substitution</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-2fvj-hgj9-j2gr</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Maven: org.eclipse.jetty:jetty-security, Maven: org.eclipse.jetty.ee8:jetty-ee8-security, Maven: org.eclipse.jetty.ee9:jetty-ee9-security&lt;/p&gt;
&lt;p&gt;### Summary
The `DigestAuthentication.apply()` method in Jetty&amp;#39;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&amp;#39;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.&lt;/p&gt;
&lt;p&gt;### Details
### Root Cause&lt;/p&gt;
&lt;p&gt;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:&lt;/p&gt;
&lt;p&gt;```java
// Line 171 — H(A1)
String hashA1 = toHexString(digester.digest(a1.getBytes(StandardCharsets.ISO_8859_1)));&lt;/p&gt;
&lt;p&gt;// Line 179 — H(A2)
String hashA2 = toHexString(digester.digest(a2.getBytes(StandardCharsets.ISO_8859_1)));&lt;/p&gt;
&lt;p&gt;// Line 196 — Final response hash
final String hashA3 = toHexString(digester.digest(a3.getBytes(StandardCharsets.ISO_8859_1)));
```&lt;/p&gt;
&lt;p&gt;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`…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Maven: org.eclipse.jetty:jetty-security, Maven: org.eclipse.jetty.ee8:jetty-ee8-security, Maven: org.eclipse.jetty.ee9:jetty-ee9-security&lt;/p&gt;
&lt;p&gt;### Summary
The `DigestAuthentication.apply()` method in Jetty&amp;#39;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&amp;#39;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.&lt;/p&gt;
&lt;p&gt;### Details
### Root Cause&lt;/p&gt;
&lt;p&gt;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:&lt;/p&gt;
&lt;p&gt;```java
// Line 171 — H(A1)
String hashA1 = toHexString(digester.digest(a1.getBytes(StandardCharsets.ISO_8859_1)));&lt;/p&gt;
&lt;p&gt;// Line 179 — H(A2)
String hashA2 = toHexString(digester.digest(a2.getBytes(StandardCharsets.ISO_8859_1)));&lt;/p&gt;
&lt;p&gt;// Line 196 — Final response hash
final String hashA3 = toHexString(digester.digest(a3.getBytes(StandardCharsets.ISO_8859_1)));
```&lt;/p&gt;
&lt;p&gt;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`…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-2fvj-hgj9-j2gr</guid>
    </item>
    <item>
      <title>NCSC-2026-0325 — Kwetsbaarheden verholpen in Atlassian producten</title>
      <link>https://cve.radiocsirt.org/vuln/ncsc-2026-0325</link>
      <description>NCSC-2026-0325</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ncsc-2026-0325</guid>
    </item>
    <item>
      <title>openSUSE-SU-2026:11505-1 — jetty-annotations-9.4.58-5.1 on GA media</title>
      <link>https://cve.radiocsirt.org/vuln/opensuse-su-2026:11505-1</link>
      <description>&lt;p&gt;jetty-annotations-9.4.58-5.1 on GA media&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;jetty-annotations-9.4.58-5.1 on GA media&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/opensuse-su-2026:11505-1</guid>
    </item>
    <item>
      <title>RHSA-2026:62260 — Red Hat Security Advisory: Red Hat OpenShift Dev Spaces 3.30.0 Release.</title>
      <link>https://cve.radiocsirt.org/vuln/rhsa-2026:62260</link>
      <description>&lt;p&gt;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…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;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…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/rhsa-2026:62260</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-10050</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-10050</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; 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&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; 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&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-10050</guid>
    </item>
    <item>
      <title>WID-SEC-W-2026-2314 — Eclipse Jetty: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2314</link>
      <description>&lt;p&gt;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.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;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.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2314</guid>
    </item>
  </channel>
</rss>
