httpcore2

Version	Released
`2.13.0` minor	Sep 14, 2026
`2.12.0` minor	Aug 18, 2026
`2.11.0` minor	Aug 18, 2026
`2.10.0` minor	Aug 09, 2026
`2.9.1` patch 1 CVE	Jul 24, 2026
`2.9.0` minor 1 CVE	Jul 23, 2026
`2.8.0` minor 1 CVE	Jul 23, 2026
`2.7.0` minor 1 CVE	Jul 14, 2026
`2.6.0` minor 1 CVE	Jul 14, 2026
`2.5.0` minor 1 CVE	Jun 25, 2026
`2.4.0` minor 1 CVE	Jun 11, 2026
`2.3.0` minor 1 CVE	Jun 01, 2026
`2.2.0` minor 1 CVE	May 17, 2026
`2.1.0` minor 1 CVE	May 15, 2026
`2.0.0` major 1 CVE	May 12, 2026
`2.0.0b1` pre 1 CVE	May 11, 2026
`0.0.0` initial 1 CVE	May 11, 2026

2.13.0 minor

Sep 14, 2026

2.12.0 minor

Aug 18, 2026

2.11.0 minor

Aug 18, 2026

2.10.0 minor

Aug 09, 2026

2.9.1 patch

1 CVE

CVE-2026-84381 PYSEC-2026-3844 GHSA-7mj9-2mp8-4m2p PYSEC-2026-3845 Sep 10, 2026

HTTPX2: Secure WebSocket traffic sent without TLS through SOCKS proxies

8.1 / 10

High

Adjacent Low None None Unchanged High High None

Summary

httpcore2 does not start TLS for wss:// connections routed through a SOCKS5 proxy. The WebSocket opening handshake and all subsequent frames are sent in plaintext through the proxy path, despite the caller selecting the secure wss scheme.

The transport flaw affects httpcore2 releases before 2.10.0. HTTPX2 exposed this behavior through its public Client.websocket() and AsyncClient.websocket() APIs from 2.6.0 through 2.9.1.

Details

The synchronous and asynchronous SOCKS5 connection implementations upgrade the established proxy tunnel to TLS only when the remote origin scheme is https. The equivalent check does not include wss. After the SOCKS5 handshake succeeds, the raw stream is therefore passed directly to the HTTP/1.1 connection, which writes the WebSocket upgrade request without first performing a TLS handshake or verifying the destination certificate.

For example, an application using HTTPX2 2.6.0 through 2.9.1 may open an authenticated WebSocket through a SOCKS proxy:

import httpx2

with httpx2.Client(proxy="socks5://proxy.example:1080") as client:
    with client.websocket(
        "wss://service.example/private?token=query-secret",
        headers={"Authorization": "Bearer header-secret"},
        cookies={"session": "cookie-secret"},
    ) as websocket:
        websocket.send_text("private message")

On affected versions, the stream passing through the SOCKS proxy begins with a plaintext request such as:

GET /private?token=query-secret HTTP/1.1
Host: service.example
Authorization: Bearer header-secret
Cookie: session=cookie-secret

Before HTTPX2 2.6.0, the same underlying httpcore2 behavior could be reached by integrations constructing a WebSocket upgrade request through the low-level transport API, but HTTPX2 did not yet provide its native WebSocket client API.

A normal secure WebSocket server will usually reject these plaintext bytes because it expects a TLS ClientHello. However, a malicious or compromised SOCKS proxy can accept the SOCKS connection, observe the plaintext handshake, return a forged 101 Switching Protocols response, and then read or modify WebSocket frames in both directions. An observer between the proxy and destination may also read the plaintext traffic.

RFC 6455 requires a client using a secure WebSocket connection to perform the TLS handshake before sending the WebSocket opening handshake. A wss URI promises confidentiality, integrity, and endpoint authentication through TLS.

Impact

An attacker able to control or observe the SOCKS proxy path can obtain URL query parameters, authorization headers, cookies, and application messages that the caller expected TLS to protect. Because no TLS handshake occurs, certificate verification also does not occur, allowing an attacker controlling the proxy to impersonate the WebSocket server and inject or alter messages.

Only wss:// connections routed through a SOCKS5 proxy are affected. Direct wss:// connections and ordinary https:// requests through SOCKS already start TLS correctly.

Mitigation

Upgrade HTTPX2 and httpcore2 to 2.10.0 or later. Patched versions start TLS for both https and wss origins in the synchronous and asynchronous SOCKS5 connection paths.

If upgrading is not immediately possible, do not route wss:// connections through a SOCKS proxy. Use a direct secure WebSocket connection or another transport that performs and verifies TLS to the WebSocket origin.

Affected versions


          0.0.0


          2.0.0


          2.0.0b1


          2.1.0


          2.2.0


          2.3.0


          2.4.0


          2.5.0


          2.6.0


          2.7.0


          2.8.0


          2.9.0

+ 1 more


            2.9.1

Fixed in


          2.10.0

References

Updated Sep 10, 2026 · Source: OSV.dev

Jul 24, 2026

2.9.0 minor

1 CVE

CVE-2026-84381 PYSEC-2026-3844 GHSA-7mj9-2mp8-4m2p PYSEC-2026-3845 Sep 10, 2026

HTTPX2: Secure WebSocket traffic sent without TLS through SOCKS proxies

8.1 / 10

High

Adjacent Low None None Unchanged High High None

Summary

httpcore2 does not start TLS for wss:// connections routed through a SOCKS5 proxy. The WebSocket opening handshake and all subsequent frames are sent in plaintext through the proxy path, despite the caller selecting the secure wss scheme.

The transport flaw affects httpcore2 releases before 2.10.0. HTTPX2 exposed this behavior through its public Client.websocket() and AsyncClient.websocket() APIs from 2.6.0 through 2.9.1.

Details

The synchronous and asynchronous SOCKS5 connection implementations upgrade the established proxy tunnel to TLS only when the remote origin scheme is https. The equivalent check does not include wss. After the SOCKS5 handshake succeeds, the raw stream is therefore passed directly to the HTTP/1.1 connection, which writes the WebSocket upgrade request without first performing a TLS handshake or verifying the destination certificate.

For example, an application using HTTPX2 2.6.0 through 2.9.1 may open an authenticated WebSocket through a SOCKS proxy:

