CVE-2026-7009

What it actually does

This flaw affects curl when it is explicitly configured to use the TLS Certificate Status Request extension, commonly known as OCSP stapling, to validate a server certificate's revocation status. In vulnerable versions, curl fails to correctly treat problematic OCSP stapling responses as validation failures and may incorrectly continue the TLS connection as if the certificate status were acceptable. The main technical consequence is weakened certificate revocation checking: a connection to a server presenting a revoked, invalid, or otherwise questionable certificate could be accepted in scenarios where OCSP stapling was expected to detect and block it. The CVSS impact is confidentiality-only and low severity because exploitation does not directly grant code execution or system control, but it can undermine trust decisions in TLS-protected communications.

Why it matters to the business

Organizations relying on curl for secure automated communications may receive a false sense of certificate validation, allowing connections to servers whose certificates should have been rejected. This can increase exposure to man-in-the-middle interception, data collection, or connection to impersonated services, especially in scripts, agents, CI/CD jobs, package downloaders, monitoring systems, and backend integrations that depend on curl for HTTPS communication. The issue is not currently listed in CISA KEV, is not associated with known ransomware use, has very low EPSS, and has no public exploit maturity indicated, so it is generally a planned remediation item rather than an emergency patch—unless OCSP stapling enforcement is part of a compliance or high-assurance trust model.

How an attack unfolds

An attacker would need to position themselves so they can influence or intercept a TLS connection made by curl, or operate a server that the victim system connects to. The target curl invocation must be configured to request and rely on OCSP stapling for certificate status validation. During the TLS handshake, the server provides an OCSP stapling response that should be considered invalid, problematic, or otherwise unacceptable. Because of the flaw, vulnerable curl does not correctly detect the OCSP problem and proceeds as though the certificate status is valid. This can allow the attacker to maintain a TLS session that should have failed revocation checking, potentially exposing request contents, response data, credentials, API tokens, or downloaded artifacts depending on how curl is used.

How to fix it

Upgrade curl and any packages, base images, appliances, SDKs, or applications that bundle libcurl to a vendor-fixed release once available from the relevant distribution or product maintainer. Because no exact fixed version was provided in the input, use official curl, operating system, container image, and application vendor advisories as the source of truth for fixed package versions. If immediate upgrade is not possible, reduce exposure by avoiding reliance on OCSP stapling as the sole revocation-control mechanism for high-risk workflows, pinning trusted endpoints where appropriate, enforcing strict certificate validation, using trusted package repositories and artifact verification, and limiting curl-based automation to trusted networks and destinations. Do not disable TLS certificate verification as a workaround.

How to confirm the fix worked

Inventory curl and libcurl versions across hosts, containers, CI runners, appliances, and applications that statically or dynamically link libcurl. Confirm whether workflows use OCSP stapling options such as curl's certificate status checking behavior. Validate remediation by checking the installed curl/libcurl package versions against vendor advisories and by rerunning representative HTTPS connection tests where a bad or revoked OCSP stapling response is expected to fail. For packaged environments, confirm the operating system package changelog includes the CVE fix or corresponding upstream patch. For containers and embedded products, rebuild and redeploy images after the fixed package is available, then rescan images and runtime hosts.

Typical attack path

1. Identify a system, script, application, or automation workflow that uses vulnerable curl for HTTPS connections with OCSP stapling enabled.
2. Gain a position to intercept traffic, redirect the target to an attacker-controlled endpoint, or operate a service the target connects to.
3. Present a certificate and OCSP stapling response that should fail proper certificate status validation.
4. Allow vulnerable curl to incorrectly accept the problematic OCSP response and complete the TLS handshake.
5. Capture or manipulate data transmitted over the resulting connection, subject to the attacker's network position and the surrounding TLS/certificate conditions.

How to detect it

This issue is difficult to detect after the fact because successful exploitation may look like a normal HTTPS connection from curl. Focus retrospective analysis on environments where curl/libcurl was configured to use OCSP stapling certificate-status checks and where sensitive data was sent to external HTTPS endpoints. Review proxy, firewall, DNS, EDR, shell history, CI/CD logs, application logs, and package download logs for unexpected curl connections, unusual destinations, certificate warnings, recent DNS changes, traffic through untrusted networks, or downloads from nonstandard mirrors. Investigate any curl-based connections that occurred during suspected network interception events, rogue Wi-Fi/VPN/proxy activity, BGP/DNS anomalies, or certificate revocation incidents. If TLS inspection or packet capture is available, examine TLS handshakes for Certificate Status Request usage and abnormal or failed OCSP stapling responses that nevertheless resulted in completed sessions. There are no reliable universal host artifacts unique to exploitation of this flaw; detection depends on correlating vulnerable curl usage, OCSP stapling, suspicious network position, and unexpected HTTPS destinations.

• curl --cert-status
• CURLOPT_SSL_VERIFYSTATUS
• SSL_VERIFYSTATUS
• OCSP stapling
• Certificate Status Request
• status_request

What your security team should do

• Prioritize patching systems where curl or libcurl handles sensitive HTTPS traffic, credentials, API tokens, software downloads, update checks, or machine-to-machine service calls.
• Inventory direct curl binaries and applications that embed or link libcurl, including containers, CI/CD images, automation runners, monitoring agents, and third-party appliances.
• Monitor vendor advisories for the exact fixed curl/libcurl versions and apply distribution-specific updates when released.
• Review scripts and automation for use of OCSP stapling certificate-status checks and ensure they do not disable normal certificate validation.
• For critical download or update workflows, add defense-in-depth such as artifact signing, checksum verification from trusted channels, repository allowlisting, and endpoint pinning where operationally feasible.
• Treat this as normal-priority remediation in most environments because EPSS is low, the vulnerability is not in KEV, and no mature exploitation is reported; increase priority where network interception risk or compliance requirements are high.