OpenSSH CVE-2026-35414: How a Comma in a Certificate Bypassed Root Login

What CVE-2026-35414 actually does

OpenSSH supports two distinct ways to authorize a login: listing individual public keys in an authorized_keys file, which is what almost every small VPS uses, and certificate-based authentication, where a trusted certificate authority signs short-lived certificates that vouch for a user's identity instead of each key being listed individually. Certificate authentication is common in larger organizations that rotate access frequently and do not want to edit authorized_keys on every server every time someone joins or leaves.

When certificate authentication is in use, an administrator can restrict which account names, called principals, a given certificate authority is allowed to grant access to, using the principals option in the authorized_keys entry that trusts that CA. CVE-2026-35414 is a flaw in how OpenSSH matched a certificate's principal name against that restriction when the principal name itself contained a comma. Because the matching logic used commas as a separator for the list of allowed principals, a maliciously or carelessly crafted certificate with a comma inside its own principal field could be parsed in a way that satisfied a restriction it was supposed to fail, letting the holder of that certificate authenticate as an account, potentially including root, that the restriction was specifically written to block.

Why a comma breaks the principals check

This class of bug, where a special character that is supposed to be a separator in one context leaks into a value it should not, has a long history in software security; SQL injection and HTTP header injection both come from the same underlying category of mistake. The specific danger with certificate principals is that the certificate itself, not just the server's configuration, is the thing supplying the value that gets parsed, and a certificate authority that does not carefully validate the principal names it signs can produce a certificate that is technically valid and technically trusted but structurally unexpected by the code checking it.

Public advisories describing the flaw, including the one published by the Cyber Security Agency of Singapore and the Center for Internet Security, describe the practical effect plainly: a user in possession of a certificate signed by a trusted CA could authenticate as a different, more privileged account than the certificate was intended to authorize, up to and including root, without needing to steal or guess a separate credential for that account.

Who is actually affected

The vulnerability only matters for servers that use OpenSSH certificate authentication with a TrustedUserCAKeys directive and a principals restriction in sshd_config or an authorized_keys cert-authority line, running an OpenSSH version before 10.3. This setup is common in larger engineering organizations, managed fleets that use short-lived access grants, and environments built around tools like HashiCorp Vault's SSH secrets engine or an internal CA for infrastructure access. It is uncommon on a typical small business VPS, where SSH access is usually managed with a handful of individually listed public keys rather than a certificate authority.

Who is not affected

A server using plain public-key authentication, meaning individual keys pasted into authorized_keys with no TrustedUserCAKeys directive configured, is not exposed to CVE-2026-35414 at all. This describes the large majority of small business VPS and self-managed server setups, and it is worth confirming rather than assuming: the quick check above, grepping sshd_config and authorized_keys for certificate-related directives, takes under a minute and gives a definitive answer.

How to check your own server

ssh -V
grep TrustedUserCAKeys /etc/ssh/sshd_config
grep cert-authority ~/.ssh/authorized_keys
grep PermitRootLogin /etc/ssh/sshd_config

If the second and third commands return nothing, certificate authentication is not configured and this specific CVE does not apply to that server. If the OpenSSH version reported by the first command is 10.3 or newer, the fix is already present regardless of authentication method used. If PermitRootLogin is not explicitly set to no, that is worth fixing independently of this CVE: our root login glossary entry and full SSH hardening guide cover why disabling it directly limits the damage any single authentication bypass, of any kind, can do.

Fixing it

The fix is to upgrade to OpenSSH 10.3 or later, which resolves the principals matching flaw directly; there is no configuration workaround that fully closes the bypass while staying on an older version, because the defect is in the parsing logic itself, not in a setting an administrator controls. On Debian and Ubuntu, sudo apt update && sudo apt install openssh-server pulls in the fix once the distribution has backported it into its supported release; on RHEL-family systems, sudo dnf upgrade openssh-server does the equivalent. Always confirm the installed version afterward with ssh -V rather than assuming the update succeeded.

If certificate authentication is central to how your organization grants server access and an immediate upgrade is not possible, a temporary mitigation is to audit and tighten which CAs are trusted and ensure no certificate authority in use issues principal names containing unusual characters, but this is a stopgap, not a substitute for patching. Our patch management guide covers building an expedited path specifically for vulnerabilities like this one, where the fix already exists and speed of application is what determines whether it becomes a real incident.

The broader lesson for VPS operators

Even for the majority of small VPS operators who do not run an SSH certificate authority and are not directly exposed to CVE-2026-35414, the case is a useful, concrete reminder of three habits worth keeping regardless of which specific CVE is in the news this month. First, know exactly which authentication mechanisms are actually active on a server rather than assuming; the two grep commands above took a few seconds and gave a definitive answer instead of a guess. Second, keep SSH itself current, since even infrequently exploited components can turn into the exact bypass this one was once a flaw is found. Third, disable root login regardless of what authentication method is used, because a bypass that only grants access as a limited account is a materially smaller incident than one that hands over root in a single step.

This same pattern, a working fix already published while some fraction of internet-facing servers remain unpatched, is precisely what CISA's Known Exploited Vulnerabilities catalog exists to track and what our patch management guide covers building a process around, rather than reacting to each individual advisory as a one-off surprise.