Pi-hole CVE-2026-119335

Requires the attacker to already possess code execution as the pihole service user (the account pihole-FTL runs as) - this is the hard prerequisite and matches PR:L. Given that foothold, the attacker writes a value beginning with a digit followed by a Bash arithmetic/array-subscript payload (e.g. '1+a[$(...)]') into /run/pihole-FTL.pid, which is created pihole:pihole at mode 0644 by the root-run pihole-FTL-prestart.sh hook and is therefore writable by that user. Execution as root is then gated on an administrator subsequently running any root-run (need_root) pihole subcommand - reloaddns, reloadlists, updateGravity, repair, updatePihole, uninstall, debug, flush, setpassword, checkout, networkflush or tail - which route through sudo and reach the vulnerable '[[ "$pid" -eq "-1" ]]' arithmetic check in getFTLPID. Limiting factors: no remote/unauthenticated path, affected versions are <= 6.4.3 (fixed in 6.5), and the trigger depends on a root-run pihole command occurring, though these are routine so the window is frequent.

This is a credible, prioritize-this-week local privilege escalation rather than an inflated high-CVSS issue. The CVSS 3.1 vector (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H = 7.8) is internally consistent with the mechanism: the attacker must already hold code execution as the unprivileged pihole service user (PR:L, AV:L), and from that foothold achieves full root (C:H/I:H/A:H). It is NOT remotely exploitable on its own - it is a second-stage escalation, realistically chained after compromise of the network-facing pihole-FTL daemon that runs as the same pihole user. No CISA KEV listing and no EPSS score were provided, so there is no evidence of active or widespread exploitation; status is therefore 'no public exploit identified' in the KEV sense, BUT the GHSA advisory contains a complete, end-to-end-verified working PoC (planting '1+a[$(id > /tmp/PWNED-ROOT-PROOF)]' and triggering it via 'pihole reloaddns'), so a functional public exploit demonstrably exists. The vuln.today priority of 'this_week' aligns with this: high impact and a trivial, reliable trigger, but gated behind an existing pihole-user foothold. A notable amplifier is that the root-side triggers (reloaddns, reloadlists, updateGravity, repair, updatePihole, uninstall, debug, flush, setpassword, etc.) are routine administrative commands, so the escalation fires during normal operations rather than requiring a rare event. Treat as a genuine priority for any host where the pihole user could be compromised, but note it is not a standalone remote threat.

An attacker who has already gained code execution as the unprivileged pihole user - for example by compromising the internet/network-facing pihole-FTL process, which runs as that same user - writes a crafted arithmetic payload such as '1+a[$(id > /tmp/PWNED-ROOT-PROOF)]' into the pihole-owned /run/pihole-FTL.pid file. The next time an administrator runs any root-level pihole subcommand (e.g. 'pihole reloaddns' after a list or config change), Bash evaluates the PID value in an arithmetic context, recursively expands the array subscript, and executes the embedded command substitution as root. A full, end-to-end-verified PoC for this is published in the GHSA-cf36-4hhc-8398 advisory.