CVE-2026-35414, The OpenSSH Comma Bug That Can Break SSH Certificate Boundaries

CVE-2026-35414 is an OpenSSH certificate authentication flaw with a narrow trigger and a serious upside for attackers when that trigger exists. The issue affects OpenSSH before 10.3 and sits in the user certificate authentication path where a CA key is trusted through an authorized_keys cert-authority entry that also uses the principals="" option. The short version is simple: a comma inside a certificate principal can be interpreted as a list separator in the wrong place, and that can let a certificate intended for one identity match another identity, including a privileged account, under specific conditions. NVD describes the vulnerability as OpenSSH before 10.3 mishandling the authorized_keys principals option in uncommon scenarios involving a principals list and a Certificate Authority that makes certain use of comma characters. (NVD)

That wording is deliberately narrow, and it should be read carefully. This is not “every OpenSSH server below 10.3 gives remote root.” It is not an unauthenticated memory corruption bug. It is not a generic SSH password bypass. It is a boundary failure in a specific certificate trust model: user certificates, a CA trusted through authorized_keys, a principals= restriction, and a signing workflow that can issue a principal string containing a comma. OpenSSH’s own 10.3 release notes state that exploitation requires an authorized_keys principals="" option listing more than one principal and a CA that will issue a certificate encoding more than one of those principal names separated by a comma; the same note says the main TrustedUserCAKeys そして AuthorizedPrincipalsFile certificate authentication path is not affected. (OpenSSH)

The risk is still real. If the vulnerable trust path exists on a server and the certificate signing system lets a user obtain a certificate with a comma-containing principal such as deploy,root, a scoped identity can cross into an account it was never supposed to access. Cyera, whose researcher Vladimir Tokarev is credited in the OpenSSH release notes, named the issue SplitSSHell and described it as a principal-escalation vulnerability in OpenSSH certificate authentication. The firm’s write-up says the root cause was a call to match_list() where an exact string comparison should have been used. (Cyera)

The practical defender’s job is not to panic over every SSH banner. It is to answer four questions quickly and with evidence: Which hosts run an affected OpenSSH build or an unfixed downstream package? Which accounts trust user CAs through authorized_keys と cert-authority,principals=? Which certificate authorities or signing APIs can issue principal strings containing commas? Which of those paths can reach root, production deploy accounts, backup accounts, database jump accounts, or other privileged identities?

Quick facts for CVE-2026-35414

フィールド	Current understanding
CVE	CVE-2026-35414
Affected software	OpenSSH before 10.3, with downstream package status depending on vendor backports
Fixed upstream version	OpenSSH 10.3 and OpenSSH Portable 10.3p1, released on April 2, 2026 (OpenSSH)
Vulnerable area	OpenSSH user certificate authentication
Specific trust path	CA trusted through authorized_keys using cert-authority そして principals=""
Main unaffected path called out by OpenSSH	TrustedUserCAKeys と AuthorizedPrincipalsFile
Trigger class	Incorrect matching of certificate principals when a certificate principal contains a comma
Required attacker position	The attacker needs a valid certificate from a trusted CA or access to a signing workflow that can issue one
Typical high-impact outcome	Authentication as a different local account if principal restrictions are bypassed
Best fix	Upgrade to OpenSSH 10.3 or a vendor package that backports the relevant fix
Best exposure check	Combine version/package inventory with authorized_keys CA trust-path review and CA signing-policy review

NVD and MITRE currently present different CVSS interpretations. NVD lists CVSS v3.1 as 8.1 High with vector AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H, while the CNA entry from MITRE shows 4.2 Medium with AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N. NVD’s history also shows reanalysis on April 9 and April 10, 2026, moving the score upward from earlier vectors. (NVD) That score difference matters less than the asset context. On a workstation lab server with no SSH CA and no cert-authority entry, the practical risk may be zero. On a fleet that uses SSH certificates for production access and permits flexible principal requests through an internal signing service, the same bug can become an identity-boundary incident.

How OpenSSH certificates are supposed to work

OpenSSH certificates are not X.509 certificates. They are a simpler OpenSSH-specific mechanism that lets an administrator trust a CA key rather than copying every user public key to every server. The ssh-keygen manual says certificates contain a public key, identity information, zero or more principal names, and options signed by a CA key; user certificates authenticate users to servers, while host certificates authenticate server hosts to users. (OpenBSD Manual Pages)

For user authentication, principals are the names a certificate is allowed to represent. In the common case, they look like usernames or role-like identifiers. The ssh-keygen manual shows that when signing a certificate, -n specifies one or more principals, separated by commas, and gives ssh-keygen -s ca_key -I id -n user1,user2 user_key.pub as the example for a certificate with multiple principals. (OpenBSD Manual Pages)

That behavior is normal. A certificate can legitimately contain several principals. A deploy certificate might contain deploy, a user certificate might contain alice, and an operations certificate might contain prod-admin if the organization’s policy allows that. The security model depends on each component agreeing on the exact unit of identity. A principal entry should be treated as an atomic name after the certificate is parsed. The server may maintain a list of allowed names, but a single certificate principal should not be silently split into extra names during authorization.

