<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://cve.radiocsirt.org/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-06T04:02:16.867736+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>csirt@opendfir.org</email>
  </author>
  <link href="https://cve.radiocsirt.org" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/cve-2025-14813</id>
    <title>CVE-2025-14813 — GOSTCTR implementation unable to process more than 255 blocks correctly</title>
    <updated>2026-10-06T04:02:17.163652+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Legion of the Bouncy Castle Inc. BC-JAVA, Red Hat AMQ Broker 7.12.7, Red Hat AMQ Broker 7.13.5, Red Hat AMQ Broker 7.14.1, Red Hat Build of Apache Camel 4.14 for Quarkus 3.27, Red Hat build of Apache Camel 4.18.1 for Spring Boot 3.5.14, Red Hat build of Quarkus 3.20.6.SP1, Red Hat build of Quarkus 3.27.3.SP1, Red Hat JBoss Enterprise Application Platform 7.4 ELS on RHEL 7, Red Hat JBoss Enterprise Application Platform 7.4 ELS on RHEL 8 and 37 more</p>
<p>: Use of a Broken or Risky Cryptographic Algorithm vulnerability in Legion of the Bouncy Castle Inc. BC-JAVA bcprov on all (core modules).</p>
<p>This vulnerability is associated with program files G3413CTRBlockCipher.</p>
<p>This issue affects BC-JAVA: from 1.59 before 1.80.2, from 1.81 before 1.81.1, from 1.82 before 1.84.</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/cve-2025-14813"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ghsa-38f8-5428-x5cv</id>
    <title>GHSA-38f8-5428-x5cv — Netty vulnerable to HTTP Request Smuggling due to malformed Transfer-Encoding</title>
    <updated>2026-10-06T04:02:17.163832+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Maven: io.netty:netty-codec-http</p>
<p>### Summary
Netty incorrectly parses malformed Transfer-Encoding, enabling request smuggling attacks.</p>
<p>### Details
Netty incorrectly marks a request as chunked when malformed "Transfer-Encoding: chunked, identity" is present.
According to RFC https://datatracker.ietf.org/doc/html/rfc9112#name-message-body-length</p>
<p>"
If a Transfer-Encoding header field is present in a request and the chunked transfer coding is not the final encoding,
 the message body length cannot be determined reliably; the server MUST respond with the 400 (Bad Request)
 status code and then close the connection.
"</p>
<p>A possible scenario is when Netty is behind a proxy that doesn't reject requests with "Transfer-Encoding: chunked, identity", but prefers "Content-Length" and forwards the content to Netty.</p>
<p>### PoC
The test below shows Netty successfully parsing the second request, demonstrating how an attacker can smuggle a second request inside a request body.</p>
<p>```java
@Test
    public void test() {
        String requestStr = "POST / HTTP/1.1\r\n" +
                "Host: localhost\r\n" +
                "Transfer-Encoding: chunked, identity\r\n" +
                "Content-Length: 48\r\n" +
                "\r\n" +
                "0\r\n" +
                "\r\n" +
                "GET /smuggled HTTP/1.1\r\n" +
                "Host: localhost\r\n" +
                "\r\n";</p>
<p>EmbeddedChannel channel = new EmbeddedChannel(new HttpRequestDecoder());
        assertTrue(channel.writeInbound(Unpooled.copied…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ghsa-38f8-5428-x5cv"/>
  </entry>
</feed>
