CVE-2026-35414

What it actually does

OpenSSH versions before 10.3 contain an authorization bypass in certificate-based SSH authentication when authorized_keys uses the principals option together with a trusted Certificate Authority entry and comma characters are interpreted in uncommon ways. In affected configurations, the intended restriction that only specific certificate principals may authenticate can be mishandled, allowing an authenticated or certificate-holding attacker to be accepted as an account for which their SSH certificate should not have been valid. The impact is limited to confidentiality and integrity of accounts reachable through the misapplied authorization rule; it does not directly provide unauthenticated remote code execution or denial of service.

Why it matters to the business

Organizations using OpenSSH certificate authentication with authorized_keys principal restrictions may have weaker access controls than intended, potentially allowing users or automation identities to log in to systems they were not meant to access. Although current public exploitation likelihood is low, the product is widely deployed and SSH often protects administrative access, so affected bastion hosts, servers, and automation endpoints should be prioritized for upgrade or vendor backport validation.

How an attack unfolds

An attacker first needs a path into SSH certificate-based authentication, such as possession of a user certificate signed by a trusted SSH Certificate Authority or the ability to obtain one from an internal certificate issuance workflow. The target account must use an authorized_keys entry that trusts a CA key and applies the principals option to restrict which certificate principals may authenticate. By presenting a certificate and CA/principal data that interacts with comma parsing in the vulnerable code path, the attacker can cause OpenSSH to evaluate the allowed principals incorrectly. If the malformed or unexpected principal handling matches the vulnerable scenario, sshd accepts the certificate and creates a normal SSH login session for an account the attacker should not have been authorized to use. Post-authentication activity then depends on the privileges of that account, such as reading files, modifying application data, pivoting through SSH, or using sudo if separately permitted.

How to fix it

Upgrade OpenSSH to version 10.3 or later, or apply the security backport supplied by the operating system or appliance vendor. Because many distributions ship vendor-patched OpenSSH packages with older upstream version strings, verify the vendor advisory and package changelog rather than relying only on ssh -V output. As interim mitigation, review authorized_keys files and centralized key-management templates for certificate authority entries that combine cert-authority with principals= restrictions; remove unnecessary CA trust entries, simplify principal lists, and avoid comma-containing principal or CA-related values where possible. Restrict SSH certificate issuance workflows so users cannot self-select arbitrary principals, and enforce principal-to-account authorization in the CA issuance policy as an additional control. Where feasible, add compensating controls such as AllowUsers/AllowGroups, Match blocks, PAM/account restrictions, MFA, bastion-only access, and detailed SSH authentication logging.

How to confirm the fix worked

Confirm all exposed and internal SSH servers are running OpenSSH 10.3 or a vendor package that explicitly includes the fix for this issue. Inventory systems by querying package managers, configuration management, and sshd banners where appropriate. Inspect authorized_keys, AuthorizedKeysFile locations, and centralized SSH key-management outputs for entries containing both cert-authority and principals=. Validate that certificate authentication behaves as expected by attempting login with authorized test certificates whose principals should be denied and confirming sshd rejects them. Review sshd configuration for TrustedUserCAKeys, AuthorizedPrincipalsFile, AuthorizedPrincipalsCommand, and account-level authorization controls. After patching, restart or reload sshd according to vendor guidance and confirm new ssh sessions are handled by the updated daemon.

Typical attack path

1. Identify an SSH service running OpenSSH before 10.3 that permits SSH certificate authentication.
2. Determine or infer that the target account uses an authorized_keys CA trust entry with the principals option.
3. Obtain a valid SSH user certificate signed by a trusted CA through legitimate access, compromised issuance workflow, stolen credentials, or insider misuse.
4. Craft or request certificate principal/CA-related values that trigger the comma-handling edge case.
5. Attempt SSH authentication to the target account using the crafted certificate.
6. If accepted, use the resulting shell or forced command context with the target account’s permissions.
7. Expand access by harvesting local secrets, using allowed sudo rules, or pivoting to other systems if possible.

How to detect it

There is no single definitive network indicator for exploitation because successful abuse appears as an SSH certificate login rather than a crash or unique exploit payload. Focus on SSH authentication and authorization telemetry. Review auth logs such as /var/log/auth.log, /var/log/secure, journald sshd units, centralized SIEM SSH events, bastion logs, and privileged access management logs for certificate-based successful logins. Look for Accepted publickey events that reference certificate key types, certificate IDs, serial numbers, CA keys, or principals that do not align with the target Unix account or expected role. Correlate SSH CA issuance logs with login logs to identify certificates containing comma characters or unusual principal lists, certificates issued to one user but used to access another account, or certificate serials reused across unexpected hosts. Examine authorized_keys and managed key templates for cert-authority entries using principals=, especially principal lists containing commas or unusual quoting. After suspicious logins, review shell history, sudo logs, process accounting, file modification times, new SSH keys, new authorized_keys entries, outbound SSH connections, and access to secrets or deployment credentials. Threat activity has not been reported in CISA KEV and public exploit maturity is currently listed as none, so prioritize exposure validation and anomaly hunting over signature-only detection.

• cert-authority
• principals=
• /etc/ssh/sshd_config
• /etc/ssh/authorized_keys
• /etc/ssh/authorized_principals
• /var/log/auth.log
• /var/log/secure
• Accepted publickey for
• ssh-rsa-cert-v01@openssh.com
• rsa-sha2-256-cert-v01@openssh.com
• rsa-sha2-512-cert-v01@openssh.com
• ecdsa-sha2-nistp256-cert-v01@openssh.com
• ecdsa-sha2-nistp384-cert-v01@openssh.com
• ecdsa-sha2-nistp521-cert-v01@openssh.com
• ssh-ed25519-cert-v01@openssh.com
• ID
• serial
• CA

What your security team should do

• Prioritize patching internet-facing SSH servers, bastion hosts, privileged administration hosts, and automation servers that use OpenSSH certificate authentication.
• Inventory use of SSH certificates and identify authorized_keys entries containing both cert-authority and principals=.
• Upgrade to OpenSSH 10.3 or the relevant vendor-fixed package; document vendor backport status where upstream version output remains below 10.3.
• Audit SSH Certificate Authority issuance policies to ensure users cannot obtain principals outside their approved account or role mappings.
• Search authentication logs for successful certificate-based logins to sensitive accounts, especially where the certificate principal does not match the expected account or role.
• Temporarily remove or tighten affected CA trust/principal configurations where immediate patching is not possible.
• Increase logging for sshd authentication events and retain logs long enough to investigate historical misuse.
• Review privileged accounts for recent SSH logins followed by unusual sudo, file access, key creation, or lateral movement activity.