OpenSSH supports more than one way to trust user certificates. The first and more centralized path is TrustedUserCAKeys.その sshd_config manual says TrustedUserCAKeys specifies a file containing public keys of CAs trusted to sign user certificates; if a presented certificate is signed by a listed CA, it may be used for authentication for any user listed in the certificate’s principals list. (OpenBSD Manual Pages) If AuthorizedPrincipalsFile または AuthorizedPrincipalsCommand is configured, OpenSSH can further restrict which certificate principals are accepted for the target user. The manual states that AuthorizedPrincipalsFile lists principal names accepted for certificate authentication when using CAs listed in TrustedUserCAKeys, and it explicitly notes that this file is not consulted for CAs trusted through ~/.ssh/authorized_keys, where the principals= key option offers a similar facility. (OpenBSD Manual Pages)

The second path is local and account-scoped: a user’s authorized_keys file can contain a CA public key marked with cert-authority.その エスエスディー manual says the cert-authority option specifies that the listed key is trusted to validate signed certificates for user authentication. On such a line, principals="principals" specifies allowed principals as a comma-separated list, and at least one name from that list must appear in the certificate’s list of principals for the certificate to be accepted. (OpenBSD Manual Pages)

CVE-2026-35414 lives in that second path. The dangerous shape looks conceptually like this:

cert-authority,principals="deploy,backup,root" ssh-ed25519 AAAA... user-ca

That line says the CA key is trusted for this local account, but only if the user certificate contains at least one allowed principal from the list. If the line is in /root/.ssh/authorized_keys, the stakes are obvious. If it is in a service account’s authorized_keys, the risk depends on what that account can do.

The exact configuration pattern that matters

A server is not exposed to this bug just because SSH is open on port 22. A vulnerable version is necessary but not sufficient. The meaningful exposure requires the following chain:

Condition	なぜそれが重要なのか	How to check
OpenSSH is older than 10.3 or the vendor package lacks the backport	The vulnerable matching logic existed before the upstream fix	Check package changelog and vendor advisory, not only the banner
User certificate authentication is in use	The bug is in certificate principal matching, not password auth	Look for SSH CA keys and certificate login workflows
A CA is trusted through authorized_keys	OpenSSH says this condition applies to user-trusted CA keys in authorized_keys	Search account authorized_keys files for cert-authority
The same line uses principals=""	The vulnerable decision is about matching that key option against certificate principals	Search for cert-authority.*principals=
The allowed principals list contains multiple names	OpenSSH’s release notes call out a principals="" option that lists more than one principal	Inspect the quoted value
The signing workflow can issue comma-containing principal strings	The attack depends on a principal that can be interpreted differently by the vulnerable matcher	Review CA API validation, not only host config
The target account is valuable	A bypass into root, deploy, backup, or CI accounts is materially different from a low-privilege test account	Prioritize privileged accounts and production hosts

A common false positive is a host that uses TrustedUserCAKeys そして AuthorizedPrincipalsFile, with no cert-authority,principals= entries in user authorized_keys files. OpenSSH specifically says the main certificate authentication path using TrustedUserCAKeys そして AuthorizedPrincipalsFile is not affected by this condition. (OpenSSH) That does not make the host immune to every SSH certificate misconfiguration. It means CVE-2026-35414’s comma-splitting bug is not in that path.

Another false positive is a host whose OpenSSH banner reports a version below 10.3, but the distribution has backported the patch. Linux distributions often keep an older upstream version string while applying security patches. Ubuntu, for example, lists fixed openssh packages for Ubuntu 26.04, 25.10, 24.04 LTS, and 22.04 LTS, even though several fixed package versions still carry upstream OpenSSH version numbers below 10.3. (Ubuntu) Debian similarly lists fixed package versions for bullseye, bookworm, trixie, forky, and sid in its tracker. (Debian Security Tracker)

That is why serious triage should not stop at ssh -V or a scanner plugin. Version discovery is step one. Configuration and CA policy review are steps two and three.

The root cause, a list matcher used where exact matching was required

The bug is easy to understand once the two lists are separated mentally.

The server-side principals="" option is a list. It is allowed to contain commas because administrators need a compact way to say “this CA is accepted only for these names.” For example:

principals="deploy,backup,release"

A certificate’s principal set is also a collection. But each principal inside that collection should be treated as a complete string after the certificate is decoded. If a certificate contains one principal string named deploy,root, that is not the same as two principals named deploy そして ルート.

The vulnerable logic blurred that line. Cyera’s analysis says OpenSSH 5.6 through 10.2p1 used match_list() での authorized_keys cert-authority,principals= path. That helper performs list-style matching, so a certificate principal containing a comma could be split and compared as if it were multiple names. The fixed model is to split only the server-controlled principals= list, then compare each allowed entry with each full certificate principal using exact string comparison. (Cyera)

