<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://vulnerability.circl.lu</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Fri, 09 Oct 2026 21:59:20 +0000</lastBuildDate>
    <item>
      <title>fkie_cve-2026-107230</title>
      <link>https://vulnerability.circl.lu/vuln/fkie_cve-2026-107230</link>
      <description>&lt;p&gt;The AsyncHttpClient (AHC) library allows Java applications to easily execute HTTP requests and asynchronously process HTTP responses. From 2.0.0 until 3.0.14, connection-pool partitioning still omits identity-defining fields for Kerberos, SPNEGO, NTLM, and authenticated proxy connections. Logins without a configured principal, proxy realms, identities sharing a user name, and SOCKS or CONNECT proxy logins can reuse a socket authenticated as a different identity. A later request is then executed under the first identity and can expose that identity&amp;#39;s data or authority to another caller. In the affected execution path, SpnegoEngine, NTLM, Kerberos, SPNEGO, SOCKS, and CONNECT control or expose the vulnerable behavior. This issue is fixed in version 3.0.14.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;The AsyncHttpClient (AHC) library allows Java applications to easily execute HTTP requests and asynchronously process HTTP responses. From 2.0.0 until 3.0.14, connection-pool partitioning still omits identity-defining fields for Kerberos, SPNEGO, NTLM, and authenticated proxy connections. Logins without a configured principal, proxy realms, identities sharing a user name, and SOCKS or CONNECT proxy logins can reuse a socket authenticated as a different identity. A later request is then executed under the first identity and can expose that identity&amp;#39;s data or authority to another caller. In the affected execution path, SpnegoEngine, NTLM, Kerberos, SPNEGO, SOCKS, and CONNECT control or expose the vulnerable behavior. This issue is fixed in version 3.0.14.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/fkie_cve-2026-107230</guid>
    </item>
    <item>
      <title>GHSA-v2j5-22fr-j62r — AsyncHttpClient: Pooled connections can still be shared across NTLM, Negotiate and proxy logins</title>
      <link>https://vulnerability.circl.lu/vuln/ghsa-v2j5-22fr-j62r</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Maven: org.asynchttpclient:async-http-client&lt;/p&gt;
&lt;p&gt;### Impact
The fix for GHSA-vvp4-63h8-v5pm in 3.0.13 folded the authenticated principal into the HTTP/1.1 connection pool key, so that a connection one principal authenticated with NTLM, Kerberos or SPNEGO is not handed to another. It left three cases out. In each, a socket that one identity authenticated can still be drawn by a request belonging to a different identity, and the server serves that request as the first one.&lt;/p&gt;
&lt;p&gt;1. **A login with no configured principal.** Kerberos and SPNEGO against the ticket cache or the default JAAS login, which is the usual deployment, leave the realm&amp;#39;s principal unset, and the key stayed unscoped in that case. A request to the same host that carries no credentials at all draws the authenticated socket and is served as the service identity.
2. **The proxy realm.** Only the origin realm went into the key. A connection authenticated to a proxy with NTLM or Negotiate is handed to requests of another proxy identity, or of none, and the proxy acts for them as the first identity.
3. **Identities that share a user name.** Only the principal string went into the key, so `CORP\alice` and `OTHER\alice` shared connections, as did two realms differing only in password, login context, keytab or service principal. The Kerberos login cache in `SpnegoEngine` had the same collision, and it was an unsynchronised map, so concurrent first use could hand one caller&amp;#39;s login to another.&lt;/p&gt;
&lt;p&gt;### Who is Impacted
Applications that authenticate with NTLM, Kerberos or SPN…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Maven: org.asynchttpclient:async-http-client&lt;/p&gt;
&lt;p&gt;### Impact
The fix for GHSA-vvp4-63h8-v5pm in 3.0.13 folded the authenticated principal into the HTTP/1.1 connection pool key, so that a connection one principal authenticated with NTLM, Kerberos or SPNEGO is not handed to another. It left three cases out. In each, a socket that one identity authenticated can still be drawn by a request belonging to a different identity, and the server serves that request as the first one.&lt;/p&gt;
&lt;p&gt;1. **A login with no configured principal.** Kerberos and SPNEGO against the ticket cache or the default JAAS login, which is the usual deployment, leave the realm&amp;#39;s principal unset, and the key stayed unscoped in that case. A request to the same host that carries no credentials at all draws the authenticated socket and is served as the service identity.
2. **The proxy realm.** Only the origin realm went into the key. A connection authenticated to a proxy with NTLM or Negotiate is handed to requests of another proxy identity, or of none, and the proxy acts for them as the first identity.
3. **Identities that share a user name.** Only the principal string went into the key, so `CORP\alice` and `OTHER\alice` shared connections, as did two realms differing only in password, login context, keytab or service principal. The Kerberos login cache in `SpnegoEngine` had the same collision, and it was an unsynchronised map, so concurrent first use could hand one caller&amp;#39;s login to another.&lt;/p&gt;
&lt;p&gt;### Who is Impacted
Applications that authenticate with NTLM, Kerberos or SPN…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/ghsa-v2j5-22fr-j62r</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-107230</title>
      <link>https://vulnerability.circl.lu/vuln/ubuntu-cve-2026-107230</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: async-http-client, Ubuntu:16.04:LTS: async-http-client, Ubuntu:18.04:LTS: async-http-client, Ubuntu:Pro:20.04:LTS: async-http-client, Ubuntu:22.04:LTS: async-http-client, Ubuntu:24.04:LTS: async-http-client, Ubuntu:26.04:LTS: async-http-client&lt;/p&gt;
&lt;p&gt;The AsyncHttpClient (AHC) library allows Java applications to easily execute HTTP requests and asynchronously process HTTP responses. From 2.0.0 until 3.0.14, connection-pool partitioning still omits identity-defining fields for Kerberos, SPNEGO, NTLM, and authenticated proxy connections. Logins without a configured principal, proxy realms, identities sharing a user name, and SOCKS or CONNECT proxy logins can reuse a socket authenticated as a different identity. A later request is then executed under the first identity and can expose that identity&amp;#39;s data or authority to another caller. In the affected execution path, SpnegoEngine, NTLM, Kerberos, SPNEGO, SOCKS, and CONNECT control or expose the vulnerable behavior. This issue is fixed in version 3.0.14.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: async-http-client, Ubuntu:16.04:LTS: async-http-client, Ubuntu:18.04:LTS: async-http-client, Ubuntu:Pro:20.04:LTS: async-http-client, Ubuntu:22.04:LTS: async-http-client, Ubuntu:24.04:LTS: async-http-client, Ubuntu:26.04:LTS: async-http-client&lt;/p&gt;
&lt;p&gt;The AsyncHttpClient (AHC) library allows Java applications to easily execute HTTP requests and asynchronously process HTTP responses. From 2.0.0 until 3.0.14, connection-pool partitioning still omits identity-defining fields for Kerberos, SPNEGO, NTLM, and authenticated proxy connections. Logins without a configured principal, proxy realms, identities sharing a user name, and SOCKS or CONNECT proxy logins can reuse a socket authenticated as a different identity. A later request is then executed under the first identity and can expose that identity&amp;#39;s data or authority to another caller. In the affected execution path, SpnegoEngine, NTLM, Kerberos, SPNEGO, SOCKS, and CONNECT control or expose the vulnerable behavior. This issue is fixed in version 3.0.14.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/ubuntu-cve-2026-107230</guid>
    </item>
  </channel>
</rss>
