CVE-2026-72694: 
Rocky Linux vulnerability analysis and mitigation

CVE-2026-72694 is a symlink-following (CWE-59) vulnerability in MRTG (Multi Router Traffic Grapher) that allows a local, low-privileged attacker to escalate privileges by manipulating the PID file path used during daemon startup. When the MRTG daemon is started as root and subsequently drops privileges, the root process performs a chown on the PID file path without safely resolving symbolic links, enabling an attacker who pre-places a symlink at that path to transfer ownership of an arbitrary file to the daemon user. Affected versions include the MRTG package as shipped in Red Hat Enterprise Linux 7, 8, 9, and 10 (confirmed in mrtg-2.17.10-12.el10). The vulnerability was reported on April 23, 2026, and publicly disclosed on August 11, 2026. It carries a CVSS v3.1 base score of 7.1 (High) (Red Hat Advisory, Github Advisory).

The root cause is improper link resolution before file access (CWE-59) in MRTG's daemon startup logic, specifically in bin/mrtg, bin/mrtg.socket6, and lib/mrtg2/MRTG_lib.pm. When started with --daemon as root, MRTG calls create_pid() to create the PID file and then immediately calls chown $uid, $gid, $pidfile to transfer ownership to the daemon user — all before dropping root privileges. The create_pid() function uses an unsafe -e existence check followed by a plain open(">$pidfile"), which does not detect or refuse symbolic links, introducing both a symlink-following chown primitive and a TOCTOU (CWE-367) race condition risk. An attacker with local access who can pre-place a symlink at the PID file path (e.g., in a world-writable directory) before MRTG starts can cause root to chown any arbitrary existing file to the daemon user. Exploitation requires: (1) local low-privileged access, (2) MRTG configured to start as root with --daemon, and (3) attacker ability to influence or pre-place a symlink at the PID file path (Red Hat Bugzilla, Red Hat Advisory).

Successful exploitation allows a local low-privileged attacker to change the ownership of any arbitrary file on the system to the MRTG daemon user, enabling unauthorized read and write access to sensitive root-owned files such as /etc/shadow, SSH keys, or service credentials. This constitutes a local privilege escalation with high confidentiality and integrity impact; availability is not directly affected. The scope is limited to the local system (no lateral movement via network), but ownership takeover of critical system files could enable further privilege escalation to full root access (Red Hat Advisory, Red Hat Bugzilla).

No public proof-of-concept exploit code is known to exist, and there is no evidence of in-the-wild exploitation as of the disclosure date (Red Hat Advisory). CISA's SSVC assessment (added August 12, 2026) classifies exploitation as "none" and the vulnerability as not automatable, though technical impact is rated "total" (Github Advisory). The EPSS score is approximately 0.127% (3rd percentile), indicating a low near-term exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. The vulnerability was discovered by "AISLE" in partnership with Red Hat (Red Hat Advisory).

1. Reconnaissance: Confirm that the target system runs MRTG in daemon mode started as root (e.g., check /etc/init.d/mrtg, systemd unit files, or ps aux | grep mrtg). Identify the configured PID file path (default or via --pid-file argument or config file).
2. Identify a writable location: Verify that the PID file directory is writable by the low-privileged attacker (e.g., /tmp, /var/run if world-writable, or a misconfigured custom path).
3. Select a target file: Choose a sensitive root-owned file whose ownership change would enable privilege escalation (e.g., /etc/shadow, /root/.ssh/authorized_keys, or a SUID binary).
4. Pre-place the symlink: Before MRTG starts (or after removing any existing PID file), create a symbolic link at the PID file path pointing to the target file:

   ln -s /etc/shadow /tmp/mrtg.pid

5. Trigger MRTG daemon startup: Wait for or trigger the MRTG daemon to start as root (e.g., at system boot, via a scheduled restart, or by inducing a service restart if the attacker has sufficient access).
6. Verify ownership change: After MRTG starts and calls chown on the PID path, confirm the target file's ownership has changed to the daemon user:

   ls -l /etc/shadow

7. Escalate privileges: With ownership of the target file transferred to the daemon user (or a user the attacker controls), read or modify the file to achieve privilege escalation (e.g., read /etc/shadow for password cracking, or write an SSH key to /root/.ssh/authorized_keys) (Red Hat Bugzilla).

• File System: Unexpected ownership changes on sensitive files (e.g., /etc/shadow, /root/.ssh/authorized_keys, SUID binaries) to the MRTG daemon user (e.g., mrtg, nobody); presence of a symbolic link at the MRTG PID file path (e.g., /var/run/mrtg.pid or /tmp/mrtg.pid) pointing to a sensitive system file.
• Logs: System logs (/var/log/secure, /var/log/auth.log, journalctl) showing MRTG daemon startup as root followed by unexpected chown operations; audit logs (auditd) recording chown syscalls by root on files outside the expected MRTG working directory.
• Process: MRTG daemon process (mrtg) started as root (UID 0) visible in process listings before privilege drop; unexpected access to sensitive files by the MRTG daemon user shortly after service startup.
• Audit Rules: Triggering of auditd rules monitoring chown/fchown syscalls on sensitive paths (e.g., -a always,exit -F arch=b64 -S chown -F path=/etc/shadow -k priv_esc) (Red Hat Bugzilla).

The primary mitigation is to avoid starting the MRTG daemon as root with the --daemon option; instead, configure MRTG to run directly as an unprivileged user from the start, eliminating the root-side chown primitive entirely. If root startup is strictly necessary, ensure the PID file and its parent directory are owned by root and not writable by unprivileged users, and prevent untrusted users from influencing the --pid-file path or config-derived PID path. A patch is available via Red Hat (tracked in Bugzilla 2460973 / RHEL-189242 for RHEL 10.3); the proposed code fix involves refusing symlinks in create_pid() using lstat() and creating PID files securely with sysopen(..., O_WRONLY|O_CREAT|O_EXCL, 0644), and deferring PID file creation until after privilege drop. Apply available security patches from Red Hat once released, and restart the MRTG service after any configuration changes (Red Hat Advisory, Red Hat Bugzilla).

The vulnerability was discovered by "AISLE Research" in partnership with Red Hat and reported through coordinated disclosure, with an embargo period observed before public disclosure on August 11, 2026 (Red Hat Advisory). Community aggregators including VulDB, Vulners, and Tenable (Nessus plugin 334497) indexed the vulnerability shortly after disclosure. No significant independent researcher commentary or broad media coverage has been identified beyond standard vulnerability database entries and automated security feeds.