A simplified, safe representation of the bug looks like this:

Vulnerable idea:

for each certificate_principal:
    if list_match(certificate_principal, allowed_principals_list):
        accept

Problem:

certificate_principal = "deploy,root"
allowed_principals_list = "root,backup"

If the matching helper treats commas inside certificate_principal as separators,
"root" may be considered a match even though the certificate did not contain
a principal exactly equal to "root".

Correct idea:

for each allowed_name in split(allowed_principals_list, ","):
    for each certificate_principal in certificate_principals:
        if allowed_name == certificate_principal:
            accept

The important phrase is “exactly equal.” Authentication authorization should not let identity strings change meaning because they passed through a helper that was originally designed for comma-separated negotiation lists.

OpenSSH’s release notes describe the issue as an incorrect algorithm used when matching an authorized_keys principals="" option against certificate principals. The release notes also state that the vulnerable condition involves a principal name in the certificate containing a comma character. (OpenSSH) The upstream fix changed the matching shape in auth2-pubkeyfile.c: it splits the configured principal list and compares entries with certificate principals using strcmp(), rather than calling match_list() on a certificate principal. The relevant GitHub commit diff shows match_list() removed from match_principals_option() and replaced by strsep() over the configured list plus strcmp() against cert->principals[i]. (ギットハブ)

That is the whole class of failure in one sentence: a parser treated identity data like a list expression.

Why the impact can be high even with narrow preconditions

The narrowness of CVE-2026-35414 does not make it harmless. It makes it uneven.

If an environment does not use OpenSSH user certificates, this CVE is unlikely to matter directly. If it uses certificates only through TrustedUserCAKeys そして AuthorizedPrincipalsFile, the specific vulnerable path called out by OpenSSH is not the main concern. If it uses authorized_keys CA trust lines without principals=, the comma-matching bug is not the limiting control because there is no local principal list being matched in that key option.

But in environments that do use cert-authority,principals= lines, the impact depends on account value and CA governance. Cyera’s write-up states that successful exploitation on an affected host grants an SSH session as the target account and that root as the target account means full control of the host. (Cyera) SecurityWeek’s coverage of Cyera’s findings similarly reported that a certificate principal containing a comma can lead to OpenSSH access-control bypass and authentication as root on a vulnerable server, provided the attacker has a valid certificate from a trusted CA. (セキュリティ・ウィーク)

The requirement for a valid CA-signed certificate is a major constraint. It means a random internet scanner cannot usually exploit the bug from nothing. But it also points to the real-world danger: many certificate systems are built to automate access. If a CI job, access portal, internal developer tool, or just-in-time SSH workflow lets users request principal strings without strict server-side validation, then the attacker’s hard part becomes a workflow abuse problem rather than a cryptography problem.

The highest-risk environments tend to share some traits:

Environment trait	Why it raises risk
SSH certificates are used for production server access	A CA-signed certificate is already a normal access artifact
Users can request principals through an API or self-service portal	Principal validation becomes part of the attack surface
Service accounts or root have authorized_keys CA trust entries	A principal bypass can land in a high-privilege account
authorized_keys is managed by automation across fleets	The same vulnerable trust pattern may be replicated widely
Principal strings are treated as free-form values	Commas, empty strings, wildcard-like values, and control characters may pass through
CA signing logs are weak or not reviewed	Abuse may look like normal certificate issuance
SSH logs are treated as the primary detection layer	Successful bypass may appear as a successful certificate login, not a failure

The low-risk environments are different. A small server with normal public keys in authorized_keys, no user certificates, and no CA signing system is not the interesting target for this CVE. A fleet that uses SSH certificates but centralizes trust through TrustedUserCAKeys and validates principals through AuthorizedPrincipalsFile is also in a different category for this specific flaw.

Why scanners may disagree

You should expect scanner output to be noisy for CVE-2026-35414.

Some scanners will flag every OpenSSH version below 10.3. That is useful for initial discovery, but it overstates exposure when a distribution has backported the patch or when the vulnerable certificate trust path is absent. Other tools may miss the issue if they parse OpenSSH CPEs incorrectly, cannot authenticate to inspect authorized_keys, or do not understand downstream package fix states. A Greenbone community discussion around this CVE shows exactly this kind of operational problem: CPE formatting for OpenSSH patch versions can affect detection behavior. (Greenbone Community Forum)

Nessus plugin descriptions for Linux and Unix hosts also note a package-based limitation: they rely on the package as reported by the vendor. (Tenable®) That is not a criticism of scanners. It is a reminder that this vulnerability is not purely banner-visible. It is a combination of software version, vendor patching, local account files, SSH daemon configuration, and external CA signing rules.

A good scanner result for this CVE should be treated as a lead, not a verdict. The next move is a configuration audit.

Safe exposure audit for Linux and Unix hosts

The following checks are intended for systems you own or are authorized to assess. They do not attempt authentication bypass, do not generate malicious certificates, and do not test login as another user. They gather the evidence defenders need to decide whether the vulnerable pattern exists.

