Pi-hole EUVD-2026-114440

Requires pre-existing code execution as the specific unprivileged 'pihole' service account (which owns the 0755, non-sticky /etc/pihole directory) - obtained via a compromised pihole account or the separately-reported config→exec bugs; no Linux capability is needed. Affected versions are Core 6.4.2 up to (not including) 6.5. Exploitation relies on the root-run advanced/Scripts/updatecheck.sh updatechecker cron (daily and @reboot, default) performing truncate -s 0, chmod 644, and append on the fixed path /etc/pihole/versions without O_NOFOLLOW/--no-dereference. The deterministic primitives (truncating or creating an arbitrary root-owned file) need no race; the non-destructive disclosure variant (chmod 644 on the real target while truncate hits a decoy) requires winning a fork/exec timing race, which the reporter states succeeds reliably. fs.protected_symlinks does NOT mitigate this because /etc/pihole is not a world-writable sticky directory. LIMITING FACTORS: local access only, the specific pihole account, and dependence on the root cron running; the only complete fix is updating to 6.5.

This is a genuine local privilege-escalation primitive, but its real-world urgency is gated by a meaningful precondition rather than being mass-exploitable. The CVSS 3.1 vector (AV:L/AC:L/PR:L/UI:N/S:U, C:H/I:H/A:H = 7.8 HIGH) correctly reflects local access requiring existing low privileges specifically as the 'pihole' service account - not any local user and not a remote attacker. No CISA KEV entry is present in the input, so this is not confirmed actively exploited; EPSS was not provided, so exploitation-probability cannot be weighed. However, a detailed, working proof-of-concept - including shell steps and a Python inotify-based symlink-race script the reporter states succeeded in 100% of tests - is published directly in the official GHSA-xch2-4qxw-g5vj advisory and the fixing commit, so publicly available exploit code exists. The vuln.today Decision label is 'this_week', consistent with a patch-this-cycle priority rather than an emergency: the deterministic truncate/create-arbitrary-root-file primitive needs no race (AC:L), while the cleanest confidentiality outcome (making /etc/shadow world-readable without destroying it) requires winning a fork/exec race the reporter characterizes as trivially winnable. Note the single input Tag 'Information Disclosure' understates the issue: the primary impacts are integrity and availability (arbitrary root-owned file truncation/creation) with disclosure as one race-dependent outcome. Bottom line: a real priority for any multi-tenant or shared Pi-hole host where the pihole account could be compromised (e.g. via the separately-reported config→exec bugs), but the local + specific-account requirement keeps it below internet-facing critical issues.

An attacker who already has code execution as the unprivileged 'pihole' user (owning the non-sticky 0755 /etc/pihole directory) deletes /etc/pihole/versions and replaces it with a symlink pointing at a sensitive root-owned file such as /etc/shadow. When the root-run updatechecker cron fires (daily/@reboot, default), its truncate/chmod/append operations follow the symlink and act on the target; by racing the symlink swap so truncate lands on a decoy but chmod 644 lands on /etc/shadow, the attacker exposes the hashes for offline cracking and root escalation. A full working PoC, including the race script, is published in the GHSA advisory.