Pi-hole: arbitrary root file clobber / chmod / disclosure via updatecheck.sh cron following /etc/pihole/versions symlink
Affects Pi-hole Core 6.4.2 through 6.4.3, where the unprivileged pihole user can replace the versions file in /etc/pihole with a symlink. Fixed in 6.5.
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- How many real-world setups can hit the bug, from the vendor's advisory and CISA data. It does not know your setup.What do these mean? →
- Specific setups only
- Fix
- Fixed in 6.5
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
- Exploitation: none
- Automatable: no
- Technical impact: total
Summary
Pi-hole, a DNS sinkhole used to block unwanted content on networks, is affected in versions from 6.4.2 up to 6.5. A local user running as the pihole account could abuse a scheduled root task to erase or create arbitrary files on the system or make sensitive files readable by all users.
Summarized by anthropic/claude-haiku-5.5. Verify details against the original sources.
Read the original description
Pi-hole is a DNS sinkhole that protects devices from unwanted content without installing any client-side software. From 6.4.2 until 6.5, the root-run advanced/Scripts/updatecheck.sh cron job applies truncate -s 0 and chmod 644 to /etc/pihole/versions while following symbolic links in a directory owned by the pihole user. An attacker executing as pihole can replace that path with a symlink so the scheduled root operations truncate or create an arbitrary root-owned file, or race the operations so chmod makes a sensitive target world-readable without truncating it. This issue is fixed in version 6.5.
Timeline
- CVE published
- First seen by cve.now
- CISA SSVC assessment
Exploitation: none · Automatable: no · Technical impact: total
- Record last updated
Affected versions
- pi-hole pi-hole
From 6.4.2 · fixed in 6.5
References 6
Questions about CVE-2026-119336
What does this mean?
The updatecheck.sh script runs as root from daily and @reboot cron jobs. Because the pihole user owns /etc/pihole, it can replace the versions file with a symlink, causing root to truncate, change permissions on, or create root-owned files at arbitrary names. It can also make sensitive root-owned files world-readable. The attacker cannot choose the file contents.Source: github.com, github.com
Am I affected, and how do I check?
Pi-hole Core 6.4.2 through 6.4.3 is affected, with the issue introduced in 6.4.2 by commit ac370146. Pi-hole Core 6.5 fixes it. The version can be checked with the pihole -v command.Source: github.com, github.com
What should I do about it?
Upgrade Pi-hole Core to 6.5 or later.Source: github.com, github.com
Is it being exploited?
It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. No public exploit code is tracked.Source: cve.now feed data