<?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>Sat, 03 Oct 2026 10:00:10 +0000</lastBuildDate>
    <item>
      <title>bdu:2024-02254</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2024-02254</link>
      <description>bdu:2024-02254</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2024-02254</guid>
    </item>
    <item>
      <title>certfr-2023-avi-1055 — De multiples vulnérabilités ont été découvertes dans &lt;span
class="textit"&gt;les produits IBM&lt;/span&gt;. Certaines d'entre el…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2023-avi-1055</link>
      <description>certfr-2023-avi-1055</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2023-avi-1055</guid>
    </item>
    <item>
      <title>CLEANSTART-2026-ID49738 — Security fix for CVE-2023-40167 applied in: apache-hive 4.0.0-r1</title>
      <link>https://cve.radiocsirt.org/vuln/cleanstart-2026-id49738</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; CleanStart: apache-hive&lt;/p&gt;
&lt;p&gt;Security vulnerability affects the apache-hive package. This issue is resolved in later releases. See references for vulnerability details.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; CleanStart: apache-hive&lt;/p&gt;
&lt;p&gt;Security vulnerability affects the apache-hive package. This issue is resolved in later releases. See references for vulnerability details.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/cleanstart-2026-id49738</guid>
    </item>
    <item>
      <title>EUVD-2026-216730</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-216730</link>
      <description>EUVD-2026-216730</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-216730</guid>
    </item>
    <item>
      <title>fkie_cve-2023-40167</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2023-40167</link>
      <description>&lt;p&gt;Jetty is a Java based web server and servlet engine. Prior to versions 9.4.52, 10.0.16, 11.0.16, and 12.0.1, Jetty accepts the `+` character proceeding the content-length value in a HTTP/1 header field.  This is more permissive than allowed by the RFC and other servers routinely reject such requests with 400 responses.  There is no known exploit scenario, but it is conceivable that request smuggling could result if jetty is used in combination with a server that does not close the connection after sending such a 400 response. Versions 9.4.52, 10.0.16, 11.0.16, and 12.0.1 contain a patch for this issue. There is no workaround as there is no known exploit scenario.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Jetty is a Java based web server and servlet engine. Prior to versions 9.4.52, 10.0.16, 11.0.16, and 12.0.1, Jetty accepts the `+` character proceeding the content-length value in a HTTP/1 header field.  This is more permissive than allowed by the RFC and other servers routinely reject such requests with 400 responses.  There is no known exploit scenario, but it is conceivable that request smuggling could result if jetty is used in combination with a server that does not close the connection after sending such a 400 response. Versions 9.4.52, 10.0.16, 11.0.16, and 12.0.1 contain a patch for this issue. There is no workaround as there is no known exploit scenario.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2023-40167</guid>
    </item>
    <item>
      <title>GHSA-hmr7-m48g-48f6 — Jetty accepts "+" prefixed value in Content-Length</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-hmr7-m48g-48f6</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Maven: org.eclipse.jetty:jetty-http&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;Jetty accepts the &amp;#39;+&amp;#39; character proceeding the content-length value in a HTTP/1 header field.  This is more permissive than allowed by the RFC and other servers routinely reject such requests with 400 responses.  There is no known exploit scenario, but it is conceivable that request smuggling could result if jetty is used in combination with a server that does not close the connection after sending such a 400 response.&lt;/p&gt;
