OpenSSH Patches a 15-Year-Old Comma-Parsing Bug That Could Promote Certificate Holders to Root

Overview

The OpenSSH project shipped version 10.3 on April 2, 2026, fixing an access-control bug in which a stray comma inside an SSH certificate principal could trick a server into authenticating the holder as a different account, including root. The flaw is tracked as CVE-2026-35414 and carries a CVSS v3.1 base score of 8.1 (HIGH) in the NIST National Vulnerability Database. According to SecurityWeek, the parsing error sat in OpenSSH for roughly fifteen years before being corrected.

What We Know

The OpenSSH 10.3 release notes describe the fix in plain terms: “when matching an authorized_keys principals="" option against a list of principals in a certificate, an incorrect algorithm was used that could allow inappropriate matching in cases where a principal name in the certificate contains a comma character.” The release notes credit the report to Vladimir Tokarev.

NIST’s official summary in the National Vulnerability Database reads: “OpenSSH before 10.3 mishandles the authorized_keys principals option in uncommon scenarios involving a principals list in conjunction with a Certificate Authority that makes certain use of comma characters.” NVD classifies the weakness as CWE-670, “Always-Incorrect Control Flow Implementation,” and assigns the vector CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H.

The practical impact is that a low-privileged identity holding a certificate from a trusted CA can be promoted to a different account, up to root, when the server’s authorized_keys configuration uses a principals= list and the attacker’s certificate principal contains a comma. The MS-ISAC advisory issued by the Center for Internet Security summarizes the risk: “A comma in an SSH certificate principal name leads to OpenSSH access control bypass, allowing users to authenticate as root on a vulnerable server, as long as they have a valid certificate from a trusted CA.” The advisory, numbered 2026-040 and dated April 28, 2026, rates the threat as HIGH for large and medium government entities and businesses.

Security firm Cyera, which publicly analyzed the bug in a research write-up on April 29, 2026, frames the parsing error with an analogy: “if you put a comma in the middle of your name on the ID - ‘John,Manager’ instead of ‘John’ - the door reads it as two IDs, sees ‘Manager,’ and lets you in as the manager.” Cyera writes that “the flaw has been present for over 15 years and was fixed this week.”

SecurityWeek adds an operational warning that complicates incident response: “The server considers the authentication legitimate, meaning this attack does not register an authentication failure in logs, making log-based detection highly unreliable.”

Distributions Are Already Backporting

Linux distributions are not waiting for users to jump to OpenSSH 10.3p1 wholesale. The Ubuntu security team has published fixes against currently supported releases, according to its tracker page: version 1:10.2p1-2ubuntu3.2 for 26.04 LTS, 1:10.0p1-5ubuntu5.4 for 25.10, 1:9.6p1-3ubuntu13.16 for 24.04 LTS, and 1:8.9p1-3ubuntu0.15 for 22.04 LTS. Canonical rates the issue Medium priority on the Ubuntu scale.

The OpenSSH 10.3 release notes bundle the principals fix with several other security corrections, including a separate ssh(1) shell-metacharacter validation issue reported by Florian Kohnhäuser and an scp(1) setuid/setgid handling bug reported by Christos Papakonstantinou of Cantina and Spearbit. Administrators upgrading for the comma bug pick up those fixes in the same step.

What We Don’t Know

Neither the OpenSSH project nor SecurityWeek has reported evidence of in-the-wild exploitation prior to disclosure. Because the attack “does not register an authentication failure in logs,” as SecurityWeek notes, defenders cannot easily reconstruct historical activity from sshd logs alone, which makes any retrospective assessment of abuse difficult.

CVSS scoring also varies across vendors. NIST publishes 8.1 (HIGH) in the NVD record; Ubuntu lists the issue at Medium priority. The disagreement reflects a real-world tension: full exploitation requires both a CA-issued user certificate and a server configuration that uses principals= matching, conditions that are common in large managed fleets but unusual for small deployments.

Analysis

The SSH certificate model exists precisely so that organizations do not have to manage millions of authorized_keys files by hand. A certificate authority signs short-lived user certificates, each binding a public key to a list of principal names, and servers grant access based on whether one of those principals matches a permitted entry. CVE-2026-35414 is a reminder that the trustworthiness of that pipeline depends not only on the CA’s discipline but also on the server’s parser. A single comma, mishandled at the wrong layer, can collapse the boundary between a low-privilege account and root.

For administrators, the practical posture is straightforward and is the same one MS-ISAC recommends: upgrade OpenSSH to 10.3 or apply the distribution backport, and audit authorized_keys files for principals= directives in front of CA-issued certificate logins. For developers of CA tooling, the bug is a prompt to reject principal names that contain delimiter characters at issuance time rather than relying on every downstream consumer to parse them safely.