When a service runs with root privileges and constantly waits for requests from the outside, it's a worthwhile target — no matter how unassuming it looks. That's exactly the case with NetworkManager: CERT-Bund has published an advisory under the identifier WID-SEC-2026-2977 about a privilege escalation affecting RHEL/CentOS derivatives. If you're running a root server on this basis, it's worth taking a quick look now rather than burying the notice in your inbox.
- CERT-Bund reports a privilege escalation via NetworkManager under WID-SEC-2026-2977.
- According to the advisory, RHEL/CentOS derivatives are affected — including distributions like AlmaLinux, Rocky Linux, or CentOS Stream that share the same base.
- NetworkManager runs with root privileges and is active by default on many preinstalled server images, even if you've never consciously touched it.
- The CVE number, affected versions, and patch status are only in the original advisory — we link to it instead of summarizing it.
Why NetworkManager of all things
NetworkManager has been the standard component for network configuration on RHEL and its derivatives for years: DHCP, static IP addresses, VPN profiles, DNS settings — it all runs through it. It operates as a system service with full root privileges and is reachable via D-Bus for local processes. That exact combination — root privileges plus an interface that even less-privileged processes can talk to — is the classic breeding ground for privilege-escalation flaws: a local attacker or an already-compromised unprivileged process exploits a flaw in the processing to execute commands with the service's privileges — that is, as root. On many preinstalled RHEL-derivative images for root servers, NetworkManager is active out of the box, without you ever having selected it during setup.
A service that runs with root privileges and accepts requests from any local process is fundamentally a trust problem — not just a networking tool.
What the CERT-Bund advisory says — and what we deliberately won't repeat
Advisory WID-SEC-2026-2977 classifies the flaw as a privilege escalation via NetworkManager on RHEL/CentOS derivatives. Details like the exact CVE number, the CVSS score, and the precisely affected version ranges change with every update to the advisory — which is why we won't quote them here secondhand.
Who this affects
The advisory targets RHEL/CentOS derivatives. That includes not just Red Hat Enterprise Linux itself, but also the binary-compatible rebuilds that many root server operators run because they don't require a Red Hat subscription:
| Distribution | Relation to RHEL | NetworkManager by default? |
|---|---|---|
| Red Hat Enterprise Linux | Original | Yes |
| CentOS Stream | Upstream preview of RHEL | Yes |
| AlmaLinux | Binary-compatible rebuild | Yes |
| Rocky Linux | Binary-compatible rebuild | Yes |
If you're running Debian or Ubuntu instead, your system usually manages the network through different mechanisms. That said, NetworkManager can't be entirely ruled out there either — it occasionally gets installed alongside desktop or GUI packages on a server. A quick check doesn't hurt there either.
How to check your server
- Check whether NetworkManager is even installed and active on your server.
rpm -q NetworkManager systemctl is-active NetworkManager - Note the installed version so you can later compare it against the patch level given in the advisory.
rpm -q --qf '%{VERSION}-%{RELEASE}\n' NetworkManager - Update the package sources and install the update.
dnf makecache dnf update NetworkManager - On older systems without
dnf, useyuminstead.yum update NetworkManager - Restart the service so the new version actually becomes active.
systemctl restart NetworkManager - Check the network connection before you close your current SSH session.
ip a ping -c 3 <your-gateway>
Verifying that the update actually took
After the restart, it's worth taking a second look: compare the version number from step 2 with the new output of rpm -q NetworkManager. If it shows a higher version or release number, the update worked. In addition, systemctl status NetworkManager shows whether the service is running cleanly (status active (running)) or getting stuck in an error loop — in which case it's worth checking the logs.
journalctl -u NetworkManager -n 50Why this is on you with a rented root server
With a root server, there's no one in the background automatically updating packages for you — the responsibility for patching lies entirely with you. That's the same principle we already described when securing SSH access: root access means full control, but also full responsibility for maintenance. That privilege bugs in core components aren't rare was also shown recently by the authentication bypass in Proxmox VE 7, where attackers could log in as root without any password at all.
How to be faster next time an advisory drops
CERT-Bund advisories like this one aren't an isolated case — operators recently had to check their DNS servers after the BIND vulnerabilities, and the compromised Virtualizor update showed just how expensive waiting can get. Anyone who keeps an eye on CERT-Bund's WID advisories and updates package sources on their root servers regularly, instead of just once during setup, will already be ahead by the time the next advisory lands.
Five minutes with rpm -q NetworkManager and a look at the original advisory is no great effort — compared to what an overlooked privilege escalation can do on a production root server.