Start with package and binary version inventory:

# OpenSSH client version, often available everywhere
ssh -V 2>&1 || true

# OpenSSH server version, available on many modern builds
/usr/sbin/sshd -V 2>&1 || sshd -V 2>&1 || true

# Debian and Ubuntu package view
dpkg -l | awk '/openssh-server|openssh-client/ {print $2, $3}'

# RHEL, CentOS, Fedora, Amazon Linux, Oracle Linux
rpm -qa | grep -E '^openssh(-server|-clients)?' | sort

# Alpine
apk info -v | grep '^openssh' || true

# macOS with Homebrew, if applicable
brew list --versions openssh 2>/dev/null || true

Then ask エスエスディー where it expects authorized keys. The default is usually .ssh/authorized_keys .ssh/authorized_keys2, but real fleets often override it:

sudo /usr/sbin/sshd -T 2>/dev/null | grep -i '^authorizedkeysfile'

Search for the vulnerable trust pattern. This is exposure mapping, not exploit detection:

sudo grep -RInE 'cert-authority.*principals=' \
  /root/.ssh \
  /home/*/.ssh \
  /etc/ssh \
  2>/dev/null

もし AuthorizedKeysFile points somewhere else, include that path. Some organizations store keys in /etc/ssh/authorized_keys/%u, a managed directory, or a generated file. A more complete search can combine effective config and common paths:

#!/usr/bin/env bash
set -euo pipefail

echo "[*] OpenSSH version candidates"
(ssh -V 2>&1 || true)
(/usr/sbin/sshd -V 2>&1 || sshd -V 2>&1 || true)

echo
echo "[*] Effective AuthorizedKeysFile setting"
auth_files="$(sudo /usr/sbin/sshd -T 2>/dev/null | awk 'tolower($1)=="authorizedkeysfile" {$1=""; sub(/^ /,""); print}')"
echo "${auth_files:-unknown}"

echo
echo "[*] Package versions"
if command -v dpkg >/dev/null 2>&1; then
  dpkg -l | awk '/openssh-server|openssh-client/ {print $2, $3}'
fi
if command -v rpm >/dev/null 2>&1; then
  rpm -qa | grep -E '^openssh(-server|-clients)?' | sort || true
fi
if command -v apk >/dev/null 2>&1; then
  apk info -v | grep '^openssh' || true
fi

echo
echo "[*] Searching common authorized_keys locations for cert-authority with principals"
sudo grep -RInE 'cert-authority.*principals=' \
  /root/.ssh \
  /home/*/.ssh \
  /etc/ssh \
  /var/lib \
  2>/dev/null || true

