CVE-2023-36478
HIGHHTTP/2 HPACK integer overflow and buffer allocation
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
Blast Radius
org.eclipse.jetty.http2:http2-hpack☕org.eclipse.jetty.http2:http2-hpack☕org.eclipse.jetty.http3:http3-qpack☕org.eclipse.jetty.http3:http3-qpack☕org.eclipse.jetty.http2:http2-hpackReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Maven packages — download data is not available via public APIs for these ecosystems.
Description
Eclipse Jetty provides a web server and servlet container. In versions 11.0.0 through 11.0.15, 10.0.0 through 10.0.15, and 9.0.0 through 9.4.52, an integer overflow in MetaDataBuilder.checkSize allows for HTTP/2 HPACK header values to
exceed their size limit. MetaDataBuilder.java determines if a header name or value exceeds the size limit, and throws an exception if the limit is exceeded. However, when length is very large and huffman is true, the multiplication by 4 in line 295
will overflow, and length will become negative. (_size+length) will now be negative, and the check on line 296 will not be triggered. Furthermore, MetaDataBuilder.checkSize allows for user-entered HPACK header value sizes to be negative, potentially leading to a very large buffer allocation later on when the user-entered size is multiplied by 2. This means that if a user provides a negative length value (or, more precisely, a length value which, when multiplied by the 4/3 fudge factor, is negative), and this length value is a very large positive number when multiplied by 2, then the user can cause a very large buffer to be allocated on the server. Users of HTTP/2 can be impacted by a remote denial of service attack. The issue has been fixed in versions 11.0.16, 10.0.16, and 9.4.53. There are no known workarounds.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| ☕Maven | org.eclipse.jetty.http2:http2-hpack | ≥ 10.0.0&&< 10.0.16 | 10.0.16 |
| ☕Maven | org.eclipse.jetty.http2:http2-hpack | ≥ 11.0.0&&< 11.0.16 | 11.0.16 |
| ☕Maven | org.eclipse.jetty.http3:http3-qpack | ≥ 10.0.0&&< 10.0.16 | 10.0.16 |
| ☕Maven | org.eclipse.jetty.http3:http3-qpack | ≥ 11.0.0&&< 11.0.16 | 11.0.16 |
| ☕Maven | org.eclipse.jetty.http2:http2-hpack | ≥ 9.3.0&&< 9.4.53 | 9.4.53 |
Research use only. For defensive security, authorized penetration testing, and academic research only. Never execute exploit code against systems without explicit written authorization.
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for org.eclipse.jetty.http2:http2-hpack. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update org.eclipse.jetty.http2:http2-hpack to 10.0.16 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2023-36478 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether CVE-2023-36478 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to CVE-2023-36478. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is CVE-2023-36478 in your dependencies?
O3 detects CVE-2023-36478 across Maven dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.