import httpx2

with httpx2.Client(proxy="socks5://proxy.example:1080") as client:
    with client.websocket(
        "wss://service.example/private?token=query-secret",
        headers={"Authorization": "Bearer header-secret"},
        cookies={"session": "cookie-secret"},
    ) as websocket:
        websocket.send_text("private message")

On affected versions, the stream passing through the SOCKS proxy begins with a plaintext request such as:

GET /private?token=query-secret HTTP/1.1
Host: service.example
Authorization: Bearer header-secret
Cookie: session=cookie-secret

Before HTTPX2 2.6.0, the same underlying httpcore2 behavior could be reached by integrations constructing a WebSocket upgrade request through the low-level transport API, but HTTPX2 did not yet provide its native WebSocket client API.

A normal secure WebSocket server will usually reject these plaintext bytes because it expects a TLS ClientHello. However, a malicious or compromised SOCKS proxy can accept the SOCKS connection, observe the plaintext handshake, return a forged 101 Switching Protocols response, and then read or modify WebSocket frames in both directions. An observer between the proxy and destination may also read the plaintext traffic.

RFC 6455 requires a client using a secure WebSocket connection to perform the TLS handshake before sending the WebSocket opening handshake. A wss URI promises confidentiality, integrity, and endpoint authentication through TLS.

Impact

An attacker able to control or observe the SOCKS proxy path can obtain URL query parameters, authorization headers, cookies, and application messages that the caller expected TLS to protect. Because no TLS handshake occurs, certificate verification also does not occur, allowing an attacker controlling the proxy to impersonate the WebSocket server and inject or alter messages.

Only wss:// connections routed through a SOCKS5 proxy are affected. Direct wss:// connections and ordinary https:// requests through SOCKS already start TLS correctly.

Mitigation

Upgrade HTTPX2 and httpcore2 to 2.10.0 or later. Patched versions start TLS for both https and wss origins in the synchronous and asynchronous SOCKS5 connection paths.

If upgrading is not immediately possible, do not route wss:// connections through a SOCKS proxy. Use a direct secure WebSocket connection or another transport that performs and verifies TLS to the WebSocket origin.

Affected versions


          0.0.0


          2.0.0


          2.0.0b1


          2.1.0


          2.2.0


          2.3.0


          2.4.0


          2.5.0


          2.6.0


          2.7.0


          2.8.0


          2.9.0

+ 1 more


            2.9.1

Fixed in


          2.10.0

References

Updated Sep 10, 2026 · Source: OSV.dev

Jul 23, 2026

2.8.0 minor

1 CVE

CVE-2026-84381 PYSEC-2026-3844 GHSA-7mj9-2mp8-4m2p PYSEC-2026-3845 Sep 10, 2026

HTTPX2: Secure WebSocket traffic sent without TLS through SOCKS proxies

8.1 / 10

High

Adjacent Low None None Unchanged High High None

Summary

httpcore2 does not start TLS for wss:// connections routed through a SOCKS5 proxy. The WebSocket opening handshake and all subsequent frames are sent in plaintext through the proxy path, despite the caller selecting the secure wss scheme.

The transport flaw affects httpcore2 releases before 2.10.0. HTTPX2 exposed this behavior through its public Client.websocket() and AsyncClient.websocket() APIs from 2.6.0 through 2.9.1.

Details

The synchronous and asynchronous SOCKS5 connection implementations upgrade the established proxy tunnel to TLS only when the remote origin scheme is https. The equivalent check does not include wss. After the SOCKS5 handshake succeeds, the raw stream is therefore passed directly to the HTTP/1.1 connection, which writes the WebSocket upgrade request without first performing a TLS handshake or verifying the destination certificate.

For example, an application using HTTPX2 2.6.0 through 2.9.1 may open an authenticated WebSocket through a SOCKS proxy:

import httpx2

with httpx2.Client(proxy="socks5://proxy.example:1080") as client:
    with client.websocket(
        "wss://service.example/private?token=query-secret",
        headers={"Authorization": "Bearer header-secret"},
        cookies={"session": "cookie-secret"},
    ) as websocket:
        websocket.send_text("private message")

On affected versions, the stream passing through the SOCKS proxy begins with a plaintext request such as:

GET /private?token=query-secret HTTP/1.1
Host: service.example
Authorization: Bearer header-secret
Cookie: session=cookie-secret

Before HTTPX2 2.6.0, the same underlying httpcore2 behavior could be reached by integrations constructing a WebSocket upgrade request through the low-level transport API, but HTTPX2 did not yet provide its native WebSocket client API.

A normal secure WebSocket server will usually reject these plaintext bytes because it expects a TLS ClientHello. However, a malicious or compromised SOCKS proxy can accept the SOCKS connection, observe the plaintext handshake, return a forged 101 Switching Protocols response, and then read or modify WebSocket frames in both directions. An observer between the proxy and destination may also read the plaintext traffic.

RFC 6455 requires a client using a secure WebSocket connection to perform the TLS handshake before sending the WebSocket opening handshake. A wss URI promises confidentiality, integrity, and endpoint authentication through TLS.

Impact

An attacker able to control or observe the SOCKS proxy path can obtain URL query parameters, authorization headers, cookies, and application messages that the caller expected TLS to protect. Because no TLS handshake occurs, certificate verification also does not occur, allowing an attacker controlling the proxy to impersonate the WebSocket server and inject or alter messages.

Only wss:// connections routed through a SOCKS5 proxy are affected. Direct wss:// connections and ordinary https:// requests through SOCKS already start TLS correctly.

Mitigation

Upgrade HTTPX2 and httpcore2 to 2.10.0 or later. Patched versions start TLS for both https and wss origins in the synchronous and asynchronous SOCKS5 connection paths.

If upgrading is not immediately possible, do not route wss:// connections through a SOCKS proxy. Use a direct secure WebSocket connection or another transport that performs and verifies TLS to the WebSocket origin.

Affected versions


          0.0.0


          2.0.0


          2.0.0b1


          2.1.0


          2.2.0


          2.3.0


          2.4.0


          2.5.0


          2.6.0


          2.7.0


          2.8.0


          2.9.0

+ 1 more


            2.9.1

Fixed in


          2.10.0

References

Updated Sep 10, 2026 · Source: OSV.dev

Jul 23, 2026

2.7.0 minor