echo
echo "[*] Searching for any cert-authority trust lines"
sudo grep -RInE '(^|,)cert-authority(,|[[:space:]])' \
  /root/.ssh \
  /home/*/.ssh \
  /etc/ssh \
  /var/lib \
  2>/dev/null || true

echo
echo "[*] Review any findings manually."
echo "    A risky line usually combines cert-authority and principals=\"name1,name2\"."
echo "    Confirm whether the package includes the OpenSSH 10.3 fix or a vendor backport."
echo "    Confirm whether the CA signing workflow rejects comma-containing principal strings."

For each hit, record the account, path, CA key fingerprint, principals value, and whether the account is privileged. You can fingerprint a CA key from an authorized_keys line after extracting the key material into a temporary file:

ssh-keygen -l -f extracted_ca_key.pub

For certificate samples gathered from your own environment, inspect principals with:

ssh-keygen -L -f user_key-cert.pub

The question is not whether ssh-keygen -n user1,user2 can create multiple principals; that is normal documented behavior. The question is whether your CA service can create a certificate containing one principal string that includes a literal comma, and whether a vulnerable server path then treats that embedded comma as authorization syntax.

How to audit the CA signing workflow

CVE-2026-35414 is partly a server bug and partly a signing-governance test. The vulnerable server logic is fixed by OpenSSH 10.3 or downstream patches, but a sloppy CA signing workflow is still a security smell. A good SSH CA service should treat principal issuance as a privileged policy decision.

At minimum, review these controls:

CA control	Secure expectation	Failure mode
Principal allowlist	The server maps requester identity to allowed principals	User can request arbitrary principal names
Character validation	Reject commas, control characters, empty strings, newlines, and shell metacharacters unless a documented standard requires them	A single string can change meaning downstream
Server-side enforcement	The backend enforces policy even if the client tampers with the request	UI restrictions can be bypassed by direct API calls
Short TTL	Certificates expire quickly, especially for production access	A mistaken or abused cert remains useful for too long
Key ID and serial logging	Every certificate has traceable key ID, serial, requester, and approved principals	Incident response cannot reconstruct access
Revocation	KRL or equivalent revocation process exists and is tested	Bad certs cannot be invalidated quickly
High-privilege approvals	Root and production service principals require stronger approval	Self-service becomes privilege escalation
Negative tests	CI tests verify dangerous principal strings are rejected	Input validation quietly regresses

A defensive principal validator can be intentionally boring. This example is not an OpenSSH parser and does not replace vendor patches. It shows the kind of server-side gate a CA API should enforce before signing:

import re

SAFE_PRINCIPAL = re.compile(r"^[a-zA-Z0-9._@:+-]{1,128}$")

def validate_principals(requested, allowed_for_requester):
    """
    Validate requested SSH certificate principals before signing.
    requested: list[str] from the API request after JSON parsing
    allowed_for_requester: set[str] computed server-side from identity policy
    """
    if not requested:
        raise ValueError("at least one principal is required")

    approved = []
    for principal in requested:
        if not isinstance(principal, str):
            raise ValueError("principal must be a string")

        if "," in principal:
            raise ValueError("comma is not allowed inside a principal")

        if principal.strip() != principal:
            raise ValueError("principal must not contain surrounding whitespace")

        if not SAFE_PRINCIPAL.fullmatch(principal):
            raise ValueError(f"unsafe principal syntax: {principal!r}")

        if principal not in allowed_for_requester:
            raise PermissionError(f"principal not allowed for requester: {principal!r}")

        approved.append(principal)

    return approved

A stricter environment may reject more characters. That is fine. Principal names are identity boundary material, not comments. They should be easy to compare, easy to log, and hard to reinterpret.

What to patch first

Patch management should start with the highest-value identity paths, not with the longest list of IPs.

First, prioritize hosts where root or privileged service accounts contain authorized_keys CA trust lines. A bypass into a low-privilege user is bad. A bypass into root, deployment automation, database backup, production break-glass, or a bastion account is a different incident class.

Second, prioritize hosts where the signing CA is self-service or API-driven. If certificate issuance requires a human administrator who only signs known safe principal names manually, exploitation is harder. If a portal accepts requested principals from developers, CI jobs, or workload identities, validation becomes critical.

Third, prioritize internet-exposed or broadly reachable SSH endpoints. The attacker still needs a valid cert, but reachability matters when internal credentials or signing access are compromised.

Fourth, prioritize environments with weak CA logs. If you cannot answer who requested a certificate, which principals were signed, which serial was issued, when it expired, and which system approved it, you have both prevention and response gaps.

The fix path should be straightforward:

1. Install OpenSSH 10.3 or a vendor package that backports the relevant fix.
2. Restart or reload エスエスディー according to the platform’s package guidance.
3. Verify package status through the vendor advisory, not only the upstream version string.
4. Remove or migrate risky authorized_keys CA trust patterns where possible.
5. Enforce CA-side validation that rejects comma-containing principals.
6. Review high-privilege account access and certificate logs for historical abuse.

Ubuntu’s CVE page lists fixed packages for several supported releases, including 26.04 LTS, 25.10, 24.04 LTS, and 22.04 LTS. (Ubuntu) Debian’s tracker lists fixed versions across multiple releases and unstable branches. (Debian Security Tracker) Amazon Linux also lists fixed status for Amazon Linux 2 and Amazon Linux 2023 advisories. (Amazon Web Services Explorer) The right answer for a production fleet is to follow the distribution’s security update channel unless you intentionally build OpenSSH from upstream source.

Why migrating to TrustedUserCAKeys can reduce this specific risk

OpenSSH’s release notes draw a clear line: CVE-2026-35414 applies to user-trusted CA keys in authorized_keys; the main certificate authentication path using TrustedUserCAKeys そして AuthorizedPrincipalsFile is not affected. (OpenSSH) That makes migration worth considering if an environment has scattered cert-authority,principals= lines across user homes.

A centralized model can look like this:

/etc/ssh/sshd_config

TrustedUserCAKeys /etc/ssh/user_ca_keys.pem
AuthorizedPrincipalsFile /etc/ssh/auth_principals/%u

Then each target user gets an explicit principals file:

/etc/ssh/auth_principals/deploy

deploy
release-bot

/etc/ssh/auth_principals/root

breakglass-root

This is not automatically secure. A global principals file reused for every account can create its own authorization mistakes. The sshd_config manual says AuthorizedPrincipalsFile accepts tokens and that after expansion the file is absolute or relative to the user’s home directory; if no file is used, the username must appear in the certificate’s principals list. (OpenBSD Manual Pages) The safer pattern is account-specific principal mapping, root-owned files, clear review, and a CA policy that refuses unsafe names.

The benefit is operational clarity. CA trust is visible in sshd_config, allowed principals are separated from raw public key lines, and administrators can review principal mappings without parsing every user’s authorized_keys.

Detection after the fact is hard

The most uncomfortable part of CVE-2026-35414 is that a successful bypass can look like a successful certificate login. The server has not crashed. The attacker has not failed authentication repeatedly. The certificate is signed by a trusted CA. The session is established through a legitimate protocol path.

Cyera stated that the server considers the authentication legitimate and that log-based detection is unreliable. (セキュリティ・ウィーク) That does not mean logs are useless. It means logs should be used to hunt for suspicious certificate issuance and unusual account use, not as the only control.

Useful signals include:

信号	What to look for
CA signing logs	Principal strings containing commas, empty principals, unexpected root or service principals
SSH authentication logs	Certificate key IDs used against accounts they do not normally access
Serial numbers	Certificates issued outside normal approval flow or used after emergency revocation
Source systems	Certificate requests from CI jobs, developer laptops, or service accounts outside expected paths
Target account	Login to root or production service accounts using a certificate not normally associated with those users
タイム・ウィンドウ	Activity after certificate issuance and before patch deployment
File changes	Changes to authorized_keys, CA trust lines, or principal lists around the disclosure window

The most valuable log is often not on the SSH server. It is in the CA or access broker that signed the certificate. A server log may say “accepted publickey” with certificate details, but the CA log can tell you who requested the principal and whether the request should have been impossible.

A practical investigation query, adjusted for your log system, looks like this:

principal contains ","
OR principals contains ","
OR requested_principal contains ","
OR approved_principal in ["root", "deploy", "backup", "breakglass-root"]
OR ssh_certificate_key_id used_with_unusual_target_account

If your CA logs do not store principals as structured fields, improve that before the next certificate incident. Identity data in plain text logs is better than nothing, but structured logs make abuse review much faster.

Safe validation without turning the check into an exploit

Security teams often ask whether they should reproduce the bypass. In a controlled lab that you own, a minimal reproduction can confirm understanding. In production, attempting to authenticate as another account is usually unnecessary and may create legal, operational, and audit problems.

For production, prefer evidence-based validation:

1. Confirm the OpenSSH package is affected or fixed.
2. Confirm the vulnerable trust path exists or does not exist.
3. Confirm the CA signing workflow rejects comma-containing principal strings.
4. Confirm high-privilege accounts do not trust CAs through vulnerable authorized_keys lines.
5. Confirm logs can reconstruct certificate issuance and use.
6. Patch and re-run the configuration audit.

A safe validation record might look like this:

asset: prod-bastion-03
openssh_package: openssh-server-9.6p1-3ubuntu13.16
vendor_status: fixed
authorized_keys_ca_principals_lines:
  - account: root
    present: false
  - account: deploy
    present: true
    path: /home/deploy/.ssh/authorized_keys
    principals: "deploy,release-bot"
ca_policy:
  comma_in_principal: rejected
  empty_principal: rejected
  high_privilege_principal_approval: required
risk_result: fixed_package_with_legacy_ca_pattern_remaining
next_action: migrate deploy account to TrustedUserCAKeys plus account-specific AuthorizedPrincipalsFile

That kind of evidence is usually more useful than a dramatic proof-of-concept. It tells the infrastructure team what exists, what is fixed, what remains risky, and what must change.

For teams that run authorized validation programs across many assets, the hard part is preserving this evidence chain. A single version scan is not enough for CVE-2026-35414 because the true answer depends on package state, local files, SSH configuration, and CA policy. In that kind of workflow, tools such as Penligent can help organize authorized testing steps, collect command output, keep human approval around sensitive checks, and turn validation artifacts into reproducible reports rather than one-off terminal notes. Penligent describes evidence-first results and guided attack-chain workflows for authorized security testing, which is the right operational framing for configuration-dependent vulnerabilities like this one. (寡黙)

Common mistakes during triage

The first mistake is treating every OpenSSH version below 10.3 as equally exploitable. That ignores backports and configuration. A downstream package may be fixed while the upstream banner still looks old. Conversely, a system may look obscure but remain exposed because a local authorized_keys trust pattern was never audited.

The second mistake is assuming that TrustedUserCAKeys exposure equals CVE-2026-35414 exposure. OpenSSH explicitly separates the affected authorized_keys trust path from the main TrustedUserCAKeys そして AuthorizedPrincipalsFile path. (OpenSSH) That distinction matters because many enterprise SSH certificate deployments use the centralized path.

The third mistake is checking only /home/*/.ssh/authorized_keys. Root matters. Service accounts matter. Custom AuthorizedKeysFile paths matter. Configuration management systems may place keys under /etc/ssh, /var/lib, or application-specific directories. Start with sshd -T, then search the actual paths.

