Security 18.05.2026 Aktualisiert: 18.05.2026

ssh-keysign-pwn CVE-2026-46333: Linux ruhig prüfen und patchen

CVE-2026-46333 kann lokale Root-Dateien lesbar machen. Patchstände, Angriffspfad, Mitigation und Einordnung für Linux-Server.

Stand: 18.05.2026, 05:00 Uhr CEST. ssh-keysign-pwn, CVE-2026-46333, ist nach Copy Fail, Dirty Frag und Fragnesia die nächste Linux-Kernel-Lücke mit öffentlichem PoC. Sie ist ernst, aber anders einzuordnen: Es geht nicht um eine unauthentifizierte Remote-Lücke in OpenSSH und nicht automatisch um eine Root-Shell. Praktisch relevant ist sie vor allem dort, wo ein Angreifer bereits lokalen Code ausführen kann.

Kurzfassung

Worum es geht: CVE-2026-46333 ist eine lokale Informationslücke im Linux-Kernel. Ein unprivilegierter lokaler Prozess kann unter passenden Bedingungen Dateideskriptoren aus einem gerade beendenden privilegierten Prozess kopieren.
Was dadurch lesbar werden kann: Die öffentlichen PoCs lesen SSH-Host-Private-Keys über ssh-keysign und /etc/shadow über chage.
Remote allein ausnutzbar: Nein. Ein offener SSH-Port reicht nicht. Der Angreifer braucht lokale Code-Ausführung, etwa einen Shell-Account, eine kompromittierte Webanwendung, einen CI-Job, Plugin-Code oder Code in einem Container.
Direkte Root-LPE: Nicht im selben Sinn wie Dirty Frag oder Fragnesia. Die Lücke schreibt nichts in den Page Cache und öffnet nicht direkt eine Root-Shell. Gelesene /etc/shadow-Hashes oder SSH-Host-Keys können aber in echten Angriffen trotzdem sehr unangenehm sein.
Warum trotzdem patchen: Auf Shared-Hosting-, Plesk-, CI-, Container- und Multi-User-Systemen ist “lokaler Benutzer kann Root-Dateien lesen” kein Randthema.
Sofortmaßnahme: Vendor-Kernel aktualisieren und in den gefixten Kernel booten. Wenn das nicht sofort geht, kernel.yama.ptrace_scope=2 oder 3 als temporäre Mitigation prüfen.
Nicht machen: Den öffentlichen PoC nicht auf Produktivsystemen starten. Er ist kein harmloser Scanner und kann sensible Inhalte auf stdout ausgeben.

Was ist ssh-keysign-pwn?

ssh-keysign-pwn ist der Name des öffentlichen Exploit-Repositories für CVE-2026-46333. Der Name ist etwas eng, weil die eigentliche Lücke nicht in OpenSSH sitzt. Der Bug liegt im Kernel, genauer im ptrace-Zugriffspfad __ptrace_may_access().

Der Kernel prüft über diese Logik, ob ein Prozess einen anderen Prozess beobachten oder auf bestimmte Informationen zugreifen darf. Beim Beenden eines Prozesses gibt es aber eine kurze Phase, in der der Prozess seine Speicherbeschreibung (mm) schon abgegeben hat, seine offenen Dateideskriptoren aber noch existieren. Genau in diesem Fenster griff die dumpable-Prüfung nicht so, wie sie greifen sollte.

Der öffentliche PoC kombiniert dieses Fenster mit pidfd_getfd(2). Damit kann ein Prozess einen offenen Dateideskriptor aus einem anderen Prozess kopieren, wenn die Kernel-Zugriffsprüfung es erlaubt. Bei verwundbaren Kerneln konnte ein unprivilegierter Benutzer in der Exit-Phase eines passenden SUID-Programms an Dateideskriptoren kommen, die eigentlich Root-Dateien öffnen.

Die beiden bekannten Ziele sind:

Ziel	Was passiert	Praktische Auswirkung
`ssh-keysign`	Öffnet SSH-Host-Private-Keys wie `/etc/ssh/ssh_host_ed25519_key` und beendet sich anschließend.	Ein lokaler Angreifer kann Host-Private-Keys lesen, wenn der Race gelingt.
`chage -l <user>`	Öffnet `/etc/shadow`, bevor die Privilegien fallen.	Ein lokaler Angreifer kann Passwort-Hashes lesen und offline knacken.

Das ist bewusst keine Exploit-Anleitung. Für den Betrieb reicht die Kernidee: Ein lokaler Prozess muss einen passenden privilegierten Prozess oft genug starten oder abfangen, bis das kleine Zeitfenster getroffen wird. Das GitHub-Repository nennt Treffer typischerweise nach 100 bis 2000 Starts. Das ist kein Remote-Klick, aber auch nicht völlig theoretisch.

Was braucht ein Angreifer?

Die wichtigste Entwarnung zuerst: CVE-2026-46333 ist keine “OpenSSH von außen übernehmen”-Lücke. Ein Angreifer braucht bereits eine lokale Ausführungsmöglichkeit auf dem Host.