1 CVE

CVE-2026-84381 PYSEC-2026-3844 GHSA-7mj9-2mp8-4m2p PYSEC-2026-3845 Sep 10, 2026

HTTPX2: Secure WebSocket traffic sent without TLS through SOCKS proxies

8.1 / 10

High

Adjacent Low None None Unchanged High High None

Summary

httpcore2 does not start TLS for wss:// connections routed through a SOCKS5 proxy. The WebSocket opening handshake and all subsequent frames are sent in plaintext through the proxy path, despite the caller selecting the secure wss scheme.

The transport flaw affects httpcore2 releases before 2.10.0. HTTPX2 exposed this behavior through its public Client.websocket() and AsyncClient.websocket() APIs from 2.6.0 through 2.9.1.

Details

The synchronous and asynchronous SOCKS5 connection implementations upgrade the established proxy tunnel to TLS only when the remote origin scheme is https. The equivalent check does not include wss. After the SOCKS5 handshake succeeds, the raw stream is therefore passed directly to the HTTP/1.1 connection, which writes the WebSocket upgrade request without first performing a TLS handshake or verifying the destination certificate.

For example, an application using HTTPX2 2.6.0 through 2.9.1 may open an authenticated WebSocket through a SOCKS proxy:

import httpx2

with httpx2.Client(proxy="socks5://proxy.example:1080") as client:
    with client.websocket(
        "wss://service.example/private?token=query-secret",
        headers={"Authorization": "Bearer header-secret"},
        cookies={"session": "cookie-secret"},
    ) as websocket:
        websocket.send_text("private message")

On affected versions, the stream passing through the SOCKS proxy begins with a plaintext request such as:

GET /private?token=query-secret HTTP/1.1
Host: service.example
Authorization: Bearer header-secret
Cookie: session=cookie-secret

Before HTTPX2 2.6.0, the same underlying httpcore2 behavior could be reached by integrations constructing a WebSocket upgrade request through the low-level transport API, but HTTPX2 did not yet provide its native WebSocket client API.

A normal secure WebSocket server will usually reject these plaintext bytes because it expects a TLS ClientHello. However, a malicious or compromised SOCKS proxy can accept the SOCKS connection, observe the plaintext handshake, return a forged 101 Switching Protocols response, and then read or modify WebSocket frames in both directions. An observer between the proxy and destination may also read the plaintext traffic.

RFC 6455 requires a client using a secure WebSocket connection to perform the TLS handshake before sending the WebSocket opening handshake. A wss URI promises confidentiality, integrity, and endpoint authentication through TLS.

Impact

An attacker able to control or observe the SOCKS proxy path can obtain URL query parameters, authorization headers, cookies, and application messages that the caller expected TLS to protect. Because no TLS handshake occurs, certificate verification also does not occur, allowing an attacker controlling the proxy to impersonate the WebSocket server and inject or alter messages.

Only wss:// connections routed through a SOCKS5 proxy are affected. Direct wss:// connections and ordinary https:// requests through SOCKS already start TLS correctly.

Mitigation

Upgrade HTTPX2 and httpcore2 to 2.10.0 or later. Patched versions start TLS for both https and wss origins in the synchronous and asynchronous SOCKS5 connection paths.

If upgrading is not immediately possible, do not route wss:// connections through a SOCKS proxy. Use a direct secure WebSocket connection or another transport that performs and verifies TLS to the WebSocket origin.

Affected versions


          0.0.0


          2.0.0


          2.0.0b1


          2.1.0


          2.2.0


          2.3.0


          2.4.0


          2.5.0


          2.6.0


          2.7.0


          2.8.0


          2.9.0

+ 1 more


            2.9.1

Fixed in


          2.10.0

References

Updated Sep 10, 2026 · Source: OSV.dev

Jul 14, 2026

2.6.0 minor

1 CVE

CVE-2026-84381 PYSEC-2026-3844 GHSA-7mj9-2mp8-4m2p PYSEC-2026-3845 Sep 10, 2026

HTTPX2: Secure WebSocket traffic sent without TLS through SOCKS proxies

8.1 / 10

High

Adjacent Low None None Unchanged High High None

Summary

httpcore2 does not start TLS for wss:// connections routed through a SOCKS5 proxy. The WebSocket opening handshake and all subsequent frames are sent in plaintext through the proxy path, despite the caller selecting the secure wss scheme.

The transport flaw affects httpcore2 releases before 2.10.0. HTTPX2 exposed this behavior through its public Client.websocket() and AsyncClient.websocket() APIs from 2.6.0 through 2.9.1.

Details

The synchronous and asynchronous SOCKS5 connection implementations upgrade the established proxy tunnel to TLS only when the remote origin scheme is https. The equivalent check does not include wss. After the SOCKS5 handshake succeeds, the raw stream is therefore passed directly to the HTTP/1.1 connection, which writes the WebSocket upgrade request without first performing a TLS handshake or verifying the destination certificate.

For example, an application using HTTPX2 2.6.0 through 2.9.1 may open an authenticated WebSocket through a SOCKS proxy:

import httpx2

with httpx2.Client(proxy="socks5://proxy.example:1080") as client:
    with client.websocket(
        "wss://service.example/private?token=query-secret",
        headers={"Authorization": "Bearer header-secret"},
        cookies={"session": "cookie-secret"},
    ) as websocket:
        websocket.send_text("private message")

On affected versions, the stream passing through the SOCKS proxy begins with a plaintext request such as:

GET /private?token=query-secret HTTP/1.1
Host: service.example
Authorization: Bearer header-secret
Cookie: session=cookie-secret

Before HTTPX2 2.6.0, the same underlying httpcore2 behavior could be reached by integrations constructing a WebSocket upgrade request through the low-level transport API, but HTTPX2 did not yet provide its native WebSocket client API.

A normal secure WebSocket server will usually reject these plaintext bytes because it expects a TLS ClientHello. However, a malicious or compromised SOCKS proxy can accept the SOCKS connection, observe the plaintext handshake, return a forged 101 Switching Protocols response, and then read or modify WebSocket frames in both directions. An observer between the proxy and destination may also read the plaintext traffic.

RFC 6455 requires a client using a secure WebSocket connection to perform the TLS handshake before sending the WebSocket opening handshake. A wss URI promises confidentiality, integrity, and endpoint authentication through TLS.

