CVE-2026-46333 — Linux-Kernel-LPE im ptrace-Pfad: wie ein neun Jahre alter Logic-Bug plus pidfd_getfd() jede unprivilegierte Shell in /etc/shadow plus root verwandelt

TL;DR — die 90-Sekunden-Zusammenfassung

Was wurde veröffentlicht?

Das Qualys Threat Research Unit (TRU) hat am 20.05.2026 das volle Advisory für CVE-2026-46333 publiziert — einen Logik-Fehler in der Linux-Kernel-Funktion __ptrace_may_access(). Der Bug sitzt seit v4.10-rc1 (November 2016) in mainline und ist erst durch das spätere pidfd_getfd() (v5.6-rc1, Januar 2020) zur vollwertigen Local-Privilege-Escalation-Kette geworden.

Wie schwer?

Hoch (CVSS 7.8, Red Hat klassifiziert als „Important“, NVD ebenfalls High — nicht Critical). Operativ trotzdem dringend zu behandeln: Public Exploits zirkulieren bereits (ein unabhängiger Exploit aus dem Public-Patch ist während der Embargo-Phase aufgetaucht), und jede unprivilegierte lokale Shell lässt sich in vier dokumentierten Aufrufketten zu root oder zu sensiblen Credentials drehen. Das Badge oben spiegelt diese operative Dringlichkeit, nicht den reinen CVSS-Score.

Welcher technische Hebel?

Ein Race-Window: ein privilegierter Prozess gibt Credentials ab (do_exit()-Pfad), aber bleibt für ptrace-Family-Operationen kurz erreichbar, weil das dumpable-Flag nicht greift wenn mm NULL ist. Der Angreifer nutzt pidfd_getfd(), um offene File-Deskriptoren und authentifizierte IPC-Kanäle des sterbenden Prozesses unter eigener UID zu kapern.

Was sind die Exploit-Targets?

Qualys hat vier funktionierende Exploits gegen Userland-Klassiker gebaut: chage (set-uid-root, leakt /etc/shadow), ssh-keysign (set-uid-root, leakt SSH-Host-Private-Keys), pkexec (set-uid-root, RCE als root), accounts-daemon (root-Daemon, RCE als root über kapernde dbus-Connection). Getestet auf Default-Installationen von Debian 13, Ubuntu 24.04 + 26.04, Fedora 43 + 44.

Bin ich als Moselwal-Kunde betroffen?

Wenn Ihre Plattform auf Linux-Container-Hosts läuft (also: ja), war sie betroffen. Container teilen den Host-Kernel — eine Alpine-/Wolfi-/Debian-Userland-Schicht schützt nicht vor Kernel-Bugs. Seit der Nacht vom 20. auf 21. Mai sind die Distribution-Kernel-Updates über unsere Pipeline ausgerollt, die Rolling-Worker-Restarts sind durch.

Sofort-Mitigation ohne Patch?

sysctl -w kernel.yama.ptrace_scope=2 persistent in /etc/sysctl.d/. Das verlangt CAP_SYS_PTRACE für ptrace-Operationen und blockt die Public Exploits, weil der pidfd_getfd()-Pfad über __ptrace_may_access() gegated ist. Achtung: ptrace_scope ist statistisch nicht-fallend — einmal hochgesetzt, kommt man nur per Reboot wieder runter. Plus Operational Impact (gdb/strace/perf-Limitierungen).

 

Operative Lage bei Moselwal-Kunden

Bei Moselwal werden alle Container-Hosts (FrankenPHP-Worker auf Wolfi-Base, Application-Container auf Debian-Slim, Kubernetes-Worker-Nodes auf Ubuntu LTS) als Continuous-Upgrade-Stack betrieben — sobald ein Distribution-Kernel-Patch verfügbar ist, läuft die Image-Rebuild-Pipeline plus rolling Worker-Restart. In der Nacht vom 20. auf 21. Mai 2026 hat sich das exakt so abgespielt: Debian 13 / Ubuntu 24.04+26.04 / Fedora 43+44-Kernel-Patches sind durch die jeweiligen Distribution-Repositories gelaufen, die Image-Builds wurden über die CI-Pipeline neu erzeugt, der Worker-Rollout ist seit dem frühen Morgen unterwegs.

Bei Kubernetes-Setups gibt es einen zusätzlichen Pfad: die Worker-Node-Image-Refreshes laufen über die Cluster-Operator-Pipeline (Karpenter / managed Node-Pools), die Pods werden gracefully evictiert, die alten Worker fallen aus dem Pool. Public-Cloud-Managed-Kubernetes-Kunden (EKS, AKS, GKE) sind vom jeweiligen Provider abhängig — die Patches sind in den AMI- / VHD- / GCE-Image-Listen seit dem Wochenende verfügbar, die Node-Recyclierung gehört zur Routine.

