Notifications
Clear all
Topic starter
02/06/2026 7:00 pm
TL;DR: A principal-escalation flaw in OpenSSH certificate authentication let a comma inside one certificate principal be treated as a separator, so a CA-signed identity such as deploy,root could satisfy a principals="root" restriction, according to Cyera Research. The issue shows how trust-path details, not cryptography, can decide whether SSH certificates preserve least privilege.
NHIMG editorial — based on content published by Cyera: SplitSSHell - When a Comma Becomes Root
By the numbers:
- OpenSSH 5.6 through 10.2p1 were affected in the vulnerable principals= path.
- The issue was patched in OpenSSH 10.3/10.3p1.
- CVE-2026-35414 was later updated to 8.1 High.
Questions worth separating out
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.
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.
Q: What breaks when principal restrictions are parsed like lists?
A: Principal restrictions stop behaving like identity controls and start behaving like token matching.
Practitioner guidance
- Audit certificate trust paths Inventory every use of authorized_keys cert-authority and principals=, then compare it to the TrustedUserCAKeys and AuthorizedPrincipalsFile model.
- 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.
- Move to exact-match authorization Where identity fields drive access decisions, require strcmp-style exact comparison or an equivalent proven primitive.
Teams should pair parsing review with The 52 NHI breaches Report to understand how small trust-path mistakes become large operational incidents?
👉 Read Cyera's analysis of the OpenSSH certificate principal bypass →
Explore further
02/06/2026 7:16 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: OpenSSH certificate principal confusion turns commas into root access
