Severity by source
CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:P/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Local nagios account required (AV:L/PR:L); symlink placement is straightforward with no race condition (AC:L); root write crosses privilege boundary (S:C); no confidentiality impact.
Primary rating from Vendor (https://github.com/Linuxfabrik/monitoring-plugins).
CVSS VectorVendor: https://github.com/Linuxfabrik/monitoring-plugins
Lifecycle Timeline
2DescriptionCVE.org
Summary
The SQLite databases are created at predictable (static) paths in /tmp. Any user can therefore create a symlink at these paths in /tmp pointing to arbitrary files. The monitoring scripts then follows these symlinks and then creates their database at the symlink target. This becomes really dangerous for the scripts which can be executed as root with sudo. With this, an attacker can write to abitrary paths.
PoC
The docker-stats check command here as an example. Because writing to /tmp is the default behaviour, the other check commands which use a SQLite database are also very likely affected.
# Create the symlink as nagios user
nagios@test-server:/tmp$ ln -s /root/nagios-was-here /tmp/linuxfabrik-monitoring-plugins-docker-stats.db
# Trigger the execution nagios user
nagios@test-server:/tmp$ sudo /usr/lib64/nagios/plugins/docker-statsCheck whether or not file was created.
root@test-server:/
# file /root/nagios-was-here
/root/nagios-was-here: SQLite 3.x database, last written using SQLite version 3046001, file counter 2, database pages 3, cookie 0x2, schema 4, UTF-8, version-valid-for 2Impact
In it's basic form, this vulnerbility can lead to a denial of service, impacting users who use the provided sudoers file and who didn't take any special precautions like systemd's PrivateTemp. It requires that an attacker already compromised the nagios account (which is quite a high barrier to be honest).
If any application on the server relies on a SQLite database, there are scenarios where this vulnerability allows for content in existing SQLite databases to be modified. An attacker could let the symlink point to an existing SQLite database and create in /tmp a specially-crafted SQLite Rollback Journal (.db-journal) or Write-Ahead-Log (.db-wal), which is then applied to the database.
Fix
A proposed fix would be to create a separate directory inside /tmp per user (e.g., /tmp/linuxfabrik-monitoring-plugins-{os.geteuid()}). After creating this directory (or using an already existing one), check the following:
# Use os.lstat() instead of os.stat() so we don't accidentally follow symlinks
dir_stat = os.lstat(TMP_DIR_PATH)
# Ensure the directory is a real dir and not a Symlink
if not stat.S_ISDIR(dir_stat.st_mode):
# abort the execution
sys.exit(1)
# Verify the owner
if dir_stat.st_uid != os.getuid():
# abort the execution
sys.exit(1)
# Verify the permissions
if (dir_stat.st_mode & 0o077) != 0:
# abort the execution
sys.exit(1)AnalysisAI
Arbitrary file write as root via symlink attack in Linuxfabrik Monitoring Plugins affects any deployment using the provided sudoers configuration. The monitoring plugins create SQLite databases at predictable, static paths under /tmp; an attacker who has already gained access to the nagios service account can pre-place symlinks at those paths, and when a monitoring script is subsequently invoked via sudo, it follows the symlink and writes a SQLite database to any attacker-chosen path on the filesystem. A proof-of-concept is included in the GitHub Security Advisory GHSA-r35r-fpx2-jgr4, and no CISA KEV listing or CVSS score has been assigned at time of analysis.
Technical ContextAI
The vulnerability class is CWE-377 (Insecure Temporary File), a well-understood TOCTOU weakness in which a program creates files in a shared, world-writable directory (/tmp) using predictable names without verifying that the path has not been redirected. The affected component is the linuxfabrik-lib Python package (CPE: pkg:pip/linuxfabrik-lib), which is the shared library underpinning the Linuxfabrik monitoring-plugins suite. Multiple check commands - including docker-stats and others that persist state via SQLite - use hardcoded paths of the form /tmp/linuxfabrik-monitoring-plugins-<check-name>.db. The root cause is the use of os.stat() (which follows symlinks) rather than os.lstat() when opening or creating the database file, combined with the absence of per-user subdirectory isolation. The sudo integration, provided by the project's own recommended sudoers file, elevates the monitoring scripts to run as root, transforming what would otherwise be a same-user file clobber into a cross-privilege arbitrary write primitive.
RemediationAI
The upstream-proposed fix is to replace the static /tmp/<plugin-name>.db path with a per-user subdirectory such as /tmp/linuxfabrik-monitoring-plugins-{os.geteuid()}, and to validate that directory using os.lstat() (not os.stat()) before use - confirming it is a real directory (not a symlink), is owned by the current effective UID, and has no world- or group-writable permissions (mode & 0o077 == 0). No patched release version has been confirmed at time of analysis; monitor https://github.com/Linuxfabrik/monitoring-plugins for a tagged release containing this fix. As an immediate compensating control, enable systemd's PrivateTemp=true for any service unit invoking these plugins - this gives each service a private /tmp namespace, eliminating the symlink attack surface entirely with no functional side effects for the plugins. Alternatively, administrators can remove or restrict the sudoers entries for affected check commands until a patched version is available; this eliminates the privilege escalation path at the cost of monitoring capability. Do not rely on /tmp sticky-bit restrictions alone, as the nagios user legitimately owns the symlink it creates.
An issue was discovered in Appsmith before 1.52. Rated critical severity (CVSS 9.8), this vulnerability is remotely expl
runc through version 1.0-rc6 (used in Docker before 18.09.2) contains a container escape vulnerability that allows attac
Netmaker makes networks with WireGuard. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no a
Unauthenticated remote code execution in Marimo ≤0.20.4 allows attackers to execute arbitrary system commands via the `/
The News & Blog Designer Pack - WordPress Blog Plugin - (Blog Post Grid, Blog Post Slider, Blog Post Carousel, Blog Post
Path traversal in JFrog Artifactory (CWE-22) enables an authenticated low-privilege user to write data outside the inten
Docker 1.3.2 allows remote attackers to execute arbitrary code with root privileges via a crafted (1) image or (2) build
Remote code execution in Gogs through 0.14.2 allows authenticated users (and unauthenticated attackers on default-config
Remote code execution in Flowise before 3.1.2 allows any authenticated user (or API caller with chatflow view/update per
Remote code execution in NocoBase Workflow Script Node (npm @nocobase/plugin-workflow-javascript) allows authenticated l
Docker Desktop Community Edition before 2.1.0.1 allows local users to gain privileges by placing a Trojan horse docker-c
Vasion Print (formerly PrinterLogic) Virtual Appliance Host prior to version 25.2.169 and Application prior to version 2
Same weakness CWE-377 – Insecure Temporary File
View allSame technique Denial Of Service
View allShare
External POC / Exploit Code
Leaving vuln.today
EUVD-2026-61490
GHSA-r35r-fpx2-jgr4