Typische Ausgangspunkte sind trotzdem nicht exotisch:

Shell-Zugang eines Kunden, Entwicklers oder Dienstleisters
kompromittierte WordPress-, TYPO3-, Shopware-, Laravel- oder Node.js-Anwendung
Plesk- oder Shared-Hosting-System mit getrennten Systembenutzern
GitLab Runner, GitHub Actions Runner, Jenkins-Agent oder anderer CI-Worker
Docker-, Kubernetes- oder LXC-Workload mit nicht vollständig vertrauenswürdigem Code
Plugin-Code, Build-Scripts, Cronjobs oder Deployment-Hooks
gestohlene SSH-Zugangsdaten eines normalen Benutzers

Auf einem Single-Tenant-Server ohne fremde Shells, ohne fremde Container und ohne unkontrollierten Build-Code ist das Risiko niedriger als bei Dirty Frag oder Fragnesia. Patchen solltest du trotzdem. Nur muss daraus nicht automatisch ein hektischer Notfall für jeden kleinen Einzelserver werden.

Was kann wirklich passieren?

Der direkte Schaden ist Informationsabfluss. Das ist ein Unterschied zu den Page-Cache-Write-Lücken der letzten Wochen.

Bei geleakten SSH-Host-Private-Keys kann ein Angreifer unter bestimmten Umständen die Host-Identität eines Servers imitieren oder spätere Man-in-the-Middle-Szenarien vorbereiten. Das heißt nicht, dass alle Benutzerpasswörter automatisch weg sind. Es heißt aber: Die Vertrauenskette von SSH-Host-Keys kann beschädigt sein.

Bei /etc/shadow hängt die Folge stark von den Passwörtern und Hash-Parametern ab. Moderne, starke Passwörter und harte Hashes sind nicht sofort “geknackt”. Schwache Passwörter, alte Hash-Verfahren oder wiederverwendete Passwörter sind ein anderes Thema. Dann kann aus einem lokalen Lesebug später echter Account-Zugriff werden.

Wichtig für die Einordnung: Wenn du keinen Hinweis auf Ausnutzung hast, ist “alle SSH-Host-Keys sofort rotieren und alle Passwörter zurücksetzen” oft überzogen. Wenn der Host aber untrusted lokale Benutzer hatte, ein PoC-Test gelaufen ist oder du konkrete Verdachtsmomente siehst, gehört genau diese Prüfung auf den Tisch.

Wie funktioniert die Lücke technisch?

Die kurze Version: __ptrace_may_access() benutzte die Dumpability des Zielprozesses als Teil der Zugriffskontrolle. Diese Dumpability hängt historisch an der Speicherabbild-Frage: Darf dieser Prozess einen Core Dump erzeugen, und wer dürfte ihn lesen?

Beim Prozessende läuft im Kernel grob diese Reihenfolge:

Der Prozess geht in do_exit().
exit_mm() entfernt die Speicherbeschreibung des Prozesses.
Erst später räumt exit_files() die offenen Dateideskriptoren auf.
Dazwischen hat der Prozess kein mm mehr, aber noch offene FDs.

Genau dort lag der Fehler. Wenn task->mm == NULL war, wurde die Dumpability-Prüfung nicht sinnvoll weitergeführt. Der Fix von Linus Torvalds, Commit 31e62c2ebbfd, speichert deshalb den letzten user-dumpable-Zustand im Task und erzwingt bei nicht dumpbaren Fällen wieder eine passende CAP_SYS_PTRACE-Prüfung.

Der öffentliche PoC nutzt pidfd_getfd(2), das seit Linux 5.6 existiert. Deshalb sind manche älteren Enterprise-Kernel zwar vom zugrunde liegenden Logikfehler betroffen, aber mit genau diesem PoC nicht direkt ausnutzbar. Das ist eine wichtige Nuance, aber keine Entwarnung für produktive Systeme. Vendoren patchen auch solche Linien, weil andere Wege in dieselbe Fehlerklasse denkbar sind.

Upstream-Fix und Kernelstände

Der zentrale Upstream-Fix ist ptrace: slightly saner 'get_dumpable()' logic mit Commit 31e62c2ebbfdc3fe3dbdf5e02c92a9dc67087a3a. NVD führt CVE-2026-46333 seit 15.05.2026, hatte zum geprüften Stand aber noch keinen eigenen CVSS-Score veröffentlicht.

Für selbst gebaute Kernel, Gentoo-Systeme oder Appliance-Kernel sind die Stable-Releases wichtig. LWN meldete am 15.05.2026 sieben Stable-Kernel mit Patches für CVE-2026-46333:

Upstream-Linie	Gepatchter Stable-Kernel
5.10 LTS	`5.10.256`
5.15 LTS	`5.15.207`
6.1 LTS	`6.1.173`
6.6 LTS	`6.6.139`
6.12 LTS	`6.12.89`
6.18 LTS	`6.18.31`
7.0 Stable	`7.0.8`