Eine inhaltliche Vorab-Linie: Dies ist kein leichter Kernel-Bug, der nur in einem exotischen Subsystem schlummert. __ptrace_may_access() ist die zentrale Zugriffskontrolle für die gesamte ptrace-Family — also für alles, was Prozesse über Prozessgrenzen hinweg inspizieren oder beeinflussen kann. Dass die Funktion einen Branch (dumpable-Flag) silently überspringt wenn der Memory-Manager-Pointer NULL ist, ist ein Klassen-Bug, kein Einzel-Fehler. Plus: pidfd_getfd() ist eine moderne, eigentlich gut entworfene API — sie wird hier zum Angriffsvektor, weil sie auf eben jenes __ptrace_may_access() als Gating-Funktion zurückgreift.

Was ist das Problem? — der Race im __ptrace_may_access()-Pfad

Der Bug in einer Zeile Code

__ptrace_may_access() ist die zentrale Zugriffskontrolle für ptrace-Operationen. Sie prüft mehrere Bedingungen — UID-Match, Capabilities, das dumpable-Flag (verhindert ptrace gegen privilegierte Prozesse) — und ruft am Ende eine LSM-Hook auf (security_ptrace_access_check()). Wenn mm NULL ist, wird der dumpable-Branch komplett übersprungen — und nur noch die LSM-Hook bestimmt das Ergebnis. Das tritt ein, wenn ein Prozess gerade in do_exit() steht: der Kernel räumt die Memory-Map auf (setzt task->mm = NULL), bevor der Prozess vollständig aus der Task-Liste verschwindet. In diesem schmalen Race-Window ist der sterbende Prozess noch über seine PID ansprechbar, aber mm ist bereits NULL — und damit greift die dumpable-Schutzbarriere nicht mehr.

Die LSM-Hook (security_ptrace_access_check) ist bei Default-YAMA-Konfiguration (ptrace_scope=1) der einzige verbleibende Filter. Wenn der Angreifer der Parent-Prozess des sterbenden privilegierten Prozesses ist (etwa weil er das set-uid-Binary selbst gestartet hat), erlaubt YAMA das ptrace ohne Capability-Anforderung. Damit ist das Tor offen.

Die zweite Hälfte: pidfd_getfd()

pidfd_getfd(2) (seit v5.6-rc1, Januar 2020) ist ein moderner Syscall, der einem Prozess erlaubt, einen offenen File-Deskriptor eines anderen Prozesses in den eigenen FD-Tisch zu importieren — gegating durch __ptrace_may_access(target, PTRACE_MODE_ATTACH_REALCREDS). Wenn die Gating-Funktion fälschlicherweise zustimmt, kann der Angreifer beliebige FDs aus dem sterbenden privilegierten Prozess unter seine eigene UID nehmen — File-Handles auf /etc/shadow, auf SSH-Host-Keys, oder authentifizierte dbus-/socket-Verbindungen zu Systemdiensten.

Damit verwandelt sich der Race-Window-Bug von einer reinen Information-Disclosure in eine vollwertige Local-Privilege-Escalation. Der Sterbeprozess hatte eben noch root-Privilegien, der Angreifer übernimmt seine I/O-Endpoints — der Effekt ist root, ohne dass der Angreifer selbst je root war.

Vier dokumentierte Aufrufketten (Qualys-PoC)

Qualys hat vier funktionierende Exploits gebaut. Alle vier zielen auf etablierte set-uid- oder root-Daemon-Binaries:

