CVE-2026-72694: 
Linux Red Hat Analyse et atténuation des vulnérabilités

CVE-2026-72694 is a symlink-following (CWE-59) local privilege escalation vulnerability in MRTG (Multi Router Traffic Grapher). When the MRTG daemon is started as root and subsequently drops privileges, a local low-privileged attacker can pre-place a symbolic link at the PID file path, causing the root process to chown an arbitrary existing file to the daemon user, enabling privilege escalation. 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); RHEL 6 status is listed as unknown. The vulnerability was reported on April 23, 2026, and publicly disclosed on August 11, 2026, with a CVSS v3.1 base score of 7.1 (High) (Red Hat CVE, Red Hat Bugzilla).

The root cause is improper link resolution (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 privileges. The create_pid() function uses an unsafe -e existence check followed by a plain open(">$pidfile"), which does not guard against symlinks; if an attacker pre-places a symlink at the PID file path pointing to a sensitive root-owned file, the subsequent chown call follows the symlink and transfers ownership of the target file to the daemon user. A secondary TOCTOU (CWE-367) risk exists in the create_pid() check-then-open sequence. Exploitation requires local low-privileged access, a deployment where MRTG is started as root with --daemon, and the ability to influence or pre-place a symlink at the PID file path (Red Hat Bugzilla, Red Hat CVE).

Successful exploitation allows a local low-privileged attacker to change the ownership of an arbitrary root-owned file to the MRTG daemon user, resulting in high confidentiality and integrity impact. The attacker can subsequently read or modify sensitive files (e.g., /etc/shadow, SSH keys, or other privileged configuration files) that become accessible under the daemon user's ownership, potentially enabling full local privilege escalation to root. Availability is not directly impacted by the primary exploit primitive, though secondary effects from file modification could disrupt system services (Red Hat CVE, Red Hat Bugzilla).

There is no public proof-of-concept exploit code and no evidence of in-the-wild exploitation at the time of disclosure (Feedly). The vulnerability is not remotely reachable and requires local access with low privileges, limiting its attack surface. The EPSS score is approximately 0.00127 (0.127%), reflecting a low probability of exploitation in the near term. The CVE is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. The vulnerability was discovered by AISLE Research in partnership with Red Hat (Red Hat Bugzilla).

1. Reconnaissance: Identify a target system running MRTG as a daemon started with root privileges (e.g., via ps aux | grep mrtg or checking /etc/init.d/mrtg or systemd unit files for --daemon and a root start context).
2. Identify PID file path: Determine the PID file path used by MRTG, either from the --pid-file argument in the startup script or from the MRTG configuration file (default is typically /var/run/mrtg/mrtg.pid or similar).
3. Select a target file: Choose a sensitive root-owned file whose ownership transfer would enable privilege escalation (e.g., /etc/shadow, /etc/sudoers, or an SSH authorized_keys file).
4. Pre-place the symlink: Before MRTG starts (or after stopping and before restarting the service), remove any existing PID file and create a symlink at the PID file path pointing to the target file: ln -s /etc/shadow /var/run/mrtg/mrtg.pid.
5. Trigger MRTG startup: Wait for or trigger the MRTG daemon to start as root (e.g., at system boot or via a service restart if the attacker can influence it).
6. Exploit the chown: When MRTG starts, it calls chown($uid, $gid, $pidfile) as root, which follows the symlink and transfers ownership of the target file (e.g., /etc/shadow) to the MRTG daemon user.
7. Access or modify the target file: As the daemon user (or by leveraging the daemon user's access), read or modify the now-accessible sensitive file to escalate privileges (e.g., read /etc/shadow for password cracking, or write to /etc/sudoers to grant sudo access) (Red Hat Bugzilla).

• File System: Unexpected ownership changes on sensitive files (e.g., /etc/shadow, /etc/sudoers, SSH key files) to the MRTG daemon user (e.g., nobody, mrtg); presence of a symlink at the MRTG PID file path (e.g., /var/run/mrtg/mrtg.pid) pointing to a system file rather than being a regular file.
• Logs: System audit logs (/var/log/audit/audit.log) showing chown syscall events on sensitive files attributed to the MRTG process (PID owned by root); auditd records with type=SYSCALL and syscall=chown or lchown referencing unexpected file paths.
• Process: MRTG daemon process (mrtg) running with root effective UID during startup phase, followed by privilege drop — observable via /proc/<pid>/status showing Uid transition; unexpected chown calls in strace output of the MRTG startup process.

Red Hat has documented the following mitigations while a patch is under development (tracked in RHEL-189242 for RHEL 10.3): avoid starting the MRTG daemon as root with the --daemon option and instead configure MRTG to run directly as an unprivileged user from the start. 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 argument or config-derived PID path. The proposed code fix involves using sysopen with O_WRONLY|O_CREAT|O_EXCL flags for secure PID file creation, adding a symlink check via lstat, and deferring PID file creation until after privilege drop (Red Hat CVE, 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 prior to public disclosure on August 11, 2026. Red Hat has acknowledged the issue and filed a tracker for a fix in RHEL 10.3 (RHEL-189242). No significant broader media coverage or notable social media commentary has been identified at this time (Red Hat Bugzilla).