WaratekVRT Sign in
Reset
More filters (1)
Columns
Including CVEs outside Waratek scope✕Product netty✕
Overview 125 matches · 114 in Waratek scope · 8 protected · 1 exploited · 1 CISA KEV · 1 public PoC · 1 EPSS ≥ 0.5
125matches 114in Waratek scope91.2% 8protected6.4% 1exploited0.8% 1CISA KEV0.8% 1public PoC0.8% 1EPSS ≥ 0.50.8%
Protected by Waratek 8 6.4% Rule in development 0 0.0% Mitigation candidate 1 0.8% No exploit published 105 84.0% Outside Waratek scope 5 4.0% Not applicable 6 4.8% Withdrawn CVE 0 0.0%
Critical 13 10.4% High 61 48.8% Medium 48 38.4% Low 3 2.4% None 0 0.0% Unknown 0 0.0%
blocked by ARMR today 8 6.4% partly blocked 0 0.0% not blocked 117 93.6% not established 0 0.0% unrecorded 0 0.0%
Exploited 1 0.8% Working exploit published 0 0.0% Proof of concept only 33 26.4% Forecast only 0 0.0% No public exploit 91 72.8%
split by peak 78 / year
Not applicable: 6Outside Waratek scope: 5No exploit published: 105Mitigation candidate: 1Protected by Waratek: 8 Low: 3Medium: 48High: 61Critical: 13 not blocked: 117blocked by ARMR today: 8 No public exploit: 91Proof of concept only: 33Exploited: 1
20142 No exploit published1 Outside Waratek scope1 Medium2 not blocked2 No public exploit2 20150 20160 20172 No exploit published2 High2 not blocked2 No public exploit2 20180 20192 No exploit published2 High2 not blocked2 No public exploit2 20209 Protected by Waratek1 No exploit published7 Outside Waratek scope1 Critical4 High3 Medium2 blocked by ARMR today1 not blocked8 No public exploit9 20217 Protected by Waratek3 No exploit published2 Outside Waratek scope2 High3 Medium4 blocked by ARMR today3 not blocked4 No public exploit7 20224 No exploit published4 High1 Medium3 not blocked4 Proof of concept only3 No public exploit1 20236 Mitigation candidate1 No exploit published4 Not applicable1 Critical1 High4 Medium1 not blocked6 Exploited1 Proof of concept only1 No public exploit4 20246 No exploit published6 Critical1 High2 Medium3 not blocked6 Proof of concept only2 No public exploit4 20259 Protected by Waratek1 No exploit published7 Outside Waratek scope1 High2 Medium6 Low1 blocked by ARMR today1 not blocked8 Proof of concept only5 No public exploit4 202678 Protected by Waratek3 No exploit published70 Not applicable5 Critical7 High42 Medium27 Low2 blocked by ARMR today3 not blocked75 Proof of concept only22 No public exploit56
2014201620182020202220242026
125 matches Sign in to download these CVEs as CSV or JSON, or to follow them in a feed. ‹ prev page 2 of 2 next ›
CVE Severity Published▾ Status Exploitation Description
CVE-2022-41881 High 2022-12-12 No exploit published Proof of concept only Netty project is an event-driven asynchronous network application framework. In versions prior to 4.1.86.Final, a StackOverflowError can be raised when parsing a malformed crafted message due to an infinite recursion. This issue is patched in version 4.1.86.Final. There is no workaround, except using a custom HaProxyMessageDecoder.
CVE-2022-31684 Medium 2022-10-19 No exploit published No public exploit Reactor Netty HTTP Server, in versions 1.0.11 - 1.0.23, may log request headers in some cases of invalid HTTP requests. The logged headers may reveal valid access tokens to those with access to server logs. This may affect only invalid HTTP requests where logging at WARN level is enabled.
CVE-2022-24823 Medium 2022-05-06 No exploit published Proof of concept only Netty is an open-source, asynchronous event-driven network application framework. The package `io.netty:netty-codec-http` prior to version 4.1.77.Final contains an insufficient fix for CVE-2021-21290. When Netty's multipart decoders are used local information disclosure can occur via the local system temporary directory if temporary storing uploads on the disk is enabled. This only impacts applications running on Java version 6 and lower. Additionally, this vulnerability impacts code running on Unix-like systems, and very old versions of Mac OSX and Windows as they all share the system temporary directory between all users. Version 4.1.77.Final contains a patch for this vulnerability. As a workaround, specify one's own `java.io.tmpdir` when starting the JVM or use DefaultHttpDataFactory.setBaseDir(...) to set the directory to something that is only readable by the current user.
CVE-2021-43797 Medium 2021-12-09 Outside Waratek scope No public exploit Netty is an asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients. Netty prior to version 4.1.71.Final skips control chars when they are present at the beginning / end of the header name. It should instead fail fast as these are not allowed by the spec and could lead to HTTP request smuggling. Failing to do the validation might cause netty to "sanitize" header names before it forward these to another remote system when used as proxy. This remote system can't see the invalid usage anymore, and therefore does not do the validation itself. Users should upgrade to version 4.1.71.Final.
CVE-2021-37137 High 2021-10-19 Outside Waratek scope No public exploit The Snappy frame decoder function doesn't 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.
CVE-2021-37136 High 2021-10-19 Protected by Waratek No public exploit The Bzip2 decompression decoder function doesn't 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
CVE-2021-32769 High 2021-07-16 Protected by Waratek No public exploit Micronaut is a JVM-based, full stack Java framework designed for building JVM applications. A path traversal vulnerability exists in versions prior to 2.5.9. With a basic configuration, it is possible to access any file from a filesystem, using "/../../" in the URL. This occurs because Micronaut does not restrict file access to configured paths. The vulnerability is patched in version 2.5.9. As a workaround, do not use `**` in mapping, use only `*`, which exposes only flat structure of a directory not allowing traversal. If using Linux, another workaround is to run micronaut in chroot.
CVE-2021-21409 Medium 2021-03-30 No exploit published No public exploit Netty is an open-source, asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients. In Netty (io.netty:netty-codec-http2) before version 4.1.61.Final there is a vulnerability that enables request smuggling. The content-length header is not correctly validated if the request only uses 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 GHSA-wm47-8v5p-wjpj/CVE-2021-21295 which did miss to fix this one case. This was fixed as part of 4.1.61.Final.
CVE-2021-21295 Medium 2021-03-09 No exploit published No public exploit Netty is an open-source, asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & 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'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, the user can do the validation by themselves by implementing a custom `ChannelInboundHandler` that is put in the `ChannelPipeline` behind `Http2StreamFrameToHttpObjectCodec`.
CVE-2021-21290 Medium 2021-02-08 Protected by Waratek No public exploit Netty is an open-source, asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients. In Netty before version 4.1.59.Final there is a vulnerability on Unix-like systems involving an insecure temp file. When netty's multipart decoders are used local information disclosure can occur via the local system temporary directory if temporary storing uploads on the disk is enabled. On unix-like systems, the temporary directory is shared between all user. As such, writing to this directory using APIs that do not explicitly set the file/directory permissions can lead to information disclosure. Of note, this does not impact modern MacOS Operating Systems. The method "File.createTempFile" on unix-like systems creates a random file, but, by default will create this file with the permissions "-rw-r--r--". Thus, if sensitive information is written to this file, other local users can read this information. This is the case in netty's "AbstractDiskHttpData" is vulnerable. This has been fixed in version 4.1.59.Final. As a workaround, one may specify your own "java.io.tmpdir" when you start the JVM or use "DefaultHttpDataFactory.setBaseDir(...)" to set the directory to something that is only readable by the current user.
CVE-2020-11973 Critical 2020-05-14 Protected by Waratek No public exploit Apache Camel Netty enables Java deserialization by default. Apache Camel 2.22.x, 2.23.x, 2.24.x, 2.25.0, 3.0.0 up to 3.1.0 are affected. 2.x users should upgrade to 2.25.1, 3.x users should upgrade to 3.2.0.
CVE-2020-11612 High 2020-04-07 Outside Waratek scope No public exploit The ZlibDecoders in Netty 4.1.x before 4.1.46 allow for unbounded memory allocation while decoding a ZlibEncoded byte stream. An attacker could send a large ZlibEncoded byte stream to the Netty server, forcing the server to allocate all of its free memory to a single decoder.
CVE-2020-7622 Critical 2020-04-06 No exploit published No public exploit This affects the package io.jooby:jooby-netty before 1.6.9, from 2.0.0 and before 2.2.1. The DefaultHttpHeaders is set to false which means it does not validates that the header isn't being abused for HTTP Response Splitting.
CVE-2020-5404 Medium 2020-03-03 No exploit published No public exploit The HttpClient from Reactor Netty, versions 0.9.x prior to 0.9.5, and versions 0.8.x prior to 0.8.16, may be used incorrectly, leading to a credentials leak during a redirect to a different domain. In order for this to happen, the HttpClient must have been explicitly configured to follow redirects.
CVE-2020-5403 High 2020-03-03 No exploit published No public exploit Reactor Netty HttpServer, versions 0.9.3 and 0.9.4, is exposed to a URISyntaxException that causes the connection to be closed prematurely instead of producing a 400 response.
CVE-2019-10797 Medium 2020-02-19 No exploit published No public exploit Netty in WSO2 transport-http before v6.3.1 is vulnerable to HTTP Response Splitting due to HTTP Header validation being disabled.
CVE-2019-20445 Critical 2020-01-29 No exploit published No public exploit 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.
CVE-2019-20444 Critical 2020-01-29 No exploit published No public exploit HttpObjectDecoder.java in Netty before 4.1.44 allows an HTTP header that lacks a colon, which might be interpreted as a separate header with an incorrect syntax, or might be interpreted as an "invalid fold."
CVE-2020-7238 High 2020-01-27 No exploit published No public exploit Netty 4.1.43.Final allows HTTP Request Smuggling because it mishandles Transfer-Encoding whitespace (such as a [space]Transfer-Encoding:chunked line) and a later Content-Length header. This issue exists because of an incomplete fix for CVE-2019-16869.
CVE-2019-11284 High 2019-10-17 No exploit published No public exploit Pivotal Reactor Netty, versions prior to 0.8.11, passes headers through redirects, including authorization ones. A remote unauthenticated malicious user may gain access to credentials for a different server than they have access to.
CVE-2019-16869 High 2019-09-26 No exploit published No public exploit 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.
CVE-2015-2156 High 2017-10-18 No exploit published No public exploit 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.
CVE-2016-4970 High 2017-04-13 No exploit published No public exploit handler/ssl/OpenSslEngine.java in Netty 4.0.x before 4.0.37.Final and 4.1.x before 4.1.1.Final allows remote attackers to cause a denial of service (infinite loop).
CVE-2014-3488 Medium 2014-07-31 Outside Waratek scope No public exploit The SslHandler in Netty before 3.9.2 allows remote attackers to cause a denial of service (infinite loop and CPU consumption) via a crafted SSLv2Hello message.
CVE-2014-0193 Medium 2014-05-06 No exploit published No public exploit WebSocket08FrameDecoder in Netty 3.6.x before 3.6.9, 3.7.x before 3.7.1, 3.8.x before 3.8.2, 3.9.x before 3.9.1, and 4.0.x before 4.0.19 allows remote attackers to cause a denial of service (memory consumption) via a TextWebSocketFrame followed by a long stream of ContinuationWebSocketFrames.
‹ prev page 2 of 2 next ›