OpenSSH certificate principal confusion turns commas into root access

At a glance

What this is: This analysis explains how an OpenSSH certificate-authentication bug let comma-splitting in principals= checks turn one certificate principal into another account, including root.

Why it matters: It matters because teams using SSH certificates for NHI governance may have assumed principal restrictions were exact-match controls when one vulnerable trust path was not.

By the numbers:

• OpenSSH 5.6 through 10.2p1 were affected in the vulnerable principals= path.
• 10.3/10.3p1.
• CVE-2026-35414 was later updated to 8.1 High.
• The issue was reported on March 28, 2026.

👉 Read Cyera's analysis of the OpenSSH certificate principal bypass

Context

SSH certificates are meant to reduce key sprawl by moving trust from copied public keys to a certificate authority. That model works only when identity checks stay exact and the authorization path treats certificate principals as opaque strings, not as something to be parsed like a list. In this case, the problem sits squarely in NHI governance: a control that should have enforced scope instead allowed a certificate principal to be reinterpreted during matching.

The issue matters for IAM and NHI teams because certificate-based access is often adopted specifically to replace brittle static key distribution. If the server-side trust path can split identities on punctuation, then the policy boundary is weaker than the architecture suggests. This is a typical class of implementation failure in identity systems, where a narrow parsing mistake can undercut a broader least-privilege design.

Key questions

Q: How should security teams validate SSH certificate trust paths before rollout?

A: Validate each trust path independently and test the exact authorization primitive it uses. A certificate system is only as strong as the comparison logic behind it, so teams should confirm whether principal checks use exact matching, whether delimiter characters are allowed, and whether the CA workflow can generate ambiguous identity strings. Review both issuance and server-side enforcement before exposing privileged accounts.

Q: Why do SSH certificates create hidden NHI governance risk?

A: SSH certificates move control from copied keys to central issuance, but they also create a new dependency on the CA, the signing workflow, and the server-side parser. If any layer can reinterpret an identity field, the certificate can still authenticate outside its intended scope. Governance has to cover encoding, approval, and verification together, not just certificate lifetime.

Q: What breaks when principal restrictions are parsed like lists?

A: Principal restrictions stop behaving like identity controls and start behaving like token matching. That creates scope drift, because one principal string can be split into multiple authorization candidates. In practice, a certificate intended for one account may satisfy another account’s restriction if the code treats punctuation as a delimiter instead of part of the identity.

Q: How should organisations respond when a privileged SSH certificate path is flawed?

A: Disable or constrain the affected trust pattern first, then search for any privileged accounts that rely on it. Rotate the CA or any signing workflow that may have issued ambiguous principals, and move sensitive access to a configuration path that uses exact principal comparison. Treat the issue as an authorization exposure, not just a software patch event.

Technical breakdown

How OpenSSH certificate principal matching failed

OpenSSH supports SSH user certificates by letting a trusted CA sign a public key and bind it to one or more principals. In the affected path, authorized_keys cert-authority entries with principals= were meant to restrict which certificate principals could authenticate. The bug came from using a list-matching helper for a comparison that should have been exact. Because match_list() splits on commas, a single principal string containing a comma could be treated as two values, which is an authorization error, not a cryptographic one.

Practical implication: Treat any identity field that feeds authorization as opaque unless the code explicitly proves list semantics are intended.

Why principals= behaved differently from AuthorizedPrincipalsFile

OpenSSH had two certificate trust patterns. One used TrustedUserCAKeys with AuthorizedPrincipalsFile, where principal comparison relied on strcmp() and therefore required an exact string match. The other used cert-authority entries directly inside authorized_keys with principals=, which took a different code path. The flaw only affected the second path, and that distinction matters because operators often assume equivalent outcomes from two different configuration models when the enforcement logic is not actually the same.

Practical implication: Review every certificate trust path separately, even when two configurations appear to implement the same policy outcome.

Why a CA-signed certificate could become root access

The exploit required a valid CA-signed certificate and a principal string that contained a comma, such as deploy,root. The vulnerable code first accepted the split fragment root against the allowed principals= value, then the later authority check skipped principal comparison because principals= was already present. That made the initial parsing mistake decisive. No memory corruption or pre-auth remote code execution was needed. The security boundary failed entirely at authorization time.

Practical implication: Prioritise exact-match validation and certificate issuance controls before assuming signature verification alone enforces least privilege.

Threat narrative

Attacker objective: Obtain privileged SSH access by turning a scoped certificate into authentication for a higher-privilege account.

1. Entry via a CA-signed SSH user certificate trusted through the vulnerable authorized_keys cert-authority path.
2. Escalation when match_list() split a single principal string containing a comma and matched a restricted account such as root.
3. Impact was an authenticated SSH session as the target account, including full host control when the target was root.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Exact-match identity checks are a governance control, not a coding detail. The OpenSSH flaw shows how a single parsing helper can collapse a policy boundary if the authorization code treats an identity string like a list. For NHI programmes, that means certificate principals, service-account names, and token subjects must be handled as opaque identifiers unless the policy explicitly allows tokenised values. The practitioner conclusion is simple: if the match rule is not exact, the least-privilege claim is not trustworthy.