1. chage (set-uid-root oder set-gid-shadow):chage öffnet /etc/shadow beim Start mit shadow-Group-Rechten. Der Angreifer startet chage, racet gegen das do_exit(), kapert den /etc/shadow-FD über pidfd_getfd(), liest die Datei. Effekt: vollständige /etc/shadow-Disclosure aus jeder unprivilegierten Shell.
2. ssh-keysign (set-uid-root): Helper-Binary für SSH-Host-Authentifizierung. Öffnet beim Start die SSH-Host-Private-Keys unter /etc/ssh/*_key. Gleicher Pfad — Race, FD-Kapern, Disclosure aller Host-Private-Keys.
3. pkexec (set-uid-root): PolicyKit-Helper. Hat eine offene dbus-Authentifizierungs-Verbindung zum PolicyKit-Daemon. Der Angreifer kapert die dbus-Connection und kann beliebige Kommandos als root ausführen — vorausgesetzt, eine allow_active-Konsolen-Session ist anwesend (für remote-SSH-Login-Angreifer ist das eine schwächere Eintrittshürde als es zunächst klingt, siehe Pumpkin-Chang-Trick im Detail-Abschnitt).
4. accounts-daemon (root-Daemon): Userspace-Daemon mit privilegiertem dbus-Endpoint. Der Angreifer kapert die dbus-Connection und führt arbitrary Commands als root aus. Ausnahme: Ubuntu ist hier nicht exploitable (YAMA ptrace_scope=1 default plus Angreifer ist nicht Parent des Daemons).

Qualys hält die genauen Exploit-Codes zurück, hat aber während der koordinierten Disclosure einen unabhängig entwickelten Exploit aus dem Public-Patch im Umlauf entdeckt — daher die vorzeitige Vollveröffentlichung.

Technische Tiefen-Analyse — der Original-Code und die genaue Race-Mechanik

Die folgende Sektion arbeitet entlang des Qualys-Detail-Advisory und gibt den Original-Kernel-Code mit den dort genannten Zeilennummern wieder. Wer den Bug auf eigener Codebase nachvollziehen will (z. B. für Custom-Kernel-Builds oder eigene Detection-Logik), findet hier die Anker.

Bug-Origin und Patch-Commit

Die Schwachstelle: __ptrace_may_access() im Kernel (kernel/ptrace.c)

Ein unprivilegierter User, der ptrace(), process_vm_readv(), process_vm_writev() oder pidfd_getfd() gegen einen Ziel-Prozess aufrufen will, muss zwei Security-Checks in __ptrace_may_access() passieren:

276 static int __ptrace_may_access(struct task_struct *task, unsigned int mode)
277 {
...
316         tcred = __task_cred(task);
317         if (uid_eq(caller_uid, tcred->euid) &&
318             uid_eq(caller_uid, tcred->suid) &&
319             uid_eq(caller_uid, tcred->uid)  &&
320             gid_eq(caller_gid, tcred->egid) &&
321             gid_eq(caller_gid, tcred->sgid) &&
322             gid_eq(caller_gid, tcred->gid))
323                 goto ok;
...
328 ok:
...
340         mm = task->mm;
341         if (mm &&
342             ((get_dumpable(mm) != SUID_DUMP_USER) &&
343              !ptrace_has_cap(mm->user_ns, mode)))
344             return -EPERM;
345
346         return security_ptrace_access_check(task, mode);
347 }

Check 1 (Zeilen 317–322): Die effektive, saved und real UID/GID des Ziel-Prozesses müssen mit der UID/GID des Aufrufers übereinstimmen. Bei einem set-uid-Binary, das setreuid(ruid, ruid) aufgerufen und seine Privilegien fallengelassen hat, ist diese Bedingung erfüllt.

Check 2 (Zeilen 341–342): Das dumpable-Flag des Prozesses muss SUID_DUMP_USER (1) sein. Wenn ein Prozess seine UID/GID gewechselt hat, setzt der Kernel dumpable automatisch auf SUID_DUMP_DISABLE (0) — als Schutz davor, dass Restzustand-Daten (Private Keys, Hashes) aus dem Memory-Bild extrahiert werden.

Der Bug: Wenn mm == NULL ist (Zeile 341 — der erste Konjunkt der if-Bedingung), wird der gesamte dumpable-Check übersprungen, und der Code fällt direkt auf die LSM-Hook in Zeile 346. Bei Default-YAMA (ptrace_scope=1) und Angreifer als Parent-Prozess erlaubt die LSM-Hook das ptrace — und damit ist der Schutz weg, obwohl der Prozess früher root-Privilegien hatte.

Wann ist mm == NULL? — der do_exit()-Race

Der Kernel setzt task->mm = NULL in do_exit(), beim Aufräumen des sterbenden Prozesses:

896 void __noreturn do_exit(long code)
897 {
...
964         exit_mm();          // hier wird task->mm = NULL gesetzt
...
971         exit_files(tsk);    // hier wird task->files = NULL gesetzt
...
1019         do_task_dead();
1020 }

Das Race-Window sitzt zwischen Zeile 964 (exit_mm()) und Zeile 971 (exit_files(tsk)) — sieben Zeilen Code, in denen task->mm bereits NULL ist, aber task->files (das File-Descriptor-Tisch) noch existiert. Ein Angreifer, der den Ziel-Prozess in dieses Zeitfenster pusht und parallel pidfd_getfd() ruft, kann offene File-Descriptors aus dem sterbenden Prozess in seinen eigenen FD-Tisch übernehmen.

pidfd_getfd() als Werkzeug-Pfad

Der Syscall-Pfad sieht laut Qualys-Advisory so aus:

947 SYSCALL_DEFINE3(pidfd_getfd, int, pidfd, int, fd, unsigned int, flags)
948 {
...
964         return pidfd_getfd(pid, fd);
}

910 static int pidfd_getfd(struct pid *pid, int fd)
911 {
...
920         file = __pidfd_fget(task, fd);
}

872 static struct file *__pidfd_fget(struct task_struct *task, int fd)
873 {
...
881         if (ptrace_may_access(task, PTRACE_MODE_ATTACH_REALCREDS))
882             file = fget_task(task, fd);
}

1123 struct file *fget_task(struct task_struct *task, unsigned int fd)
1124 {
....
1128         if (task->files)
1129             file = __fget_files(task->files, fd, 0);
}

Die Gating-Funktion ptrace_may_access() in Zeile 881 ruft __ptrace_may_access() auf — exakt die Funktion mit dem Bug. Wenn der Race greift, gibt die Funktion fälschlicherweise „access allowed“ zurück, und fget_task() in Zeile 1128 sieht task->files noch als nicht-NULL (weil das erst sieben Zeilen später passiert) und liefert den File-Pointer zurück. Aus Sicht des Angreifers: der File-Descriptor des privilegierten Prozesses landet im eigenen FD-Tisch.

Der konkrete Race-Tanz

Der Exploit-Pfad in vier Schritten (am Beispiel chage):

1. Angreifer startet das set-uid-Target (z. B. chage -l self). Das Target öffnet /etc/shadow als shadow-Group-User (Zeile 776 im chage-Source), dann ruft es setregid(rgid, rgid) plus setreuid(ruid, ruid) (Zeilen 778–779), um seine Privilegien fallenzulassen.
2. SIGKILL. Sofort nach dem Privileg-Drop schickt der Angreifer SIGKILL an den chage-Prozess. Der Kernel beginnt den do_exit()-Pfad.
3. Tight Loop von pidfd_getfd(). Während chage durch exit_mm() läuft, calle der Angreifer in einer engen Loop pidfd_getfd(pidfd, target_fd) gegen chage's PID. Der Loop ist auf eine effektive Trefferquote ausgelegt — das Race-Window ist klein, aber durch wiederholte Versuche praktisch immer gewinnbar.
4. FD übernommen. Sobald der Race trifft (task->mm == NULL, task->files != NULL), liefert pidfd_getfd() den /etc/shadow-FD in den Angreifer-FD-Tisch. read(fd) liest die Datei — als unprivilegierter User.

Bei ssh-keysign: identisches Pattern, aber gegen die /etc/ssh/*_key-FDs. Wichtig: ssh-keysign öffnet die Keys vor dem Check auf EnableSSHKeysign (das standardmäßig disabled ist); der Bug greift trotzdem.

Bei pkexec und accounts-daemon: gleicher Pfad, aber das übernommene File-Descriptor ist eine bereits authentifizierte dbus-System-Bus-Connection (mit SCM_CREDENTIALS als root). Der Angreifer schickt darüber org.freedesktop.systemd1.Manager.StartTransientUnit an systemd (PID 1) und führt arbiträre Commands als root aus.

Pumpkin-Chang-Trick: allow_active-Bypass für pkexec

Der pkexec-Exploit sieht auf den ersten Blick aus, als verlangte er, dass der Angreifer physisch an der Konsole sitzt (PolicyKit's allow_active-Regel im org.gnome.settings-daemon.plugins.power.policy). Qualys verweist auf Pumpkin Chang's Blog-Post „dbus-and-polkit-introduction“ (Mai 2025): wer per systemd-run --user einen weiteren Prozess innerhalb der eigenen User-Session startet und darin den Exploit ausführt, kann die allow_active-Prüfung umgehen. Der Angreifer kann also auch über SSH eingeloggt sein, solange ein realer Konsolen-User in derselben Session existiert (tty1 mit eingeloggtem User). Damit wird der pkexec-Pfad in der Praxis deutlich breiter exploitable, als die allow_active-Bedingung suggeriert.

Ubuntu-Ausnahme bei accounts-daemon

Qualys schreibt explizit: „Ubuntu is notably not [exploitable for accounts-daemon] because it enables the Yama ptrace protection by default (it sets kernel.yama.ptrace_scope to 1)“. Die Logik: bei accounts-daemon ist der Angreifer nicht der Parent — accounts-daemon läuft als PID-1-systemd-gestarteter Daemon und wird vom Angreifer per dbus-Request adressiert. YAMA ptrace_scope=1 erlaubt ptrace nur gegen Child-Prozesse oder explizit per PR_SET_PTRACER autorisierte. Damit blockt YAMA den accounts-daemon-Pfad auf Ubuntu, nicht aber die anderen drei Targets (chage, ssh-keysign, pkexec), wo der Angreifer das Target selbst startet und damit Parent ist.

Fedora-SELinux-Ausnahme — und der SetPassword-Workaround

Auf Fedora blockt SELinux den org.freedesktop.systemd1.Manager.StartTransientUnit-Pfad aus accounts-daemon heraus. Qualys hat einen Alternativ-Pfad dokumentiert: statt eine transient Unit zu starten, schickt der Angreifer einen org.freedesktop.Accounts.User.SetPassword-Request über die gestohlene dbus-Connection. Damit setzt sich der Angreifer das Passwort eines lokalen Admin-Users (z. B. john) — und meldet sich anschließend per su -l john als dieser User an, dann sudo -i zu root. SELinux greift hier nicht, weil der Request innerhalb der erlaubten accounts-daemon-Operationen liegt.

Disclosure-Timeline (Qualys-Original)

2026-05-11   Advisory + PoC privat an security@kernel
2026-05-14   Patch commit 31e62c2 von Linus Torvalds — gleichzeitig
             Heads-up an private linux-distros@openwall
2026-05-15   Heads-up an public oss-security@openwall
             (Tag, an dem ein unabhängig entwickelter Exploit aus
             dem Public-Patch im Umlauf erschien — Embargo-Bruch)
2026-05-20   Volles Advisory publiziert

Der Zeitraum zwischen 14.05. (Public-Patch) und 20.05. (Volles Advisory) ist das Fenster, in dem die Distributions ihre Pakete gebaut haben — und in dem unabhängige Researcher den Patch lesen und den Exploit reproduzieren konnten. Das ist die übliche Reibung zwischen koordinierter Disclosure und der Realität, dass öffentliche Patches immer rückrechnenbar sind.

Wer ist betroffen?

Praktisch jede Linux-Distribution mit einem Kernel ab v4.10 (November 2016) bis zu den Patch-Versionen vom 14.–21. Mai 2026. Das umfasst die letzten neun Jahre Enterprise-Linux-Geschichte — die historische Exposition ist erheblich, auch wenn das öffentliche Bekanntwerden auf den Mai-Tagen 2026 sitzt.

Verteilungs-Tabelle

Qualys hat das Advisory explizit gegen fünf Default-Installationen verifiziert und schreibt zu allem anderen: „other distributions may also be exploitable“. Die Tabelle macht den Unterschied transparent:

Welche Stack-Schichten konkret?

• Container-Images:Nicht direkt patchbar — Container nutzen den Host-Kernel. Der Schutz liegt auf dem Host.
• Container-Hosts: Bare-Metal-Hosts, VMs, EC2-Instances, Hetzner-Cloud-Server, Azure-VMs — alles betroffen, alles patchbar über die Distribution.
• Kubernetes-Worker-Nodes: Direkt betroffen. Worker-Node-Image-Refresh durchs Cluster.
• Managed Kubernetes (EKS/AKS/GKE): Worker-Nodes laufen auf Provider-AMIs/Images. Patch über Image-Refresh-Rollout.
• CI/CD-Self-Hosted-Runner: Besonders kritisch. Build-Runner werden routinemäßig von untrusted Build-Steps (z. B. Pull-Request-Builds aus Forks) benutzt — jeder dieser Builds ist ein potenzieller Local-Exploit-Vektor.
• Shared-Multi-Tenant-Hosts: Wo mehrere Kunden auf demselben Host shell-fähig sind (klassisches Shared-Hosting, manche Container-Hosting-Setups).

Wer ist nicht direkt betroffen?

• Reine Frontend-Apps ohne Shell-Zugang: Wenn der Host nie unprivilegierte lokale User mit Shell-Login akzeptiert (also: hardened Production-Server, auf den niemand über SSH einloggen kann außer Admin), fehlt der Eintrittsvektor. Aber: Container und CI-Runner mit beliebigen Build-Schritten gelten als „unprivilegierte lokale Shell“ für Kernel-Zwecke.
• Hosts mit kernel.yama.ptrace_scope=2: Diese Mitigation blockt den pidfd_getfd()-Vektor (siehe Mitigation-Sektion).

Auswirkungen

Local-Only, aber severe. Die Schwere-Einschätzung „local“ ist hier irreführend wenn sie als „niedrige Priorität“ verstanden wird. Konkret:

• /etc/shadow-Disclosure: Alle Login-Passwort-Hashes des Systems werden lesbar. Mit modernen GPU-Cracking-Toolchains (hashcat, John the Ripper) sind schwache Passwörter innerhalb von Minuten gebrochen, mittlere innerhalb von Tagen.
• SSH-Host-Key-Exfiltration: Wenn ein Angreifer den SSH-Host-Private-Key ausleitet, kann er als dieser Host gegenüber jedem SSH-Client auftreten, der den public-Key bereits in known_hosts hat. Das öffnet MITM-Pfade ohne weitere Vorwarnung.
• Root-RCE über dbus-Kapern: Voller Root-Zugang auf dem Host. Anschließend: Container-Breakout durch direkten Zugriff auf /proc/*/root, namespace-escape, Persistenzmechanismen.
• Container-Multi-Tenant-Impact: Auf einem Container-Host mit mehreren Tenants reicht eine kompromittierte Pod-Instance, um den gesamten Host zu übernehmen — und damit auch alle anderen Pods auf diesem Host.

