Skip to main content

🪐 Backed by $16.5M to build the security workforce for the security workforce. Meet the new Cantina.

Cantina case study: Apex finds 44-year-old bugs in OpenSSH

OpenSSH 10.3p1 fixes two vulnerabilities rooted in decades-old trust assumptions from Berkeley rcp.

Cantina 4 min read
OpenSSH CVE-2026-35385 CVE-2026-35387 security vulnerabilities SSH scp ECDSA

OpenSSH vulnerabilities explained: CVE-2026-35385 in scp and CVE-2026-35387 in ECDSA policy

One of the security issues fixed in OpenSSH 10.3p1 traces back to the original Berkeley rcp program. Infrastructure teams should pause on that for a minute. Some of the bugs that matter in 2026 are old trust assumptions still running inside modern workflows.

OpenSSH 10.3p1, released on April 2, 2026, fixed two vulnerabilities reported by Christos Papakonstantinou of Cantina and Spearbit:

Start with the short version.

  • Upgrade to OpenSSH 10.3p1 or later.
  • Review any scp workflows that run as root with legacy -O.
  • Recheck any policy that assumes listing one ECDSA algorithm restricts the rest.

What changed in OpenSSH 10.3p1?

According to the official release notes, OpenSSH 10.3p1 fixed a high-severity scp issue and a low-severity ECDSA policy issue alongside other security fixes.

The scp bug matters because it comes from inherited behavior that survived for decades. The ECDSA bug matters because it shows how policy intent and actual enforcement can drift apart in mature infrastructure.

What is CVE-2026-35385 in scp?

CVE-2026-35385 affects scp before 10.3. NVD describes the issue this way in substance: when a file is downloaded by scp, it may preserve setuid or setgid bits from the source code“ as it’s not installed

The OpenSSH release notes add the detail that makes this bug memorable: the behavior dates back to the original Berkeley rcp program. Berkeley rcp (short for “remote copy”) was an early Unix tool for copying files between machines over rsh. It predates strong authentication and encryption and assumed the machines and networks involved were trusted, so it also copied more file metadata by default than you would want across modern trust boundaries. scp was created later as a more secure replacement, but it inherited some of rcp’s metadata-handling assumptions.

That is the story here. scp inherited a trust model from an earlier era of Unix administration, when copying file metadata across systems felt normal inside a shared administrative boundary. In a modern environment, teams use SSH tooling across CI systems, mixed-trust infrastructure, external hosts, and automated workflows. The trust boundary changed. The inherited behavior stayed.

The relevant conditions are:

  • the download is performed as root
  • legacy scp protocol is used via -O
  • the transfer is done without -p

The exposure sits in a specific operational path. It still deserves attention because many teams treat SSH file transfer behavior as boring, stable infrastructure and do not revisit the assumptions underneath it.

What is CVE-2026-35387 in ECDSA policy handling?

CVE-2026-35387 affects OpenSSH before 10.3. The OpenSSH release notes say the fix addresses the incomplete application of PubkeyAcceptedAlgorithms and HostbasedAcceptedAlgorithms for ECDSA keys.

Before the fix, if one of those directives contained any ECDSA algorithm name, another ECDSA algorithm could be accepted in its place, even if it was not listed. NVD summarizes the issue as OpenSSH using unintended ECDSA algorithms.

This is an enforcement gap in algorithm policy. An administrator could think they enforced a curve-specific ECDSA policy when the effective policy was broader than the configuration suggested.

Why this release matters beyond the two CVEs

Security teams spend a lot of time looking for new attack paths. OpenSSH 10.3p1 is a useful reminder to look for old trust assumptions, too.

The scp issue survived because it lived inside normal behavior. The ECDSA issue survived because the policy looked more precise than the implementation actually was. Those are two different bug classes, but they point to the same lesson: mature software still needs fresh scrutiny, especially where configuration, legacy compatibility, and trust boundaries meet.

That is why bugs like this keep showing up in foundational tools. The code is old. The environments are new. The assumptions sit somewhere in the middle.

Who should pay attention to this?

This release deserves a close read from:

  • scp transfers, especially any scripted or automated workflows (and especially those that run as root and still use the legacy -O protocol)
  • security teams reviewing SSH-related hardening and access policy
  • identity and access owners who depend on ECDSA allowlists for tighter authentication control
  • engineering teams that assume mature system tools already match modern trust boundaries

What should teams do now?

  1. Upgrade to OpenSSH 10.3p1 or later.
  2. Audit any scp workflow that runs as root and uses legacy -O.
  3. Prefer current transfer paths and retire legacy mode where you can.
  4. Review PubkeyAcceptedAlgorithms and HostbasedAcceptedAlgorithms if your policy depends on specific ECDSA algorithms.
  5. Share this release with the teams that own SSH access, artifact movement, and authentication policy.

Final takeaway

One of these fixes came from a trust assumption old enough to feel invisible. That is what makes this release useful beyond the patch itself. It shows how long legacy behavior can survive once it becomes part of the furniture.

Send this blog to the team that owns your SSH workflows, build pipelines, and access policy.

Want help reviewing your SSH algorithm policy posture? Contact us to book a demo.

Keep exploring

Related research

Explore Apex