SSH certificates do not remove risk, they move it into the CA and trust-path design. Organisations often adopt SSH certificates to reduce key sprawl and centralise lifecycle control, but that only shifts the security burden. The CA, issuance workflow, and server-side trust configuration become the real control surface. If any of those layers permit ambiguous identity encoding, the certificate model can still fail closed or open in surprising ways. The practitioner conclusion is to govern issuance and verification as one system.

Comma-splitting created an identity blast radius that exceeded the intended principal scope. The vulnerable code turned one principal into multiple authorization candidates, which is exactly the kind of scope drift NHI governance is supposed to prevent. This kind of identity blast radius is especially dangerous in environments that treat machine and service identities as lower-risk than human accounts. The practitioner conclusion is to audit every parser that touches identity fields.

Authorization bugs in NHI systems are often more dangerous than authentication bugs because they look correct until a specific string shape appears. That makes testing against punctuation, encoding, and boundary values essential for any workload or agent identity scheme. Security teams should assume that trust logic can fail even when signatures, certificates, and CA validation all succeed. The practitioner conclusion is to test the policy edge cases, not just the happy path.

From our research:

• 57% of organisations lack a complete inventory of their machine identities, according to The Critical Gaps in Machine Identity Management report.
• Certificate and workload identity programmes also suffer from manual control debt, with 61% relying on spreadsheets or manual tracking for machine identity management.
• For the broader control model behind this topic, see Ultimate Guide to NHIs , Key Challenges and Risks for visibility, sprawl, and over-privilege patterns.

What this signals

Identity blast radius is the right lens for this class of flaw. When a parser can widen a principal from one identity into another, the governance problem is no longer just certificate hygiene, it is containment of authorization scope across the full lifecycle. Teams should pair parsing review with The 52 NHI breaches Report to understand how small trust-path mistakes become large operational incidents.

With 57% of organisations lacking a complete inventory of their machine identities, teams cannot assume they know where certificate-based access is in use or which accounts depend on it. That makes exposure mapping a prerequisite to hardening, not a follow-on task. The next governance step is to tie certificate issuance, principal rules, and privileged account reviews into one inventory.

SSH certificate governance should now be reviewed alongside workload identity and agent identity controls, especially where privileged access is still anchored to static configuration files. Exact-match policy, delimiter restrictions, and issuance review belong in the same control plane as access reviews. For teams building that control plane, the OWASP NHI Top 10 is a useful reference point for identity handling failures and trust-boundary mistakes.

For practitioners

• Audit certificate trust paths Inventory every use of authorized_keys cert-authority and principals=, then compare it to the TrustedUserCAKeys and AuthorizedPrincipalsFile model. Do not assume two certificate configurations enforce the same matching logic.
• Reject ambiguous principal encoding Treat commas, spaces, and other delimiter characters as prohibited in certificate principals unless the entire signing and verification chain is explicitly designed for them. Enforce this at issuance time and at verification time.
• Move to exact-match authorization Where identity fields drive access decisions, require strcmp-style exact comparison or an equivalent proven primitive. Review any helper that was originally built for list negotiation before reusing it for authorization.
• Search for exposed CA trust lines Look for cert-authority entries paired with principals= in authorized_keys and confirm whether the allowed principals could be parsed differently than intended. Focus on hosts where certificate-based SSH access is used for privileged accounts.

Key takeaways

• A comma-handling bug in OpenSSH certificate matching turned a scoped principal into an authorization bypass.
• The impact is about governance failure, not cryptographic failure, because the vulnerable path changed how identity was compared.
• Teams using SSH certificates should verify exact-match enforcement, restrict ambiguous principal strings, and inventory every privileged trust path.

Key terms

• Certificate Principal: A certificate principal is the identity name a certificate is allowed to authenticate as. In SSH user certificates, it should function as an exact authorization label, not a list to be parsed. If the comparison logic can split the value, the principal boundary is weaker than it appears.
• Cert-Authority Trust Path: A cert-authority trust path is an SSH configuration pattern where a server trusts certificates signed by a specific CA instead of storing each user key directly. It centralises trust and lifecycle control, but it also makes CA policy, parsing, and verification logic part of the security boundary.
• Identity Blast Radius: Identity blast radius is the amount of access that can be unintentionally widened when a control misinterprets an identity or entitlement. In NHI systems, a small parsing or policy mistake can expand from one scoped credential to many accounts or workloads, including privileged ones.
• Exact-Match Authorization: Exact-match authorization requires the system to compare an identity value byte for byte, or with an equivalently strict rule, before granting access. It is the correct pattern when the field represents one identity, because list-style parsing can silently widen scope and break least privilege.

Deepen your knowledge

SSH certificate principal matching and NHI trust-path governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are reviewing privileged access built on certificate authorities, it is worth exploring.

This post draws on content published by Cyera: SplitSSHell - When a Comma Becomes Root. Read the original.