The fourth mistake is ignoring the CA. A host-side patch fixes this OpenSSH bug, but a CA that accepts arbitrary principal strings remains an identity-boundary hazard. Commas are the headline for CVE-2026-35414, but empty strings, wildcards, newlines, and shell metacharacters are also worth rejecting unless there is a specific, documented reason to allow them.

The fifth mistake is relying on authentication failures. This is a successful-authentication problem under the vulnerable conditions. You may not see a neat sequence of failures. You need issuance logs, certificate serials, key IDs, account mapping, and unusual target-account analysis.

Related OpenSSH 10.3 vulnerabilities worth patching in the same window

CVE-2026-35414 was not the only security issue fixed around OpenSSH 10.3. Treating it as part of a broader OpenSSH update cycle is usually more efficient than creating a one-off exception.

CVE	Issue	Why it is related	Practical remediation
CVE-2026-35385	scp legacy mode could install downloaded files with setuid or setgid bits when run as root without preserving modes	It is another OpenSSH 10.3-era security fix where surprising legacy behavior can create privilege risk	Update OpenSSH, avoid legacy scp -O workflows as root, and prefer safer transfer patterns
CVE-2026-35386	Shell metacharacters in a username could lead to command execution in specific non-default client configuration paths involving % expansion	It shows the same broad class of “identity string becomes command/config syntax” risk	Update OpenSSH and avoid passing untrusted usernames into SSH command-line or Match exec flows
CVE-2026-35387	Listing one ECDSA algorithm in algorithm allowlists could unintentionally allow other ECDSA algorithms	It is another control-boundary mismatch, this time in algorithm policy enforcement	Update OpenSSH and review cryptographic allowlists
CVE-2026-35388	Proxy-mode multiplexing sessions could omit confirmation when ControlMaster ask/autoask is used	It affects SSH client session-control expectations rather than server certificate principal matching	Update OpenSSH and review multiplexing assumptions