Bei Distributionskerneln ersetzt diese Tabelle nicht den Vendor-Tracker. Debian, Red Hat, SUSE, AlmaLinux, CloudLinux, Proxmox und Cloud-Images backporten Kernel-Fixes. Ein Kernel mit optisch alter Hauptversion kann gefixt sein, und ein scheinbar neuer Kernel kann offen sein, wenn genau dieser Backport fehlt.

Das erklärt auch scheinbare Versionswidersprüche: Debian kann CVE-2026-46333 zum Beispiel in 5.10.251-5, 6.12.88-1 oder 7.0.7-1 gefixt haben, obwohl die Upstream-Stable-Tabelle erst 5.10.256, 6.12.89 oder 7.0.8 nennt. Debian übernimmt dann den konkreten Fix in das eigene Kernelpaket, ohne die komplette Upstream-Stable-Version zu übernehmen. Für Debian zählt deshalb der Security Tracker, nicht die reine Upstream-Grenze.

Wer ist betroffen?

Betroffen sind Linux-Systeme mit verwundbarem Kernel und lokal erreichbarem Angriffspfad. Der konkrete öffentliche PoC braucht zusätzlich pidfd_getfd(2) und passende SUID-Ziele wie ssh-keysign oder chage.

Umgebung	Einschätzung	Worauf prüfen
Debian	Debian listet fixe Security-Kernel für Bullseye, Bookworm, Trixie und Sid/Forky.	Installiertes Paket, laufenden Kernel und Debian Security Tracker prüfen.
Ubuntu	Der öffentliche PoC nennt Ubuntu 22.04, 24.04 und 26.04 als bestätigt. Zum geprüften Stand fand die Ubuntu-CVE-Suche keinen Eintrag zu CVE-2026-46333.	Nicht als Entwarnung werten. Kernel-Flavour, Ubuntu Security Notices und Livepatch-Status prüfen; bis dahin `ptrace_scope`-Mitigation bewerten.
RHEL / OpenShift	Red Hat führt RHSB-2026-004 als Important/Ongoing. Betroffen sind RHEL 8, 9, 10 und Produkte auf RHEL-Kernelbasis, inklusive RHEL CoreOS/OpenShift.	Red-Hat-Bulletin, Errata und laufenden Kernel prüfen.
AlmaLinux	Gepatchte Kernel für AlmaLinux 8, 9 und 10 sind seit 16.05.2026 in Production-Repositories.	Mindestens `kernel-4.18.0-553.124.4.el8_10`, `kernel-5.14.0-611.54.6.el9_7` oder `kernel-6.12.0-124.56.5.el10_1`, danach Reboot.
Rocky Linux	Kein eigener belastbarer Rocky-Fixstand im geprüften Material. Rocky folgt meist RHEL oder temporären Security-Repo-Pfaden, aber das muss pro CVE geprüft werden.	Rocky-Errata, Security-Repo-Hinweise, laufenden Kernel und Red-Hat-Basisstand nicht blind gleichsetzen.
CloudLinux	CL7 ist laut CloudLinux nicht betroffen. CL8 LTS, CL9 und CL10 sind mit aktuellem PoC betroffen; CL7h/CL8 enthalten den Logikfehler, sind aber mit dem öffentlichen `pidfd_getfd`-PoC nicht direkt ausnutzbar.	CL7h/CL8 Beta-Fixes `kernel-4.18.0-553.124.4.lve...`; CL9/CL10 folgen AlmaLinux-Zielständen. `kernel.user_ptrace=0` als CloudLinux-spezifische Mitigation prüfen.
SUSE / openSUSE	SUSE bewertet die Lücke als moderate, Gesamtstatus “New”. Viele SLE-15-SP7-Pakete standen auf “In progress”; SLE Micro 5.3 bis 5.5 und mehrere LTSS-Linien hatten bereits “Released”-Stände.	Produkt- und Service-Pack-Tabelle auf der SUSE-CVE-Seite prüfen.
Fedora / Arch / Rolling Releases	Upstream-Stable-Fixes sind in aktuellen Kernelständen angekommen. Bei Fedora tauchten `7.0.8`-basierte Updates zeitnah auf.	Aktualisieren, rebooten, laufenden Kernel gegen Paketstand prüfen.
Amazon Linux / AWS	Zum geprüften Stand war kein klarer AWS-Sammelstand für CVE-2026-46333 sichtbar.	ALAS, AWS Security Bulletins und AMI-/Node-Image-Version prüfen, nicht aus Copy-Fail-/Dirty-Frag-Ständen ableiten.
Proxmox VE	Der Proxmox-Host zählt wie jeder andere Linux-Host. LXC teilt den Host-Kernel, KVM-Gäste haben eigene Guest-Kernel.	PVE-Kernel-Changelogs und `uname -r` prüfen. Dirty-Frag-/Fragnesia-Fixes nicht automatisch als CVE-2026-46333-Fix behandeln.
Plesk-Server	Plesk selbst ist nicht der Bug. Praktisch relevant sind Plesk-Hosts wegen mehrerer lokaler Benutzer, PHP-FPM-Pools, Cronjobs und Shell-Zugänge.	OS-Vendor-Kernel patchen, Reboot-Status prüfen, bei CloudLinux CageFS und `kernel.user_ptrace` bewerten.
Docker, Kubernetes, CI-Runner	Relevant, wenn fremder Code läuft. Container teilen sich den Host-Kernel.	Node-Kernel patchen, seccomp/RuntimeDefault, SCC/PodSecurity und Debug-Zugänge prüfen.
Single-Tenant-Server ohne fremde lokale Benutzer	Niedrigeres Risiko, aber nicht “egal”. Eine Webshell oder ein kompromittierter Dienst ist lokaler Code.	Normal priorisiert patchen, ohne Panikmaßnahmen.

