OpenSSH CVE-2026-35414: Bin ich betroffen? authorized_keys principals, Root-Risiko und Sofortmaßnahmen

Stand: 27. April 2026 – zuletzt aktualisiert

Autor: Mika Schmidt (IT-Security Experte) – Six Eight Consulting, Fokus: Analyse, IAM, Security Engineering.

CVE-2026-35414 in OpenSSH sorgt aktuell für widersprüchliche Schlagzeilen. Die offiziellen OpenSSH-Release-Notes vom 2. April 2026 beschreiben einen engen Fehlerpfad rund um authorized_keys, principals= und bestimmte SSH-Zertifikats-Setups. SecurityWeek berichtete dagegen am 27. April 2026 unter Berufung auf Cyera über mögliche Root-Shell-Szenarien. [Vendor Advisory] [News]

Für Unternehmen ist deshalb nicht die pauschale Frage entscheidend, ob „OpenSSH verwundbar“ ist, sondern welcher Authentifizierungsweg im eigenen Umfeld wirklich genutzt wird. Wenn Sie ausschließlich Passwörter, klassische Public Keys oder den CA-Pfad über TrustedUserCAKeys und AuthorizedPrincipalsFile einsetzen, ist Ihre Betroffenheit laut OpenSSH anders zu bewerten als bei user-trusted CAs direkt in ~/.ssh/authorized_keys. [Vendor Docs] [Vendor Advisory]

Was ist technisch passiert?

Laut OpenSSH wurde bei der Auswertung der authorized_keys principals=-Option ein falscher Matching-Algorithmus verwendet. Problematisch wird das in Fällen, in denen ein Zertifikats-Principal ein Komma enthält und dadurch ungewollt wie eine Liste interpretiert werden kann. [Vendor Advisory] [Mailing List]

OpenSSH grenzt die Voraussetzungen recht deutlich ein: Ausnutzung setzt laut Release-Notes voraus, dass die principals=-Option mehrere Principals enthält und dass eine CA Zertifikate ausstellt, in denen Principal-Namen mit Kommas auftauchen. Gleichzeitig schreiben die Maintainer ausdrücklich, dass der Hauptpfad über TrustedUserCAKeys und AuthorizedPrincipalsFile nicht betroffen sei. [Vendor Advisory] [Vendor Docs]

SecurityWeek stellt die Auswirkungen am 27. April 2026 drastischer dar und verweist auf Cyera: Demnach könne unter den betroffenen Bedingungen aus einem niedrig privilegierten Zertifikatskontext ein Root-Login werden, ohne dass klassische Fehl-Authentifizierungen im Log auftauchen. Diese Schilderung passt zum möglichen Impact, aber nicht zu einem „jedes OpenSSH-System ist sofort rootbar“-Szenario. [News]

Welche Setups sind wirklich betroffen?

Der wichtigste praktische Unterschied ist das Authentifizierungsmodell. OpenSSH-Dokumentation und Manpage trennen klar zwischen Zertifikaten über TrustedUserCAKeys auf der einen Seite und CAs, die direkt über authorized_keys mit cert-authority vertraut werden, auf der anderen. [Vendor Docs]

Warum schwankt die Risikobewertung so stark?

Auch bei den Scorings herrscht keine Einigkeit. NVD zeigt nach Reanalysen am 10. April 2026 einen CVSS 3.1 Score von 8.1 High, während MITRE als CNA und Ubuntu weiterhin 4.2 Medium ausweisen. [NVD] [Vendor Tracker]

Meine Einordnung: Die Differenz deutet darauf hin, dass hier unterschiedliche Annahmen über die Vorbedingungen getroffen werden. Wer die Spezialkonfiguration und einen passenden CA-Issuance-Flow voraussetzt, kommt eher bei „Medium“ heraus. Wer den möglichen Endeffekt Root-Zugang auf produktiven SSH-Zielen höher gewichtet, landet näher an „High“. Die offiziellen Quellen lösen diesen Widerspruch bisher nicht gemeinsam auf. [NVD] [News]

Betroffenheit prüfen: Diese Fragen sollten Sie jetzt beantworten

Viele Teams prüfen zuerst nur die OpenSSH-Version. Das reicht hier nicht. Für CVE-2026-35414 müssen Sie zusätzlich nachvollziehen, ob und wie SSH-Zertifikate im eigenen Umfeld eingesetzt werden.

# Server- und Client-Version prüfen
sshd -V 2>&1 | head -n1
ssh -V

# Distro-Paketstand prüfen (Debian/Ubuntu)
dpkg -l | grep openssh

# RPM-basierte Systeme
rpm -qa | grep -i openssh
    

# cert-authority/principals in authorized_keys suchen
find /home /root -path '*/.ssh/authorized_keys' -type f -exec grep -nHE 'cert-authority|principals='  \;

# Zentralen CA-Pfad im sshd_config prüfen
grep -RInE 'TrustedUserCAKeys|AuthorizedPrincipals(File|Command)' \
  /etc/ssh/sshd_config /etc/ssh/sshd_config.d 2>/dev/null

