CVE-2026-53759: Linuxfabrik lib Linuxfabrik Monitoring Plugins Allow Insecure Vulnerability

LOW
Advisory Identifier: GHSA-r35r-fpx2-jgr4
CWE-377
Published
Advisory Summary

CVE-2026-53759 is a LOW linuxfabrik monitoring plugins allow insecure vulnerability (CWE-377: Insecure Temporary File) affecting Linuxfabrik lib libraries in the PyPI ecosystem. The issue involves linuxfabrik monitoring plugins allow insecure creation of sqlite databases. Remediation is available by upgrading affected packages to version 4.2.0.

CVE-2026-53759 at a Glance

CVE Identifier CVE-2026-53759
GHSA Identifier GHSA-r35r-fpx2-jgr4
Severity LOW
CVSS v3.1 Base Score N/A
CWE Classification CWE-377: Insecure Temporary File
Affected Product Linuxfabrik lib
Package Ecosystem PyPI
Published Date
Last Updated

How to Fix CVE-2026-53759

To remediate this vulnerability, upgrade all affected Linuxfabrik lib dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

linuxfabrik-lib fixed: 4.2.0
pip install linuxfabrik-lib>=4.2.0
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

pip show linuxfabrik-lib

How to Check if You Are Affected

To determine whether your Python environment is affected by CVE-2026-53759, inspect your installed packages using pip:

pip show linuxfabrik-lib

Analyze the terminal output to locate any version of Linuxfabrik lib in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 4.2.0), your application is affected.

Note: The pip show linuxfabrik-lib command checks currently installed packages in your active Python environment.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-377: Insecure Temporary File, where creating and using insecure temporary files can leave application and system data vulnerable to attack. In Linuxfabrik lib, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

### 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-stats ``` Check 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 2 ``` ### Impact 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) ```

CVE-2026-53759 Affected Linuxfabrik lib Versions

1 component(s)
Fixed Versions:
4.2.0
Product / Package Ecosystem Affected Versions Fixed Version
linuxfabrik-lib
PyPI
< 4.2.0
4.2.0

References

Frequently Asked Questions

What is CVE-2026-53759?
CVE-2026-53759 is a security vulnerability in Linuxfabrik lib involving Linuxfabrik Monitoring Plugins allow insecure creation of SQLite databases under CWE-377: Insecure Temporary File.
Which Linuxfabrik lib versions are affected?
Affected versions include releases prior to 4.2.0 across affected packages: linuxfabrik-lib.
What version fixes CVE-2026-53759?
Upgrading to 4.2.0 (or the latest patched release for your respective branch) resolves the vulnerability.
Is linuxfabrik-lib affected?
Yes, linuxfabrik-lib is affected in releases prior to 4.2.0. Upgrade your dependency to 4.2.0 or later.
What CWE is associated with CVE-2026-53759?
CVE-2026-53759 is classified under CWE-377: Insecure Temporary File (Creating and using insecure temporary files can leave application and system data vulnerable to attack.).
How can I check PyPI dependencies for CVE-2026-53759?
Run the dependency tree command: 'pip show linuxfabrik-lib'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-r35r-fpx2-jgr4",
  "modified" : "2026-07-06T20:31:43Z",
  "published" : "2026-07-06T20:31:43Z",
  "aliases" : [ "CVE-2026-53759" ],
  "summary" : "Linuxfabrik Monitoring Plugins allow insecure creation of SQLite databases",
  "details" : "### Summary\nThe 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.\nThis becomes really dangerous for the scripts which can be executed as root with sudo. With this, an attacker can write to abitrary paths.\n\n### PoC\nThe 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.\n```\n# Create the symlink as nagios user\nnagios@test-server:/tmp$ ln -s /root/nagios-was-here /tmp/linuxfabrik-monitoring-plugins-docker-stats.db\n# Trigger the execution nagios user\nnagios@test-server:/tmp$ sudo /usr/lib64/nagios/plugins/docker-stats\n```\nCheck whether or not file was created.\n```\nroot@test-server:/# file /root/nagios-was-here\n/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 2\n```\n\n### Impact\nIn 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).\n\nIf 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.\n\n### Fix\nA 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:\n```\n# Use os.lstat() instead of os.stat() so we don't accidentally follow symlinks\ndir_stat = os.lstat(TMP_DIR_PATH)\n\n# Ensure the directory is a real dir and not a Symlink\nif not stat.S_ISDIR(dir_stat.st_mode):\n  # abort the execution\n  sys.exit(1)\n\n# Verify the owner\nif dir_stat.st_uid != os.getuid():\n  # abort the execution\n  sys.exit(1)\n\n# Verify the permissions\nif (dir_stat.st_mode & 0o077) != 0:\n  # abort the execution\n  sys.exit(1)\n```",
  "severity" : [ {
    "type" : "CVSS_V4",
    "score" : "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"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "PyPI",
      "name" : "linuxfabrik-lib"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "fixed" : "4.2.0"
      } ]
    } ]
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/Linuxfabrik/monitoring-plugins/security/advisories/GHSA-r35r-fpx2-jgr4"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/Linuxfabrik/monitoring-plugins"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-377" ],
    "severity" : "LOW",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-07-06T20:31:43Z",
    "nvd_published_at" : null
  }
}