Vulnerabilities affecting this package (0)
| Vulnerability |
Summary |
Fixed by |
|
This package is not known to be affected by vulnerabilities.
|
Vulnerabilities fixed by this package (2)
| Vulnerability |
Summary |
Aliases |
|
VCID-daws-9x98-vbbm
|
The Eclipse Jetty Server Artifact has a Gzip request memory leak
### Description (as reported)
There is a memory leak when using `GzipHandler` in jetty-12.0.30 that can cause off-heap OOMs. This can be used for DoS attacks so I'm reporting this as a vulnerability.
The leak is created by requests where the request is inflated (`Content-Encoding: gzip`) and the response is not deflated (no `Accept-Encoding: gzip`). In these conditions, a new inflator will be created by `GzipRequest` and never released back into `GzipRequest.__inflaterPool` because `gzipRequest.destory()` is not called.
In heap dumps one can see thousands of `java.util.zip.Inflator` objects, which use both Java heaps and native memory. Leaking native memory causes of off-heap OOMs.
Code path in `GzipHandler.handle()`:
1. Line 601: `GzipRequest` is created when request inflation is needed.
2. Lines 611-616: The callback is only wrapped in `GzipResponseAndCallback` when both inflation and deflation are needed.
3. Lines 619-625: If the handler accepts the request (returns true), `gzipRequest.destroy()` is only called in the "request not accepted" path (returns false)
When deflation is needed, `GzipResponseAndCallback` (lines 102 and 116) properly calls `gzipRequest.destroy()` in its `succeeded()` and `failed()` methods. But this wrapper is only created when deflation is needed.
Possible fix:
The callback should be wrapped whenever a `GzipRequest` is created, not just when deflation is needed. This ensures `gzipRequest.destroy()` is always called when the request completes.
### Impact
The leak causes the JVM to crash with OOME.
### Patches
No patches yet.
### Workarounds
Disable `GzipHandler`.
### References
https://github.com/jetty/jetty.project/issues/14260
https://gitlab.eclipse.org/security/cve-assignment/-/issues/79
|
CVE-2026-1605
GHSA-xxh7-fcf3-rj7f
|
|
VCID-e1r9-bbdh-qqf6
|
org.eclipse.jetty:jetty-http has different parsing of invalid URIs
The Jetty URI parser has some key differences compared to other common parsers when evaluating invalid or unusual URIs. Specifically:
#### Invalid Scheme
| URI | Jetty | uri-js (nodejs) | node-url(nodejs) |
|---|---|---| --- |
| `https>://vulndetector.com/path` | scheme=`http>`| scheme=`https` | invalid URI |
#### Improper IPv4 mapped IPv6
| URI | Jetty | System.Uri(CSharp) | curl(C) |
|---|---|---| --- |
| `http://[0:0:0:0:0:ffff:127.0.0.1]` | invalid | host=`[::ffff:127.0.0.1]` | host=`[::ffff:127.0.0.1]` |
| `http://[::ffff:255.255.0.0]` | invalid | host=`[::ffff:255.255.0.0]` | host=`[::ffff:255.255.0.0]` |
#### Incorrect IPv6 delimeter priority
| URI | Jetty | urllib3(python) | furl(python) | Spring | chromium |
|---|---|---| --- |---|---|
| `http://[normal.com@]vulndetector.com/` | host=`[normal.com@]` | invalid | invalid | | |
| `http://normal.com[user@vulndetector].com/` | host=`[noirmal.com@vulndetector | | | host=`normal.com` | invalid |
| `http://normal.com[@]vulndetector.com/` | host=`normal.com[@] | | | host=`normal.com` | invalid |
#### Incorrect delimeter priority
| URI | Jetty | urllib3(python) | jersey |
|---|---|---| --- |
| `http://normal.com/#@vulndetector.com` | host=`vulndetector.com` | host=`normal.com` | host=`normal.com` |
| `http://normal.com/?@vulndetector.com` | host=`vulndetector.com` | host=`normal.com` | host=`normal.com` |
### Impact
Differential parsing of URIs in systems using multiple components may result in security by-pass. For example a component that enforces a black list may interpret the URIs differently from one that generates a response.
At the very least, differential parsing may divulge implementation details.
### Patches
Patched in Supported Open Source versions.
* 12.1.5 - Supported and available on Maven Central
* 12.0.31 - Supported and available on Maven Central
* 11.0.x - EOL Release, patches available on [tuxcare](https://tuxcare.com/) and [herodevs](https://www.herodevs.com/)
* 10.0.x - EOL Release, patches available on [tuxcare](https://tuxcare.com/) and [herodevs](https://www.herodevs.com/)
* 9.4.x - EOL Release, patches available on [tuxcare](https://tuxcare.com/) and [herodevs](https://www.herodevs.com/)
### Workarounds
None
### Resources
+ [Java Eclipse Jetty Report_ Incorrect Parsing Priority of the IPv6 Hostname Delimeter.pdf](https://github.com/user-attachments/files/22222625/Java.Eclipse.Jetty.Report_.Incorrect.Parsing.Priority.of.the.IPv6.Hostname.Delimeter.pdf)
+ [Java Eclipse Jetty Report_ The Parsing Priority of the Delimiter.pdf](https://github.com/user-attachments/files/22222626/Java.Eclipse.Jetty.Report_.The.Parsing.Priority.of.the.Delimiter.pdf)
+ [Java Eclipse Jetty Report_ Parsing Difference Due to Deformed Scheme.pdf](https://github.com/user-attachments/files/22222627/Java.Eclipse.Jetty.Report_.Parsing.Difference.Due.to.Deformed.Scheme.pdf)
+ [Java Eclipse Jetty Report_ Improper IPv4-mapped IPv6 Parsing.pdf](https://github.com/user-attachments/files/22222630/Java.Eclipse.Jetty.Report_.Improper.IPv4-mapped.IPv6.Parsing.pdf)
|
CVE-2025-11143
GHSA-wjpw-4j6x-6rwh
|