CVE-2023-38545

What it actually does

The flaw is a heap-based buffer overflow in curl/libcurl during the SOCKS5 proxy handshake when remote DNS resolution is requested, such as through a SOCKS5-hostname proxy mode. A hostname longer than the SOCKS5 protocol limit of 255 bytes should cause curl to resolve the name locally and send only the resolved address to the proxy. Under slow SOCKS5 handshake conditions, the internal state controlling whether the proxy or local client resolves the hostname can become incorrect, causing the oversized hostname from the URL to be copied into a heap buffer sized for the shorter SOCKS5 field. Depending on build options, allocator behavior, target process privileges, and memory layout, this can result in process crash, memory corruption, or potentially arbitrary code execution in the process using curl/libcurl.

Why it matters to the business

curl and libcurl are widely embedded in operating systems, applications, scripts, appliances, CI/CD tooling, containers, and third-party products, so exposure may exist both in direct curl command-line use and indirectly through software that links against libcurl. If exploitable in a business-critical process, the flaw could allow an attacker-controlled URL and proxy interaction to crash services, disrupt automation, or potentially execute code with the privileges of the affected application. The high CVSS score and high EPSS value indicate this should be treated as a high-priority remediation item, even though it is not listed in CISA KEV and no ransomware use is indicated in the provided data.

How an attack unfolds

An attacker needs a vulnerable curl/libcurl client to make a request through a SOCKS5 proxy mode that asks the proxy to resolve the hostname, commonly represented by socks5h behavior or equivalent libcurl options. The attacker then supplies or influences a URL containing an overly long hostname. During the SOCKS5 handshake, the attacker benefits from or induces a slow proxy negotiation so that curl incorrectly preserves the state indicating that the proxy should resolve the hostname. Instead of falling back to local resolution and sending a short resolved address, the vulnerable client copies the oversized hostname into a heap buffer intended for the SOCKS5 hostname field. The immediate result may be a crash, but under favorable conditions the heap corruption could be shaped toward code execution inside the process using curl/libcurl. Practical exploitation depends heavily on how the vulnerable application accepts URLs, whether SOCKS5-hostname proxying is enabled, memory protections, and whether the attacker can control timing in the proxy handshake.

How to fix it

Upgrade curl/libcurl to a fixed release from the vendor or distribution. For source builds from the curl Git repository, ensure the fix commit 172e54cda18412da73fd8eb4e444e8a5b371ca59 or later is included; in standard upstream versioning, deploy curl/libcurl 8.4.0 or later. Because libcurl is commonly bundled or statically linked, update not only the operating system package but also containers, appliances, language runtime packages, statically linked binaries, vendor applications, and CI images that include their own libcurl copy. If immediate upgrade is not possible, reduce exposure by disabling SOCKS5-hostname proxy use where feasible, avoiding socks5h:// proxy configurations, blocking untrusted users from supplying arbitrary URLs to curl/libcurl-backed workflows, enforcing hostname length validation before passing URLs to curl/libcurl, and isolating processes that must fetch attacker-controlled URLs.

How to confirm the fix worked

Confirm the runtime curl/libcurl version and build provenance rather than relying only on package inventory. Check command-line curl with `curl --version` and application-linked libcurl through package manager metadata, SBOMs, container image scans, vendor advisories, and binary dependency inspection. Validate that deployed builds contain curl/libcurl 8.4.0 or later, a vendor-backported fix, or the Git commit 172e54cda18412da73fd8eb4e444e8a5b371ca59. Search configurations, scripts, environment variables, and application settings for SOCKS5-hostname proxy use such as socks5h://, --socks5-hostname, ALL_PROXY, HTTPS_PROXY, HTTP_PROXY, and libcurl settings using CURLPROXY_SOCKS5_HOSTNAME. Where safe, perform negative testing in a non-production environment using a fixed build and a long-hostname URL through a SOCKS5-hostname proxy to confirm the client rejects or safely handles the case without crashing.

Typical attack path

1. Identify an application, script, service, or embedded product using a vulnerable curl/libcurl build.
2. Determine whether the target uses a SOCKS5 proxy mode where the proxy resolves destination hostnames, such as socks5h or CURLPROXY_SOCKS5_HOSTNAME.
3. Influence the target to request an attacker-controlled URL with a hostname longer than 255 bytes.
4. Ensure the SOCKS5 handshake is slow or controlled so the vulnerable state transition is reached.
5. Trigger the vulnerable copy operation during the SOCKS5 handshake.
6. Cause the process to crash or attempt to shape heap corruption for code execution with the privileges of the curl/libcurl-using process.

How to detect it

Detection should focus on both exploitation attempts and post-crash artifacts because successful exploitation may not leave a unique application-level marker. Review proxy logs, egress telemetry, EDR network events, application logs, shell history, CI job logs, and process command-line telemetry for curl/libcurl activity using SOCKS5-hostname proxying and unusually long hostnames. Look for use of socks5h:// proxy URLs, --socks5-hostname, ALL_PROXY/HTTP_PROXY/HTTPS_PROXY values pointing to SOCKS5 proxies, and destination hostnames exceeding 255 bytes. Review system logs, crash reporters, core dumps, container termination records, and EDR events for curl, applications linked to libcurl, or vendor processes terminating with segmentation faults, heap corruption, aborts, or allocator errors around outbound SOCKS5 connections. If exploitation is suspected, preserve core dumps and memory artifacts before patching where policy allows, then inspect them for long attacker-controlled hostnames, SOCKS5 handshake state, suspicious return addresses, or unexpected child processes spawned by the affected application. No named threat actors or ransomware campaigns are indicated in the provided data, so detection should emphasize behavioral evidence rather than actor-specific infrastructure.

• socks5h://
• --socks5-hostname
• CURLPROXY_SOCKS5_HOSTNAME
• ALL_PROXY=socks5h://
• all_proxy=socks5h://
• HTTP_PROXY=socks5h://
• http_proxy=socks5h://
• HTTPS_PROXY=socks5h://
• https_proxy=socks5h://
• Proxy: socks5h://
• SOCKS5
• Segmentation fault
• segfault
• malloc(): corrupted top size
• malloc(): invalid size
• free(): invalid pointer
• double free or corruption
• corrupted double-linked list
• heap corruption
• AddressSanitizer: heap-buffer-overflow
• curl: (97)
• curl: (7)

What your security team should do

• Prioritize patching all directly installed curl/libcurl packages and all products or containers that bundle libcurl, especially internet-facing services, automation workers, CI/CD runners, and systems processing user-supplied URLs.
• Inventory use of SOCKS5-hostname proxying, including socks5h:// proxy URLs, --socks5-hostname command usage, and libcurl applications configured with CURLPROXY_SOCKS5_HOSTNAME.
• Treat vulnerable systems as higher risk when they fetch URLs supplied by users, partners, webhooks, documents, feeds, package metadata, or other untrusted sources.
• Ask vendors of appliances, agents, and packaged applications whether their products embed a vulnerable libcurl version and whether the fix commit or curl/libcurl 8.4.0 or later is present.
• Apply compensating controls until patching is complete: disable SOCKS5-hostname proxy mode, restrict outbound proxy settings, validate URL hostname length, and run URL-fetching components with least privilege and sandboxing.
• Monitor for abnormal curl/libcurl crashes, heap corruption messages, and suspicious outbound SOCKS5 proxy traffic involving unusually long destination hostnames.
• Because the EPSS score is high, continue tracking exploit intelligence and revisit prioritization if public exploit code, KEV listing, or threat actor activity emerges.