Patchstände nach Distribution

Die Tabelle ist eine Momentaufnahme. Maßgeblich bleibt der jeweilige Vendor-Tracker.

Distribution / Plattform	Stand 18.05.2026
Debian Bullseye	`linux` in Bullseye Security ab `5.10.251-5` gefixt; `linux-6.1` in Bullseye Security ab `6.1.172-1~deb11u1` gefixt.
Debian Bookworm	Bookworm Security ab `6.1.172-1` gefixt. Die normale Bookworm-Zeile `6.1.170-3` war im Tracker noch vulnerable markiert.
Debian Trixie	Trixie Security ab `6.12.88-1` gefixt.
Debian Forky / Sid	Ab `7.0.7-1` gefixt.
Ubuntu 22.04 / 24.04 / 26.04	Vom öffentlichen PoC als bestätigt genannt. Die Ubuntu-CVE-Suche lieferte zum geprüften Stand keinen CVE-2026-46333-Eintrag; deshalb Kernel-Flavour und USN/Livepatch-Kanal direkt prüfen.
RHEL 8/9/10 und OpenShift	Red Hat RHSB-2026-004: Important, Ongoing, Fixes werden beschleunigt. Betroffen sind RHEL 8, 9, 10 und RHEL-Kernel-basierte Produkte.
AlmaLinux 8	Production-Fix ab `kernel-4.18.0-553.124.4.el8_10`.
AlmaLinux 9	Production-Fix ab `kernel-5.14.0-611.54.6.el9_7`.
AlmaLinux 10	Production-Fix ab `kernel-6.12.0-124.56.5.el10_1`.
AlmaLinux Kitten 10	Zielstand `kernel-6.12.0-227.el10`; laut AlmaLinux-Post war der Build zum Initialstand noch in Arbeit.
CloudLinux 7	Laut CloudLinux nicht betroffen, weil die 3.10-Kernelbasis vor dem Upstream-Regressionsbereich liegt.
CloudLinux 7h / 8	Logikfehler vorhanden, aktueller öffentlicher PoC wegen fehlendem `pidfd_getfd(2)` nicht direkt nutzbar. Beta-Fixes: `kernel-4.18.0-553.124.4.lve.el7h` und `kernel-4.18.0-553.124.4.lve.el8`; Stable-Promotion prüfen.
CloudLinux 8 LTS	Vom öffentlichen PoC betroffen. CloudLinux empfiehlt sofort `kernel.user_ptrace=0`, bis ein passender LTS-Kernel oder KernelCare-Fix aktiv ist.
CloudLinux 9 / 10	Folgen den AlmaLinux-Zielständen `kernel-5.14.0-611.54.6.el9_7` und `kernel-6.12.0-124.56.5.el10_1`; laut CloudLinux seit 17.05. über normale Production-Updates erreichbar.
SUSE / openSUSE	SUSE-CVE-Seite: Gesamtstatus “New”, Severity “moderate”. SLE Micro 5.3/5.4/5.5 und mehrere LTSS-Linien mit Released-Ständen; viele SLE-15-SP7- und SLE-16-Pakete noch In progress oder Analysis.
Fedora / Rolling	Upstream-Stable-Fixes ab `7.0.8` und den genannten LTS-Ständen. Fedora-Systeme sollten auf aktuelle Kernelupdates gehen und rebooten.
Proxmox VE	Kein pauschaler CVE-2026-46333-Fixstand aus den geprüften offiziellen PVE-Changelogs ableitbar. PVE-Kernel-Changelog und laufenden Kernel prüfen.
Amazon Linux / Bottlerocket	Kein belastbarer CVE-2026-46333-Sammelstand im geprüften Material. AWS-ALAS, Security Bulletins und Node-Images getrennt prüfen.

Was ist nicht betroffen oder deutlich entschärft?

Nicht betroffen oder praktisch deutlich entschärft sind Systeme, bei denen der betroffene Kernelpfad gefixt ist oder der bekannte Angriffspfad nicht erreichbar ist.