Die Grenze zwischen „unprivilegierter Foothold“ und „voller Host-Kompromittierung“ kollabiert. Ein gephishter Developer-Account, ein durchgerutschter CI-Build, ein Low-Privilege-Service-Account oder ein Multi-Tenant-Host werden zu Direkt-Pfaden zu root.

Wir sind nicht getroffen worden

Bei Moselwal-Kunden hat keiner unserer Container-Hosts oder Kubernetes-Worker-Nodes zum Stand 21.05.2026, 12:00 Uhr UTC eine kompromittierende Exploitation-Spur in den Audit-Logs. Das ist keine Glanzleistung — das ist der erwartete Output einer Continuous-Upgrade-Pipeline, die Distribution-Patches innerhalb von Stunden nach Verfügbarkeit ausrollt. Der wirkliche Stresstest kommt bei der nächsten 0-Day-Welle, wenn der Patch noch nicht verfügbar ist.

Mitigation und Sofortmaßnahmen

Drei Pfade, in Reihenfolge der Sauberkeit:

Pfad 1 — Distribution-Kernel-Patch einspielen

Der saubere Fix. Distribution-Updates sind seit dem 20./21. Mai verfügbar.

# Debian / Ubuntu
sudo apt update && sudo apt upgrade linux-image-generic linux-image-amd64

