Search for packages
| purl | pkg:maven/org.jboss.netty/netty@3.1.5.GA |
| Next non-vulnerable version | None. |
| Latest non-vulnerable version | None. |
| Risk | 4.0 |
| Vulnerability | Summary | Fixed by |
|---|---|---|
|
VCID-3mgs-vrus-q3ag
Aliases: CVE-2019-20445 GHSA-p2v9-g2qv-p635 |
HTTP Request Smuggling in Netty HttpObjectDecoder.java in Netty before 4.1.44 allows a Content-Length header to be accompanied by a second Content-Length header, or by a Transfer-Encoding header. |
Affected by 0 other vulnerabilities. |
|
VCID-81nf-zd3k-mud7
Aliases: CVE-2015-2156 GHSA-xfv3-rrfm-f2rv |
Information Exposure in Netty Netty before 3.9.8.Final, 3.10.x before 3.10.3.Final, 4.0.x before 4.0.28.Final, and 4.1.x before 4.1.0.Beta5 and Play Framework 2.x before 2.3.9 might allow remote attackers to bypass the httpOnly flag on cookies and obtain sensitive information by leveraging improper validation of cookie name and value characters. |
Affected by 0 other vulnerabilities. Affected by 0 other vulnerabilities. |
|
VCID-8p4t-8f51-h3dc
Aliases: CVE-2021-37137 GHSA-9vjp-v76f-g363 |
Uncontrolled Resource Consumption The Snappy frame decoder function does not restrict the chunk length which may lead to excessive memory usage. Beside this it also may buffer reserved skippable chunks until the whole chunk was received which may lead to excessive memory usage as well. This vulnerability can be triggered by supplying malicious input that decompresses to a very big size (via a network stream or a file) or by sending a huge skippable chunk. |
Affected by 0 other vulnerabilities. |
|
VCID-e92u-331h-bkcb
Aliases: CVE-2021-21290 GHSA-5mcr-gq6c-3hq2 |
This advisory has been marked as False Positive and moved to `netty-codec-http`, `netty-handler` and `netty-common`. |
Affected by 0 other vulnerabilities. |
|
VCID-hzxz-sqmu-s7e1
Aliases: CVE-2021-21409 GHSA-f256-j965-7f32 |
Possible request smuggling in HTTP/2 due missing validation of content-length ### Impact The content-length header is not correctly validated if the request only use a single Http2HeaderFrame with the endStream set to to true. This could lead to request smuggling if the request is proxied to a remote peer and translated to HTTP/1.1 This is a followup of https://github.com/netty/netty/security/advisories/GHSA-wm47-8v5p-wjpj which did miss to fix this one case. ### Patches This was fixed as part of 4.1.61.Final ### Workarounds Validation can be done by the user before proxy the request by validating the header. |
Affected by 0 other vulnerabilities. |
|
VCID-mba8-bg91-77ak
Aliases: CVE-2019-16869 GHSA-p979-4mfw-53vg |
HTTP Request Smuggling in Netty Netty before 4.1.42.Final mishandles whitespace before the colon in HTTP headers (such as a "Transfer-Encoding : chunked" line), which leads to HTTP request smuggling. |
Affected by 0 other vulnerabilities. |
|
VCID-swu5-a9h5-ffex
Aliases: CVE-2021-43797 GHSA-wx5j-54mm-rqqq |
Inconsistent Interpretation of HTTP Requests ('HTTP Request Smuggling') This CVE has been marked as a False Positive and has been removed. |
Affected by 0 other vulnerabilities. |
|
VCID-ug8h-p8kf-t7e1
Aliases: CVE-2021-21295 GHSA-wm47-8v5p-wjpj |
Possible request smuggling in HTTP/2 due missing validation ### 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'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. A sample attack request looks like: ``` POST / HTTP/2 :authority:: externaldomain.com Content-Length: 4 asdfGET /evilRedirect HTTP/1.1 Host: internaldomain.com ``` 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. ### Patches This has been patched in 4.1.60.Final ### Workarounds The user can do the validation by themselves by implementing a custom `ChannelInboundHandler` that is put in the `ChannelPipeline` behind `Http2StreamFrameToHttpObjectCodec`. ### References Related change to workaround the problem: https://github.com/Netflix/zuul/pull/980 |
Affected by 0 other vulnerabilities. |
|
VCID-xyc4-63ra-mfh2
Aliases: CVE-2021-37136 GHSA-grg4-wf29-r9vv |
Uncontrolled Resource Consumption The Bzip2 decompression decoder function does not allow setting size restrictions on the decompressed output data (which affects the allocation size used during decompression). All users of Bzip2Decoder are affected. The malicious input can trigger an OOME and so a DoS attack |
Affected by 0 other vulnerabilities. |
| Vulnerability | Summary | Aliases |
|---|---|---|
| This package is not known to fix vulnerabilities. | ||