VSA-2026-009: OpenSSH ECDSA & CA vulnerabilities
| Published | Updated | Severity | CVSS 4.0 | Affected products |
|---|---|---|---|---|
| 2026-04-28 | 2026-04-28 | 🟠Moderate | Not available yet | - XCP-ng 8.3 |
info
A vulnerability in the OpenSSH server has been discovered. For Vates products, we classify the impact as Moderate, as the vulnerability can be exploited from a VM. For details on how we assign severity levels, see our Severity Levels Explained page.
Summary​
The new version of OpenSSH 10.3 fixes two vulnerabilities.
- In the case where principals="" is defined in the authorized_keys file with a CA, this is misinterpreted.
- For ECDSA keys, if one of its algorithms is activated, then all the others will also be activated without verifying that they are actually active and usable.
info
By default, we allow ECDSA keys. Therefore, if the default configuration has not been changed, this has no impact.
Impact​
- In some cases, this could grant access without authorization.
- Disabled algorithms could still be used, leading to a connection not being as secure as user would expect
info
The main certificate authentication path (TrustedUserCAKeys/AuthorizedPrincipalsFile) is not affected.
Affected Versions​
- XCP-ng 8.3: Only if authorized_keys contains principals="" with a CA with commas.
Mitigation​
- Do not use principals="" or avoid commas between CAs
- Disable all ECDSA key login via sshd_config then restart sshd.
Resolution​
As of the 2026-04-28, the updated openssh-* packages for XCP-ng 8.3 have been updated to address this issue.
List of packages fixing these issues:
- XCP-ng 8.3:
openssh-9.8p1-1.2.3.xcpng8.3openssh-server-9.8p1-1.2.3.xcpng8.3
Credits​
- Reported by Vladimir Tokarev.
- Reported by Christos Papakonstantinou of Cantina and Spearbit.
- Fixed by djm from OpenBSD