# Fedora / RHEL / AlmaLinux / Rocky / CloudLinux
sudo dnf update kernel kernel-core kernel-modules

# SUSE
sudo zypper update kernel-default

# Anschließend in allen Fällen
sudo reboot

Nach dem Reboot Verifikation: uname -r gegen die Distribution-Patch-Liste vergleichen.

Pfad 2 — Interim-Mitigation: kernel.yama.ptrace_scope=2

Wenn der Patch nicht sofort möglich ist (Wartungsfenster steht aus, Reboot blockiert), blockt diese Sysctl den Public-Exploit-Pfad sofort:

# Sofort wirksam, persistent ab nächstem Reboot
echo 'kernel.yama.ptrace_scope = 2' | sudo tee /etc/sysctl.d/99-yama-ptrace.conf
sudo sysctl -p /etc/sysctl.d/99-yama-ptrace.conf

Mechanismus: pidfd_getfd(2) wird über __ptrace_may_access(target, PTRACE_MODE_ATTACH_REALCREDS) gegated. Bei ptrace_scope=1 (Default) erlaubt die YAMA-LSM-Hook ptrace gegen Child-Prozesse — also auch gegen das selbst-gestartete set-uid-Binary. Bei ptrace_scope=2 verlangt YAMA explizit CAP_SYS_PTRACE, das ein unprivilegierter Angreifer nicht hat. Damit liefert pidfd_getfd()-EPERM zurück, unabhängig vom Kernel-Race im dumpable-Branch.

