# SplitSSHell: a comma in SSH certificates opened root access in OpenSSH (CVE-2026-35414)

- **Published on:** 2026-04-22
- **Category:** Security
- **Original page:** https://linuxgratis.com/en/articles/cve-2026-35414-splitsshell-openssh-principals-coma-auth-bypass

A 15-year-old OpenSSH flaw let a certificate with a 'deploy,root' principal bypass access control and authenticate as root. Fixed in OpenSSH 10.3.

---

OpenSSH carried a bug in how it handles principal names inside SSH certificates for roughly fifteen years. The security firm Cyera found it, and it went public on 22 April 2026 under the name **SplitSSHell**, tracked as **CVE-2026-35414** with a CVSS score of 8.1. The fix shipped in **OpenSSH 10.3**.

## What the flaw actually is

The problem comes from two parts of the code reading the same thing in different ways. During session negotiation, one function splits the certificate's principals field on commas and treats it as a list. The function that checks authorization in `authorized_keys`, on the other hand, reads it as a single string with no splitting at all.

That mismatch is the crack. If a trusted certificate authority (CA) issues a certificate whose principal contains a comma, say `deploy,root`, the two code paths disagree. One sees a single principal literally named `deploy,root`; the other sees two, `deploy` and `root`. The upshot is that someone meant to log in only as `deploy` slips through as `root` on vulnerable servers.

## Who is affected

Any deployment using SSH certificate authentication with the `principals=` option in `authorized_keys` or in authorized-principals files. That pattern is common in larger infrastructures that sign short-lived certificates from a central CA instead of handing out public keys by hand.

You need a valid certificate signed by a CA the server trusts. This is not something anyone can fire off from the open internet: the attacker has to get the CA to issue a certificate with the crafted principal, or otherwise influence that issuance process. Even so, in organizations where many people or systems request certificates from the same CA, the room to abuse it is real.

One detail makes it worse. The bypass does not record an authentication failure in the logs, so log-based detection misses the attempt entirely. You would end up with unauthorized root access and no obvious trace that anything went wrong.

## Severity and mitigation

At CVSS 8.1 with an impact reaching root, treat it as a priority on any server that relies on SSH certificates. The recommended path is direct: upgrade to **OpenSSH 10.3** or later, where both halves of the code now read principals the same way.

If you cannot upgrade right away, review your CA policies and make sure no principal contains commas or characters that could be read as list separators. Restrict which principals each trusted CA may issue, and audit certificates already in circulation. It also helps to review who can request certificates and under what names, since that issuance step is where the abuse starts.

A flaw surviving three decades' worth of half-lifetime in a codebase as scrutinized as OpenSSH is a reminder that consistency between how a value is validated and how it is authorized matters as much as the cryptography underneath.

## Source

- [SecurityWeek — OpenSSH Flaw Allowing Full Root Shell Access Lurked for 15 Years](https://www.securityweek.com/openssh-flaw-allowing-full-root-shell-access-lurked-for-15-years/)
- [NVD — CVE-2026-35414](https://nvd.nist.gov/vuln/detail/CVE-2026-35414)