OpenSSH’s 10.3 release notes list the shell metacharacter issue, the authorized_keys principals issue, the legacy scp setuid/setgid behavior, the ECDSA algorithm allowlist issue, and the proxy-mode multiplexing confirmation issue in the same security section. (OpenSSH) NVD separately describes CVE-2026-35385 as an scp legacy-mode setuid/setgid issue, CVE-2026-35386 as command execution via shell metacharacters in a username under specific non-default configuration conditions, and CVE-2026-35387 as unintended ECDSA algorithm use when algorithm lists contain an ECDSA entry. (NVD)

The connective tissue is not that all of these bugs are equally exploitable. They are not. The common lesson is that SSH is a dense trust boundary where usernames, principals, algorithms, command templates, certificate metadata, legacy transfer behavior, and local configuration all have security meaning. When those values are parsed with the wrong assumptions, policy can drift away from administrator intent.

Hardening SSH certificate programs after CVE-2026-35414

The long-term fix is not just “install OpenSSH 10.3.” That is the urgent fix. The durable fix is to make SSH certificate governance boring, explicit, and testable.

Use centralized trust where possible. TrustedUserCAKeys with account-specific AuthorizedPrincipalsFile is easier to review than scattered user-owned authorized_keys CA trust lines. If you must use cert-authority entries in authorized_keys, keep them under configuration management, restrict file ownership, review high-privilege accounts, and avoid broad principal lists.

Keep principal naming simple. Use names that survive parsing, logging, dashboards, and code review without ambiguity. A principal like deploy-prod is easier to reason about than a free-form string. Reject delimiters that your ecosystem uses for lists. Commas are now the obvious example, but the deeper rule is to avoid letting identity fields double as syntax.

Make the CA the policy enforcement point. The signing service should compute allowed principals from the requester’s identity, group membership, device posture, ticket approval, or workload identity. It should not blindly sign principals supplied by the requester. UI restrictions are not enough; the API backend must enforce the policy.

Use short-lived certificates. Short TTLs reduce blast radius when a signing mistake happens. They do not fix authorization bugs, but they narrow the incident window.

Log certificate issuance and use as one story. The CA should log requester, approved principals, key ID, serial, public key fingerprint, TTL, source system, approval path, and reason. SSH servers should log certificate key IDs and target accounts where possible. Your SIEM should be able to join those fields.

Test negative cases. Security regression tests should verify that unsafe principal values are rejected before signing. Examples include:

deploy,root
root,
,root
"root"
root\nbackup
*
?
../../root
$(id)
`whoami`

Not every string above maps directly to CVE-2026-35414. That is the point. A mature identity system should reject values that can become syntax in common downstream contexts.

Review root access separately. Root certificate login is convenient and dangerous. Many organizations should require operators to log in as named users and escalate through audited mechanisms rather than issue user certificates that directly target root. If direct root access exists, keep the principal name unique, approval-gated, short-lived, and heavily logged.

A practical remediation plan

A focused remediation plan can be completed in phases.

Phase one is inventory. Collect OpenSSH package versions, vendor fix status, sshd -T output, and cert-authority,principals= occurrences. Do not stop at network banners. Include root, service accounts, and custom authorized-key paths.

Phase two is emergency reduction. Patch exposed systems. Remove unnecessary cert-authority lines from high-privilege accounts. If a line must remain temporarily, reduce the allowed principals list, confirm CA validation rejects commas, and tighten account access.

Phase three is CA policy correction. Reject comma-containing principal strings and other unsafe values. Require server-side allowlists. Add tests. Add structured logging. Add high-privilege approvals.

Phase four is architecture cleanup. Move from scattered authorized_keys CA trust to centralized TrustedUserCAKeys and account-specific principal files where it fits the environment. Keep exceptions documented.

Phase five is incident review. Search CA logs for historical comma-containing principals and suspicious root or service-account certificate issuance. Review SSH logs for certificate key IDs used against unusual target accounts. Revoke questionable certificates with KRLs or your CA’s revocation mechanism.

