CVE-2026-73974

CVE-2026-73974 is a medium-severity path traversal vulnerability in linuxfabrik-lib (pip), affecting versions < 6.1.0. It is fixed in 6.1.0.

Does this CVE actually affect you?

Kodem shows which CVEs are reachable and running in your applications, so you fix what's exploitable, not just what's listed.

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Runtime intelligence, not another scanner.

Summary

linuxfabrik-lib: Arbitrary root file read via live --test argument (lib.lftest) across sudoers-whitelisted plugins (LPE)

Every Linuxfabrik check plugin that supports the shared --test argument (routed through lib.lftest.test()) will, when --test is supplied, treat the first CSV element as a filesystem path and read its full contents as the plugin's simulated STDOUT, running as root when the plugin is invoked through the shipped nagios/icinga sudoers allowlist. --test is a live production argument (centrally mapped to argparse.SUPPRESS, so it is hidden from --help but still accepted on the command line), not a build-time-only gate. This yields an arbitrary root file-read primitive (full disclosure on deb-updates; filtered disclosure / existence-and-readability oracle on ~22 other whitelisted plugins), i.e. local privilege escalation from the nagios account to root.

Root Cause

  • lib.lftest.test(args) (lftest.py lines 659-664): stdout = args[0]; if stdout and os.path.isfile(stdout): _, stdout = disk.read_file(stdout). Element[1] (stderr channel) is read the same way. There is no path confinement on the supplied path.
  • check-plugins/deb-updates/deb-updates: --test is registered with type=lib.args.csv (lines 78-82). When supplied, control flows to stdout, _, retc = lib.lftest.test(args.TEST) (line 143), bypassing the apt path (if args.TEST is None: at 121). Each returned line is stored as a package row and, under the default --query='1' (WHERE 1, matches all rows), every row is printed via '\n* '.join([row['package'] ...]) → lib.base.oao(...).
  • The same --test/lib.lftest.test() mechanism exists identically on ~22 whitelisted plugins (e.g. docker-info), each performing a root open()/read of the attacker-named path. Disclosure degree varies by each plugin's downstream parser: full (deb-updates), filtered (docker-info echoes lines containing warning:/error:; openvpn-client-list echoes CLIENT_LIST lines), or existence/readability oracle (JSON parsers).

Proof of Concept

Full disclosure (deb-updates):

sudo /usr/lib64/nagios/plugins/deb-updates --test=/etc/shadow,,0

Filtered disclosure / oracle (docker-info, target routed to the stderr channel that gets echoed):

sudo /usr/lib64/nagios/plugins/docker-info --test="dummy,/etc/shadow,0"

Attack Chain

  1. Entry: sudo /usr/lib64/nagios/plugins/deb-updates --test=/etc/shadow,,0
    • Action: the nagios user invokes the whitelisted plugin as root with a --test CSV whose element[0] is the target path and retc=0.
    • Guard: sudoers (Debian.sudoers:3) lists the binary only; --test is not gated to test builds.
    • Bypass proof: CONTRIBUTING.md documents --test as centrally mapped to argparse.SUPPRESS, hidden from --help but still accepted on the command line; lib.args.csv splits /etc/shadow,,0 into ['/etc/shadow','','0'].
  2. Sink: lib.lftest.test(args.TEST) (deb-updates:143) reads element[0] as a file, as root.
    • Guard: none, no path confinement on element[0].
    • Bypass proof (from lib source): lftest.py:661-664: stdout = args[0]; if stdout and os.path.isfile(stdout): _, stdout = disk.read_file(stdout), element[0], if it exists on disk, is opened and its contents returned as stdout. retc=0 (element[2]) so there is no early cu() abort.
  3. Store + query: each line → lib.db_sqlite.insert(conn, {'package': item}, ...); default QUERY='1' → SELECT * FROM deb_updates WHERE 1.
    • Guard: --only-critical or a restrictive --query would filter, but both default to permissive (ONLY_CRITICAL=False, QUERY='1').
    • Bypass proof: attacker passes neither → all rows selected.
  4. Disclosure: msg += '\n* '.join([row['package'] for row in result]) → lib.base.oao(...) → stdout.
    • Guard: none.
    • Bypass proof: with len(result) > 0 the branch prints every row (every file line).
  5. Impact: full contents of any root-readable file disclosed to the nagios user → root. On the ~22 other --test plugins the same primitive yields a filtered leak / universal root file existence-and-readability oracle.

Bypass Evidence

  • lib.lftest.test() file-read behavior verified directly from linuxfabrik-lib source (lftest.py:659-664, disk.read_file(stdout) when os.path.isfile(stdout)).
  • --test registration (type=lib.args.csv) and the stdout, _, retc = lib.lftest.test(args.TEST) call verified on the latest release tag v6.0.0 at check-plugins/deb-updates/deb-updates:143 (GitHub contents API); default QUERY='1' confirmed.
  • No path-confinement guard exists on the --test path element in either the plugin or lib.lftest.

Affected Versions

<= 6.0.0 (latest release; --test/lib.lftest.test() flow present on tag v6.0.0). Not covered by any existing advisory (none reference --test or arbitrary file read).

Impact

An attacker controlling the low-privilege nagios/icinga account (the documented threat model for the shipped sudoers file, same precondition as CVE-2026-52817) obtains the full contents of any root-readable file via deb-updates (e.g. /etc/shadow, /root/.ssh/id_*, TLS keys, cloud credentials), plus a fleet-wide root file existence/readability oracle and filtered content leak via the other plugins → local privilege escalation to root.

Input manipulates file paths to reach files outside the intended directory, such as configuration or credential files. Typical impact: unauthorized file read or write outside the intended directory.

CVE-2026-73974 has a CVSS score of 5.5 (Medium). The vector is requires local access, low privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (6.1.0); upgrading removes the vulnerable code path.

Affected versions

linuxfabrik-lib (< 6.1.0)

Security releases

linuxfabrik-lib → 6.1.0 (pip)

Kodem intelligence

Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.

Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.

Already deployed Kodem?

See it in your environmentNew to Kodem? Get a demo →

Remediation advice

Compile --test out of production builds (or gate it behind an explicit build/dev flag so it is not accepted at runtime), OR confine the --test path element(s) to a dedicated fixtures directory via realpath() + containment check before disk.read_file(). As defense-in-depth, constrain the sudoers entries to specific argument values so --test cannot be supplied to a root-run plugin.

Reported by zx (Jace)

Frequently Asked Questions

  1. What is CVE-2026-73974? CVE-2026-73974 is a medium-severity path traversal vulnerability in linuxfabrik-lib (pip), affecting versions < 6.1.0. It is fixed in 6.1.0. Input manipulates file paths to reach files outside the intended directory, such as configuration or credential files.
  2. How severe is CVE-2026-73974? CVE-2026-73974 has a CVSS score of 5.5 (Medium). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
  3. Which versions of linuxfabrik-lib are affected by CVE-2026-73974? linuxfabrik-lib (pip) versions < 6.1.0 is affected.
  4. Is there a fix for CVE-2026-73974? Yes. CVE-2026-73974 is fixed in 6.1.0. Upgrade to this version or later.
  5. Is CVE-2026-73974 exploitable, and should I be worried? Whether CVE-2026-73974 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
  6. What actually determines whether CVE-2026-73974 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
  7. How do I fix CVE-2026-73974? Upgrade linuxfabrik-lib to 6.1.0 or later.

Stop the waste.
Protect your environment with Kodem.

Get a personalized demo
Get a personalized demo