Operational Impact dieser Mitigation:

• Non-root-User können nicht mehr gdb -p, strace -p, perf record -p gegen Prozesse benutzen, die sie nicht selbst über PR_SET_PTRACER autorisiert haben
• Browser-Crash-Reporter-Sandboxes (Firefox, Chromium) verlieren ggf. einen Debugging-Pfad — beide handhaben das graceful
• Container-Debug-Funktionalität, kdump-Userspace-Helper, CRIU (Checkpoint and Restore in Userspace) können brechen
• ptrace_scope ist statistisch nicht-fallend: einmal hochgesetzt, lässt es sich zur Laufzeit nicht mehr runtersetzen. Erst ein Reboot resettet den Wert.

In Produktion-Container-Hosts ohne aktives Debug-Workflow ist ptrace_scope=2 aus unserer Sicht eine sinnvolle Default-Hardening-Maßnahme über die akute Lücke hinaus.

Pfad 3 — Credential-Rotation auf exposed Hosts

Wenn ein Host während des Exposure-Fensters untrusted lokale User akzeptiert hat, sind SSH-Host-Keys und lokal gecachte Credentials als potenziell disclosed zu behandeln:

# SSH-Host-Keys rotieren
sudo rm /etc/ssh/ssh_host_*_key /etc/ssh/ssh_host_*_key.pub
sudo ssh-keygen -A
sudo systemctl restart sshd

# known_hosts-Einträge auf Client-Seite invalidieren
# (Alle Maschinen, die per SSH auf den rotierten Host zugreifen, müssen
# die neuen Host-Keys akzeptieren — das ist eine Operations-Welle)

Für /etc/shadow: alle Lokal-Accounts mit non-trivialen Passwörtern erzwingen einen Password-Reset im nächsten Login. Bei externen Auth-Quellen (LDAP, SSSD, Active Directory) ist /etc/shadow weniger kritisch.

Detection und Prüfung

Welche Kernel-Version läuft?

uname -r
# Gegen die Stable-Kernel-Linien-Tabelle unten abgleichen,
# oder gegen die Distribution-Patch-Liste

Greg Kroah-Hartman hat sieben gepatchte Stable-Kernel-Linien gleichzeitig released (Quelle: LWN, 17.05.2026). Ihr uname -r-Output sollte gleich oder größer einer dieser Versionen sein:

Beispiel: ein Host mit 6.6.135-1-debian ist nicht gepatcht (135 < 139). Ein Host mit 6.6.139-1-debian oder höher ist gepatcht. Distributions fügen oft eigene Suffix-Strings hinzu (-1-debian, -generic, -aws), aber die numerische Patch-Komponente ist der Vergleichsanker.

Welcher ptrace_scope ist aktiv?

sysctl kernel.yama.ptrace_scope
# 0 = ptrace überall erlaubt (schlechtester Fall)
# 1 = nur gegen Child-Prozesse (Default auf Ubuntu/Debian, exploitable)
# 2 = nur mit CAP_SYS_PTRACE (Mitigation-Stufe für CVE-2026-46333)
# 3 = ptrace komplett deaktiviert (rare, sehr restriktiv)