Phase six is proof. Re-run the audit, preserve evidence, and update vulnerability records with package versions, config findings, CA validation status, and residual exceptions.

A remediation record for a fleet should contain more than “patched.” It should include enough detail for a future reviewer to understand why the exposure is gone:

CVE: CVE-2026-35414
Fleet: production Linux bastions
Patch status: all hosts on vendor-fixed openssh packages
Affected trust path found: 3 cert-authority,principals lines in deploy accounts
High-privilege exposure: no root cert-authority,principals lines found
CA validation: comma, empty principal, wildcard-only principal rejected server-side
Logs reviewed: no comma-containing principal issuance in prior 180 days
Residual risk: two legacy hosts use authorized_keys CA trust pending migration
Owner: infrastructure security
Next review: after migration to TrustedUserCAKeys

That is the level of evidence this CVE deserves.

よくあるご質問

Does CVE-2026-35414 affect every OpenSSH server before 10.3?

• No. A vulnerable or unpatched OpenSSH build is only one condition.
• The specific issue requires OpenSSH user certificate authentication with a CA trusted through an authorized_keys cert-authority line that also uses principals="".
• OpenSSH’s release notes state that the main TrustedUserCAKeys そして AuthorizedPrincipalsFile certificate authentication path is not affected by this bug.
• Servers that use only password authentication or ordinary public keys are not exposed to this specific certificate principal matching flaw.
• Distribution backports matter, so check vendor package status rather than relying only on the upstream version string.

Why does a comma matter in CVE-2026-35414?

• The server-side principals="" option is a comma-separated allowlist.
• A certificate principal should be treated as a complete identity string after parsing.
• The vulnerable path used list-style matching in a context where exact string matching was required.
• If a certificate contained one principal string with a comma, vulnerable matching could treat part of that string as a separate allowed name.
• The OpenSSH fix changes the logic so configured allowed names are compared against full certificate principals.

How can I check whether my servers use the affected trust path?

• Check OpenSSH package status through your vendor’s advisory or package changelog.
• 走る sshd -T to identify effective AuthorizedKeysFile locations.
• Search root, service account, user, and custom authorized-key paths for lines containing both cert-authority そして principals=.
• Review whether those lines contain multiple allowed principals.
• Confirm whether the signing CA can issue principal strings containing commas.
• Treat banner-only scanner results as leads, not proof of exploitability.

Is upgrading to a vendor backport enough?

• Usually yes, if the vendor has backported the relevant OpenSSH fix into the package you run.
• Do not require the displayed upstream version to be exactly 10.3 if your distribution security tracker says the package is fixed.
• After patching, still audit authorized_keys CA trust lines because scattered high-privilege CA trust is risky even beyond this CVE.
• Also fix the CA signing workflow so unsafe principal strings cannot be issued.
• Keep evidence of package version, advisory status, and configuration review for audit purposes.

Can logs reliably detect exploitation of CVE-2026-35414?

• Not by themselves.
• A successful bypass can appear as successful certificate authentication because the certificate is signed by a trusted CA.
• SSH server logs are useful when joined with CA issuance logs, certificate key IDs, serial numbers, target accounts, and source systems.
• Search CA logs for comma-containing principals and unexpected high-privilege principal issuance.
• Patch and CA-side validation are stronger controls than hoping for a distinctive failure pattern.

Should organizations stop using OpenSSH certificates?

• No. OpenSSH certificates remain a useful way to manage SSH access at scale.
• The lesson is to design the certificate trust path and CA policy carefully.
• Prefer centralized trust with account-specific principal mapping where possible.
• Reject ambiguous principal strings at the CA layer.
• Use short TTLs, structured logs, serial numbers, key IDs, revocation, and high-privilege approvals.
• Review certificate access as identity infrastructure, not just SSH configuration.

Which assets should be fixed first?

• Start with internet-reachable SSH servers that use certificate authentication.
• Prioritize root, deploy, backup, CI/CD, bastion, and production service accounts.
• Prioritize hosts with cert-authority,principals= lines in authorized_keys.
• Prioritize environments where users or workloads can request certificates through an API.
• Prioritize systems where CA logs are incomplete, because incident review will be harder.

Closing judgment

CVE-2026-35414 is a sharp reminder that access-control bugs often hide in parsing assumptions, not in cryptography. The CA signature can be valid. The SSH protocol can work as designed. The server can log a successful authentication. The failure is that an identity string passed through code that treated a comma as syntax when it should have treated the principal as data.

The right response is precise. Patch OpenSSH through upstream 10.3 or vendor backports. Find authorized_keys CA trust lines that use principals="". Review high-privilege accounts first. Make the CA reject comma-containing principals and other ambiguous identity values. Migrate scattered trust patterns where possible. Preserve evidence for the systems that matter.

This is not a reason to abandon SSH certificates. It is a reason to treat certificate principal handling as a production identity boundary.