Wenn ein Dienst mit Root-Rechten läuft und ständig auf Anfragen von außen wartet, ist er ein lohnendes Ziel – ganz gleich, wie unscheinbar er wirkt. Genau das trifft auf NetworkManager zu: CERT-Bund hat unter der Kennung WID-SEC-2026-2977 eine Meldung zu einer Rechteausweitung veröffentlicht, die RHEL/CentOS-Derivate betrifft. Wer einen Rootserver auf dieser Basis betreibt, sollte jetzt kurz nachsehen, statt die Meldung im Postfach zu vergraben.
- CERT-Bund meldet unter WID-SEC-2026-2977 eine Rechteausweitung (Privilege Escalation) über NetworkManager.
- Betroffen sind laut Meldung RHEL/CentOS-Derivate – also auch Distributionen wie AlmaLinux, Rocky Linux oder CentOS Stream, die denselben Unterbau nutzen.
- NetworkManager läuft mit Root-Rechten und ist auf vielen vorinstallierten Server-Images standardmäßig aktiv, selbst wenn du ihn nie bewusst angefasst hast.
- CVE-Nummer, betroffene Versionen und Patch-Stand stehen nur in der Original-Meldung – wir verlinken sie, statt sie zu verkürzen.
Warum ausgerechnet NetworkManager
NetworkManager ist auf RHEL und seinen Ablegern seit Jahren die Standardkomponente für die Netzwerkkonfiguration: DHCP, statische IP-Adressen, VPN-Profile, DNS-Einstellungen – alles läuft über ihn. Er arbeitet als Systemdienst mit vollen Root-Rechten und ist über D-Bus für lokale Prozesse erreichbar. Genau diese Kombination – Root-Rechte plus eine Schnittstelle, die auch weniger privilegierte Prozesse ansprechen können – ist der klassische Nährboden für Rechteausweitungs-Lücken: Ein lokaler Angreifer oder ein bereits kompromittierter unprivilegierter Prozess nutzt einen Fehler in der Verarbeitung, um Befehle mit den Rechten des Dienstes auszuführen – also als root. Bei vielen vorinstallierten RHEL-Ableger-Images für Rootserver ist NetworkManager von Haus aus aktiv, ganz ohne dass du ihn beim Setup ausgewählt hättest.
Ein Dienst, der mit Root-Rechten läuft und Anfragen von jedem lokalen Prozess entgegennimmt, ist im Kern ein Vertrauensproblem – nicht nur ein Netzwerk-Tool.
Was die CERT-Bund-Meldung sagt – und was wir bewusst nicht wiederholen
Die Meldung WID-SEC-2026-2977 ordnet die Lücke als Rechteausweitung über NetworkManager auf RHEL/CentOS-Derivaten ein. Details wie die genaue CVE-Nummer, der CVSS-Wert und die exakt betroffenen Versionsstände ändern sich mit jedem Update des Advisorys – deshalb zitieren wir sie hier nicht aus zweiter Hand.
Wen das betrifft
Die Meldung zielt auf RHEL/CentOS-Derivate. Darunter fallen nicht nur Red Hat Enterprise Linux selbst, sondern auch die binärkompatiblen Nachbauten, die viele Rootserver-Betreiber einsetzen, weil sie ohne Red-Hat-Abo auskommen:
| Distribution | Verhältnis zu RHEL | NetworkManager als Standard? |
|---|---|---|
| Red Hat Enterprise Linux | Original | Ja |
| CentOS Stream | Upstream-Vorstufe von RHEL | Ja |
| AlmaLinux | Binärkompatibler Nachbau | Ja |
| Rocky Linux | Binärkompatibler Nachbau | Ja |
Setzt du stattdessen Debian oder Ubuntu ein, verwaltet dein System das Netzwerk in der Regel über andere Mechanismen. Ganz ausschließen lässt sich NetworkManager dort trotzdem nicht – er wird gelegentlich nachinstalliert, etwa zusammen mit Desktop- oder GUI-Paketen auf einem Server. Ein kurzer Check schadet also auch dort nicht.
So prüfst du deinen Server
- Prüfe, ob NetworkManager auf deinem Server überhaupt installiert und aktiv ist.
rpm -q NetworkManager systemctl is-active NetworkManager - Notiere die installierte Version, damit du sie später mit dem Patch-Stand aus der Meldung abgleichen kannst.
rpm -q --qf '%{VERSION}-%{RELEASE}\n' NetworkManager - Aktualisiere die Paketquellen und spiele das Update ein.
dnf makecache dnf update NetworkManager - Auf älteren Systemen ohne
dnfnutzt du stattdessenyum.yum update NetworkManager - Starte den Dienst neu, damit die neue Version tatsächlich aktiv wird.
systemctl restart NetworkManager - Prüfe die Netzwerkverbindung, bevor du deine aktuelle SSH-Sitzung schließt.
ip a ping -c 3 <dein-gateway>
Prüfen, ob das Update wirklich sitzt
Nach dem Neustart lohnt sich ein zweiter Blick: Vergleiche die Versionsnummer aus Schritt 2 mit der neuen Ausgabe von rpm -q NetworkManager. Steht dort eine höhere Versions- oder Release-Nummer, hat das Update funktioniert. Zusätzlich zeigt systemctl status NetworkManager, ob der Dienst sauber läuft (Status active (running)) oder ob er in eine Fehlerschleife gerät – dann lohnt ein Blick in die Logs.
journalctl -u NetworkManager -n 50Warum das bei einem gemieteten Rootserver an dir hängt
Bei einem Rootserver gibt es niemanden, der im Hintergrund automatisch Pakete für dich aktualisiert – die Verantwortung für Patches liegt vollständig bei dir. Das ist derselbe Grundsatz, den wir schon beim Absichern des SSH-Zugangs beschrieben haben: Root-Zugriff bedeutet volle Kontrolle, aber eben auch volle Pflicht zur Pflege. Dass Rechte-Bugs in Kernkomponenten keine Seltenheit sind, zeigte zuletzt auch die Authentifizierungslücke in Proxmox VE 7, bei der sich Angreifer sogar ganz ohne Passwort als root anmelden konnten.
Wie du beim nächsten Advisory schneller bist
CERT-Bund-Meldungen wie diese sind kein Einzelfall – erst kürzlich mussten Betreiber nach den BIND-Sicherheitslücken ihre DNS-Server prüfen, und beim kompromittierten Virtualizor-Update zeigte sich, wie teuer Abwarten werden kann. Wer die WID-Meldungen von CERT-Bund im Blick behält und Paketquellen auf seinen Rootservern regelmäßig aktualisiert, statt nur einmal beim Setup, liegt bei der nächsten Meldung schon vorne.
Fünf Minuten mit rpm -q NetworkManager und einem Blick in die Original-Meldung sind kein großer Aufwand – im Vergleich zu dem, was eine übersehene Rechteausweitung auf einem produktiven Rootserver anrichten kann.
