CVE-2026-67433: Linuxfabrik Path Traversal Vulnerability

CVE-2026-67433 Overview

CVE-2026-67433 affects Linuxfabrik monitoring-plugins, a Python-based collection of monitoring plugins for Icinga, Nagios, and related monitoring systems. In version 6.0.0, the logfile check contains a legacy database migration routine that moves a predictable file from /tmp using os.rename(). A local user controlling the plugin account can plant a symbolic link at the predictable path. When the check runs as root, sqlite3.connect() follows the symlink, allowing the low-privileged user to influence a root-owned write operation. The flaw maps to CWE-59: Improper Link Resolution Before File Access.

Critical Impact
A local user controlling the plugin account can leverage a symlink attack on a predictable /tmp path to cause a root-run check to write through the attacker-controlled link.

Affected Products

Linuxfabrik monitoring-plugins version 6.0.0
The logfile check plugin containing the legacy state-database migration
Environments running the plugin under root via Icinga or Nagios schedulers

Discovery Timeline

2026-07-29 - CVE-2026-67433 published to NVD
2026-07-30 - Last updated in NVD database

Technical Details for CVE-2026-67433

Vulnerability Analysis

The logfile check plugin performs a one-time migration of a legacy state database from a predictable location under /tmp. The migration calls os.rename() on the source path, then opens the destination through sqlite3.connect(). Neither operation validates that the path components resolve to regular files owned by root. An attacker with write access to /tmp can pre-create a symbolic link at the predictable name. When the plugin executes with elevated privileges, the symlink is followed, and SQLite creates or writes a database file at the attacker-chosen target. The impact translates to arbitrary file write as root, constrained by the SQLite file format written at the target path.

Root Cause

The root cause is unsafe path handling in a privileged migration routine. The plugin trusts a predictable /tmp filename without checking file type, ownership, or link status prior to os.rename() and sqlite3.connect(). This pattern matches the classic symlink-following file operation flaw described by CWE-59. The maintainers addressed the issue by removing the legacy migration entirely rather than hardening the path handling.

Attack Vector

Exploitation requires local access with the plugin account's privileges and the ability to write to /tmp. The attacker plants a symlink at the predictable migration path pointing to a root-writable target. The next scheduled root-run execution of the logfile check triggers the rename and connect sequence, following the link. Attack complexity is high because the attacker must win a timing window tied to the check's scheduled execution.

text

// Patch excerpt from check-plugins/logfile/logfile
// Source: https://github.com/Linuxfabrik/monitoring-plugins/commit/6df1f574aa9dc6541e092f1ce482ecc1315cded0
 import lib.args
 import lib.base
 import lib.db_sqlite
-import lib.disk
 import lib.icinga
 import lib.time
 import lib.txt
 from lib.globals import STATE_CRIT, STATE_OK, STATE_UNKNOWN, STATE_WARN

 __author__ = 'Linuxfabrik GmbH, Zurich/Switzerland'
-__version__ = '2026060101'
+__version__ = '2026070701'

The fix drops the lib.disk dependency and the entire legacy state-DB migration block, closing the symlink-follow root write. See the GitHub Security Advisory GHSA-w2gg-hx6w-24w3 for full details.

Detection Methods for CVE-2026-67433

Indicators of Compromise

Symbolic links present in /tmp matching the legacy state database filename used by the logfile check plugin
Unexpected root-owned SQLite database files created outside the plugin's documented state directory
Audit records showing os.rename() or sqlite3.connect() operations from the logfile check targeting non-standard paths

Detection Strategies

Monitor process execution of the logfile check binary and correlate with file creation events under /tmp and root-writable directories
Enable Linux audit rules on /tmp for symlink and symlinkat syscalls initiated by the plugin account
Inspect installed versions of Linuxfabrik monitoring-plugins and flag hosts running version 6.0.0

Monitoring Recommendations

Alert when the plugin account creates symbolic links whose targets fall outside standard user-writable directories
Track file integrity for root-owned SQLite files that appear in unexpected locations after monitoring plugin execution
Review scheduled check output for sqlite3 operational errors that may indicate failed or successful symlink exploitation attempts

How to Mitigate CVE-2026-67433

Immediate Actions Required

Upgrade Linuxfabrik monitoring-plugins beyond version 6.0.0 to a build that includes the fix from commit 6df1f574
Restrict the plugin account so it cannot be controlled by untrusted local users, and avoid running the logfile check as root where possible
Audit /tmp for existing symbolic links that reference paths used by the plugin's legacy migration

Patch Information

The maintainers removed the legacy state-database migration in commit 6df1f574aa9dc6541e092f1ce482ecc1315cded0, bumping the plugin version from 2026060101 to 2026070701. Additional context is available in the GitHub Security Advisory GHSA-w2gg-hx6w-24w3.

Workarounds

Run the logfile check under a dedicated unprivileged account rather than root to remove the privilege differential the attack requires
Configure the plugin to use a private state directory owned by the plugin account with restrictive permissions instead of /tmp
Apply PrivateTmp=yes in the systemd unit that launches the monitoring agent to isolate /tmp per service

bash

# Example: enforce private /tmp for the monitoring agent service
sudo systemctl edit icinga2.service
# Add the following under [Service]:
# PrivateTmp=yes
sudo systemctl daemon-reload
sudo systemctl restart icinga2.service