# Optional: bekannte SSH-Zertifikate inventarisieren
find /home /root -path '*/.ssh/*-cert.pub' -type f -print
    

Wenn Sie zwar OpenSSH einsetzen, aber nicht sicher sagen können, wie Zertifikats-Logins modelliert sind, ist das bereits ein Steuerungsproblem. In vielen Umgebungen liegen die sensiblen Risiken nicht in der Version allein, sondern in historisch gewachsenen Admin-Shortcuts und uneinheitlichen CA-Regeln.

Sofortmaßnahmen für Security- und Infrastruktur-Teams

1. Auf 10.3/10.3p1 oder bestätigte Backports aktualisieren

Upstream ist der Fix seit dem 2. April 2026 in OpenSSH 10.3 beziehungsweise 10.3p1 enthalten. Bei Distributionen zählen aber nicht nur Upstream-Versionsnummern, sondern auch Backports und Paket-Revisionen. [Vendor Advisory] [Package Update]

• Debian: Im Debian-Bugtracking wurde die Korrektur am 12. April 2026 in 1:10.3p1-1 als behoben markiert.
• Ubuntu: Auf der Ubuntu-CVE-Seite standen mehrere Releases am 10. April 2026 noch auf Needs evaluation.
• Praxisregel: Immer die konkrete Vendor-Advisory oder Paket-Maintainer-Info prüfen, nicht nur ssh -V.

2. Riskante CA-Pfade kurzfristig entschärfen

Wenn Sie die problematische Kombination aus cert-authority in authorized_keys plus principals= im Einsatz haben, sollten Sie diese Pfade kurzfristig priorisieren. Je nach Umgebung kann es sinnvoll sein, betroffene Einträge vorübergehend zu entfernen, auf weniger privilegierte Principals zu begrenzen oder den Root-Login generell zu schließen. [Vendor Advisory]

• Root- und Break-Glass-Accounts prüfen: Gibt es Zertifikats-Authentifizierung für root oder gleichwertige Admin-Identitäten?
• Komma-Patterns verbieten: CA-Policies und Issuance-Skripte sollten problematische Principal-Namen blockieren.
• Mittelfristig vereinheitlichen: Wo möglich auf TrustedUserCAKeys plus AuthorizedPrincipalsFile umstellen.

3. Nicht nur Logs, sondern Konfiguration und Zertifikatsfluss prüfen

SecurityWeek zitiert Cyera mit dem Hinweis, dass erfolgreiche Ausnutzung nicht wie ein klassischer Fehlversuch aussieht. Das bedeutet: Wer nur auf fehlgeschlagene SSH-Logins schaut, verpasst unter Umständen das eigentliche Risiko. Relevanter sind in diesem Fall Konfigurationsaudit, Zertifikats-Inventar und CA-Governance. [News]

4. Historische Admin-Workarounds bereinigen

Gerade ältere SSH-Setups enthalten oft Altlasten: manuell gepflegte authorized_keys, Broad-Match-Principals, Notfall-CAs oder unterschiedliche Regeln je Team. CVE-2026-35414 ist ein gutes Beispiel dafür, wie aus einem seltenen Feature ein reales Betriebsrisiko werden kann.

FAQ zu OpenSSH CVE-2026-35414

Ist das dieselbe Lage wie bei regreSSHion?

Nein. CVE-2024-6387 (regreSSHion) war eine andere OpenSSH-Schwachstelle mit ganz anderem technischen Pfad. Bei CVE-2026-35414 geht es um die Auswertung von Principals in speziellen Zertifikatskonfigurationen.

Wenn ich nur normale SSH-Keys nutze, kann ich den Beitrag ignorieren?

Nicht ganz, aber die Priorität ist meist anders. Patchen sollten Sie OpenSSH trotzdem. Die unmittelbare Betroffenheit dieses CVE ist jedoch vor allem dort hoch, wo SSH-Zertifikate und CA-Vertrauen aktiv genutzt werden.

Reicht Patchen allein aus?

Patchen ist der erste Schritt. Zusätzlich sollten Sie aber Authentifizierungsmodell, Principal-Listen und CA-Richtlinien prüfen. Wenn Sie privilegierte Zertifikats-Logins im Einsatz haben, gehört das in denselben Arbeitsblock wie das Update.

Was ist die wichtigste Management-Botschaft?

CVE-2026-35414 zeigt, dass nicht nur „ungepatchte Software“, sondern auch selten dokumentierte Identity- und Access-Patterns ein Risiko werden können. Wer SSH-Zertifikate nutzt, sollte diese Konfigurationen wie ein kritisches IAM-Thema behandeln.

Wenn Sie unsicher sind, welche SSH-Zertifikats- und CA-Pfade in Ihrer Umgebung produktiv genutzt werden, hilft ein IT-Security Check dabei, diese Altlasten schnell sichtbar und priorisierbar zu machen.