monitoring-plugins EUVD-2026-50552

Exploitation requires three concurrent conditions: (1) the host must have the non-default kernel parameter fs.protected_symlinks=0 - on modern Linux distributions (RHEL 8+, Ubuntu 18.04+, Debian 10+) this defaults to 1, which blocks the attack entirely in sticky /tmp; (2) the attacker must have a local account that can write to /tmp and shares, or has been granted, access equivalent to the monitoring plugin's execution account; (3) the vulnerable migration code path must be reached, meaning the logfile check must be running for the first time post-upgrade from a pre-v6.0.0 version with a legacy state file absent from the secured per-user directory. The attack window closes after the first successful (or failed) migration attempt, making it a one-shot opportunity per affected logfile check instance. Root-level execution of the check (typical in Nagios/Icinga daemon deployments) is required for the symlink follow to produce privilege escalation impact.

The CVSS 4.0 score of 5.8 reflects several mitigating factors that together materially suppress real-world risk. Attack vector is local (AV:L), complexity is high (AC:H), the attack target requires a specific prerequisite (AT:P - the non-default fs.protected_symlinks=0 kernel setting), and low privileges are required (PR:L). On modern Linux distributions, fs.protected_symlinks defaults to 1 (enabled), which blocks unprivileged symlink attacks in world-writable sticky directories like /tmp - this single control eliminates the vulnerability on the vast majority of production hosts. The integrity impact is high (VI:H) because a root-run check would rename and then open the attacker's symlink target, but confidentiality is unaffected (VC:N) and availability impact is low (VA:L). No KEV listing and no public exploit code exists, making opportunistic mass exploitation implausible. This is a real but narrow local privilege escalation with integrity consequence, relevant primarily to environments that have explicitly disabled symlink protection or are running older kernels lacking it. Organizations running this plugin on non-hardened Linux hosts should patch; others face substantially reduced risk.

A local user who shares or has write access to the monitoring plugin account creates a symlink at /tmp/linuxfabrik-monitoring-plugins-logfile-<target>.db pointing to a sensitive root-owned file (e.g., /etc/shadow or a critical configuration file) on a host where fs.protected_symlinks=0. When the root-privileged Icinga or Nagios daemon next executes the logfile check for a v6.0.0 installation, os.rename() moves the symlink to the secured per-user directory and sqlite3.connect() opens it, overwriting or corrupting the target file with SQLite database content. No public exploit code exists, but the attack primitive is well-understood.