WaratekVRT Sign in

High async-http-client CVEs

2 CVEs

Reset
More filters (2)
Columns
Vendor asynchttpclient project✕Product async-http-client✕
Overview 2 matches · 0 protected · 0 exploited · 0 CISA KEV · 0 public PoC · 0 EPSS ≥ 0.5
2matches 0protected0.0% 0exploited0.0% 0CISA KEV0.0% 0public PoC0.0% 0EPSS ≥ 0.50.0%
Protected by Waratek 0 0.0% Rule in development 0 0.0% Mitigation candidate 0 0.0% No exploit published 2 100.0%
Critical 0 0.0% High 2 100.0% Medium 0 0.0% Low 0 0.0% None 0 0.0% Unknown 0 0.0%
blocked by ARMR today 0 0.0% partly blocked 0 0.0% not blocked 2 100.0% not established 0 0.0% unrecorded 0 0.0%
Exploited 0 0.0% Working exploit published 0 0.0% Proof of concept only 1 50.0% Forecast only 0 0.0% No public exploit 1 50.0%
split by peak 1 / year
No exploit published: 2 High: 2 not blocked: 2 No public exploit: 1Proof of concept only: 1
20171 No exploit published1 High1 not blocked1 No public exploit1 20180 20190 20200 20210 20220 20230 20240 20250 20261 No exploit published1 High1 not blocked1 Proof of concept only1
2017201820192020202120222023202420252026
2 matches Sign in to download these CVEs as CSV or JSON, or to follow them in a feed.
CVE Severity Published▾ Status Exploitation Description
CVE-2026-45300 High 2026-06-05 No exploit published Proof of concept only The AsyncHttpClient (AHC) library allows Java applications to easily execute HTTP requests and asynchronously process HTTP responses. Versions on the 2.x branch prior to 2.15.0 and the 3.x branch prior to 3.0.10 leak `Cookie` headers to cross-origin redirect targets. When following a redirect to a different origin, the `propagatedHeaders()` method in `Redirect30xInterceptor.java` strips `Authorization` and `Proxy-Authorization` headers but does not strip the `Cookie` header, causing session cookies and other sensitive cookie values to be sent to attacker-controlled servers. Versions 2.15.0 and 3.0.10 patch the issue.
CVE-2017-14063 High 2017-08-31 No exploit published No public exploit Async Http Client (aka async-http-client) before 2.0.35 can be tricked into connecting to a host different from the one extracted by java.net.URI if a '?' character occurs in a fragment identifier. Similar bugs were previously identified in cURL (CVE-2016-8624) and Oracle Java 8 java.net.URL.