SplitSSHell: a comma in a cert principal has been root in OpenSSH since 2011

OpenSSH before 10.3 gets certificate principal matching wrong in a specific way. When you use a cert-authority line in authorized_keys with a principals= restriction, the server checks that the connecting user’s certificate includes one of the listed principals. CVE-2026-35414 is what happens when a comma shows up inside a principal name.

The matching code treated comma as a list separator. A certificate encoding the principal admin,root would match both admin and root in the authorized list. Issue yourself a certificate with a principal name containing a comma followed by a target you should not have access to, and the server lets you in, logs a successful authentication, and moves on with its day.

The bug has been in the code since OpenSSH 5.6. That is 2011. Fifteen years. The patch shipped in 10.3 on April 2. Government CERTs are circulating advisories about it this week because the Cyera research team published SplitSSHell, a full technical write-up with a working proof of concept, after the embargo window closed. Five-month-old patch, fresh proof of concept.

Who is in the blast radius

Narrower than the headline implies, but the configuration is not unusual.

You need all three of these. Certificate authentication, not just key auth. An authorized_keys file using cert-authority with a principals= option listing multiple principals. A CA in your trust chain that will issue certificates encoding comma-separated principal strings.

The TrustedUserCAKeys / AuthorizedPrincipalsFile path is not affected. This is the authorized_keys cert-authority path only.

If you run a bastion host or jump host where certificate issuance is centralized and authorized_keys uses principals restrictions, audit recent certificate issuance. Check whether anything in your PKI would encode principals with commas. Unlikely is not zero, and the authentication logs will not help you if exploitation already happened. The server logged it as a successful login.

The parsing failure is not a surprise

A comma has no business being a significant character inside a security principal name. The reason it was is that someone chose to encode multiple principals as a comma-delimited string inside a certificate field and then wrote matching code that split on commas without asking whether the principal itself might contain one.

Comma-delimited lists in security-critical parsing have a known track record here. CSV injection, HTTP header injection, email folding bugs. The correct format for a list of discrete identifiers is not a flat string with a separator character that can appear in the values. This is why structured encodings exist.

The good news is that the OpenSSH developers closed the report on March 28 and shipped the fix by April 2. Four days from disclosure to patch in a security advisory, for a bug that lived in the codebase for fifteen years. Credit where it is due.

What to do

Check your version now: ssh -V. If the output says anything before 10.3, you have work to do.

If you have been sitting on the 10.x upgrade because of the breakage that came with it, the ML-KEM key exchange changes were the main source of enterprise pain. CVE-2026-35414 is a separate and more immediately exploitable problem if you are using cert auth.

For the broader certificate lifecycle picture, the certificate lifetimes piece from July covers why short-lived certificates make this class of bug hurt less even when you cannot patch immediately. Issuing 24-hour certs from your internal CA limits the window a malformed certificate can be used even if the bug is present on the target.

The OpenSSH 10 overview from August has the full changelog context if you want to know what else changed in the jump.

Patch the SSH daemon.