LONDON (IT BOLTWISE) – Eine Lücke im Linux-Kernel-Data-Path von Open vSwitch mit der Bezeichnung OVSwrap (CVE-2026-64531, CVSS 7,8) kann auf vielen Standard-Setups Root-Rechte für lokale Nutzer ermöglichen. Der Angriff nutzt eine Speicherbeschädigung in der Flow-Verarbeitung, weil ein Sicherheits-Guard durch eine Änderung im Jahr 2025 entfernt wurde. Veröffentlicht wurde außerdem ein Proof-of-Concept mit vorgefertigten Daten für rund 800 x86-64 Kernel-Builds. Betroffene sollten vor allem gepatchte Vendor-Kernel einsetzen oder, falls Open vSwitch nicht zwingend gebraucht wird, das Modul per Modprobe blockieren.
Für die Praxis klingt die Meldung erst einmal nach einer typischen Kernel-Sicherheitslücke in einem Spezialpfad. Genau dort liegt aber die Besonderheit: OVSwrap betrifft nicht den User-Space-Daemon ovs-vswitchd, sondern den Kernel-Datapath von Open vSwitch. Dadurch fällt ein Teil der sonstigen „Entkopplung“ weg; der Angriff kann direkt in den Bereich vorstoßen, in dem Netzwerk- und Flow-Informationen verarbeitet werden. Benannt wird die Schwachstelle mit CVE-2026-64531, sie erhält einen CVSS-Score von 7,8 und trägt intern den Namen OVSwrap. Laut der Offenlegung durch den Sicherheitsforscher Asim Manizada wurde die Schwachstelle am 28. Juli 2026 bekannt gegeben.
Technisch betrachtet hängt das Szenario an zwei Voraussetzungen: Erstens muss der Kernel-Datapath von Open vSwitch auf dem System verfügbar sein, und zweitens müssen unprivilegierte User-Namespaces aktiviert sein. Der Kernweg verläuft über die Erstellung privater User- und Netzwerk-Namespaces per unshare -Urn. Im Rahmen dieses Namespace gewinnt ein normaler Nutzer CAP_NET_ADMIN innerhalb der abgegrenzten Umgebung und erreicht dann den verletzlichen Flow-Installationspfad. Zusätzlich kann es sogar reichen, dass das openvswitch-Modul „installiert, aber nicht geladen“ ist: Wenn das System den Generic-Netlink-Familiennamen auflösen muss, kann das Modul automatisch geladen werden. Wichtig ist dabei die Warnung, dass ein leeres lsmod-Ergebnis allein keineswegs bedeutet, die Umgebung sei sicher.
Für die Einordnung ist entscheidend, warum es überhaupt zu dem Fehler kommt. Open vSwitch speichert generierte Flow-Actions als Netlink-Attribute; das Feld nla_len ist nur 16 Bit breit und begrenzt damit einzelne verschachtelte Attribute auf 65.535 Byte. In der Vergangenheit existierte zwar bereits eine unsichere Zuweisung, allerdings blieb sie offenbar unterhalb der Wrap-Grenze, weil ein Gesamtlimit von 32 KiB auf den erzeugten Action-Stream eine kritische Größe verhinderte. Im März 2025 wurde dieses Limit entfernt, weil es zu unvorhersehbaren Ausfällen führte – inklusive Problemen in großen OpenStack-Setups. Die spätere technische Konsequenz: Der alte Truncation-Fehler blieb bestehen, aber die Abbruchbedingung war weg.
Der Angriff nutzt genau diese Mechanik aus. Ein Beispiel für den Ansatz ist eine CLONE-Action, die mit Hunderten conntrack-Unteraktionen gepackt wird. Auf x86-64 expandiert der Kernel jede dieser Unteraktionen auf 164 Byte; dadurch überschreitet der erzeugte verschachtelte Action-Block schnell die 65.535-Byte-Schwelle. Wenn OVS das Ergebnis anschließend in das 16-Bit-Längenfeld schreibt, „wrappt“ der Wert. Danach vertraut nachgelagerte Logik der scheinbar plausiblen Länge und setzt das Parsen deterministisch im gleichen zusammenhängenden Puffer fort – an der Stelle, an der vom Angreifer vorbereitete conntrack-Daten „wartend“ liegen. Manizada beschreibt das Ergebnis als Memory-Corruption mit „logic-bug-grade reliability“, also als einen Fehler, der mit hoher Planbarkeit ausnutzbar ist, ohne dass komplexes Heap-Grooming erforderlich wäre.
Damit ist klar, warum das veröffentlichte Material für Betreiber so relevant ist: Der Proof-of-Concept ist explizit destruktiv und zielt auf konkrete Privileg- und Persistenzschritte. In der veröffentlichten Kettenlogik kombiniert der Exploit drei Primitive aus dem Wraparound: einen Kernel-Pointer-Leak über eine gefälschte OUTPUT-Action, einen arbiträren Kernel-Read über eine gefälschte Tunnel-SET-Action sowie einen zielgerichteten Decrement-Effekt beim Teardown einer gefälschten tun_dst-Struktur. Mit diesen Schritten versucht der Code, die Zugangsdaten eines Prozesses zu finden und auf modernen Kernels schließlich fsuid und fsgid auf null zu setzen. Erfolgreich bedeutet hier nicht nur „root shell“, sondern auch das Anfassen relevanter Systemkonfigurationen, etwa über /etc/sudoers.d oder /etc/sudoers; zudem versucht der PoC, Prozesse und OVS-Zustand so zu hinterlassen, dass keine gefährliche, instabile Aufräumlogik getriggert wird.
Auch die Paket- und Distributionsebene ist in der Meldung konkret: Die PoC-Repo enthält vorbereitete Datensätze für ungefähr 800 exakte x86-64 Kernel-Builds und versucht Abdeckungen darüber hinaus über symbolbasierte oder BTF-basierte Ableitungen. In einer nicht erschöpfenden Testmatrix nennt man unter anderem AlmaLinux 9 und 10, Alpine 3.22 bis 3.24, Amazon Linux 2023, Arch, CentOS Stream 9 und 10, Debian 12 und 13, Fedora 42 bis 44, Gentoo, Kali 2026.1, Linux Mint 22.3, NixOS, openSUSE Tumbleweed, Pop!_OS, Rocky Linux 9 und 10 sowie Ubuntu 22.04 als mit Standard-Konfigurationen ausnutzbar. Bei Ubuntu 24.04 soll AppArmor den direkten Namespace-Weg blockiert haben, aber ein aa-exec-basiertes Fallback stellte die Erreichbarkeit wieder her; Ubuntu 26.04 hingegen blockierte den Pfad für unprivilegierte Nutzer, und erst das Deaktivieren der AppArmor-Namespace-Einschränkung machte die getesteten Systeme verwundbar. Für Amazon Linux 2, Debian 11, Rocky Linux 8 und Ubuntu 20.04 wird festgehalten, dass ältere Codepfade existieren und die Lücke über diesen Weg nicht ausgenutzt werden konnte.
Was Betreiber jetzt tun können, lässt sich aus der Veröffentlichung recht handfest ableiten. Laut Angaben ist der Upstream-Fix bereits in stabilen Trees ab dem 24. Juli verfügbar; die ersten genannten Upstream-Releases sind Linux 5.15.212, 6.1.178, 6.6.145, 6.12.97, 6.18.40 und 7.1.5. Für die Reihen 6.13 bis 6.17, 6.19 sowie 7.0 wird ausdrücklich gesagt, dass sie keine Upstream-Stable-Fixes mehr erhalten. Gleichzeitig reicht das allein nicht für die Risikoabschätzung, weil Distributionen Backports und Downstream-Änderungen einbauen; als „safer source of truth“ gilt deshalb der jeweilige Vendor-Tracker. Als schnelle Zwischenmaßnahme nennt die Veröffentlichung den Modul-Block über /etc/modprobe.d, etwa mit „install openvswitch /bin/false“. Wenn das Modul bereits im Speicher ist, muss ein Neustart bzw. ein kontrolliertes Entfernen folgen.
Bleibt noch die Absicherung auf Systemprinzip-Ebene: Das Deaktivieren von unprivilegierten User-Namespaces schließt zwar den konkreten lokalen Nutzerpfad, blockiert aber nicht automatisch Szenarien, in denen ein Angreifer bereits CAP_NET_ADMIN in einem von ihm kontrollierten Netzwerk-Namespace besitzt – etwa aus anderen Kompromittierungswegen. Laut Darstellung ist „Container-Richtung“ theoretisch erreichbar, aber im freigegebenen PoC nicht demonstriert. Zusätzlich erwähnt der Freigabestand ein Notfall-BPF-Guard für Umgebungen, die sowohl OVS als auch Namespaces aktiv halten müssen. Besonders kritisch wird es dann, wenn mehrere Nutzer oder untrusted Workloads denselben Host teilen: In so einem Modell kann ein einzelner zuvor kompomittierter Account zur Eintrittskarte werden, und OVSwrap macht daraus dann potenziell ein „ganzer Server“-Problem. Entscheidend ist daher, nicht nur auf eine einzelne Komponente zu starren, sondern das Zusammenspiel aus Kernel-Version, Namespace-Policy, Open-vSwitch-Load-Verhalten und Security-Controls in der konkreten Distribution zu prüfen.
Für die operative Umsetzung heißt das: Prüfen Sie, ob Open vSwitch in Ihrer Umgebung über den Kernel-Datapath genutzt wird, ob unprivilegierte User-Namespaces aktiv sind und welche Kernel-Revision Ihr Vendor bereits gepatcht hat. Gerade in heterogenen Cloud- oder Virtualisierungslandschaften entscheidet die Kombination aus „modul verfügbar“ plus „unprivilegierter Namespace-Traffic“ darüber, ob der Weg realistisch ist. Sobald der Vendor-Fix verfügbar ist, sollte er bevorzugt eingespielt werden; parallel kann der Modul-Block den Risikohebel sofort senken, falls Open vSwitch nicht zwingend gebraucht wird. OVSwrap zeigt damit exemplarisch, wie schnell ein Guard-Entfernen in historisch gewachsenen Codepfaden zum Sicherheitsproblem wird – und warum man stabile Limits und Parsing-Annahmen im Kernel auch dann ernst nehmen muss, wenn sie ursprünglich nur Stabilitätsfehler verhindern sollten.
💳 Amazon-Kreditkarte mit 2.000 Euro Limit bestellen!
🔥 Heutige Hot Deals bei Amazon: Bis zu 80% Rabatte!
🎉 Amazon Haul-Store für absolute Schnäppchenjäger!
- ★ 23-stufiges KI-Go-Training – Für Spieler mit Grundkenntnissen der Regeln – Entwickelt als intelligenter Trainingspartner passt sich die KI Spielern von 18K bis 9D an. Ideal für alle, die die Grundregeln bereits beherrschen und ihr Spiel verbessern möchten.
- IHR EMOTIONALER AI-BEGLEITER: Eiliko ist mehr als nur ein Anhänger, es ist ein charismatischer KI-Freund. Mit einem dynamischen LED-Bildschirm, der eine Vielzahl von animierten Gesichtern und Ausdrucksformen anzeigt, reagiert er auf Ihre Interaktionen mit einzigartiger Persönlichkeit und Charme.
- 【MEHR LEBEN FÜR DEINEN SCHREIBTISCH】 Lerne Eilik kennen – deinen kleinen Roboter-Freund mit Persönlichkeit. Mit liebevollen Animationen, ausdrucksstarken Reaktionen und spielerischen Interaktionen bringt Eilik mehr Freude in deinen Alltag. Ob auf dem Schreibtisch, im Büro oder am Nachttisch – Eilik wird schnell zu einem vertrauten Begleiter für besondere Momente.
- 【XL-Größe für gedeihende Pflanzen】Geben Sie Ihren Pflanzen den Raum, den sie verdienen! Unser verbessertes, großes 13,7 cm großes Design bietet Platz für Pflanzen mit einem Durchmesser von bis zu 8,9 cm und damit deutlich mehr Platz für Wurzelwachstum und Pflanzengesundheit im Vergleich zu kleineren, veralteten Modellen. Die Produktabmessungen betragen 13,6 x 13,6 x 13,2 cm und das Gerät wiegt nur 355 g.
- V28 Update - JETZT MIT NEUEN FUNKTIONEN! Als Reaktion auf das Ladeproblem von Loona haben wir das automatische Aufladen 2.0 verbessert. Diese Optimierung hilft Loona, die Ladewege in verschiedenen Szenarien zu erkennen und anzupassen, um die Erfolgsquote beim automatischen Aufladen zu erhöhen. Mobile Hotspots können sich mit Loona verbinden und überwinden WLAN-Einschränkungen, sodass Sie jederzeit und überall mit Loona interagieren können.
- Die besten Bücher rund um KI & Robotik!
- Die besten KI-News kostenlos per eMail erhalten!
- Zur Startseite von IT BOLTWISE® für aktuelle KI-News!
- IT BOLTWISE® kostenlos auf Patreon unterstützen!
- Aktuelle KI-Jobs auf StepStone finden und bewerben!
- Künstliche Intelligenz: Dem Menschen überlegen – wie KI uns rettet und bedroht | Der Neurowissenschaftler, Psychiater und SPIEGEL-Bestsellerautor von »Digitale Demenz«
Du hast einen wertvollen Beitrag oder Kommentar zum Artikel "OVSwrap: Linux-Open-vSwitch-Kernel-Lücke ermöglicht Root für lokale Nutzer" für unsere Leser?
#Sophos
#AmazonPrime
#Bestseller
Es werden alle Kommentare moderiert!
Für eine offene Diskussion behalten wir uns vor, jeden Kommentar zu löschen, der nicht direkt auf das Thema abzielt oder nur den Zweck hat, Leser oder Autoren herabzuwürdigen.
Wir möchten, dass respektvoll miteinander kommuniziert wird, so als ob die Diskussion mit real anwesenden Personen geführt wird. Dies machen wir für den Großteil unserer Leser, der sachlich und konstruktiv über ein Thema sprechen möchte.
Du willst nichts verpassen?
Du möchtest über ähnliche News und Beiträge wie "OVSwrap: Linux-Open-vSwitch-Kernel-Lücke ermöglicht Root für lokale Nutzer" informiert werden? Neben der E-Mail-Benachrichtigung habt ihr auch die Möglichkeit, den Feed dieses Beitrags zu abonnieren. Wer natürlich alles lesen möchte, der sollte den RSS-Hauptfeed oder IT BOLTWISE® bei Google News wie auch bei Bing News abonnieren.
Nutze die Google-Suchmaschine für eine weitere Themenrecherche: »OVSwrap: Linux-Open-vSwitch-Kernel-Lücke ermöglicht Root für lokale Nutzer« bei Google Deutschland suchen, bei Bing oder Google News!