Der laufende Kernel enthält den Upstream-Fix 31e62c2ebbfd oder einen Vendor-Backport.
Ein Livepatch nennt CVE-2026-46333 oder den passenden ptrace-/get_dumpable()-Fix für exakt den laufenden Kernel.
CloudLinux 7 ist laut CloudLinux nicht betroffen.
CL7h/CL8 und andere 4.18-Kernel ohne pidfd_getfd(2) sind mit dem aktuellen öffentlichen PoC nicht direkt ausnutzbar. Der Logikfehler kann trotzdem vorhanden sein.
Systeme ohne lokale Benutzer, ohne fremde Workloads und ohne untrusted Code haben ein niedrigeres praktisches Risiko.
CageFS kann CloudLinux-Tenants schützen, wenn ssh-keysign und chage im Cage nicht erreichbar sind. Das schützt aber nicht jeden Host-Kontext und ersetzt keinen Kernel-Fix.
kernel.yama.ptrace_scope=2 oder 3 blockiert die bekannten öffentlichen PoCs nach Herstellerangaben. Es bleibt eine Mitigation, kein Fix.

Vorsicht mit einer zu einfachen Aussage wie “ssh-keysign wird bei uns nicht genutzt”. Der öffentliche Name kommt von einem Zielprogramm. Die Kernel-Lücke ist breiter: Jedes SUID-root-Programm, das in der falschen Phase sensible Dateien offen hält, kann theoretisch interessant sein.

Schnelle Prüfung auf einem Host

Zuerst brauchst du den laufenden Kernel:

uname -r
uname -a

Dann prüfst du die installierten Kernelpakete. Auf Debian, Ubuntu und Proxmox:

dpkg -l 'linux-image*' 'linux-modules*' 'proxmox-kernel*' 'pve-kernel*' 2>/dev/null | awk '/^ii/ {print $2, $3}'

Auf RHEL-, Alma-, Rocky-, CloudLinux-, Oracle- und Fedora-nahen Systemen:

rpm -q kernel kernel-core kernel-modules kernel-modules-extra kernel-uek 2>/dev/null
uname -r

Auf SUSE und openSUSE:

zypper se -si 'kernel*'
uname -r

Prüfen, ob die bekannten Zielprogramme vorhanden und SUID-root sind:

ls -l /usr/lib/openssh/ssh-keysign /usr/libexec/openssh/ssh-keysign /usr/bin/chage 2>/dev/null
find /usr/lib /usr/libexec /usr/bin -xdev \( -name ssh-keysign -o -name chage \) -perm -4000 -ls 2>/dev/null

Prüfen, wie ptrace_scope aktuell steht:

sysctl kernel.yama.ptrace_scope 2>/dev/null || cat /proc/sys/kernel/yama/ptrace_scope 2>/dev/null

Grob einordnen, ob pidfd_getfd im Userspace-Header überhaupt bekannt ist:

grep -R "pidfd_getfd" /usr/include/asm-generic/unistd.h /usr/include/*/asm/unistd*.h 2>/dev/null | head

Das ist nur ein Hinweis. Header können von der tatsächlich gebooteten Kernel-ABI abweichen. Bei Enterprise-Kerneln ohne pidfd_getfd(2) kann der öffentliche PoC scheitern, während der zugrunde liegende Kernel-Fix trotzdem relevant bleibt.

Für Ubuntu ist der konkrete nächste Schritt der Kernel-Flavour. Prüfe nicht nur linux-generic, sondern das gebootete Image und die dazugehörigen Changelogs oder Ubuntu Security Notices:

uname -r
dpkg -S "/boot/vmlinuz-$(uname -r)" 2>/dev/null || true
dpkg -l 'linux-image*' 'linux-modules*' | awk '/^ii/ {print $2, $3}'
apt-cache policy "linux-image-$(uname -r)" linux-image-generic linux-image-generic-hwe-24.04 linux-image-aws linux-image-azure linux-image-gcp 2>/dev/null
apt changelog "linux-image-$(uname -r)" 2>/dev/null | grep -Ei 'CVE-2026-46333|ptrace|dumpable|pidfd_getfd|get_dumpable' || true

Wenn apt changelog nichts findet, ist das noch keine Entwarnung. Dann bleibt der Abgleich gegen die Ubuntu Security Notices, den Ubuntu-CVE-Tracker und den tatsächlichen Kernel-Flavour.

Für Proxmox ist der schnellste lokale Pfad:

pveversion -v
uname -r
dpkg -l 'proxmox-kernel*' 'pve-kernel*' | awk '/^ii/ {print $2, $3}'
apt-cache policy proxmox-kernel-6.8 proxmox-kernel-6.14 proxmox-kernel-6.17 proxmox-kernel-7.0 pve-kernel-6.8 pve-kernel-6.14 2>/dev/null
apt changelog proxmox-kernel-6.8 proxmox-kernel-6.14 proxmox-kernel-6.17 proxmox-kernel-7.0 2>/dev/null | grep -Ei 'CVE-2026-46333|ssh-keysign|ptrace|dumpable|pidfd_getfd|get_dumpable' || true

Zusätzlich lohnt der Blick in die Proxmox-Kernel-Changelogs und ins Proxmox-Forum. Wichtig ist wieder: Ein Dirty-Frag- oder Fragnesia-Eintrag im Changelog ist kein Nachweis für CVE-2026-46333.

Für Rocky Linux sind die sinnvollen Anker errata.rockylinux.org, die Rocky-News bzw. Announce-Kanäle und der tatsächlich angebotene Kernel:

cat /etc/rocky-release 2>/dev/null || true
dnf clean metadata
dnf updateinfo list --cve CVE-2026-46333 2>/dev/null || true
dnf repoquery --latest-limit=3 kernel kernel-core 2>/dev/null
rpm -q kernel kernel-core 2>/dev/null

Wenn dnf updateinfo nichts liefert, prüfe trotzdem, ob ein neuer Kernel angeboten wird. Rocky kann bei sehr frischen Kernel-Themen über temporäre Security-Repo- oder News-Hinweise schneller kommunizieren als über die normale Updateinfo-Ausgabe.

Für Amazon Linux ist der lokale Startpunkt ALAS plus laufender Kernel:

cat /etc/os-release
uname -r
dnf updateinfo list --cve CVE-2026-46333 2>/dev/null || yum updateinfo list --cve CVE-2026-46333 2>/dev/null || true
dnf check-update 'kernel*' 2>/dev/null || yum check-update 'kernel*' 2>/dev/null || true

Bei größeren AWS-Flotten ist AWS Systems Manager Inventory oder ein vergleichbarer Inventarweg sinnvoller als SSH von Hand. Entscheidend bleibt aber derselbe Nachweis: gebooteter Kernel, angebotenes Kernelpaket, ALAS- oder AWS-Bulletin-Status.

Das ist kein vollständiger Vulnerability-Scanner. Es beantwortet nur die ersten Betriebsfragen:

Welcher Kernel läuft wirklich?
Gibt es ein Vendor-Update oder einen Livepatch?
Sind die bekannten SUID-Ziele vorhanden?
Ist ptrace_scope bereits restriktiv gesetzt?
Gibt es lokale Benutzer oder Workloads, denen du nicht vollständig vertraust?

Als einfache Upstream-Faustregel gilt: Wenn dein unveränderter Kernel aus einer der oben genannten Upstream-Linien älter ist als der gepatchte Stable-Kernel, behandelst du ihn als betroffen. Bei Vendor-Kerneln gilt diese Regel nur als Startpunkt, weil Backports die sichtbare Versionsnummer absichtlich nicht auf die neue Upstream-Stable-Version heben.

Updates einspielen

Die saubere Lösung ist ein Kernel-Update aus den Repositories deiner Distribution. Danach muss der Host in den gefixten Kernel booten oder du musst einen passenden Livepatch nachweisen.

Debian, Ubuntu und Proxmox:

sudo apt update
sudo apt full-upgrade
sudo reboot
uname -r

RHEL, AlmaLinux, Rocky Linux, CloudLinux, Oracle Linux und Fedora:

sudo dnf clean metadata
sudo dnf update 'kernel*'
sudo reboot
uname -r

Bei älteren EL-Systemen kann noch yum statt dnf relevant sein.

SUSE und openSUSE:

sudo zypper refresh
sudo zypper patch
sudo reboot
uname -r

Bei Kernel-Livepatching reicht uname -r nicht. Der Release-String bleibt normalerweise gleich. Du brauchst den Nachweis aus dem Livepatch-Tool:

canonical-livepatch status --verbose 2>/dev/null || true
kpatch list 2>/dev/null || true
kcarectl --patch-info 2>/dev/null | grep -Ei 'CVE-2026-46333|ptrace|dumpable|pidfd_getfd' || true
uptrack-show --available 2>/dev/null || true

Auf RHEL-, Alma-, Rocky-, CloudLinux- und Fedora-nahen Systemen hilft nach Updates zusätzlich:

needs-restarting -r 2>/dev/null || true

Auf Debian und Ubuntu:

needrestart -r l 2>/dev/null || true
checkrestart 2>/dev/null || true

Das ersetzt nicht den Kernelvergleich. Es fängt aber typische Fälle ab, in denen ein Kernelpaket installiert wurde und der Host trotzdem noch mit dem alten Kernel läuft.

Temporäre Mitigation

Wenn ein Kernel-Fix noch nicht verfügbar ist oder ein Reboot nicht sofort geht, ist ptrace_scope die naheliegende Zwischenlösung. Red Hat empfiehlt für die meisten Produktionsumgebungen 2, weil dann nur Prozesse mit CAP_SYS_PTRACE attachen dürfen. 3 ist härter und deaktiviert ptrace-Attach vollständig.

Admin-only Attach:

printf '%s\n' 'kernel.yama.ptrace_scope = 2' | sudo tee /etc/sysctl.d/99-ssh-keysign-pwn.conf
sudo sysctl --system
sysctl kernel.yama.ptrace_scope

Maximal restriktiv:

printf '%s\n' 'kernel.yama.ptrace_scope = 3' | sudo tee /etc/sysctl.d/99-ssh-keysign-pwn.conf
sudo sysctl --system
sysctl kernel.yama.ptrace_scope

Die Nebenwirkungen sind real. gdb, strace -p, einige Profiler, Debugging-Workflows und Monitoring-Werkzeuge können betroffen sein. ptrace_scope=3 ist auf vielen Systemen deshalb eher eine kurzfristige Brücke als eine dauerhafte Standardhärtung.

Zurücknehmen nach gepatchtem Kernel:

sudo rm /etc/sysctl.d/99-ssh-keysign-pwn.conf
sudo sysctl --system

Auf CloudLinux ist die herstellerspezifische Mitigation oft besser:

sudo sysctl -w kernel.user_ptrace=0
printf '%s\n' 'kernel.user_ptrace = 0' | sudo tee /etc/sysctl.d/99-cloudlinux-user-ptrace.conf
sudo sysctl --system

Der Unterschied: kernel.yama.ptrace_scope ist die normale Yama-LSM-Einstellung vieler Linux-Distributionen und steuert, wer Prozesse per ptrace beobachten darf. kernel.user_ptrace ist eine CloudLinux-spezifische Kernel-Erweiterung, die unprivilegiertes ptrace hostweit abschalten kann. Auf CloudLinux ist sie deshalb der direktere Schalter; auf Debian, Ubuntu, RHEL, SUSE oder Proxmox existiert sie normalerweise nicht.

Wenn keine Kernel-Mitigation möglich ist, kann das Entfernen des SUID-Bits von ssh-keysign und chage den bekannten PoC-Zielen den Weg nehmen. Das ist aber enger als der Kernel-Fix und kann Funktionen verändern:

sudo chmod u-s /usr/lib/openssh/ssh-keysign 2>/dev/null || true
sudo chmod u-s /usr/libexec/openssh/ssh-keysign 2>/dev/null || true
sudo chmod u-s /usr/bin/chage

ssh-keysign wird für hostbasierte SSH-Authentifizierung gebraucht, die auf normalen Servern selten aktiv ist. chage ohne SUID-Bit kann von normalen Benutzern nicht mehr wie gewohnt für eigene Passwortalterungsinformationen genutzt werden. Für reine Produktionsserver ist das oft akzeptabel; für Multi-User- oder Entwicklungsumgebungen muss man es testen.

Container, Kubernetes und CI

Bei Containern gilt wieder die alte Regel: Das Image ist nicht der Kernel. Ein Debian-, Ubuntu- oder Alpine-Container nutzt den Host-Kernel. Wenn der Node-Kernel verwundbar ist und der Workload die nötigen Syscalls nutzen darf, ist das ein Node-Thema.

Für Kubernetes und OpenShift ist deshalb wichtig:

Node-Kernel patchen, nicht nur Images aktualisieren.
RuntimeDefault-seccomp statt unconfined bevorzugen.
Debug-Zugänge wie kubectl debug, oc debug und privilegierte Pods nur vertrauenswürdigen Admins geben.
Workloads als non-root fahren, wo es praktikabel ist.
CI-Runner mit fremdem Pull-Request-Code priorisieren.

Ein schneller Node-Überblick:

kubectl get nodes -o custom-columns='NAME:.metadata.name,KERNEL:.status.nodeInfo.kernelVersion,OS:.status.nodeInfo.osImage'
kubectl describe node <node-name> | grep -E 'Kernel Version|OS Image|Container Runtime'

Das ist keine vollständige Policy-Prüfung, aber ein guter Start. Wenn ein Node nach dem Wartungsfenster noch mit dem alten Kernel zurückkommt, ist die Arbeit nicht fertig.

Wenn ein Host verdächtig ist

Bei einem reinen Patchvorgang ohne Verdacht musst du nicht automatisch alle Secrets rotieren. Bei konkretem Verdacht sieht es anders aus.

Prüfe dann mindestens:

Wurde der öffentliche PoC oder ein ähnliches Binary ausgeführt?
Gab es lokale Benutzer oder Container, denen du nicht vertraust?
Sind /etc/ssh/ssh_host_*_key oder /etc/shadow in Logs, Shell-History, CI-Artefakten oder Prozessausgaben aufgetaucht?
Gibt es ungewöhnliche chage, ssh-keysign, pidfd_getfd, ptrace, strace oder Compiler-Aktivität?
Müssen SSH-Host-Keys rotiert und known_hosts-Änderungen sauber kommuniziert werden?
Müssen lokale Passwörter zurückgesetzt oder Passwort-Hashes als kompromittiert behandelt werden?

Ein geleakter SSH-Host-Key bedeutet nicht, dass der Server selbst automatisch übernommen wurde. Es bedeutet aber, dass Clients diesem Host-Key nicht mehr blind vertrauen sollten. Eine Rotation muss deshalb sauber geplant werden, sonst erzeugst du bei Benutzern nur Warnmeldungen ohne Erklärung.

Bei /etc/shadow ist die Lage abhängig von Passwortqualität und Hash-Verfahren. Wenn der Host untrusted lokale Benutzer hatte und der PoC plausibel gelaufen sein könnte, ist Passwortrotation oft günstiger als langes Raten.

Einordnung für Plesk, Proxmox und Hosting

Für Plesk-Server ist CVE-2026-46333 vor allem wegen Mandantentrennung relevant. Viele Plesk-Hosts haben getrennte Systembenutzer, PHP-FPM-Pools, Cronjobs, Backups, Deployment-Scripte und manchmal Shell-Zugänge. Ein normaler Website-Benutzer sollte keine SSH-Host-Keys und keine Shadow-Datei lesen können. Wenn so ein Host verwundbar ist, gehört er weiter nach oben in der Patch-Reihenfolge.

Bei CloudLinux/Plesk ist CageFS eine nützliche zusätzliche Schicht. CloudLinux schreibt, dass die bekannten Zielprogramme für caged Tenants nicht erreichbar sind. Das ist gut, aber kein Grund, den Kernel-Fix auszulassen. Nicht jeder Prozess auf dem Host läuft im Cage, und nicht jeder Angriffspfad muss exakt dem öffentlichen PoC folgen.

Bei Proxmox ist die Trennung wie immer wichtig:

Proxmox-Host: Der Host-Kernel muss gefixt oder mitigiert sein. Hooks, Backup-Scripte, Admin-Shells und Automatisierung laufen nahe am Host.
LXC-Container: LXC teilt den Host-Kernel. Ein verwundbarer Host-Kernel ist deshalb direkt relevant.
KVM-VMs: KVM-Gäste haben eigene Kernel. Ein Exploit im Gast ist nicht automatisch ein Exploit im Host. Die Gäste müssen trotzdem separat gepatcht werden.
Cluster: Reboots brauchen Reihenfolge. Dokumentiere, welcher Node mit welchem Kernel läuft und wo eine temporäre Mitigation aktiv ist.

Für Hoster, Agenturen und MSPs ist die Priorisierung pragmatisch: Systeme mit fremdem oder schwer kontrollierbarem Code zuerst. Danach normale Single-Tenant-Server im nächsten Wartungsfenster.

Wie wir damit umgehen würden

Bei einem produktiven Setup würde ich CVE-2026-46333 nicht isoliert behandeln, sondern zusammen mit den Kernel-Themen der letzten Wochen prüfen:

Hostliste aus Inventar, Monitoring, Proxmox, Cloud, Plesk und CI ziehen.
Systeme nach Risiko sortieren: Shared Hosting, Container, CI, Shell-Zugänge und Multi-User zuerst.
Pro Host laufenden Kernel, installierte Kernelpakete und Vendor-Fixstand prüfen.
Bei Linux-Kerneln zusätzlich Copy Fail, Dirty Frag und Fragnesia im selben Wartungsfenster gegenprüfen.
Wenn kein Fix oder kein sofortiger Reboot möglich ist: ptrace_scope=2 oder 3 mit Nebenwirkungen testen.
Reboot- oder Livepatch-Nachweis dokumentieren.
Nachkontrolle: laufender Kernel, ptrace_scope, Monitoring und offene Hosts.
Bei Verdacht auf Ausnutzung nicht nur patchen, sondern Secret- und Account-Prüfung starten.

Wenn du nicht sicher bist, ob deine Server wirklich betroffen sind, ist ein kurzer Security- und Kernel-Check sinnvoller als blinde Hektik. Gerade bei Plesk-, Proxmox-, Container- und CI-Umgebungen ist die Frage nicht nur “Update ja/nein”, sondern “welcher Host kann wann rebooten, welche Mitigation bricht welche Workflows, und welche Secrets müssen wir bei Verdacht anfassen?”

Update-Log

2020-10-16: Jann Horn beschrieb einen Patchvorschlag für dieselbe Grundform der ptrace-/Dumpability-Problematik.
2026-05-14: Linus Torvalds mergte den Upstream-Fix 31e62c2ebbfd für ptrace: slightly saner 'get_dumpable()' logic.
2026-05-14: Phoronix berichtete über ssh-keysign-pwn als neue lokale Linux-Kernel-Lücke zum Lesen root-eigener Dateien.
2026-05-15: CVE-2026-46333 wurde in NVD aufgenommen. Das öffentliche GitHub-Repository mit sshkeysign_pwn und chage_pwn war verfügbar.
2026-05-15: Stable-Kernel 7.0.8, 6.18.31, 6.12.89, 6.6.139, 6.1.173, 5.15.207 und 5.10.256 wurden mit Fixes für CVE-2026-46333 angekündigt.
2026-05-16: AlmaLinux meldete gepatchte Kernel für AlmaLinux 8, 9 und 10 in den Production-Repositories.
2026-05-16: Red Hat veröffentlichte RHSB-2026-004 als Important/Ongoing für RHEL 8, 9, 10 und RHEL-Kernel-basierte Produkte.
2026-05-18: Artikel angelegt. Patchstände gegen NVD, Upstream-Fix, Debian Security Tracker, Red Hat, AlmaLinux, CloudLinux, SUSE und die angegebenen Sekundärquellen geprüft.