No fixed build or workaround is published yet. Limit exposure and watch for a patch.
ProductAffected versionsUpgrade toStated by
CurlAffected: ≥ 8.22.0, ≤ 8.22.0Upgrade to: after 8.22.0Affected: ≥ 8.21.0, ≤ 8.21.0Upgrade to: after 8.21.0Affected: ≥ 8.20.0, ≤ 8.20.0Upgrade to: after 8.20.0Affected: ≥ 8.19.0, ≤ 8.19.0Upgrade to: after 8.19.0 + 13 more branchesStated by: CVE record
Check whether any of your applications, internal tools, or services use curl or libcurl to connect to FTP, IMAP, POP3, or SMTP servers.
If you connect to untrusted or third-party mail/file servers using curl-based tools, be aware these connections could hang indefinitely.
There is no fixed version available yet — watch for an official curl security release and apply it as soon as it's published.
As a temporary measure, consider adding external watchdog timeouts or process-level kill switches around any curl-based transfers to untrusted servers.
By permanently omitting the final control-response line, a malicious FTP,
IMAP, POP3, or SMTP server can exploit libcurl and completely bypass its
configured transfer timeout mechanism, indefinitely blocking all concurrent
transfers bound to the same multi-handle.
In plain language
Written by AI from the record
A bug in the widely-used curl software lets a malicious server freeze your application's internet transfers indefinitely, but there's no fix yet and no sign it's being actively attacked — still, businesses using curl should watch closely.
A malicious FTP/IMAP/POP3/SMTP server can permanently withhold the final control-response line to libcurl, defeating the configured transfer timeout and indefinitely hanging all concurrent transfers sharing the same multi-handle, resulting in a denial-of-service condition.
If you're affected
Application hangs/freezes
Service disruption for customers
Resource exhaustion on servers
Operational downtime
What is it
curl is a tool many apps use behind the scenes to fetch files or emails from other servers. This bug means a dishonest or compromised server can trick curl into waiting forever for a reply that never comes, like a phone call where the other person goes silent but never hangs up — tying up your line indefinitely.
Who is affected
This matters to you if any of your software, scripts, or internal tools use curl (or the underlying libcurl library) to connect to FTP, IMAP, POP3, or SMTP servers. The risk is real only when curl connects to a server that is malicious or has been compromised — a well-behaved, trusted server will not trigger this.
How urgent is it
This is a serious concern because there is currently no official fix available, and curl is embedded in an enormous number of applications and tools, making exposure widespread even though no active attacks have been confirmed yet. Treat this as high-priority to track: the lack of a patch combined with the broad reach of curl means you should be ready to act the moment a fix ships, and in the meantime limit or monitor connections to untrusted mail/file servers.
What to do — in detail
Inventory all applications and services that depend on curl or libcurl, particularly any that perform FTP, IMAP, POP3, or SMTP transfers.
Identify which of these connect to third-party, untrusted, or externally-operated servers — these are the exposed paths.
No fixed curl version has been published yet; monitor curl's official security advisories and changelog for a release addressing this issue, then upgrade as soon as it's available.
As an interim mitigation, wrap curl-based transfer calls with an external timeout/watchdog (e.g., process-level alarm, container resource limits, or a supervising process that force-kills hung transfers) since curl's own timeout mechanism is bypassed by this bug.
Monitor for unusually long-running or stuck connections/threads tied to curl multi-handle operations, especially those sharing a handle with other concurrent transfers, as a single malicious server can stall unrelated transfers too.
There is no CISA KEV listing and no CISA-mandated remediation date for this CVE at this time.
Technical context
This is a denial-of-service weakness (resource/thread exhaustion via indefinite blocking) triggered when a malicious FTP/IMAP/POP3/SMTP server omits the final control-response line, bypassing libcurl's configured transfer timeout. Exploit maturity is low: no public exploit code exists, it is not listed in CISA's Known Exploited Vulnerabilities catalog, and predicted exploitation likelihood is low with a flat trend. No patch or fixed version has been published yet. Attack vector requires the client to connect to an attacker-controlled or compromised server; it is not remotely triggerable without that server-side control. Press attention is recent but reflects a roundup mention rather than confirmed in-the-wild exploitation.
This is a general assessment based on public vulnerability data. It does not account for your specific infrastructure — when in doubt, consult a security specialist.
