cve-2026-35414 break down

[Daniel_Kavan]

sk65269 - Check Point response to OpenSSH CVEs

RE: CVE-2026-35414

Can anyone add where and how or steps to check to this description?  I'm trying to confirm customer that has certificate authentication thru check point management ICA for VPN users if they aren't vulnerable.

Vulnerable, Conditional. This is a combination of a very rare setup: certificate authentication configured (not regular public key auth) + the CA key must be trusted via the cert-authority option (not via TrustedUserCAKeys) + the principals = option must list more than one principal + the attacker must either control or compromise the CA.

[Bob_Zimmerman · Accepted solution]

I've worked with OpenSSH for decades, including hanging out on the development list and even contributing some minor patches. I have never personally seen a single environment which uses this feature, and I've only even heard of two.

The short version is you set up an SSH server key for the CA, you use ssh-keygen(1) to have the CA sign itself, then use that key to sign keys generated by users. The process of signing a user key involves specifying the users for whom that user key is valid. This is shown in the ssh-keygen(1) manpage in this line:

ssh-keygen -s ca_key -I key_id -n user1,user2 user_key.pub

Then you tell the SSH server to trust user keys signed by a particular CA key, typically with a TrustedUserCAKeys entry in the sshd_config(5) file. It can be done with an AuthorizedKeysFile entry instead, which is required for this CVE to be an issue.

See the comma in the command above? That's the "more than one principal" which is required for this CVE to be an issue.