A 15-Year Gap in SSH Security - And What to Do About It

WHAT DID WE FIND?

Cyera Research discovered a critical flaw in OpenSSH - the software that secures remote access to virtually every Linux server in the world.A crafted SSH certificate can bypass principal restrictions and grant access as an unintended user, including root, on servers using the affected configuration. Exploitation requires a single SSH connection but depends on the CA issuing a certificate with attacker-influenced principal content. The flaw has been present for over 15 years and was fixed this week.

In plain terms: imagine a door that checks ID before letting someone in. This bug means that 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. OpenSSH was doing exactly this.
OpenSSH has two doors. Only one of them - the cert-authority path in authorized_keys - reads the comma this way. The other (TrustedUserCAKeys) does not.
‍

CVE AND TIMELINE

WHO IS AFFECTED?

Any organization whose Linux servers use SSH certificate authentication with a specific configuration - cert-authority entries in authorized_keys files. This configuration is common in:

• Bastion hosts and jump servers
• CI/CD pipelines (GitHub Actions, GitLab CI, Jenkins)
• Environments that adopted SSH certificates incrementally - adding them to existing authorized_keys files rather than migrating to a centralized configuration
• Organizations using HashiCorp Vault, Netflix BLESS, or custom SSH CA workflows

‍

If your team uses the alternative configuration - TrustedUserCAKeys in sshd_config - you are not affected.

‍

WHAT IS THE RISK?

An attacker who can obtain a certificate with a crafted principal name containing a comma - even through a low-privilege issuance path - can use this flaw to authenticate as root on servers using the affected configuration, if the CA does not reject comma-containing principals.

• Fleet-wide impact: one crafted certificate can be reused across servers trusting that CA through authorized_keys, where principals= values match a fragment of the crafted principal.
• Deterministic exploitation: once a crafted certificate is obtained, the attack is a single SSH connection - no exploit code, no timing, no brute force.
• Invisible in many logs: the server considers the authentication legitimate - no failure is logged
• Data exposure: root access to servers means access to databases, API tokens, cloud credentials, and secrets stored on those hosts

‍

WHAT SHOULD YOU DO?

HOW DOES CYERA HELP?

SSH certificate authentication is one of the primary pathways between identities and sensitive data. Cyera's platform maps exactly which data assets are reachable through SSH certificate paths - so you know your blast radius before an attacker does

• Identity and Access mapping: Cyera surfaces which sensitive data stores are accessible by SSH certificate-authenticated identities, including CI/CD and automated agents
• Blast radius visibility: when a vulnerability like CVE-2026-35414 is disclosed, Cyera shows you which data assets are at risk through affected SSH paths
• Detection query: Cyera customers can run the linked SSH identity exposure query to identify cert-authority access paths to sensitive data in their environment

‍

For the complete technical deep-dive - root cause analysis, source code walkthrough, exploitation steps, detection rules, and CVSS dispute - read the Cyera Research technical blog