&lt;p&gt;### Workarounds&lt;/p&gt;
&lt;p&gt;There is no workaround as there is no known exploit scenario.&lt;/p&gt;
&lt;p&gt;### Original Report&lt;/p&gt;
&lt;p&gt;[RFC 9110 Secion 8.6](https://www.rfc-editor.org/rfc/rfc9110#section-8.6) defined the value of Content-Length header should be a string of 0-9 digits. However we found that Jetty accepts &amp;#34;+&amp;#34; prefixed Content-Length, which could lead to potential HTTP request smuggling.&lt;/p&gt;
&lt;p&gt;Payload:&lt;/p&gt;
&lt;p&gt;```
 POST / HTTP/1.1
 Host: a.com
 Content-Length: +16
 Connection: close
 ​
 0123456789abcdef
```&lt;/p&gt;
&lt;p&gt;When sending this payload to Jetty, it can successfully parse and identify the length.&lt;/p&gt;
&lt;p&gt;When sending this payload to NGINX, Apache HTTPd or other HTTP servers/parsers, they will return 400 bad request.&lt;/p&gt;
&lt;p&gt;This behavior can lead to HTTP request smuggling and can be leveraged to bypass WAF or IDS.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Maven: org.eclipse.jetty:jetty-http&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;Jetty accepts the &amp;#39;+&amp;#39; character proceeding the content-length value in a HTTP/1 header field.  This is more permissive than allowed by the RFC and other servers routinely reject such requests with 400 responses.  There is no known exploit scenario, but it is conceivable that request smuggling could result if jetty is used in combination with a server that does not close the connection after sending such a 400 response.&lt;/p&gt;
&lt;p&gt;### Workarounds&lt;/p&gt;
&lt;p&gt;There is no workaround as there is no known exploit scenario.&lt;/p&gt;
&lt;p&gt;### Original Report&lt;/p&gt;
&lt;p&gt;[RFC 9110 Secion 8.6](https://www.rfc-editor.org/rfc/rfc9110#section-8.6) defined the value of Content-Length header should be a string of 0-9 digits. However we found that Jetty accepts &amp;#34;+&amp;#34; prefixed Content-Length, which could lead to potential HTTP request smuggling.&lt;/p&gt;
&lt;p&gt;Payload:&lt;/p&gt;
&lt;p&gt;```
 POST / HTTP/1.1
 Host: a.com
 Content-Length: +16
 Connection: close
 ​
 0123456789abcdef
```&lt;/p&gt;
&lt;p&gt;When sending this payload to Jetty, it can successfully parse and identify the length.&lt;/p&gt;
&lt;p&gt;When sending this payload to NGINX, Apache HTTPd or other HTTP servers/parsers, they will return 400 bad request.&lt;/p&gt;
&lt;p&gt;This behavior can lead to HTTP request smuggling and can be leveraged to bypass WAF or IDS.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-hmr7-m48g-48f6</guid>
    </item>
    <item>
      <title>gsd-2023-40167</title>
      <link>https://cve.radiocsirt.org/vuln/gsd-2023-40167</link>
      <description>gsd-2023-40167</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/gsd-2023-40167</guid>
    </item>
    <item>
      <title>OESA-2024-2268 — jetty security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2024-2268</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:20.03-LTS-SP4: jetty&lt;/p&gt;
&lt;p&gt;%global desc \ Jetty is a 100% Java HTTP Server and Servlet Container. This means that you\ do not need to configure and run a separate web server (like Apache) in order\ to use Java, servlets and JSPs to generate dynamic content. Jetty is a fully\ featured web server for static and dynamic content. Unlike separate\ server/container solutions, this means that your web server and web\ application run in the same process, without interconnection overheads\ and complications. Furthermore, as a pure java component, Jetty can be simply\ included in your application for demonstration, distribution or deployment.\ Jetty is available on all Java supported platforms. \ %global extdesc \\ \ This package contains&#13;
&#13;
Security Fix(es):&#13;
&#13;
Jetty is a java based web server and servlet engine. In affected versions servlets with multipart support (e.g. annotated with `@MultipartConfig`) that call `HttpServletRequest.getParameter()` or `HttpServletRequest.getParts()` may cause `OutOfMemoryError` when the client sends a multipart request with a part that has a name but no filename and very large content. This happens even with the default settings of `fileSizeThreshold=0` which should stream the whole part content to disk. An attacker client may send a large multipart request and cause the server to throw `OutOfMemoryError`. However, the server may be able to recover after the `OutOfMemoryError` and continue its service -- although it may take some time. This issue has been patched in versions…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:20.03-LTS-SP4: jetty&lt;/p&gt;
&lt;p&gt;%global desc \ Jetty is a 100% Java HTTP Server and Servlet Container. This means that you\ do not need to configure and run a separate web server (like Apache) in order\ to use Java, servlets and JSPs to generate dynamic content. Jetty is a fully\ featured web server for static and dynamic content. Unlike separate\ server/container solutions, this means that your web server and web\ application run in the same process, without interconnection overheads\ and complications. Furthermore, as a pure java component, Jetty can be simply\ included in your application for demonstration, distribution or deployment.\ Jetty is available on all Java supported platforms. \ %global extdesc \\ \ This package contains&#13;
&#13;
Security Fix(es):&#13;
&#13;
Jetty is a java based web server and servlet engine. In affected versions servlets with multipart support (e.g. annotated with `@MultipartConfig`) that call `HttpServletRequest.getParameter()` or `HttpServletRequest.getParts()` may cause `OutOfMemoryError` when the client sends a multipart request with a part that has a name but no filename and very large content. This happens even with the default settings of `fileSizeThreshold=0` which should stream the whole part content to disk. An attacker client may send a large multipart request and cause the server to throw `OutOfMemoryError`. However, the server may be able to recover after the `OutOfMemoryError` and continue its service -- although it may take some time. This issue has been patched in versions…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2024-2268</guid>
    </item>
    <item>
      <title>openSUSE-SU-2024:13329-1 — jetty-annotations-9.4.53-1.1 on GA media</title>
      <link>https://cve.radiocsirt.org/vuln/opensuse-su-2024:13329-1</link>
      <description>&lt;p&gt;jetty-annotations-9.4.53-1.1 on GA media&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;jetty-annotations-9.4.53-1.1 on GA media&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/opensuse-su-2024:13329-1</guid>
    </item>
    <item>
      <title>RHSA-2023:5441 — Red Hat Security Advisory: Red Hat Integration Camel for Spring Boot 4.0.0 release and security update</title>
      <link>https://cve.radiocsirt.org/vuln/rhsa-2023:5441</link>
      <description>&lt;p&gt;batik: Server-Side Request Forgery vulnerability batik: Server-Side Request Forgery vulnerability apache-ivy: XML External Entity vulnerability jetty-server: OutOfMemoryError for large multipart without filename read via request.getParameter() jetty-server: Cookie parsing of quoted values can exfiltrate values from other cookies apache-johnzon: Prevent inefficient internal conversion from BigDecimal at large scale netty: SniHandler 16MB allocation leads to OOM jetty: Improper validation of HTTP/1 content-length&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;batik: Server-Side Request Forgery vulnerability batik: Server-Side Request Forgery vulnerability apache-ivy: XML External Entity vulnerability jetty-server: OutOfMemoryError for large multipart without filename read via request.getParameter() jetty-server: Cookie parsing of quoted values can exfiltrate values from other cookies apache-johnzon: Prevent inefficient internal conversion from BigDecimal at large scale netty: SniHandler 16MB allocation leads to OOM jetty: Improper validation of HTTP/1 content-length&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/rhsa-2023:5441</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2023-40167</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2023-40167</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&lt;/p&gt;
&lt;p&gt;Jetty is a Java based web server and servlet engine. Prior to versions 9.4.52, 10.0.16, 11.0.16, and 12.0.1, Jetty accepts the `+` character proceeding the content-length value in a HTTP/1 header field.  This is more permissive than allowed by the RFC and other servers routinely reject such requests with 400 responses.  There is no known exploit scenario, but it is conceivable that request smuggling could result if jetty is used in combination with a server that does not close the connection after sending such a 400 response. Versions 9.4.52, 10.0.16, 11.0.16, and 12.0.1 contain a patch for this issue. There is no workaround as there is no known exploit scenario.&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&lt;/p&gt;
&lt;p&gt;Jetty is a Java based web server and servlet engine. Prior to versions 9.4.52, 10.0.16, 11.0.16, and 12.0.1, Jetty accepts the `+` character proceeding the content-length value in a HTTP/1 header field.  This is more permissive than allowed by the RFC and other servers routinely reject such requests with 400 responses.  There is no known exploit scenario, but it is conceivable that request smuggling could result if jetty is used in combination with a server that does not close the connection after sending such a 400 response. Versions 9.4.52, 10.0.16, 11.0.16, and 12.0.1 contain a patch for this issue. There is no workaround as there is no known exploit scenario.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2023-40167</guid>
    </item>
    <item>
      <title>WID-SEC-W-2023-2359 — Eclipse Jetty: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2023-2359</link>
      <description>&lt;p&gt;Ein entfernter authentifizierter Angreifer kann mehrere Schwachstellen in Eclipse Jetty ausnutzen, um beliebigen Code auszuführen, Sicherheitsmaßnahmen zu umgehen oder einen HTTP-Cache-Poison-Angriff durchzuführen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein entfernter authentifizierter Angreifer kann mehrere Schwachstellen in Eclipse Jetty ausnutzen, um beliebigen Code auszuführen, Sicherheitsmaßnahmen zu umgehen oder einen HTTP-Cache-Poison-Angriff durchzuführen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2023-2359</guid>
    </item>
  </channel>
</rss>
