Red Hat Issues Fix for Local Privilege Escalation Flaw in MRTG Monitoring Package
Red Hat published security advisory RHSA-2026:91644 on 28 October 2026, delivering a fix for the Multi Router Traffic Grapher (MRTG) package on Red Hat Enterprise Linux 9.6 Extended Update Support. The advisory addresses a single issue, CVE-2026-72694, described as a symlink-following chown in the MRTG daemon that permits local privilege escalation through manipulation of the PID file path. Red Hat Product Security has rated the update as Important. MRTG is a long-standing monitoring utility that polls traffic load on network links and renders HTML pages with PNG graphs, so it typically lives on monitoring and management servers rather than general-purpose workstations. The fixed package is mrtg-2.17.7-11.el9_6.1, shipped for x86_64, s390x, ppc64le and aarch64 across a wide set of long-life channels including RHEL 9.6 Extended Update Support, Server AUS, Update Services for SAP Solutions, the four-years-of-updates streams and Extended Life Cycle Support.
The weakness sits in how the MRTG daemon handles its process ID file. According to the advisory text, the daemon performs a change-of-ownership operation on a PID file path that can be influenced locally, and because that operation follows symbolic links, the privileged process can be redirected to act on a file it was never meant to touch. In the classic form of this flaw, an unprivileged local user who can place or control a symlink at the expected PID file location causes the daemon to transfer ownership of an arbitrary target file to an account the attacker controls, which is the stepping stone to full privilege escalation. Red Hat's errata does not publish proof-of-concept code, an exploitation walkthrough, or a CVSS base score in the advisory body itself, instead pointing readers to the CVE page and to Bugzilla record 2460973 for scoring and acknowledgements. What is clear from the published description is that the attacker needs an existing local foothold on the host running the MRTG daemon; this is not a remotely reachable flaw.
The practical significance lies in where MRTG tends to run. Network monitoring servers are often given broad visibility into infrastructure, hold SNMP community strings and device credentials in their configuration files, and are trusted by operations teams to a degree that end-user systems are not. A local-to-root escalation on such a host converts a modest compromise, a contractor shell or a hijacked service account into control of the monitoring fabric, with the stored credentials offering an obvious path to further movement. The breadth of affected channels is also notable: the same package has been released for EUS, AUS, E4S and Extended Life Cycle Support streams, which is where organisations park systems they cannot rebuild quickly, meaning affected hosts are disproportionately likely to be production monitoring boxes with long change windows. On current evidence the risk is latent rather than active. FIRST EPSS places the probability of exploitation of CVE-2026-72694 in the next 30 days at 0.1 percent, the advisory reports no in-the-wild activity, and the flaw is not listed in CISA's Known Exploited Vulnerabilities catalogue. The exposure is therefore an unpatched escalation primitive sitting on sensitive infrastructure, not an ongoing campaign.
Attack Surface
Server OS, System Management Service, Infrastructure
Tactics
Privilege Escalation, Defense Evasion
Techniques
- T1068 – Exploitation for Privilege Escalation
- T1548 – Abuse Elevation Control Mechanism
- T1222.002 – File and Directory Permissions Modification: Linux and Mac File and Directory Permissions Modification
SuperPRO's Threat Countermeasures Procedures
- Install mrtg-2.17.7-11.el9_6.1 or later on all RHEL 9.6 systems running MRTG, covering the x86_64, s390x, ppc64le and aarch64 builds shipped for Extended Update Support, Server AUS, Update Services for SAP Solutions, the four-years-of-updates streams and Extended Life Cycle Support; confirm with rpm -q mrtg after the transaction.
- Validate downloaded packages against the SHA-256 digests published in RHSA-2026:91644 before deployment, for example 9d3d4b70900421bd56eacd5fb3d7bf5fe0db389c1f19fcf649dd2ea6aa684e0f for mrtg-2.17.7-11.el9_6.1.src.rpm and 2a51a281abaab8d51160bad4204aa8facbf31d25cac45fe8078348ac02bdeef1 for the x86_64 binary RPM.
- Use the Red Hat Lightspeed patch analysis linked from RHSA-2026:91644 to enumerate every registered host still carrying a pre-2.17.7-11.el9_6.1 mrtg build, and apply the update using the procedure in Red Hat article 11258.
- Review the PIDFile and RunAsDaemon directives in /etc/mrtg/mrtg.cfg and ensure the PID file path resolves inside a root-owned directory such as /run/mrtg with mode 0755 or tighter, so unprivileged users cannot pre-create a symlink at that location.
- Run the MRTG daemon under a dedicated non-root service account and confine it with a systemd unit that sets ProtectSystem=strict, PrivateTmp=yes and NoNewPrivileges=yes, limiting what a successful chown redirection on the PID file can reach.
- Add an auditd watch on the MRTG PID directory, for example -w /run/mrtg -p wa -k mrtg_pidfile, and alert on symlink creation or chown syscalls targeting that path from non-root UIDs on monitoring servers.
- Inventory interactive and service accounts with shell access on MRTG monitoring hosts and rotate any SNMP community strings or device credentials stored in mrtg.cfg if local compromise of one of those hosts is suspected, since CVE-2026-72694 requires a local foothold to be useful.
