CVE-2022-27782

What it actually does

libcurl reuses pooled connections even after TLS or SSH configuration changes that should have invalidated the match, bypassing intended security restrictions on connection reuse.

Why it matters to the business

Applications relying on curl for secure transfers may send data over connections that no longer meet updated security requirements, raising the chance of information disclosure or failed authentication in environments with high curl usage.

How an attack unfolds

An attacker supplies requests that cause libcurl to reuse a prior connection despite altered TLS or SSH options between transfers, allowing the mismatched connection to be used and potentially bypassing certificate validation or other security checks.

How to fix it

Upgrade curl to the version containing commit 462196e6b4a47f924293a0e26b8e9c23d37ac26f or later; rebuild dependent applications against the patched library.

How to confirm the fix worked

Confirm the installed curl version includes the referenced commit, then test that changed TLS or SSH options now correctly prevent connection reuse from the pool.

Typical attack path

1. Identify applications using libcurl connection pooling
2. Issue transfers that alter TLS or SSH settings between requests
3. Trigger reuse of a previously pooled connection
4. Leverage the bypassed security settings for unauthorized data access or MITM

How to detect it

Review application and libcurl debug logs for connection reuse events that occur after TLS or SSH option changes; look for patterns of mismatched connection use in network traces.

What your security team should do

• Prioritize upgrade of curl across all affected systems given the available public exploit
• Audit code paths that modify TLS or SSH options between transfers
• Enable verbose logging of connection reuse decisions during testing