12.0.16
15 years ago
2 months ago
Known vulnerabilities in the org.eclipse.jetty:jetty-server package. This does not include vulnerabilities belonging to this package’s dependencies.
Automatically find and fix vulnerabilities affecting your projects. Snyk scans for vulnerabilities and provides fixes for free.
Fix for freeVulnerability | Vulnerable Version |
---|---|
org.eclipse.jetty:jetty-server is a lightweight highly scalable java based web server and servlet engine. Affected versions of this package are vulnerable to Denial of Service (DoS) via the How to fix Denial of Service (DoS)? Upgrade | [9.3.12,9.4.56)[10.0.0,10.0.24)[11.0.0,11.0.24)[12.0.0,12.0.9) |
org.eclipse.jetty:jetty-server is a lightweight highly scalable java based web server and servlet engine. Affected versions of this package are vulnerable to Improper Validation of Syntactic Correctness of Input via the Notes:
How to fix Improper Validation of Syntactic Correctness of Input? Upgrade | [,9.4.57.v20241219)[10.0.0,12.0.12) |
org.eclipse.jetty:jetty-server is a lightweight highly scalable java based web server and servlet engine. Affected versions of this package are vulnerable to Information Exposure such that nonstandard cookie parsing may allow an attacker to smuggle cookies within other cookies, or otherwise perform unintended behavior by tampering with the cookie parsing mechanism. If Jetty sees a cookie VALUE that starts with Note:
A cookie header such as: How to fix Information Exposure? Upgrade | [,9.4.51)[10.0.0,10.0.14)[11.0.0,11.0.14)[12.0.0alpha0,12.0.0.beta0) |
org.eclipse.jetty:jetty-server is a lightweight highly scalable java based web server and servlet engine. Affected versions of this package are vulnerable to Denial of Service (DoS) such that servlets with multipart support (e.g. annotated with Note: This happens even with the default settings of How to fix Denial of Service (DoS)? Upgrade | [,9.4.51)[10.0.0,10.0.14)[11.0.0,11.0.14)[12.0.0.alpha0,12.0.0.beta0) |
org.eclipse.jetty:jetty-server is a lightweight highly scalable java based web server and servlet engine. Affected versions of this package are vulnerable to Information Exposure. If an exception is thrown by the How to fix Information Exposure? Upgrade | [11.0.0,11.0.3)[10.0.0,10.0.3)[,9.4.41) |
org.eclipse.jetty:jetty-server is a lightweight highly scalable java based web server and servlet engine. Affected versions of this package are vulnerable to Denial of Service (DoS). When Jetty handles a request containing multiple Accept headers with a large number of “quality” (i.e. q) parameters, the server may enter a denial of service (DoS) state due to high CPU usage processing those quality values, resulting in minutes of CPU time exhausted processing those quality values. How to fix Denial of Service (DoS)? Upgrade | [9.4.6.v20170531,9.4.37.v20210219)[10.0.0,10.0.1)[11.0.0,11.0.1) |
org.eclipse.jetty:jetty-server is a lightweight highly scalable java based web server and servlet engine. Affected versions of this package are vulnerable to HTTP Request Smuggling. If GZIP request body inflation is enabled and requests from different clients are multiplexed onto a single connection, and if an attacker can send a request with a body that is received entirely but not consumed by the application, then a subsequent request on the same connection will see that body prepended to its body. The attacker will not see any data but may inject data into the body of the subsequent request. How to fix HTTP Request Smuggling? Upgrade | [9.4.0.RC0,9.4.35.v20201120)[10.0.0.alpha0,10.0.0.beta3)[11.0.0.alpha0,11.0.0.beta3) |
org.eclipse.jetty:jetty-server is a lightweight highly scalable java based web server and servlet engine. Affected versions of this package are vulnerable to Operation on a Resource after Expiration or Release. In Eclipse Jetty, versions 9.4.27.v20200227 to 9.4.29.v20200521, in case of too large response headers, Jetty throws an exception to produce an HTTP 431 error. When this happens, the ByteBuffer containing the HTTP response headers is released back to the ByteBufferPool twice. Because of this double release, two threads can acquire the same ByteBuffer from the pool and while thread1 is about to use the ByteBuffer to write response1 data, thread2 fills the ByteBuffer with response2 data. Thread1 then proceeds to write the buffer that now contains response2 data. This results in client1, which issued request1 and expects responses, to see response2 which could contain sensitive data belonging to client2 (HTTP session ids, authentication credentials, etc.). How to fix Operation on a Resource after Expiration or Release? Upgrade | [9.4.27.v20200227,9.4.30.v20200611) |