libcurl EUVD-2026-105274

Requires a specific application behavior, not a special product configuration: the application must (1) use AWS SigV4 authentication via CURLOPT_AWS_SIGV4, (2) subsequently set CURLOPT_AWS_SIGV4 to NULL expecting to disable it, and (3) reuse the SAME curl easy handle for a later transfer to a different URL. Exploitation is LIMITED by these factors: it cannot occur on a fresh/duplicated handle, it requires the 'next' URL to be a host that should not receive the AWS signature (ideally attacker-controlled or an untrusted third party for the leak to have security value), and the disclosed material is the AWS4-HMAC-SHA256 request signature in the Authorization header rather than the raw secret key. There is no attacker-side network trigger; the flaw manifests through the victim application's own request sequencing.

This is a low-to-moderate real-world risk best characterized as an information-exposure/state-leak defect in libcurl, not a remote code execution or high-severity flaw. No CVSS vector was provided by NVD or the vendor, no EPSS score is available, there is no CISA KEV listing, and no public POC was identified - so all quantitative exploitation signals are MISSING and cannot be compared. The only confirmed signals are the vendor description (Ubuntu) and the availability of a patch. The functional impact is limited: setting CURLOPT_AWS_SIGV4 to NULL fails to clear SigV4 state, so a subsequent transfer on the SAME reused handle emits an 'Authorization: AWS4-HMAC-SHA256' header to whatever URL is configured next. Exploitation is contingent on a specific application coding pattern (handle reuse after attempting to disable SigV4) rather than any attacker-triggerable network condition, which sharply constrains realistic impact despite libcurl's enormous deployment footprint. The leaked value is a derived request signature in the Authorization header rather than the raw AWS secret key, so confidentiality impact is partial. Net: treat as a routine library-hygiene patch (low urgency) unless your application is known to reset CURLOPT_AWS_SIGV4 to NULL and reuse handles across differing endpoints, in which case it merits prompt remediation due to credential-signature disclosure to unintended hosts.

An application uses libcurl with AWS SigV4 authentication, then sets CURLOPT_AWS_SIGV4 to NULL intending to disable signing before reusing the same handle for an unrelated request. Because the state is not cleared, libcurl attaches a valid AWS4-HMAC-SHA256 Authorization header to the next request - and if that next URL points to an attacker-controlled or third-party endpoint, the signed credential material is disclosed to it. No public exploit identified at time of analysis; exploitation depends entirely on the victim application's handle-reuse behavior rather than a directly attacker-initiated action.