https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sat, 03 Oct 2026 15:13:23 +0000 https://cve.radiocsirt.org/vuln/bdu:2022-00303 bdu:2022-00303 https://cve.radiocsirt.org/vuln/bdu:2022-00303 https://cve.radiocsirt.org/vuln/bit-zookeeper-2021-21295 <p><strong>Affected:</strong> Bitnami: zookeeper</p> <p>Netty is an open-source, asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers &amp; clients. In Netty (io.netty:netty-codec-http2) before version 4.1.60.Final there is a vulnerability that enables request smuggling. If a Content-Length header is present in the original HTTP/2 request, the field is not validated by `Http2MultiplexHandler` as it is propagated up. This is fine as long as the request is not proxied through as HTTP/1.1. If the request comes in as an HTTP/2 stream, gets converted into the HTTP/1.1 domain objects (`HttpRequest`, `HttpContent`, etc.) via `Http2StreamFrameToHttpObjectCodec `and then sent up to the child channel&#39;s pipeline and proxied through a remote peer as HTTP/1.1 this may result in request smuggling. In a proxy case, users may assume the content-length is validated somehow, which is not the case. If the request is forwarded to a backend channel that is a HTTP/1.1 connection, the Content-Length now has meaning and needs to be checked. An attacker can smuggle requests inside the body as it gets downgraded from HTTP/2 to HTTP/1.1. For an example attack refer to the linked GitHub Advisory. Users are only affected if all of this is true: `HTTP2MultiplexCodec` or `Http2FrameCodec` is used, `Http2StreamFrameToHttpObjectCodec` is used to convert to HTTP/1.1 objects, and these HTTP/1.1 objects are forwarded to another remote peer. This has been patched in 4.1.60.Final As a workaround,…</p> <p><strong>Affected:</strong> Bitnami: zookeeper</p> <p>Netty is an open-source, asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers &amp; clients. In Netty (io.netty:netty-codec-http2) before version 4.1.60.Final there is a vulnerability that enables request smuggling. If a Content-Length header is present in the original HTTP/2 request, the field is not validated by `Http2MultiplexHandler` as it is propagated up. This is fine as long as the request is not proxied through as HTTP/1.1. If the request comes in as an HTTP/2 stream, gets converted into the HTTP/1.1 domain objects (`HttpRequest`, `HttpContent`, etc.) via `Http2StreamFrameToHttpObjectCodec `and then sent up to the child channel&#39;s pipeline and proxied through a remote peer as HTTP/1.1 this may result in request smuggling. In a proxy case, users may assume the content-length is validated somehow, which is not the case. If the request is forwarded to a backend channel that is a HTTP/1.1 connection, the Content-Length now has meaning and needs to be checked. An attacker can smuggle requests inside the body as it gets downgraded from HTTP/2 to HTTP/1.1. For an example attack refer to the linked GitHub Advisory. Users are only affected if all of this is true: `HTTP2MultiplexCodec` or `Http2FrameCodec` is used, `Http2StreamFrameToHttpObjectCodec` is used to convert to HTTP/1.1 objects, and these HTTP/1.1 objects are forwarded to another remote peer. This has been patched in 4.1.60.Final As a workaround,…</p> https://cve.radiocsirt.org/vuln/bit-zookeeper-2021-21295 https://cve.radiocsirt.org/vuln/certfr-2021-avi-407 certfr-2021-avi-407 https://cve.radiocsirt.org/vuln/certfr-2021-avi-407 https://cve.radiocsirt.org/vuln/cleanstart-2026-ci66802 <p><strong>Withdrawn by the publisher.</strong></p> <p><strong>Affected:</strong> CleanStart: cassandra-fips</p> <p>Multiple security vulnerabilities affect the cassandra-fips package. These issues are resolved in later releases. See references for individual vulnerability details.</p> <p><strong>Withdrawn by the publisher.</strong></p> <p><strong>Affected:</strong> CleanStart: cassandra-fips</p> <p>Multiple security vulnerabilities affect the cassandra-fips package. These issues are resolved in later releases. See references for individual vulnerability details.</p> https://cve.radiocsirt.org/vuln/cleanstart-2026-ci66802 https://cve.radiocsirt.org/vuln/euvd-2026-22123 EUVD-2026-22123 https://cve.radiocsirt.org/vuln/euvd-2026-22123 https://cve.radiocsirt.org/vuln/fkie_cve-2021-21295 <p>Netty is an open-source, asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers &amp; clients. In Netty (io.netty:netty-codec-http2) before version 4.1.60.Final there is a vulnerability that enables request smuggling. If a Content-Length header is present in the original HTTP/2 request, the field is not validated by `Http2MultiplexHandler` as it is propagated up. This is fine as long as the request is not proxied through as HTTP/1.1. If the request comes in as an HTTP/2 stream, gets converted into the HTTP/1.1 domain objects (`HttpRequest`, `HttpContent`, etc.) via `Http2StreamFrameToHttpObjectCodec `and then sent up to the child channel&#39;s pipeline and proxied through a remote peer as HTTP/1.1 this may result in request smuggling. In a proxy case, users may assume the content-length is validated somehow, which is not the case. If the request is forwarded to a backend channel that is a HTTP/1.1 connection, the Content-Length now has meaning and needs to be checked. An attacker can smuggle requests inside the body as it gets downgraded from HTTP/2 to HTTP/1.1. For an example attack refer to the linked GitHub Advisory. Users are only affected if all of this is true: `HTTP2MultiplexCodec` or `Http2FrameCodec` is used, `Http2StreamFrameToHttpObjectCodec` is used to convert to HTTP/1.1 objects, and these HTTP/1.1 objects are forwarded to another remote peer. This has been patched in 4.1.60.Final As a workaround,…</p> <p>Netty is an open-source, asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers &amp; clients. In Netty (io.netty:netty-codec-http2) before version 4.1.60.Final there is a vulnerability that enables request smuggling. If a Content-Length header is present in the original HTTP/2 request, the field is not validated by `Http2MultiplexHandler` as it is propagated up. This is fine as long as the request is not proxied through as HTTP/1.1. If the request comes in as an HTTP/2 stream, gets converted into the HTTP/1.1 domain objects (`HttpRequest`, `HttpContent`, etc.) via `Http2StreamFrameToHttpObjectCodec `and then sent up to the child channel&#39;s pipeline and proxied through a remote peer as HTTP/1.1 this may result in request smuggling. In a proxy case, users may assume the content-length is validated somehow, which is not the case. If the request is forwarded to a backend channel that is a HTTP/1.1 connection, the Content-Length now has meaning and needs to be checked. An attacker can smuggle requests inside the body as it gets downgraded from HTTP/2 to HTTP/1.1. For an example attack refer to the linked GitHub Advisory. Users are only affected if all of this is true: `HTTP2MultiplexCodec` or `Http2FrameCodec` is used, `Http2StreamFrameToHttpObjectCodec` is used to convert to HTTP/1.1 objects, and these HTTP/1.1 objects are forwarded to another remote peer. This has been patched in 4.1.60.Final As a workaround,…</p> https://cve.radiocsirt.org/vuln/fkie_cve-2021-21295 https://cve.radiocsirt.org/vuln/ghsa-wm47-8v5p-wjpj <p><strong>Affected:</strong> Maven: io.netty:netty-codec-http2, Maven: org.jboss.netty:netty, Maven: io.netty:netty</p> <p>### Impact If a Content-Length header is present in the original HTTP/2 request, the field is not validated by `Http2MultiplexHandler` as it is propagated up. This is fine as long as the request is not proxied through as HTTP/1.1. If the request comes in as an HTTP/2 stream, gets converted into the HTTP/1.1 domain objects (`HttpRequest`, `HttpContent`, etc.) via `Http2StreamFrameToHttpObjectCodec `and then sent up to the child channel&#39;s pipeline and proxied through a remote peer as HTTP/1.1 this may result in request smuggling.</p> <p>In a proxy case, users may assume the content-length is validated somehow, which is not the case. If the request is forwarded to a backend channel that is a HTTP/1.1 connection, the Content-Length now has meaning and needs to be checked.</p> <p>An attacker can smuggle requests inside the body as it gets downgraded from HTTP/2 to HTTP/1.1. A sample attack request looks like:</p> <p>``` POST / HTTP/2 :authority:: externaldomain.com Content-Length: 4</p> <p>asdfGET /evilRedirect HTTP/1.1 Host: internaldomain.com ```</p> <p>Users are only affected if all of this is `true`: * `HTTP2MultiplexCodec` or `Http2FrameCodec` is used * `Http2StreamFrameToHttpObjectCodec` is used to convert to HTTP/1.1 objects * These HTTP/1.1 objects are forwarded to another remote peer.</p> <p>### Patches This has been patched in 4.1.60.Final</p> <p>### Workarounds The user can do the validation by themselves by implementing a custom `ChannelInboundHandler` that is put in the `ChannelPipeline` behind…</p> <p><strong>Affected:</strong> Maven: io.netty:netty-codec-http2, Maven: org.jboss.netty:netty, Maven: io.netty:netty</p> <p>### Impact If a Content-Length header is present in the original HTTP/2 request, the field is not validated by `Http2MultiplexHandler` as it is propagated up. This is fine as long as the request is not proxied through as HTTP/1.1. If the request comes in as an HTTP/2 stream, gets converted into the HTTP/1.1 domain objects (`HttpRequest`, `HttpContent`, etc.) via `Http2StreamFrameToHttpObjectCodec `and then sent up to the child channel&#39;s pipeline and proxied through a remote peer as HTTP/1.1 this may result in request smuggling.</p> <p>In a proxy case, users may assume the content-length is validated somehow, which is not the case. If the request is forwarded to a backend channel that is a HTTP/1.1 connection, the Content-Length now has meaning and needs to be checked.</p> <p>An attacker can smuggle requests inside the body as it gets downgraded from HTTP/2 to HTTP/1.1. A sample attack request looks like:</p> <p>``` POST / HTTP/2 :authority:: externaldomain.com Content-Length: 4</p> <p>asdfGET /evilRedirect HTTP/1.1 Host: internaldomain.com ```</p> <p>Users are only affected if all of this is `true`: * `HTTP2MultiplexCodec` or `Http2FrameCodec` is used * `Http2StreamFrameToHttpObjectCodec` is used to convert to HTTP/1.1 objects * These HTTP/1.1 objects are forwarded to another remote peer.</p> <p>### Patches This has been patched in 4.1.60.Final</p> <p>### Workarounds The user can do the validation by themselves by implementing a custom `ChannelInboundHandler` that is put in the `ChannelPipeline` behind…</p> https://cve.radiocsirt.org/vuln/ghsa-wm47-8v5p-wjpj https://cve.radiocsirt.org/vuln/gsd-2021-21295 gsd-2021-21295 https://cve.radiocsirt.org/vuln/gsd-2021-21295 https://cve.radiocsirt.org/vuln/oesa-2021-1161 <p><strong>Affected:</strong> openEuler:20.03-LTS-SP1: netty</p> <p>Netty is an asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers &amp;amp; clients. %package help Summary: Documents for %{name} Buildarch: noarch Requires: man info Provides: %{name}-javadoc = %{version}-%{release} Obsoletes: %{name}-javadoc &amp;lt; %{version}-%{release} %description help Man pages and other related documents for %{name}. Security Fix(es): Netty is an open-source, asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers &amp;amp; clients. In Netty (io.netty:netty-codec-http2) before version 4.1.60.Final there is a vulnerability that enables request smuggling. If a Content-Length header is present in the original HTTP/2 request, the field is not validated by `Http2MultiplexHandler` as it is propagated up. This is fine as long as the request is not proxied through as HTTP/1.1. If the request comes in as an HTTP/2 stream, gets converted into the HTTP/1.1 domain objects (`HttpRequest`, `HttpContent`, etc.) via `Http2StreamFrameToHttpObjectCodec `and then sent up to the child channel&amp;apos;s pipeline and proxied through a remote peer as HTTP/1.1 this may result in request smuggling. In a proxy case, users may assume the content-length is validated somehow, which is not the case. If the request is forwarded to a backend channel that is a HTTP/1.1 connection, the Content-Length now has…</p> <p><strong>Affected:</strong> openEuler:20.03-LTS-SP1: netty</p> <p>Netty is an asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers &amp;amp; clients. %package help Summary: Documents for %{name} Buildarch: noarch Requires: man info Provides: %{name}-javadoc = %{version}-%{release} Obsoletes: %{name}-javadoc &amp;lt; %{version}-%{release} %description help Man pages and other related documents for %{name}. Security Fix(es): Netty is an open-source, asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers &amp;amp; clients. In Netty (io.netty:netty-codec-http2) before version 4.1.60.Final there is a vulnerability that enables request smuggling. If a Content-Length header is present in the original HTTP/2 request, the field is not validated by `Http2MultiplexHandler` as it is propagated up. This is fine as long as the request is not proxied through as HTTP/1.1. If the request comes in as an HTTP/2 stream, gets converted into the HTTP/1.1 domain objects (`HttpRequest`, `HttpContent`, etc.) via `Http2StreamFrameToHttpObjectCodec `and then sent up to the child channel&amp;apos;s pipeline and proxied through a remote peer as HTTP/1.1 this may result in request smuggling. In a proxy case, users may assume the content-length is validated somehow, which is not the case. If the request is forwarded to a backend channel that is a HTTP/1.1 connection, the Content-Length now has…</p> https://cve.radiocsirt.org/vuln/oesa-2021-1161 https://cve.radiocsirt.org/vuln/opensuse-su-2021:0448-1 <p>Security update for netty</p> <p>Security update for netty</p> https://cve.radiocsirt.org/vuln/opensuse-su-2021:0448-1 https://cve.radiocsirt.org/vuln/rhsa-2021:0943 <p>netty: Information disclosure via the local system temporary directory netty: possible request smuggling in HTTP/2 due missing validation</p> <p>netty: Information disclosure via the local system temporary directory netty: possible request smuggling in HTTP/2 due missing validation</p> https://cve.radiocsirt.org/vuln/rhsa-2021:0943 https://cve.radiocsirt.org/vuln/suse-su-2022:1271-1 <p>Security update for netty</p> <p>Security update for netty</p> https://cve.radiocsirt.org/vuln/suse-su-2022:1271-1 https://cve.radiocsirt.org/vuln/ubuntu-cve-2021-21295 <p><strong>Affected:</strong> Ubuntu:Pro:14.04:LTS: netty, Ubuntu:Pro:16.04:LTS: netty, Ubuntu:Pro:18.04:LTS: netty, Ubuntu:Pro:20.04:LTS: netty, Ubuntu:22.04:LTS: netty</p> <p>Netty is an open-source, asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers &amp; clients. In Netty (io.netty:netty-codec-http2) before version 4.1.60.Final there is a vulnerability that enables request smuggling. If a Content-Length header is present in the original HTTP/2 request, the field is not validated by `Http2MultiplexHandler` as it is propagated up. This is fine as long as the request is not proxied through as HTTP/1.1. If the request comes in as an HTTP/2 stream, gets converted into the HTTP/1.1 domain objects (`HttpRequest`, `HttpContent`, etc.) via `Http2StreamFrameToHttpObjectCodec `and then sent up to the child channel&#39;s pipeline and proxied through a remote peer as HTTP/1.1 this may result in request smuggling. In a proxy case, users may assume the content-length is validated somehow, which is not the case. If the request is forwarded to a backend channel that is a HTTP/1.1 connection, the Content-Length now has meaning and needs to be checked. An attacker can smuggle requests inside the body as it gets downgraded from HTTP/2 to HTTP/1.1. For an example attack refer to the linked GitHub Advisory. Users are only affected if all of this is true: `HTTP2MultiplexCodec` or `Http2FrameCodec` is used, `Http2StreamFrameToHttpObjectCodec` is used to convert to HTTP/1.1 objects, and these HTTP/1.1 objects are forwarded to another remote peer. This has been patched in 4.1.60.Final As a workaround,…</p> <p><strong>Affected:</strong> Ubuntu:Pro:14.04:LTS: netty, Ubuntu:Pro:16.04:LTS: netty, Ubuntu:Pro:18.04:LTS: netty, Ubuntu:Pro:20.04:LTS: netty, Ubuntu:22.04:LTS: netty</p> <p>Netty is an open-source, asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers &amp; clients. In Netty (io.netty:netty-codec-http2) before version 4.1.60.Final there is a vulnerability that enables request smuggling. If a Content-Length header is present in the original HTTP/2 request, the field is not validated by `Http2MultiplexHandler` as it is propagated up. This is fine as long as the request is not proxied through as HTTP/1.1. If the request comes in as an HTTP/2 stream, gets converted into the HTTP/1.1 domain objects (`HttpRequest`, `HttpContent`, etc.) via `Http2StreamFrameToHttpObjectCodec `and then sent up to the child channel&#39;s pipeline and proxied through a remote peer as HTTP/1.1 this may result in request smuggling. In a proxy case, users may assume the content-length is validated somehow, which is not the case. If the request is forwarded to a backend channel that is a HTTP/1.1 connection, the Content-Length now has meaning and needs to be checked. An attacker can smuggle requests inside the body as it gets downgraded from HTTP/2 to HTTP/1.1. For an example attack refer to the linked GitHub Advisory. Users are only affected if all of this is true: `HTTP2MultiplexCodec` or `Http2FrameCodec` is used, `Http2StreamFrameToHttpObjectCodec` is used to convert to HTTP/1.1 objects, and these HTTP/1.1 objects are forwarded to another remote peer. This has been patched in 4.1.60.Final As a workaround,…</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2021-21295 https://cve.radiocsirt.org/vuln/wid-sec-w-2022-0567 <p>Ein entfernter, anonymer oder lokaler Angreifer kann mehrere Schwachstellen in Red Hat OpenShift ausnutzen, um Sicherheitsvorkehrungen zu umgehen oder Informationen offenzulegen.</p> <p>Ein entfernter, anonymer oder lokaler Angreifer kann mehrere Schwachstellen in Red Hat OpenShift ausnutzen, um Sicherheitsvorkehrungen zu umgehen oder Informationen offenzulegen.</p> https://cve.radiocsirt.org/vuln/wid-sec-w-2022-0567