// LINUXNEWS.DE — LINUX & OPEN SOURCE
Zwei Sicherheitslücken mit öffentlichen Exploits
Zwei aktuelle Sicherheitslücken sollte man diese Woche im Auge behalten, denn für beide gibt es bereits öffentlich verfügbaren Exploit-Code, der die Ausnutzung deutlich vereinfacht.
Die erste Lücke steckt tief im Linux-Kernel, genauer gesagt, im Traffic-Control-Subsystem. Unter dem Namen pedit COW und der Kennung CVE-2026-46331 erlaubt sie es einem lokalen, unprivilegierten Nutzer, Root-Rechte auf betroffenen Systemen zu erlangen. Der Bug liegt in der Funktion tcf_pedit_act(), Bevor der Kernel Daten verändert, soll er eigentlich nach dem Copy-on-Write-Prinzip erst eine private Arbeitskopie anlegen, damit das Original und gemeinsam genutzte Speicherbereiche unangetastet bleiben.
Genau das schlägt hier fehl: Der Kernel berechnet, wie viel Speicher er kopieren muss, bevor er weiß, an welcher genauen Stelle er später tatsächlich schreiben wird. Bei bestimmten Bearbeitungsschritten stellt sich diese Stelle aber erst während der eigentlichen Verarbeitung heraus und liegt dann außerhalb des Bereichs, der vorab kopiert wurde. Der Schreibzugriff landet so versehentlich nicht in der sicheren, privaten Kopie, sondern direkt im gemeinsam genutzten Page-Cache – also in einem Speicherbereich, auf den auch andere Programme zugreifen.
Für die Ausnutzung müssen zwei Bedingungen erfüllt sein: Das Kernelmodul act_pedit muss ladbar sein, und unprivilegierte User-Namespaces müssen aktiv sein. Letztere geben einem Angreifer die Capability CAP_NET_ADMIN, die für den Trigger nötig ist. Genau diese Kombination findet sich häufig in Container-Umgebungen und auf Testsystemen.
Debian hat den Patch bislang nur für Trixie über den Security-Channel ausgerollt, Debian 11 und 12 gelten derzeit noch als verwundbar. Bei Ubuntu sind Versionen von 18.04 bis 26.04 betroffen, wobei Ubuntu 26.04 dank restriktiverer AppArmor-Profile für User-Namespaces zumindest in der Standardkonfiguration etwas besser dasteht. RHEL 8 bis 10 sind ebenfalls betroffen, wobei Red Hat die Schwere als Important einstuft. Falls der Patch bisher nicht verfügbar ist, lässt sich das Modul blockieren mit:
Alternativ können unprivilegierte User-Namespaces deaktiviert werden, was aber Rootless-Container und Browser-Sandboxing beeinträchtigen kann.
Die zweite Lücke betrifft libssh2, eine SSH-Bibliothek, die die meisten von uns nutzen, ohne es zu wissen. Sie steckt unter anderem in curl, Git, PHP und diversen Backup- und Firmware-Tools. Unter CVE-2026-55200 mit einem CVSS-Wert von 9,2 (kritisch) liegt der Fehler in der Funktion ssh2_transport_read(), die beim SSH-Handshake eingehende Pakete verarbeitet. Die Funktion verwarf zwar zu kleine Werte für das Feld packet_length, prüfte aber nie, ob der Wert eine Obergrenze überschreitet.
Das Tückische an dieser Lücke: Hier braucht es keinerlei Zutun des Opfers über das bloße Verbinden hinaus. Ein manipulierter SSH-Server kann auf verbindenden Clients Code ausführen – ganz ohne Anmeldedaten und ohne weitere Nutzerinteraktion. Wer also mit einem verwundbaren Tool eine Verbindung zu einem nicht vertrauenswürdigen oder kompromittierten SSH-Server aufbaut, kann sich schnell Schadcode einfangen.
Wie bei pedit COW ist auch hier mittlerweile Proof-of-Concept-Code (PoC) öffentlich, veröffentlicht im GitHub-Repository exploitarium, dessen Autor Exploits ohne vorherige koordinierte Offenlegung publiziert. Wichtig zur Einordnung: Auch wenn der PoC nicht komplett einsatzfähig ist, senkt er die Hürde für Angreifer spürbar.
Bis ein offizieller Patch vorliegt, hilft nur eingeschränkte Vorsicht: ausgehende SSH-Verbindungen auf vertrauenswürdige Server beschränken, Hostschlüssel konsequent prüfen und ein Auge auf ungewöhnlich große Pakete oder unerklärliche Client-Abstürze haben. Bitte auch prüfen, ob die jeweils genutzte Distribution ein Update für die anfällige Bibliothek libssh2 v1.11.1 oder älter bereitstellt. Prüfen könnt ihr das mit dpkg -l | grep libssh2 bei Debian und Derivaten oder mit rpm -q libssh2 auf RPM-basierten Distributionen. Da die Bibliothek a