Impact

An attacker able to control or observe the SOCKS proxy path can obtain URL query parameters, authorization headers, cookies, and application messages that the caller expected TLS to protect. Because no TLS handshake occurs, certificate verification also does not occur, allowing an attacker controlling the proxy to impersonate the WebSocket server and inject or alter messages.

Only wss:// connections routed through a SOCKS5 proxy are affected. Direct wss:// connections and ordinary https:// requests through SOCKS already start TLS correctly.

Mitigation

Upgrade HTTPX2 and httpcore2 to 2.10.0 or later. Patched versions start TLS for both https and wss origins in the synchronous and asynchronous SOCKS5 connection paths.

If upgrading is not immediately possible, do not route wss:// connections through a SOCKS proxy. Use a direct secure WebSocket connection or another transport that performs and verifies TLS to the WebSocket origin.

Affected versions


          0.0.0


          2.0.0


          2.0.0b1


          2.1.0


          2.2.0


          2.3.0


          2.4.0


          2.5.0


          2.6.0


          2.7.0


          2.8.0


          2.9.0

+ 1 more


            2.9.1

Fixed in


          2.10.0

References

Updated Sep 10, 2026 · Source: OSV.dev

Jul 14, 2026

2.5.0 minor

1 CVE

CVE-2026-84381 PYSEC-2026-3844 GHSA-7mj9-2mp8-4m2p PYSEC-2026-3845 Sep 10, 2026

HTTPX2: Secure WebSocket traffic sent without TLS through SOCKS proxies

8.1 / 10

High

Adjacent Low None None Unchanged High High None

Summary

httpcore2 does not start TLS for wss:// connections routed through a SOCKS5 proxy. The WebSocket opening handshake and all subsequent frames are sent in plaintext through the proxy path, despite the caller selecting the secure wss scheme.

The transport flaw affects httpcore2 releases before 2.10.0. HTTPX2 exposed this behavior through its public Client.websocket() and AsyncClient.websocket() APIs from 2.6.0 through 2.9.1.

Details

The synchronous and asynchronous SOCKS5 connection implementations upgrade the established proxy tunnel to TLS only when the remote origin scheme is https. The equivalent check does not include wss. After the SOCKS5 handshake succeeds, the raw stream is therefore passed directly to the HTTP/1.1 connection, which writes the WebSocket upgrade request without first performing a TLS handshake or verifying the destination certificate.

For example, an application using HTTPX2 2.6.0 through 2.9.1 may open an authenticated WebSocket through a SOCKS proxy:

import httpx2

with httpx2.Client(proxy="socks5://proxy.example:1080") as client:
    with client.websocket(
        "wss://service.example/private?token=query-secret",
        headers={"Authorization": "Bearer header-secret"},
        cookies={"session": "cookie-secret"},
    ) as websocket:
        websocket.send_text("private message")

On affected versions, the stream passing through the SOCKS proxy begins with a plaintext request such as:

GET /private?token=query-secret HTTP/1.1
Host: service.example
Authorization: Bearer header-secret
Cookie: session=cookie-secret

Before HTTPX2 2.6.0, the same underlying httpcore2 behavior could be reached by integrations constructing a WebSocket upgrade request through the low-level transport API, but HTTPX2 did not yet provide its native WebSocket client API.

A normal secure WebSocket server will usually reject these plaintext bytes because it expects a TLS ClientHello. However, a malicious or compromised SOCKS proxy can accept the SOCKS connection, observe the plaintext handshake, return a forged 101 Switching Protocols response, and then read or modify WebSocket frames in both directions. An observer between the proxy and destination may also read the plaintext traffic.

RFC 6455 requires a client using a secure WebSocket connection to perform the TLS handshake before sending the WebSocket opening handshake. A wss URI promises confidentiality, integrity, and endpoint authentication through TLS.

Impact

An attacker able to control or observe the SOCKS proxy path can obtain URL query parameters, authorization headers, cookies, and application messages that the caller expected TLS to protect. Because no TLS handshake occurs, certificate verification also does not occur, allowing an attacker controlling the proxy to impersonate the WebSocket server and inject or alter messages.

Only wss:// connections routed through a SOCKS5 proxy are affected. Direct wss:// connections and ordinary https:// requests through SOCKS already start TLS correctly.

Mitigation

Upgrade HTTPX2 and httpcore2 to 2.10.0 or later. Patched versions start TLS for both https and wss origins in the synchronous and asynchronous SOCKS5 connection paths.

If upgrading is not immediately possible, do not route wss:// connections through a SOCKS proxy. Use a direct secure WebSocket connection or another transport that performs and verifies TLS to the WebSocket origin.

Affected versions


          0.0.0


          2.0.0


          2.0.0b1


          2.1.0


          2.2.0


          2.3.0


          2.4.0


          2.5.0


          2.6.0


          2.7.0


          2.8.0


          2.9.0

+ 1 more


            2.9.1

Fixed in


          2.10.0

References

Updated Sep 10, 2026 · Source: OSV.dev

Jun 25, 2026

2.4.0 minor

1 CVE

CVE-2026-84381 PYSEC-2026-3844 GHSA-7mj9-2mp8-4m2p PYSEC-2026-3845 Sep 10, 2026

HTTPX2: Secure WebSocket traffic sent without TLS through SOCKS proxies

8.1 / 10

High

Adjacent Low None None Unchanged High High None

Summary

httpcore2 does not start TLS for wss:// connections routed through a SOCKS5 proxy. The WebSocket opening handshake and all subsequent frames are sent in plaintext through the proxy path, despite the caller selecting the secure wss scheme.

The transport flaw affects httpcore2 releases before 2.10.0. HTTPX2 exposed this behavior through its public Client.websocket() and AsyncClient.websocket() APIs from 2.6.0 through 2.9.1.

Details

The synchronous and asynchronous SOCKS5 connection implementations upgrade the established proxy tunnel to TLS only when the remote origin scheme is https. The equivalent check does not include wss. After the SOCKS5 handshake succeeds, the raw stream is therefore passed directly to the HTTP/1.1 connection, which writes the WebSocket upgrade request without first performing a TLS handshake or verifying the destination certificate.

For example, an application using HTTPX2 2.6.0 through 2.9.1 may open an authenticated WebSocket through a SOCKS proxy:

