In Eclipse Jetty, versions 9.2.x and older, 9.3.x (all configurations), and 9.4.x (non-default configuration with RFC2616 compliance enabled
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- Fix
- Fixed in 9.3.24, 9.4.11, 9.2.25.v20180606, 9.3.24.v20180605
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
Summary
In Eclipse Jetty, versions 9.2.x and older, 9.3.x (all configurations), and 9.4.x (non-default configuration with RFC2616 compliance enabled), transfer-encoding chunks are handled poorly. The chunk length parsing was vulnerable to an integer overflow. Thus a large chunk size could be interpreted as a smaller chunk size and content sent as chunk body could be interpreted as a pipelined request. If Jetty was deployed behind an intermediary that imposed some authorization and that intermediary allowed arbitrarily large chunks to be passed on unchanged, then this flaw could be used to bypass the authorization imposed by the intermediary as the fake pipelined request would not be interpreted by the intermediary as a request.
Timeline
- CVE published
- Record last updated
- EPSS reached 10%
FIRST estimates at least a 10% chance of exploitation in the next 30 days
Affected versions
- The Eclipse Foundation Eclipse Jetty
through 9.2.0; From 9.3.0; fixed in 9.3.24; From 9.4.0; fixed in 9.4.11
- org.eclipse.jetty:jetty-serverMaven
fixed in 9.2.25.v20180606
- org.eclipse.jetty:jetty-serverMaven
From 9.3.0 · fixed in 9.3.24.v20180605
References 16
debian.org
securitytracker.com
lists.apache.org
- thread.html/708d94141126eac03011144a971a6411fcac16d9c248d1d535a39451@<solr-user.lucene.apache.org>
- thread.html/053d9ce4d579b02203db18545fee5e33f35f2932885459b74d1e4272@<issues.activemq.apache.org>
- thread.html/9317fd092b257a0815434b116a8af8daea6e920b6673f4fd5583d5fe@<commits.druid.apache.org>
- thread.html/r1b103833cb5bc8466e24ff0ecc5e75b45a705334ab6a444e64e840a0@<issues.bookkeeper.apache.org>
- thread.html/ra6f956ed4ec2855583b2d0c8b4802b450f593d37b77509b48cd5d574@<commits.druid.apache.org>
- thread.html/r41af10c4adec8d34a969abeb07fd0d6ad0c86768b751464f1cdd23e8@<commits.druid.apache.org>
- thread.html/r9159c9e7ec9eac1613da2dbaddbc15691a13d4dbb2c8be974f42e6ae@<commits.druid.apache.org>