CVE-2026-86410: redirect to SFTP or SCP bypasses host verification

How it was found

Summary

ssh_setopts() in src/config2setopts.c returns immediately when the initial URL is not SCP or SFTP. This means --knownhosts, --hostpubsha256, and --hostpubmd5 are never installed on the easy handle when the initial URL is HTTPS. If --location --proto-redir +sftp is used and the server returns a Location: sftp://… redirect, the SFTP connection proceeds without any of the user's requested SSH host-key verification.

Commit ab3bb8cd8be8f9d4acb97da0418abc279182041e fixed CVE-2026-12064 for --proto-default but did not touch the early-return guard that causes this redirect variant. The vulnerable guard is present in the released curl-8_21_0 tag and at current HEAD.

Affected versions

Affected versions: curl CLI 7.81.0 through 8.21.0, plus affected 8.22.0

Root cause

In src/config2setopts.c, ssh_setopts() (line 205) bails out early:

if(use_proto != proto_scp && use_proto != proto_sftp)
  return CURLE_OK;

use_proto is derived from the initial command-line URL in config2setopts(). When the initial URL is HTTPS, none of CURLOPT_SSH_KNOWNHOSTS, CURLOPT_SSH_HOST_PUBLIC_KEY_SHA256, or CURLOPT_SSH_HOST_PUBLIC_KEY_MD5 are set on the easy handle. Redirect handling occurs inside libcurl and does not rerun config2setopts(), so the SFTP connection has no host-key verification policy. Verbose output on the redirected connection explicitly reports SSH: no knownhosts file configured.

Security impact

An attacker who can impersonate the redirected SFTP endpoint can substitute downloaded content while curl reports success. The user's explicit --knownhosts or --hostpubsha256 policy is silently ignored.

Preconditions:

1. SSH-enabled curl build (libssh2 or libssh).
2. --location --proto-redir +sftp (user explicitly enables SFTP redirects).
3. A trusted HTTPS origin that redirects to SFTP.
4. Authentication credentials usable at the SFTP endpoint.
5. An attacker able to impersonate the SSH endpoint.

I expect Low severity given the narrow attack surface and leave classification to the security team.

Reproduction

1. Build an affected curl command-line tool, starting with 7.81.0, with SFTP support through libssh2 or libssh and HTTPS support through a TLS backend.
2. Start an SFTP server with a known SSH host key, valid test credentials, and a file containing recognizable test data.
3. Create a known_hosts file for the SFTP hostname and port that deliberately contains a different SSH host key.
4. Start an HTTPS server with a certificate that curl can validate normally.
5. Configure the HTTPS server to return a redirect whose Location header points to the test file on the SFTP server.
6. As a direct-transfer control, invoke curl against the SFTP URL with the mismatching --knownhosts file.
7. Confirm that the direct transfer fails host-key verification and does not download the file. This demonstrates that the file is valid and enforced for an initially selected SFTP protocol.
8. Invoke curl against the HTTPS URL with certificate verification enabled, redirect following enabled, SFTP explicitly permitted in --proto-redir, and the same mismatching --knownhosts file.
9. Observe the vulnerable result: curl follows the redirect, authenticates to the SFTP server, downloads the file, and reports success despite the requested host-key policy mismatch.
10. Enable verbose output and confirm that the redirected SFTP connection reports that no known-hosts file was configured.
11. Repeat the redirected transfer using a deliberately incorrect --hostpubsha256 value instead of, or in addition to, the mismatching known_hosts file.
12. Confirm that the redirected transfer also omits that host-key pin while a direct SFTP request enforces it.
13. As a protocol-policy control, remove SFTP from the redirect allowlist and repeat the HTTPS request.
14. Confirm that curl refuses the redirect, demonstrating that exploitation still requires the user to permit the HTTP(S)-to-SFTP transition.
15. Confirm a fix by installing SSH-specific easy-handle options independently of the initial URL protocol rather than returning early for an initial HTTP or HTTPS URL.
16. Repeat the redirect case and verify that the SFTP connection enforces the supplied host-key policy and fails before authentication or file transfer.

Expected result

SSH host-verification options supplied on the command line must apply whenever the transfer reaches SCP or SFTP, including through an allowed redirect.

Vulnerable result

Curl configures SSH verification only when the initial URL is SSH-based. An HTTP or HTTPS easy handle redirected to SFTP therefore connects without the requested known-hosts file or host-key pin.

Suggested fix

Remove the protocol guard in ssh_setopts() so that SSH options are always installed on the easy handle. The handle can later transition to SCP/SFTP via redirect, and unused SSH options on a non-SSH transfer are harmless. Add regression tests for an HTTPS-to-SFTP redirect with mismatching --knownhosts and --hostpubsha256.

Impact

Summary:

An attacker able to impersonate an SFTP endpoint referenced by a trusted HTTPS redirect can bypass the user’s requested known-hosts or host-key pin verification. Curl may authenticate to the attacker-controlled SSH server, potentially exposing SFTP credentials and allowing the attacker to substitute downloaded content while curl reports success.