import httpx2

with httpx2.Client(proxy="socks5://proxy.example:1080") as client:
    with client.websocket(
        "wss://service.example/private?token=query-secret",
        headers={"Authorization": "Bearer header-secret"},
        cookies={"session": "cookie-secret"},
    ) as websocket:
        websocket.send_text("private message")

On affected versions, the stream passing through the SOCKS proxy begins with a plaintext request such as:

GET /private?token=query-secret HTTP/1.1
Host: service.example
Authorization: Bearer header-secret
Cookie: session=cookie-secret

Before HTTPX2 2.6.0, the same underlying httpcore2 behavior could be reached by integrations constructing a WebSocket upgrade request through the low-level transport API, but HTTPX2 did not yet provide its native WebSocket client API.

A normal secure WebSocket server will usually reject these plaintext bytes because it expects a TLS ClientHello. However, a malicious or compromised SOCKS proxy can accept the SOCKS connection, observe the plaintext handshake, return a forged 101 Switching Protocols response, and then read or modify WebSocket frames in both directions. An observer between the proxy and destination may also read the plaintext traffic.

RFC 6455 requires a client using a secure WebSocket connection to perform the TLS handshake before sending the WebSocket opening handshake. A wss URI promises confidentiality, integrity, and endpoint authentication through TLS.

Impact

An attacker able to control or observe the SOCKS proxy path can obtain URL query parameters, authorization headers, cookies, and application messages that the caller expected TLS to protect. Because no TLS handshake occurs, certificate verification also does not occur, allowing an attacker controlling the proxy to impersonate the WebSocket server and inject or alter messages.

Only wss:// connections routed through a SOCKS5 proxy are affected. Direct wss:// connections and ordinary https:// requests through SOCKS already start TLS correctly.

Mitigation

Upgrade HTTPX2 and httpcore2 to 2.10.0 or later. Patched versions start TLS for both https and wss origins in the synchronous and asynchronous SOCKS5 connection paths.

If upgrading is not immediately possible, do not route wss:// connections through a SOCKS proxy. Use a direct secure WebSocket connection or another transport that performs and verifies TLS to the WebSocket origin.

Affected versions


          0.0.0


          2.0.0


          2.0.0b1


          2.1.0


          2.2.0


          2.3.0


          2.4.0


          2.5.0


          2.6.0


          2.7.0


          2.8.0


          2.9.0

+ 1 more


            2.9.1

Fixed in


          2.10.0

References

Updated Sep 10, 2026 · Source: OSV.dev

Jun 11, 2026

2.3.0 minor

1 CVE

CVE-2026-84381 PYSEC-2026-3844 GHSA-7mj9-2mp8-4m2p PYSEC-2026-3845 Sep 10, 2026

HTTPX2: Secure WebSocket traffic sent without TLS through SOCKS proxies

8.1 / 10

High

Adjacent Low None None Unchanged High High None

Summary

httpcore2 does not start TLS for wss:// connections routed through a SOCKS5 proxy. The WebSocket opening handshake and all subsequent frames are sent in plaintext through the proxy path, despite the caller selecting the secure wss scheme.

The transport flaw affects httpcore2 releases before 2.10.0. HTTPX2 exposed this behavior through its public Client.websocket() and AsyncClient.websocket() APIs from 2.6.0 through 2.9.1.

Details

The synchronous and asynchronous SOCKS5 connection implementations upgrade the established proxy tunnel to TLS only when the remote origin scheme is https. The equivalent check does not include wss. After the SOCKS5 handshake succeeds, the raw stream is therefore passed directly to the HTTP/1.1 connection, which writes the WebSocket upgrade request without first performing a TLS handshake or verifying the destination certificate.

For example, an application using HTTPX2 2.6.0 through 2.9.1 may open an authenticated WebSocket through a SOCKS proxy:

import httpx2

with httpx2.Client(proxy="socks5://proxy.example:1080") as client:
    with client.websocket(
        "wss://service.example/private?token=query-secret",
        headers={"Authorization": "Bearer header-secret"},
        cookies={"session": "cookie-secret"},
    ) as websocket:
        websocket.send_text("private message")

On affected versions, the stream passing through the SOCKS proxy begins with a plaintext request such as:

GET /private?token=query-secret HTTP/1.1
Host: service.example
Authorization: Bearer header-secret
Cookie: session=cookie-secret

Before HTTPX2 2.6.0, the same underlying httpcore2 behavior could be reached by integrations constructing a WebSocket upgrade request through the low-level transport API, but HTTPX2 did not yet provide its native WebSocket client API.

A normal secure WebSocket server will usually reject these plaintext bytes because it expects a TLS ClientHello. However, a malicious or compromised SOCKS proxy can accept the SOCKS connection, observe the plaintext handshake, return a forged 101 Switching Protocols response, and then read or modify WebSocket frames in both directions. An observer between the proxy and destination may also read the plaintext traffic.

RFC 6455 requires a client using a secure WebSocket connection to perform the TLS handshake before sending the WebSocket opening handshake. A wss URI promises confidentiality, integrity, and endpoint authentication through TLS.

Impact

An attacker able to control or observe the SOCKS proxy path can obtain URL query parameters, authorization headers, cookies, and application messages that the caller expected TLS to protect. Because no TLS handshake occurs, certificate verification also does not occur, allowing an attacker controlling the proxy to impersonate the WebSocket server and inject or alter messages.

Only wss:// connections routed through a SOCKS5 proxy are affected. Direct wss:// connections and ordinary https:// requests through SOCKS already start TLS correctly.

Mitigation

Upgrade HTTPX2 and httpcore2 to 2.10.0 or later. Patched versions start TLS for both https and wss origins in the synchronous and asynchronous SOCKS5 connection paths.

If upgrading is not immediately possible, do not route wss:// connections through a SOCKS proxy. Use a direct secure WebSocket connection or another transport that performs and verifies TLS to the WebSocket origin.

Affected versions


          0.0.0


          2.0.0


          2.0.0b1


          2.1.0


          2.2.0


          2.3.0


          2.4.0


          2.5.0


          2.6.0


          2.7.0


          2.8.0


          2.9.0

+ 1 more


            2.9.1

Fixed in


          2.10.0

References

Updated Sep 10, 2026 · Source: OSV.dev

Jun 01, 2026