eBPF-/Tetragon-Detection auf pidfd_getfd()-Aufrufe

Wenn Sie Tetragon (Cilium) oder ein eBPF-basiertes Monitoring im Stack haben, lässt sich der pidfd_getfd-Syscall pauschal auf Auffälligkeiten beobachten. Die folgende Tracing-Policy ist ein Skizzen-Vorschlag auf Basis der Qualys-Mechanik — nicht in Produktion gegen den Exploit verifiziert, weil Qualys den PoC-Code zurückgehalten hat. Vor dem Einsatz in eine eigene Validierungs-Umgebung übernehmen und gegen die laufenden legitimen Caller-Patterns abgleichen:

# tetragon-policy.yaml — Skizze, vor Produktiv-Einsatz validieren
apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: observe-pidfd-getfd
spec:
  kprobes:
    - call: "__x64_sys_pidfd_getfd"
      syscall: true
      args:
        - index: 0
          type: "int"   # pidfd
        - index: 1
          type: "int"   # targetfd
      selectors:
        - matchActions:
            - action: Post
              rateLimit: "5"

Im Telemetry-Pipeline-Output erscheinen pidfd_getfd-Aufrufe als individuelle Events. Legitime Caller im typischen Linux-Stack: containerd, systemd, dbus-broker, crun/runc, ggf. criu. Anomalien sind unprivilegierte Caller, die pidfd_getfd gegen einen Prozess mit anderer UID anwenden — das Pattern, das CVE-2026-46333-Exploits zeigen müssen.

Falco-Rule als Alternative

Ebenfalls ein Skizzen-Vorschlag, der die Qualys-Mechanik abbildet, aber nicht gegen den realen PoC verifiziert ist. proc.is_suid_descendant ist ein vorausgesetztes Macro, das in Standard-Falco-Rule-Sets gepflegt sein muss:

# Skizze — vor Produktiv-Einsatz gegen eigenes Falco-Macro-Set verifizieren
- rule: Suspicious pidfd_getfd against suid binary
  desc: Unprivileged process calling pidfd_getfd against a suid target
  condition: >
    evt.type = pidfd_getfd and
    evt.dir = > and
    not user.uid = 0 and
    proc.is_suid_descendant = true
  output: >
    Possible CVE-2026-46333 exploit attempt
    (user=%user.name uid=%user.uid command=%proc.cmdline target_pid=%evt.arg.pid)
  priority: CRITICAL
  tags: [process, kernel, ptrace, cve-2026-46333]

Audit-Subsystem als kostengünstige Variante

# /etc/audit/rules.d/cve-2026-46333.rules
-a always,exit -F arch=b64 -S pidfd_getfd -k cve-2026-46333-pidfd-getfd

# Reload und prüfen
sudo augenrules --load
sudo auditctl -l | grep cve-2026-46333
# Alerts in /var/log/audit/audit.log mit key=cve-2026-46333-pidfd-getfd

Betreiberempfehlung — Operativer Entscheidungsblock

Empfehlung nach Setup-Typ

Mittelstand — Single-Site-Container-Hosting auf einem Bare-Metal- oder VM-Host. Distribution-Update einspielen, Reboot planen. Bei einem Host ohne aktive untrusted Local-Users (also: nur Admin-SSH, keine Shell für externe Nutzer) ist die akute Exploit-Hürde höher, aber die langfristige Hygiene verlangt den Patch trotzdem.

Enterprise — Multi-Host-Container-Cluster. Rolling Image-Rebuild plus Worker-Node-Recyclierung. Auf Production-Hosts zusätzlich kernel.yama.ptrace_scope=2 als Default-Baseline für die Container-Host-Hardening-Linie. Im selben Wartungsfenster die SSH-Host-Keys rotieren, wenn der Host während der neunjährigen Exposure-Phase Shell-Zugang für externe Parteien hatte.

Kubernetes — managed oder self-hosted. Worker-Node-Image-Refresh ist der primäre Mitigation-Pfad. Bei managed Kubernetes (EKS, AKS, GKE) den Provider-Image-Refresh in der nächsten Node-Pool-Rotation einplanen. Bei self-hosted Karpenter-/Cluster-Autoscaler-Setups die AMI-Reference im NodeClass-Manifest auf die gepatchte Version pinnen und einen Drain-and-Replace-Cycle anstoßen.

Deklarative Stacks (NixOS, Talos, Flatcar). Image-Rebuild über das jeweilige Channel-Update.

Was wir bei Moselwal konkret getan haben

Seit dem Qualys-Advisory am 20.05.2026 nachmittags läuft bei Moselwal die Standard-Kernel-Patch-Welle, mit folgenden konkreten Schritten:

