CVE-2026-35414: A 15-Year-Old Comma in OpenSSH

The bug in one sentence

OpenSSH before 10.3 mishandles the authorized_keys principals="..." option when matching against certificate principals: a comma embedded in a principal name (e.g., deploy,root) is treated as a list separator, allowing a low-privileged certificate holder to authenticate as a higher-privileged account. NVD classifies the weakness as CWE-670 Always-Incorrect Control Flow Implementation — already pointing toward a server-side implementation defect rather than a credential lifecycle problem.

OpenSSH fixed the issue in 10.3 / 10.3p1 on April 2, 2026. The root cause is a code-reuse error: matching logic originally written to split cipher and key-exchange lists on commas was reapplied to principal comparison, where commas can legitimately appear inside a principal name. Cyera's analysis demonstrated full root shell access on a test server using a crafted certificate — and noted that because the server treats the authentication as successful, log-based detection produces no failure record. The bug has been latent in OpenSSH for roughly 15 years.

Why this is easy to mis-map

At first glance, this looks like an identity issue. The attacker presents an SSH certificate, and sshd accepts it for an account it should not. The temptation is to map the CVE directly to #4 Identity Theft.

But TLCTC is cause-oriented. The cluster assignment follows the generic vulnerability initially exploited, not the impact label. Per Axiom VII and R-ROLE, server-role implementation defects map to #2 Exploiting Server, regardless of how the request that triggered them was framed. The white paper makes this explicit: credential acquisition and credential application must be distinguished from the underlying vulnerability that enabled the attack.

That gives us two answers — one for the path, one for the CVE:

Scenario path:        #4 → #2
Primary CVE mapping:  #2

The TLCTC reading

The certificate is an identity artifact. When the attacker presents it intending to authenticate as a principal they are not entitled to, that action falls under R-CRED: credential application to operate as an identity always maps to #4 Identity Theft.

sshd then processes the authentication attempt. The vulnerability triggered is server-side principal-matching logic — code imperfection on the server side — which under R-ROLE maps to #2 Exploiting Server. The TLCTC decision tree treats concrete code-implementation flaws as #2 or #3 depending on the role of the vulnerable component.

The clean attack-path expression:

#4 ||[auth][@External→@OpenSSH-sshd]|| →[Δt=instant] #2 + [DRE: C, I]

Plain reading: the attacker presents an SSH certificate to authenticate as a principal they do not legitimately hold; OpenSSH's sshd then mismatches the certificate's comma-containing principal against the configured principals list, granting access — typically with confidentiality and integrity consequences. Where the matched account is root, the realistic outcome is full system compromise, and [DRE: A] becomes reachable through follow-on actions.

Why #4 belongs in the path (not just #2)

A natural objection: Appendix B5 of the v2.1 white paper maps a broken-access-control logic flaw — an authenticated user reaching another user's data through a server-side defect — to #2 alone, with no preceding #4 step. Why is this CVE different?

Because of the operate-as-identity criterion in R-CRED. In B5, the attacker is authenticated as themselves and uses a server flaw to reach data they should not see; no identity claim is being asserted. In CVE-2026-35414, the attacker presents a certificate to authenticate as a principal they are not entitled to be — the unauthorized identity assertion is the action, the matching flaw is what makes it succeed. That is precisely the configuration R-CRED was written for.

So the path includes #4 because credential application to claim an unauthorized identity occurs. The CVE itself remains #2 because the vulnerability being exploited is server-side code.

Why the CVE is not primarily #4

A #4-only mapping would be correct if the root vulnerability were credential theft, forgery, replay, or weak binding. CVE-2026-35414 is more specific: the server's matching algorithm is wrong. The certificate is cryptographically valid; the CA signed it; nothing about credential lifecycle was breached. What broke is sshd's control flow when comparing strings that legitimately may contain commas.

That is why #4 → #2 is the right scenario expression and #2 is the right CVE classification. The #4 step gets the attacker to the authentication decision point. The #2 step is where the implementation defect produces the wrong answer.

Why not #7

There is no need to add #7 Malware unless foreign executable content actually executes. Successful authentication — even as root — is not, by itself, foreign code execution. Per R-EXEC, #7 must be recorded as a separate step only when foreign executable content runs through a designed execution capability. The CVE description does not describe that path. If a post-authentication scenario adds shell command execution by the attacker afterward, that would be a separate question — and would typically be #1 Abuse of Functions, since the attacker is invoking legitimate shell capabilities; only foreign-code introduction would push it to #7.

So this is not:

#4 → #2 → #7

It is:

#4 → #2 + [DRE: C, I]

unless a separate post-compromise scenario adds something more.

On severity scoring

The scoring is divergent. NVD lists CVSS 3.1 Base 8.1 (High) with PR:N. The CNA vector on the same NVD page yields 4.2 (Medium) with PR:L; some downstream catalogs (e.g., Ubuntu) follow that. Cyera's published demonstration of root shell access supports the higher score: an attacker holding a cert with deploy,root as the principal authenticates as root, and log-based detection does not fire because the authentication is "successful" from the server's perspective.

CVSS estimates severity. TLCTC classifies cause and path.

This divergence is operationally relevant, but it does not change the TLCTC mapping. For CVE-2026-35414, the cause remains a server-side implementation flaw in sshd, and the scenario includes credential presentation as a preceding step.

Practical takeaway

For defenders, "patch OpenSSH" is necessary but not sufficient. The reachable consequence is silent privilege elevation that bypasses log-based detection — meaning environments that relied on auth-failure telemetry to spot unauthorized access have a blind spot for any past or future exploitation of this class of bug. Audit which CAs are trusted for SSH cert authentication, audit the principal names those CAs have issued, and review any principals="..." entries in authorized_keys. The OpenSSH release notes also confirm that the canonical certificate path using TrustedUserCAKeys / AuthorizedPrincipalsFile is not affected — the issue is specific to per-key principals= in authorized_keys.

Final classification

This is exactly the kind of case where TLCTC saves defenders from outcome-driven naming. "Auth bypass" describes what happens. "#4 → #2" describes how the attack reaches and exploits the vulnerable server behavior — and tells you which controls actually address the root cause.