2.2.0 minor

1 CVE

CVE-2026-84381 PYSEC-2026-3844 GHSA-7mj9-2mp8-4m2p PYSEC-2026-3845 Sep 10, 2026

HTTPX2: Secure WebSocket traffic sent without TLS through SOCKS proxies

8.1 / 10

High

Adjacent Low None None Unchanged High High None

Summary

httpcore2 does not start TLS for wss:// connections routed through a SOCKS5 proxy. The WebSocket opening handshake and all subsequent frames are sent in plaintext through the proxy path, despite the caller selecting the secure wss scheme.

The transport flaw affects httpcore2 releases before 2.10.0. HTTPX2 exposed this behavior through its public Client.websocket() and AsyncClient.websocket() APIs from 2.6.0 through 2.9.1.

Details

The synchronous and asynchronous SOCKS5 connection implementations upgrade the established proxy tunnel to TLS only when the remote origin scheme is https. The equivalent check does not include wss. After the SOCKS5 handshake succeeds, the raw stream is therefore passed directly to the HTTP/1.1 connection, which writes the WebSocket upgrade request without first performing a TLS handshake or verifying the destination certificate.

For example, an application using HTTPX2 2.6.0 through 2.9.1 may open an authenticated WebSocket through a SOCKS proxy:

import httpx2

with httpx2.Client(proxy="socks5://proxy.example:1080") as client:
    with client.websocket(
        "wss://service.example/private?token=query-secret",
        headers={"Authorization": "Bearer header-secret"},
        cookies={"session": "cookie-secret"},
    ) as websocket:
        websocket.send_text("private message")

On affected versions, the stream passing through the SOCKS proxy begins with a plaintext request such as:

GET /private?token=query-secret HTTP/1.1
Host: service.example
Authorization: Bearer header-secret
Cookie: session=cookie-secret

Before HTTPX2 2.6.0, the same underlying httpcore2 behavior could be reached by integrations constructing a WebSocket upgrade request through the low-level transport API, but HTTPX2 did not yet provide its native WebSocket client API.

A normal secure WebSocket server will usually reject these plaintext bytes because it expects a TLS ClientHello. However, a malicious or compromised SOCKS proxy can accept the SOCKS connection, observe the plaintext handshake, return a forged 101 Switching Protocols response, and then read or modify WebSocket frames in both directions. An observer between the proxy and destination may also read the plaintext traffic.

RFC 6455 requires a client using a secure WebSocket connection to perform the TLS handshake before sending the WebSocket opening handshake. A wss URI promises confidentiality, integrity, and endpoint authentication through TLS.

Impact

An attacker able to control or observe the SOCKS proxy path can obtain URL query parameters, authorization headers, cookies, and application messages that the caller expected TLS to protect. Because no TLS handshake occurs, certificate verification also does not occur, allowing an attacker controlling the proxy to impersonate the WebSocket server and inject or alter messages.

Only wss:// connections routed through a SOCKS5 proxy are affected. Direct wss:// connections and ordinary https:// requests through SOCKS already start TLS correctly.

Mitigation

Upgrade HTTPX2 and httpcore2 to 2.10.0 or later. Patched versions start TLS for both https and wss origins in the synchronous and asynchronous SOCKS5 connection paths.

If upgrading is not immediately possible, do not route wss:// connections through a SOCKS proxy. Use a direct secure WebSocket connection or another transport that performs and verifies TLS to the WebSocket origin.

Affected versions


          0.0.0


          2.0.0


          2.0.0b1


          2.1.0


          2.2.0


          2.3.0


          2.4.0


          2.5.0


          2.6.0


          2.7.0


          2.8.0


          2.9.0

+ 1 more


            2.9.1

Fixed in


          2.10.0

References

Updated Sep 10, 2026 · Source: OSV.dev

May 17, 2026

2.1.0 minor

1 CVE

CVE-2026-84381 PYSEC-2026-3844 GHSA-7mj9-2mp8-4m2p PYSEC-2026-3845 Sep 10, 2026

HTTPX2: Secure WebSocket traffic sent without TLS through SOCKS proxies

8.1 / 10

High

Adjacent Low None None Unchanged High High None

Summary

httpcore2 does not start TLS for wss:// connections routed through a SOCKS5 proxy. The WebSocket opening handshake and all subsequent frames are sent in plaintext through the proxy path, despite the caller selecting the secure wss scheme.

The transport flaw affects httpcore2 releases before 2.10.0. HTTPX2 exposed this behavior through its public Client.websocket() and AsyncClient.websocket() APIs from 2.6.0 through 2.9.1.

Details

The synchronous and asynchronous SOCKS5 connection implementations upgrade the established proxy tunnel to TLS only when the remote origin scheme is https. The equivalent check does not include wss. After the SOCKS5 handshake succeeds, the raw stream is therefore passed directly to the HTTP/1.1 connection, which writes the WebSocket upgrade request without first performing a TLS handshake or verifying the destination certificate.

For example, an application using HTTPX2 2.6.0 through 2.9.1 may open an authenticated WebSocket through a SOCKS proxy:

import httpx2

with httpx2.Client(proxy="socks5://proxy.example:1080") as client:
    with client.websocket(
        "wss://service.example/private?token=query-secret",
        headers={"Authorization": "Bearer header-secret"},
        cookies={"session": "cookie-secret"},
    ) as websocket:
        websocket.send_text("private message")

On affected versions, the stream passing through the SOCKS proxy begins with a plaintext request such as:

GET /private?token=query-secret HTTP/1.1
Host: service.example
Authorization: Bearer header-secret
Cookie: session=cookie-secret

Before HTTPX2 2.6.0, the same underlying httpcore2 behavior could be reached by integrations constructing a WebSocket upgrade request through the low-level transport API, but HTTPX2 did not yet provide its native WebSocket client API.

A normal secure WebSocket server will usually reject these plaintext bytes because it expects a TLS ClientHello. However, a malicious or compromised SOCKS proxy can accept the SOCKS connection, observe the plaintext handshake, return a forged 101 Switching Protocols response, and then read or modify WebSocket frames in both directions. An observer between the proxy and destination may also read the plaintext traffic.

RFC 6455 requires a client using a secure WebSocket connection to perform the TLS handshake before sending the WebSocket opening handshake. A wss URI promises confidentiality, integrity, and endpoint authentication through TLS.

