CVE-2026-55200: Verified Repro With Script Download

• Affected versions: vulnerable libssh2 commit 39cd3a82c7e07a08c1e218b91e69fd92d4f35ca3 and earlier; fixed at commit 97acf3dfda80c91c3a8c9f2372546301d4a1a7a8
• Risk level: high, because attacker-controlled SSH peer bytes can trigger a process-level crash in a widely used CLI client path
• Consequence: denial of service of the curl process; in a broader deployment context, this could terminate automation jobs, batch transfers, or other client-side workflows that rely on curl + libssh2

Root Cause

The vulnerable path processes attacker-controlled SSH packet data after a real SSH handshake and channel/subsystem negotiation. In the reproduced scenario, the peer sends a malformed encrypted packet whose clear packet length is 0xfffffff0. The vulnerable build accepts the packet boundary conditions far enough into the libssh2 transport parser that the curl process hits a native segmentation fault.

The fixed commit 97acf3dfda80c91c3a8c9f2372546301d4a1a7a8 rejects or fails closed on the same traffic shape, so the product exits cleanly instead of crashing.

Reproduction Steps

1. Run bundle/repro/reproduction_steps.sh.
2. The script reuses the prepared project cache, identifies the real curl product binaries, verifies dynamic linkage to the vulnerable and fixed libssh2 prefixes, starts a localhost malicious SSH peer, and drives curl through its normal SFTP-over-SSH path.
3. The vulnerable curl binary is executed twice and crashes with SIGSEGV each time. The fixed curl binary is executed twice and exits cleanly without the crash.
4. Expected evidence includes the SSH server logs showing TCP connection, authentication, SFTP subsystem negotiation, injection of the malformed encrypted packet, and curl loader/product logs showing the linked libssh2 path.

Evidence

Primary evidence is stored under bundle/logs/ and bundle/repro/:

• bundle/logs/reproduction_steps.log
• bundle/logs/curl-vulnerable-run1.server.log
• bundle/logs/curl-vulnerable-run1.loader.log
• bundle/logs/curl-vulnerable-run2.server.log
• bundle/logs/curl-vulnerable-run2.loader.log
• bundle/logs/curl-fixed-run1.server.log
• bundle/logs/curl-fixed-run1.loader.log
• bundle/logs/curl-fixed-run2.server.log
• bundle/logs/curl-fixed-run2.loader.log
• bundle/logs/curl-vulnerable-ldd.log
• bundle/logs/curl-fixed-ldd.log
• bundle/logs/curl-vulnerable-readelf.log
• bundle/logs/curl-fixed-readelf.log
• bundle/logs/curl-vulnerable-version.log
• bundle/logs/curl-fixed-version.log
• bundle/repro/runtime_manifest.json

Key excerpts observed during execution:

• curl binary loaded vulnerable libssh2 from .../libssh2-vuln-prefix/lib/libssh2.so.1
• curl binary loaded fixed libssh2 from .../libssh2-fixed-prefix/lib/libssh2.so.1
• malicious peer log: sent encrypted malformed packet seq=11 clear_packet_length=0xfffffff0 body_len=32 wire_len=52
• vulnerable runs: Segmentation fault (core dumped) with return code 139
• fixed runs: return code 2 without the native crash

Environment details captured:

• product binary: 32-bit i386 curl 8.21.0-DEV
• runtime stack: curl, libssh2, asyncssh
• entrypoint kind: tcp_peer

Recommendations / Next Steps

• Apply the upstream fix at 97acf3dfda80c91c3a8c9f2372546301d4a1a7a8 or upgrade to a release that includes it.
• Rebuild curl and any other libssh2 consumers against the patched library.
• Add regression coverage for malformed encrypted SSH packets, especially around packet-length validation after authentication and subsystem negotiation.
• Keep a negative-control test that verifies the fixed build fails closed on the same packet shape without a native crash.

Additional Notes

• The reproduction script is idempotent enough for repeated execution; it was run twice consecutively and produced the same result.
• This proof is product-mode and non-sanitized; sanitizer output was not used as the primary success oracle.
• The exploit path is limited to a localhost SSH peer in this environment, but it exercises the real curl/libssh2 boundary and the real parser path.