CVE-2026-4873

What it actually does

This is a connection-pool TLS enforcement flaw in curl/libcurl affecting IMAP, SMTP, and POP3 workflows. When an application first opens a clear-text mail protocol connection to a host, that unencrypted connection can remain in the reusable connection pool. A later transfer to the same host that is configured to require TLS may incorrectly reuse the existing clear-text connection instead of establishing or upgrading to an encrypted TLS session. The result is unintended plaintext transmission of data that the application expected to protect with TLS, creating a high-confidentiality-impact exposure without directly affecting integrity or availability.

Why it matters to the business

Sensitive mail-related data, including credentials, message contents, headers, or operational metadata, may be sent over the network without encryption even when the application believes TLS is required. This can lead to credential theft, mailbox compromise, regulatory exposure, breach notification obligations, and loss of trust where mail traffic contains customer, employee, or business-sensitive information. The vulnerability is not currently listed in CISA KEV, has low EPSS probability, and has no reported mature public exploit in the supplied data, but the consequence is still significant for systems using curl/libcurl for mail protocols over networks where traffic could be observed.

How an attack unfolds

An attacker needs a situation where an application using curl/libcurl communicates with the same mail host using both clear-text and TLS-required IMAP, SMTP, or POP3 transfers while connection reuse is enabled. First, the application performs a clear-text transfer, leaving an unencrypted connection in the pool. Later, the same process or handle initiates a transfer to the same host that is expected to require TLS. Due to the flaw, curl/libcurl may select the previously opened clear-text connection rather than creating a new TLS-protected connection. An attacker positioned to observe network traffic between the client and mail server can then capture data that should have been encrypted, such as authentication material or mail content. The attacker does not need to break TLS; the weakness is that TLS is bypassed by incorrect connection reuse.

How to fix it

Upgrade curl/libcurl to a vendor-fixed version as soon as an official patched release is available for the affected distribution or product package. No exact fixed version was supplied in the input, so administrators should consult the Haxx/curl advisory and their operating system or application vendor security errata for the corrected version. Until patched, avoid mixing clear-text and TLS-required IMAP, SMTP, or POP3 transfers to the same host within the same process or connection pool. Prefer implicit TLS schemes where supported, such as imaps://, smtps://, and pop3s://, and disable or eliminate clear-text mail protocol use. Where application changes are possible, segregate connection pools by security requirements, disable connection reuse for affected mail transfers, or ensure TLS-required transfers cannot reuse prior plaintext connections. Network controls should block outbound clear-text IMAP, SMTP submission, and POP3 where business requirements allow.

How to confirm the fix worked

Confirm the installed curl/libcurl package version is at or above the vendor-fixed version once published by the relevant package maintainer. Review applications that embed or dynamically link libcurl and verify they are using the patched library, not a bundled vulnerable copy. Functionally validate by creating a controlled sequence: first perform a clear-text IMAP, SMTP, or POP3 transfer to a host, then perform a TLS-required transfer to the same host using the same connection reuse context. Capture traffic with tcpdump, Wireshark, or equivalent and verify the second transfer performs a TLS handshake and does not send protocol commands, credentials, or message content in plaintext. Also validate that clear-text mail protocol egress is blocked or removed where mitigation policies require it.

Typical attack path

1. Identify an application or service that uses curl/libcurl for IMAP, SMTP, or POP3 connections.
2. Wait for or induce a clear-text mail protocol transfer to a target host so an unencrypted connection remains reusable in the connection pool.
3. Rely on the application to later perform a TLS-required transfer to the same host using the same connection pool.
4. The vulnerable client incorrectly reuses the existing unencrypted connection instead of establishing a TLS session.
5. Observe network traffic between the client and server and collect credentials, message data, or other sensitive mail protocol content transmitted in plaintext.

How to detect it

To determine whether exposure or exploitation already occurred, focus on network and application telemetry rather than host compromise artifacts. Review packet captures, NetFlow, proxy logs, firewall logs, and mail server logs for clients that made plaintext IMAP, SMTP, or POP3 connections followed closely by expected TLS-protected connections to the same host. Look for authentication commands, usernames, message metadata, or mail content visible in clear text on ports commonly associated with mail protocols. On mail servers, correlate sessions from the same client where TLS was not negotiated despite the application or policy expecting TLS. Application debug logs from curl/libcurl may show connection reuse decisions, such as reusing an existing connection, without a corresponding TLS handshake. Because exploitation is passive confidentiality exposure, there may be no malware, process, file, or registry artifact; evidence is most likely found in network captures, mail server TLS negotiation logs, and application transfer/debug logs.

• imap://
• smtp://
• pop3://
• AUTH PLAIN
• AUTH LOGIN
• USER
• PASS
• STARTTLS
• Re-using existing connection
• Connection #0 to host
• TLS connection established
• SSL connection using
• LOGIN
• CAPABILITY

What your security team should do

• Inventory systems, applications, containers, and appliances that use curl or libcurl for IMAP, SMTP, or POP3 traffic.
• Prioritize remediation for internet-connected systems, automation that sends or retrieves mail, and systems transmitting credentials or sensitive message content.
• Upgrade curl/libcurl through vendor-supported packages as soon as patched versions are available; track Haxx/curl and operating system advisories for exact fixed releases.
• As an interim control, disable clear-text IMAP, SMTP, and POP3 usage and require implicit TLS or properly validated STARTTLS where applicable.
• Review application code for mixed clear-text and TLS-required transfers to the same host using shared libcurl connection pools.
• Disable connection reuse or separate connection pools for mail protocol transfers with different TLS requirements until patching is complete.
• Monitor network telemetry for plaintext mail protocol authentication or content leaving systems that are expected to use TLS.
• Because this is not currently KEV-listed and EPSS is low, handle as a targeted confidentiality-risk issue rather than an active mass-exploitation emergency, while still prioritizing environments carrying sensitive mail data.