Impact

An attacker able to control or observe the SOCKS proxy path can obtain URL query parameters, authorization headers, cookies, and application messages that the caller expected TLS to protect. Because no TLS handshake occurs, certificate verification also does not occur, allowing an attacker controlling the proxy to impersonate the WebSocket server and inject or alter messages.

Only wss:// connections routed through a SOCKS5 proxy are affected. Direct wss:// connections and ordinary https:// requests through SOCKS already start TLS correctly.

Mitigation

Upgrade HTTPX2 and httpcore2 to 2.10.0 or later. Patched versions start TLS for both https and wss origins in the synchronous and asynchronous SOCKS5 connection paths.

If upgrading is not immediately possible, do not route wss:// connections through a SOCKS proxy. Use a direct secure WebSocket connection or another transport that performs and verifies TLS to the WebSocket origin.

Affected versions


          0.0.0


          2.0.0


          2.0.0b1


          2.1.0


          2.2.0


          2.3.0


          2.4.0


          2.5.0


          2.6.0


          2.7.0


          2.8.0


          2.9.0

+ 1 more


            2.9.1

Fixed in


          2.10.0

References

Updated Sep 10, 2026 · Source: OSV.dev

May 15, 2026

2.0.0 major

1 CVE

CVE-2026-84381 PYSEC-2026-3844 GHSA-7mj9-2mp8-4m2p PYSEC-2026-3845 Sep 10, 2026

HTTPX2: Secure WebSocket traffic sent without TLS through SOCKS proxies

8.1 / 10

High

Adjacent Low None None Unchanged High High None

Summary

httpcore2 does not start TLS for wss:// connections routed through a SOCKS5 proxy. The WebSocket opening handshake and all subsequent frames are sent in plaintext through the proxy path, despite the caller selecting the secure wss scheme.

The transport flaw affects httpcore2 releases before 2.10.0. HTTPX2 exposed this behavior through its public Client.websocket() and AsyncClient.websocket() APIs from 2.6.0 through 2.9.1.

Details

The synchronous and asynchronous SOCKS5 connection implementations upgrade the established proxy tunnel to TLS only when the remote origin scheme is https. The equivalent check does not include wss. After the SOCKS5 handshake succeeds, the raw stream is therefore passed directly to the HTTP/1.1 connection, which writes the WebSocket upgrade request without first performing a TLS handshake or verifying the destination certificate.

For example, an application using HTTPX2 2.6.0 through 2.9.1 may open an authenticated WebSocket through a SOCKS proxy:

import httpx2

with httpx2.Client(proxy="socks5://proxy.example:1080") as client:
    with client.websocket(
        "wss://service.example/private?token=query-secret",
        headers={"Authorization": "Bearer header-secret"},
        cookies={"session": "cookie-secret"},
    ) as websocket:
        websocket.send_text("private message")

On affected versions, the stream passing through the SOCKS proxy begins with a plaintext request such as:

GET /private?token=query-secret HTTP/1.1
Host: service.example
Authorization: Bearer header-secret
Cookie: session=cookie-secret

Before HTTPX2 2.6.0, the same underlying httpcore2 behavior could be reached by integrations constructing a WebSocket upgrade request through the low-level transport API, but HTTPX2 did not yet provide its native WebSocket client API.

A normal secure WebSocket server will usually reject these plaintext bytes because it expects a TLS ClientHello. However, a malicious or compromised SOCKS proxy can accept the SOCKS connection, observe the plaintext handshake, return a forged 101 Switching Protocols response, and then read or modify WebSocket frames in both directions. An observer between the proxy and destination may also read the plaintext traffic.

RFC 6455 requires a client using a secure WebSocket connection to perform the TLS handshake before sending the WebSocket opening handshake. A wss URI promises confidentiality, integrity, and endpoint authentication through TLS.

Impact

An attacker able to control or observe the SOCKS proxy path can obtain URL query parameters, authorization headers, cookies, and application messages that the caller expected TLS to protect. Because no TLS handshake occurs, certificate verification also does not occur, allowing an attacker controlling the proxy to impersonate the WebSocket server and inject or alter messages.

Only wss:// connections routed through a SOCKS5 proxy are affected. Direct wss:// connections and ordinary https:// requests through SOCKS already start TLS correctly.

Mitigation

Upgrade HTTPX2 and httpcore2 to 2.10.0 or later. Patched versions start TLS for both https and wss origins in the synchronous and asynchronous SOCKS5 connection paths.

If upgrading is not immediately possible, do not route wss:// connections through a SOCKS proxy. Use a direct secure WebSocket connection or another transport that performs and verifies TLS to the WebSocket origin.

Affected versions


          0.0.0


          2.0.0


          2.0.0b1


          2.1.0


          2.2.0


          2.3.0


          2.4.0


          2.5.0


          2.6.0


          2.7.0


          2.8.0


          2.9.0

+ 1 more


            2.9.1

Fixed in


          2.10.0

References

Updated Sep 10, 2026 · Source: OSV.dev

May 12, 2026

2.0.0b1 pre

1 CVE

CVE-2026-84381 PYSEC-2026-3844 GHSA-7mj9-2mp8-4m2p PYSEC-2026-3845 Sep 10, 2026

HTTPX2: Secure WebSocket traffic sent without TLS through SOCKS proxies

8.1 / 10

High

Adjacent Low None None Unchanged High High None

Summary

httpcore2 does not start TLS for wss:// connections routed through a SOCKS5 proxy. The WebSocket opening handshake and all subsequent frames are sent in plaintext through the proxy path, despite the caller selecting the secure wss scheme.

The transport flaw affects httpcore2 releases before 2.10.0. HTTPX2 exposed this behavior through its public Client.websocket() and AsyncClient.websocket() APIs from 2.6.0 through 2.9.1.

Details

The synchronous and asynchronous SOCKS5 connection implementations upgrade the established proxy tunnel to TLS only when the remote origin scheme is https. The equivalent check does not include wss. After the SOCKS5 handshake succeeds, the raw stream is therefore passed directly to the HTTP/1.1 connection, which writes the WebSocket upgrade request without first performing a TLS handshake or verifying the destination certificate.

For example, an application using HTTPX2 2.6.0 through 2.9.1 may open an authenticated WebSocket through a SOCKS proxy:

