Update dependency org.asynchttpclient:async-http-client to v2.16.1 [SECURITY] (master) - #729
Draft
renovatebot-confluentinc[bot] wants to merge 1 commit into
Draft
renovatebot-confluentinc[bot] wants to merge 1 commit into
renovatebot-confluentinc[bot] wants to merge 1 commit into
Conversation
renovatebot-confluentinc
Bot
changed the title
renovatebot-confluentinc
Bot
force-pushed
the
renovate/master-asynchttpclient.version
branch
from
September 18, 2026 13:56
36fbd50 to
71e5275
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
For any questions/concerns about this PR, please review the Renovate Bot wiki/FAQs, or the #renovatebot Slack channel.
This PR contains the following updates:
2.15.0→2.16.1AsyncHttpClient stores cookie for an unrelated domain (cookie tossing) via ThreadSafeCookieStore
CVE-2026-55688 / GHSA-m452-q8c9-rg2f
More information
Details
Impact
A cookie tossing / cookie injection issue (CWE-1275).
ThreadSafeCookieStorestored a cookie under the value of itsDomainattribute without verifying that the responding host is allowed to set a cookie for that domain (RFC 6265 §5.3 step 6). A host the client connects to can therefore plant a cookie scoped to an unrelated domain, and the client will then send that cookie on later requests to that domain.Who is Impacted
Applications that use a single
AsyncHttpClientinstance - and thus the default, sharedCookieStore- to reach both an attacker-influenced host and a trusted host. Typical exposure: crawlers, link-preview / webhook fetchers, SSRF-style "fetch this URL" features, multi-backend aggregators, or following redirects to an attacker-controlled host. The attacker can write a cookie the client presents to the victim host (session fixation, overwriting a session id / CSRF-token cookie); they cannot read the victim host's cookies. Applications that talk only to a fixed trusted backend, or that disable/scope the cookie store, are not exposed.Patches
Fixed in 3.0.11 and 2.16.0
Workarounds
Severity
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:N/I:L/A:NReferences
This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).
AsyncHttpClient's unbounded HTTP/1.1 response decompression enables a decompression-bomb denial of service
CVE-2026-85721 / GHSA-7grg-jcf7-rpmx
More information
Details
Impact
With automatic response decompression enabled (the default), the HTTP/1.1 path decompresses response bodies with no limit on the total output size. A hostile or compromised server, or an attacker who can change a response in transit, can send a small compressed body that inflates without bound in memory, exhausting the client's heap and causing an OutOfMemoryError. gzip, deflate and snappy are always available as vectors; brotli and zstd apply only when those optional codecs are on the classpath.
Affected versions
The HTTP/2 path carries its own limit from 3.0.11 onward. On 3.0.8, 3.0.9 and 3.0.10 the HTTP/2 decompressor is also unbounded, so on those versions switching to HTTP/2 is not a mitigation.
Patches
Fixed in 3.0.12 on the 3.x line and in 2.16.1 on the 2.x line. The fix counts the decompressed bytes produced for each response and fails the response once the configured maximum is exceeded, so the limit applies to the whole body rather than to any single chunk.
Workarounds
On 3.x, disable automatic decompression (setEnableAutomaticDecompression(false)) and decompress manually with your own size limit. The 2.x line has no such setting; the decompressor is installed unconditionally, so the only option there is to remove the inflater handler through httpAdditionalChannelInitializer. On either line, running the client behind a proxy that caps response sizes also works.
Details
ChannelManager.newHttpContentDecompressor() created Netty's HttpContentDecompressor without any bound, and Netty's own maxAllocation parameter limits a single decode step rather than the accumulated size of a response, so it cannot bound a decompression bomb delivered as many small chunks. The fix tracks the accumulated decompressed size per response instead.
Note that 3.0.12 is itself affected by a separate issue, GHSA-rqf5-2wxv-rjf4, where a Digest challenge the client cannot read downgrades to Basic and sends the password in cleartext. Upgrade to 3.0.13 to pick up both fixes.
Severity
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:HReferences
This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).
AsyncHttpClient re-sends client-wide realm credentials to a cross-origin redirect target
CVE-2026-85717 / GHSA-f8m2-889x-vw4x
More information
Details
Impact
A client configured with a client-wide realm (a Realm set on the config builder rather than on an individual request) and following redirects could re-send those credentials to a redirect target on a different origin. The redirect code strips the per-exchange realm, but when the target answered 401 the credentials were re-derived from the client config, handing Basic or Digest credentials, or a Negotiate or NTLM token, to an attacker controlled origin. This is a residual of the earlier cross-origin credential leak advisories, whose strip this bypassed.
Affected versions
Releases below those floors are covered by the earlier advisories GHSA-cmxv-58fp-fm3g and GHSA-fmxf-pm6p-7xgm: the cross-origin strip that this issue bypasses did not exist yet, so the leak there is the original one rather than this residual.
Patches
Fixed in 3.0.12 on the 3.x line and in 2.16.1 on the 2.x line. The realm is taken from the per-exchange state that the redirect already cleared, rather than being re-derived from the client configuration.
Workarounds
Set the Realm on the individual request instead of on the client configuration. A per-request realm is stripped correctly on a cross-origin redirect while still authenticating same-origin, so this is a complete workaround with no loss of function. Turning off follow-redirects also avoids it. Note that setStripAuthorizationOnRedirect(true) is not a workaround: it forces the strip, but the configuration fallback re-derived the realm regardless.
Details
The interceptor read the realm as the request's realm or, failing that, the client configuration's realm, which re-attached the config realm after the redirect strip had cleared it. It now reads the realm held on the response future. See also GHSA-cmxv-58fp-fm3g and GHSA-fmxf-pm6p-7xgm.
Severity
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:N/A:NReferences
This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).
AsyncHttpClient sends origin credentials to the proxy on the plaintext CONNECT request
CVE-2026-85720 / GHSA-xr57-gcx8-52hf
More information
Details
Impact
When a request uses an HTTP proxy to reach an HTTPS origin, the client opens the tunnel with a plaintext CONNECT sent to the proxy before any TLS exists. On affected versions the origin's preemptive credentials were added to that CONNECT. A Basic realm sent
Authorization: Basic base64(user:pass)to the proxy in the clear, and NTLM, SPNEGO or Kerberos realms sent their token. The proxy, and anyone who can read the client to proxy hop, saw credentials that were meant only for the origin.Affected versions
Patches
Fixed in 3.0.12 on the 3.x line and in 2.16.1 on the 2.x line. The origin Basic or Digest Authorization is no longer put on the CONNECT; it is added to the tunnelled request once the tunnel is up. The per-connection NTLM, Kerberos and SPNEGO token is likewise no longer attached on the tunnel path; it never reached the origin there in any case, and the challenge flow still negotiates it inside the tunnel.
Workarounds
Do not use preemptive origin authentication together with an HTTP proxy, or reach the origin without a CONNECT proxy.
Details
NettyRequestFactory added the origin Authorization to every request it built, including the CONNECT, and NettyRequestSender did the same for the per-connection NTLM or SPNEGO token in sendRequestWithNewChannel. Both now skip the CONNECT.
Note that 3.0.12 is itself affected by a separate issue, GHSA-rqf5-2wxv-rjf4, where a Digest challenge the client cannot read downgrades to Basic and sends the password in cleartext. Upgrade to 3.0.13 to pick up both fixes.
Severity
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:NReferences
This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).
Configuration
📅 Schedule: (UTC)
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR has been generated by Mend Renovate CLI.