The curl project has released curl 8.23.0 to fix a vulnerability in HTTP/2 uploads that could allow a malicious server to corrupt memory on the client machine sending the data. According to the reported findings, the issue can lead to client crashes, and a proof-of-concept reportedly demonstrated code execution under specific conditions.

Although the curl project indicated that a real-world attack would likely more often result in a crash than a full system compromise, the flaw is still important for businesses because curl is widely used in scripts, server workflows, development pipelines and application integrations.

What happened

The vulnerability affects how curl handles HTTP/2 uploads. If a client uploads data to a malicious server, that server may be able to trigger memory corruption on the uploading machine. The issue was fixed on 14 October in curl 8.23.0.

The available reporting states that turning the flaw into code execution requires precise knowledge of the target client build and memory layout. That makes exploitation more complex, but it does not remove the operational risk for organisations that rely on curl in automated environments.

Why it matters for European businesses

curl is not only a command-line tool used by administrators. It is also embedded in many operational processes, including automated file transfers, API calls, deployment scripts, monitoring jobs and application components. That means a client-side flaw can affect more than employee laptops: it may also touch backend systems that send data to third-party endpoints.

For European businesses, the practical risk is strongest where systems upload data to external services over HTTP/2, especially when those destinations are not fully controlled by the organisation. If an affected curl version is present in business-critical workflows, a crash could interrupt operations, while a successful exploit could create a broader security incident.

The issue is also relevant from a supply-chain perspective. Many companies may not realise where curl is installed directly or bundled indirectly through operating systems, containers, software packages or internal tooling.

Who may be affected

• IT and infrastructure teams using curl in automation, scripts, CI/CD pipelines or server maintenance tasks
• Software and web teams whose applications, containers or developer environments include vulnerable curl versions
• E-commerce and digital businesses that rely on automated uploads to external platforms, marketplaces, cloud services or content systems
• Managed service providers and digital agencies operating hosted environments or deployment workflows for clients
• Security and compliance teams responsible for vulnerability management and third-party software inventories

What companies should consider

• Check curl versions across endpoints, servers, containers and automation environments, and identify systems still running versions older than 8.23.0.
• Prioritise patching on systems that upload data to external or less-trusted servers over HTTP/2.
• Review automated workflows that send files or data to third-party services, especially where those transfers happen without close monitoring.
• Audit software dependencies to determine whether curl is bundled in internal tools, images or vendor-supplied environments.
• Monitor for crashes and anomalies in jobs or systems performing uploads, as service instability may be an early sign of attempted exploitation or exposure.
• Apply least-privilege controls so automated upload processes run with limited permissions where possible, reducing potential impact if a client-side tool is abused.

At this stage, the confirmed development is that a patch is available in curl 8.23.0 and that a proof-of-concept reportedly showed code execution in a controlled context. Businesses should treat this primarily as a patching and asset-visibility issue: even when exploitation is difficult, widely deployed utilities such as curl can create meaningful operational risk when left unpatched.