import httpx2

with httpx2.Client(proxy="socks5://proxy.example:1080") as client:
    with client.websocket(
        "wss://service.example/private?token=query-secret",
        headers={"Authorization": "Bearer header-secret"},
        cookies={"session": "cookie-secret"},
    ) as websocket:
        websocket.send_text("private message")

On affected versions, the stream passing through the SOCKS proxy begins with a plaintext request such as:

GET /private?token=query-secret HTTP/1.1
Host: service.example
Authorization: Bearer header-secret
Cookie: session=cookie-secret

Before HTTPX2 2.6.0, the same underlying httpcore2 behavior could be reached by integrations constructing a WebSocket upgrade request through the low-level transport API, but HTTPX2 did not yet provide its native WebSocket client API.

A normal secure WebSocket server will usually reject these plaintext bytes because it expects a TLS ClientHello. However, a malicious or compromised SOCKS proxy can accept the SOCKS connection, observe the plaintext handshake, return a forged 101 Switching Protocols response, and then read or modify WebSocket frames in both directions. An observer between the proxy and destination may also read the plaintext traffic.

RFC 6455 requires a client using a secure WebSocket connection to perform the TLS handshake before sending the WebSocket opening handshake. A wss URI promises confidentiality, integrity, and endpoint authentication through TLS.

Impact

An attacker able to control or observe the SOCKS proxy path can obtain URL query parameters, authorization headers, cookies, and application messages that the caller expected TLS to protect. Because no TLS handshake occurs, certificate verification also does not occur, allowing an attacker controlling the proxy to impersonate the WebSocket server and inject or alter messages.

Only wss:// connections routed through a SOCKS5 proxy are affected. Direct wss:// connections and ordinary https:// requests through SOCKS already start TLS correctly.

Mitigation

Upgrade HTTPX2 and httpcore2 to 2.10.0 or later. Patched versions start TLS for both https and wss origins in the synchronous and asynchronous SOCKS5 connection paths.

If upgrading is not immediately possible, do not route wss:// connections through a SOCKS proxy. Use a direct secure WebSocket connection or another transport that performs and verifies TLS to the WebSocket origin.

Affected versions


          0.0.0


          2.0.0


          2.0.0b1


          2.1.0


          2.2.0


          2.3.0


          2.4.0


          2.5.0


          2.6.0


          2.7.0


          2.8.0


          2.9.0

+ 1 more


            2.9.1

Fixed in


          2.10.0

References

Updated Sep 10, 2026 · Source: OSV.dev

May 11, 2026

0.0.0 initial

1 CVE

CVE-2026-84381 PYSEC-2026-3844 GHSA-7mj9-2mp8-4m2p PYSEC-2026-3845 Sep 10, 2026

HTTPX2: Secure WebSocket traffic sent without TLS through SOCKS proxies

8.1 / 10

High

Adjacent Low None None Unchanged High High None

Summary

httpcore2 does not start TLS for wss:// connections routed through a SOCKS5 proxy. The WebSocket opening handshake and all subsequent frames are sent in plaintext through the proxy path, despite the caller selecting the secure wss scheme.

The transport flaw affects httpcore2 releases before 2.10.0. HTTPX2 exposed this behavior through its public Client.websocket() and AsyncClient.websocket() APIs from 2.6.0 through 2.9.1.

Details

The synchronous and asynchronous SOCKS5 connection implementations upgrade the established proxy tunnel to TLS only when the remote origin scheme is https. The equivalent check does not include wss. After the SOCKS5 handshake succeeds, the raw stream is therefore passed directly to the HTTP/1.1 connection, which writes the WebSocket upgrade request without first performing a TLS handshake or verifying the destination certificate.

For example, an application using HTTPX2 2.6.0 through 2.9.1 may open an authenticated WebSocket through a SOCKS proxy:

import httpx2

with httpx2.Client(proxy="socks5://proxy.example:1080") as client:
    with client.websocket(
        "wss://service.example/private?token=query-secret",
        headers={"Authorization": "Bearer header-secret"},
        cookies={"session": "cookie-secret"},
    ) as websocket:
        websocket.send_text("private message")

On affected versions, the stream passing through the SOCKS proxy begins with a plaintext request such as:

GET /private?token=query-secret HTTP/1.1
Host: service.example
Authorization: Bearer header-secret
Cookie: session=cookie-secret

Before HTTPX2 2.6.0, the same underlying httpcore2 behavior could be reached by integrations constructing a WebSocket upgrade request through the low-level transport API, but HTTPX2 did not yet provide its native WebSocket client API.

A normal secure WebSocket server will usually reject these plaintext bytes because it expects a TLS ClientHello. However, a malicious or compromised SOCKS proxy can accept the SOCKS connection, observe the plaintext handshake, return a forged 101 Switching Protocols response, and then read or modify WebSocket frames in both directions. An observer between the proxy and destination may also read the plaintext traffic.

RFC 6455 requires a client using a secure WebSocket connection to perform the TLS handshake before sending the WebSocket opening handshake. A wss URI promises confidentiality, integrity, and endpoint authentication through TLS.

Impact

An attacker able to control or observe the SOCKS proxy path can obtain URL query parameters, authorization headers, cookies, and application messages that the caller expected TLS to protect. Because no TLS handshake occurs, certificate verification also does not occur, allowing an attacker controlling the proxy to impersonate the WebSocket server and inject or alter messages.

Only wss:// connections routed through a SOCKS5 proxy are affected. Direct wss:// connections and ordinary https:// requests through SOCKS already start TLS correctly.

Mitigation

Upgrade HTTPX2 and httpcore2 to 2.10.0 or later. Patched versions start TLS for both https and wss origins in the synchronous and asynchronous SOCKS5 connection paths.

If upgrading is not immediately possible, do not route wss:// connections through a SOCKS proxy. Use a direct secure WebSocket connection or another transport that performs and verifies TLS to the WebSocket origin.

Affected versions


          0.0.0


          2.0.0


          2.0.0b1


          2.1.0


          2.2.0


          2.3.0


          2.4.0


          2.5.0


          2.6.0


          2.7.0


          2.8.0


          2.9.0

+ 1 more


            2.9.1

Fixed in


          2.10.0

References

Updated Sep 10, 2026 · Source: OSV.dev

May 11, 2026

Activity

Reach

Details