Product: libcurl
libcurl is a widely used client-side data transfer library supporting secure protocols such as HTTPS, SFTP, SCP, FTPS, and others. It is embedded in operating systems, enterprise software, cloud platforms, DevOps tooling, and custom applications where secure network communication is required.
Initial Vulnerability Information
| Field | CVE-2025-15079 | CVE-2025-14819 |
|---|---|---|
| Affected Product | libcurl | libcurl |
| Affected Component | libssh backend (SFTP / SCP) | OpenSSL TLS backend |
| Vulnerability Type | Host trust bypass | Improper certificate validation |
| Attack Vector | Network | Network |
| Authentication Required | No | No |
| User Interaction | No | No |
| CVSS Score | 5.3 (Medium) | 5.3 (Medium) |
| Severity | Medium | Medium |
| Exploitability | Conditional | Conditional |
| Exploit Availability | No public exploit | No public exploit |
| PoC Availability | Educational / research only | Educational / research only |
| Affected Versions | 7.58.0 – 8.17.0 | 7.87.0 – 8.17.0 |
| Fixed Version | 8.18.0 | 8.18.0 |
Common Characteristics
Root Cause
Both vulnerabilities originate from trust state confusion inside libcurl rather than classic memory corruption or logic crashes. In each case, libcurl behaves differently than what the application explicitly configures, causing security assumptions to break silently.
Common Impact Themes
- Weakening of transport-level trust guarantees
- Increased exposure to man-in-the-middle attacks
- Silent acceptance of connections that should have failed
- Risk amplification in automated, non-interactive workflows
Exploitation Reality
- Exploitation is environment-dependent
- Requires specific backend usage and configuration
- Not trivially exploitable at scale
- No known real-world attacks at this time
- Higher risk in long-running services and shared environments
General Detection Strategy
- Asset and version inventory of libcurl usage
- Focus on applications performing:
- Automated SFTP / SCP transfers
- TLS-secured API calls
- Enhanced logging around trust decisions
- Correlation between configuration and runtime behavior
Recommended Log Sources
- Application logs using libcurl
- Endpoint Detection & Response (EDR)
- Linux audit logs (auditd)
- File Integrity Monitoring (FIM)
- Network telemetry (TLS metadata, SSH sessions)
CVE-2025-15079
SSH Host Trust Bypass – libssh Backend
Vulnerability Details
When libcurl is compiled with the libssh backend, it relies on libssh for SSH host key verification. Even when an application explicitly configures a custom known_hosts file, libssh may fall back to global or system-wide known_hosts files if the host is not found in the specified file.
This fallback behavior can cause libcurl to trust SSH host keys that the application never intended to allow, violating strict host verification expectations.
How Exploitation Could Occur
An attacker could:
- Insert a malicious SSH key into a global known_hosts file
- Reuse polluted trust data on shared systems
- Exploit permissive environments where host keys are accepted automatically
Once the key exists in a fallback location, libcurl may silently accept it, enabling SSH impersonation.
Impact
- SFTP / SCP man-in-the-middle attacks
- Data interception or manipulation
- Compromise of automated file transfers
- Loss of host authenticity assurance
MITRE Mapping
- CWE-297 – Improper Validation of Certificate with Host Mismatch
- ATT&CK:
- T1557 – Adversary-in-the-Middle
- T1040 – Network Traffic Capture
Detection Guidance
- Monitor modifications to:
/etc/ssh/ssh_known_hosts- User-level
known_hostsfiles
- Alert on new SSH fingerprints
- Correlate host key changes with outbound SFTP activity
- Flag SFTP connections to first-seen hosts
Mitigation
- Upgrade libcurl to 8.18.0 or later
- Prefer libssh2 backend if rebuilding
- Restrict write access to known_hosts files
- Enable file integrity monitoring
CVE-2025-14819
TLS Partial Certificate Chain Trust Confusion – OpenSSL Backend
Vulnerability Details
libcurl caches Certificate Authority (CA) stores for performance. When applications reuse libcurl handles and change TLS validation settings between requests, the cached CA store may be reused with outdated policy rules.
This can result in partial TLS certificate chains being accepted even when the application explicitly disables partial-chain validation.
How Exploitation Could Occur
An attacker could present:
- A TLS certificate chain missing intermediate certificates
- A chain that would normally fail strict validation
Under affected conditions, libcurl may incorrectly accept the connection, enabling traffic interception or service impersonation.
Impact
- Acceptance of improperly validated TLS certificates
- Compromise of encrypted API communications
- Increased exposure to MitM attacks
- Undermined TLS trust enforcement
MITRE Mapping
- CWE-295 – Improper Certificate Validation
- ATT&CK:
- T1557 – Adversary-in-the-Middle
- T1600 – Weaken Encryption
Detection Guidance
- Log and inspect full TLS certificate chains
- Alert on accepted partial chains
- Monitor inconsistent TLS verification outcomes
- Track long-lived libcurl handle reuse
Mitigation
- Upgrade libcurl to 8.18.0 or later
- Disable CA certificate caching if upgrade is delayed
- Avoid toggling partial-chain options across requests
- Enforce TLS validation at reverse proxies
Official Patch / Upgrade
Upgrade libcurl to version 8.18.0 or later
Official download page:
https://curl.se/download.html
Final Takeaway
These vulnerabilities highlight the risks of implicit trust inheritance in security-critical libraries. While exploitation is not trivial, environments relying on automated secure transfers or strict TLS enforcement should prioritize patching.
Applying the official upgrade fully resolves both issues.