Host-Kernel-Patches auf den Container-Hosts ausgerollt. Der entscheidende Schritt für diese CVE ist nicht der Container-Image-Rebuild — Wolfi (FrankenPHP-Worker), Debian-Slim (TYPO3-/Sylius-Application) und Alpine (Auxiliary-Worker) sind allesamt Container-Images ohne eigenen Kernel und sind als Userland von der Lücke nicht direkt betroffen. Patchen mussten wir den darunterliegenden Host-Kernel der Container-Hosts und Kubernetes-Worker-Nodes (Debian/Ubuntu LTS unter den Containern, AKS-/EKS-Provider-AMIs auf den Managed-Cluster-Workern). Sobald die Distribution den Patch im Security-Repo veröffentlicht hat, hat Renovate (für die selbst-gemanagten Hosts) bzw. das Cluster-Operator-Pipeline (für die Managed-Kubernetes-Worker-Pools) die Host-Node-Replacement-Welle gestartet. Container-Image-Rebuilds liefen separat aus Hygiene-Gründen mit, ohne dass das für die akute CVE-Mitigation nötig gewesen wäre.

Rolling-Restart auf Bestandskunden-Container, priorisiert nach Exposure. Container-Hosts mit aktiven CI-Runner-Workloads (Pull-Request-Builds aus Forks, höchste Exposition) wurden zuerst neu gestartet. Production-Hosts ohne untrusted Shell-Zugang im normalen Rolling-Fenster. Die FrankenPHP-Worker-Restarts sind graceful, für die End-User unsichtbar.

kernel.yama.ptrace_scope=2 als Baseline-Hardening. Wir haben den Sysctl in unserer Container-Host-Image-Baseline gesetzt — nicht nur als CVE-Mitigation, sondern als langfristige Default-Hardening-Linie. Anwendungen, die ptrace-Operationen brauchen (sind in unserem Stack: keine), müssen explizit per PR_SET_PTRACER opt-in. Das ist eine Stack-Architektur-Entscheidung, die wir mit dieser CVE-Welle vorgezogen haben.

Audit-Pass über die Bestandskonfiguration. Skript läuft über alle Kunden-Hosts: welche Kernel-Version, welcher ptrace_scope-Wert, welche set-uid-Binaries existieren, welche dbus-System-Services laufen. Ergebnis fließt ins interne Audit-Log und in die nächste Wartungs-Routine.

Keiner unserer Kunden hatte zum Stand 21.05.2026, 12:00 Uhr UTC eine kompromittierende Spur in den Audit- oder Application-Logs.

Fazit

CVE-2026-46333 ist ein Kernel-LPE-Bug der schweren Sorte — neun Jahre alt, in praktisch jedem Linux-Stack der letzten halben Dekade, mit öffentlich zirkulierenden Exploits, mit vier dokumentierten Aufrufketten zu root und zu sensiblen Credentials. Das Race-Pattern im __ptrace_may_access()-Pfad ist nicht ein einzelner Schreibfehler — es ist eine logische Lücke, die durch das spätere pidfd_getfd() (2020) erst zur vollwertigen LPE-Kette wurde. Solche „dormant“ Bugs sind die ehrlichsten Kandidaten für künftige Forschungs-Sweeps: jeder neue Syscall, der Zugriffsentscheidungen über __ptrace_may_access() gateet, hat das Potenzial, alte Race-Fenster zu reaktivieren.

Bei Moselwal-Kunden mit Renovate-/Continuous-Upgrade-Pipelines sind die Distribution-Kernel-Patches seit der Nacht durch. Für Self-Hosted-Setups ohne Auto-Update-Pipeline gilt: Kernel-Patch und Reboot innerhalb 24 Stunden, oder zumindest kernel.yama.ptrace_scope=2 als Interim-Mitigation in der nächsten Stunde. Wer Self-Hosted-CI-Runner für Pull-Request-Builds aus Forks betreibt, gehört zur höchsten Prioritätsstufe — diese Klasse von Build-Workloads ist genau das Szenario, das die Lücke zur Massen-Bedrohung macht.

Über die akute Welle hinaus: ptrace_scope=2 ist aus unserer Sicht der bessere Default für Container-Host-Baselines. Production-Hosts brauchen keine offene ptrace-Schicht für unprivilegierte User. Wer das in seinen Hardening-Standards noch nicht eingezogen hat, kann diese CVE-Welle als Anlass nehmen — die Operational-Costs sind beherrschbar, der Schutz reicht über CVE-2026-46333 hinaus.

Die spannende Frage lautet nicht, ob in den nächsten Wochen weitere Kernel-LPE-Bugs auftauchen — die werden kommen. Die Frage lautet, ob die eigene Patch-Pipeline so eingespielt ist, dass der nächste Distribution-Kernel-Update über Nacht durchläuft, ohne dass jemand morgens davon wach werden muss.

Dieser Beitrag spiegelt unsere technische und strategische Einschätzung. Er ersetzt keine eigene Code-Review und keine Datenschutz-Folgenabschätzung, falls SSH-Host-Keys oder Credentials rotiert werden müssen.