Pi-hole v6.5, published on 17 October, is a patch-now security release for the DNS sinkhole many self-hosted networks run: it fixes four high-severity advisories and one low, all of them local privilege escalations that turn a foothold as the unprivileged pihole service account, or a file it owns, into root. None of the set is a remote, pre-authentication bug; the common thread is what the pihole account can reach on the root side of the same machine.
The advisories
Four high issues, as the project lists them. First, “command execution via a crafted PID”: the check added for the earlier CVE-2026-41489 fix matched only a value’s first character, so payloads beginning with a digit pass into a bash arithmetic context, where command substitution expands (CVSS 7.8). The root update checker truncates and chmods /etc/pihole/versions following symlinks, and the pihole user owns that directory, so it can point the path at any root-owned file, “root following a symlink when writing the version file” (CVSS 7.8, a regression introduced in v6.4.2). The FTL service carries an ambient CAP_CHOWN capability that elevates code execution in its context toward root, the oldest issue in the set, reaching back to v5.4 (CVSS 7.8). And gravity, run as root by the routine sudo pihole -g, chowns the parent directory of the path in files.gravity without validating it, so a pihole-owned setting can hand a directory like /etc/cron.d to the pihole user after one routine gravity update (CVSS 7.3). The low issue (CVSS 2.2): “the file:// adlist read check and curl could resolve different files”; local lists are now read as the user whose access was checked.
The fix and the hardening
Update with the standard pihole -up: every affected version is patched in 6.5; the ranges end at 6.4.3 except the CAP_CHOWN issue, which reaches back to v5.4. Beyond the direct fixes, the release de-privileges the same surfaces: gravity runs as the pihole user even when started as root, the update checker runs as pihole and trusts only git repositories that user cannot modify, and CAP_CHOWN is no longer granted to everything pihole-FTL executes, though it stays in the FTL service’s own ambient set. The gravity database migrates to schema version 21 on update (WITHOUT ROWID tables and new indexes, a performance change), /opt/pihole becomes read-only for the FTL service, and the deprecated arpflush command is removed in favor of networkflush.
My read
The class matters as much as the count: these are local escalations, not holes open to the internet, and each starts from the pihole account or a file it owns. In a household deployment, that account is what any weakness elsewhere in the stack eventually reaches, so the direction this release takes, dropping root from gravity and the update checker and tightening FTL’s capabilities, is the right one. But the set also argues for checking your version rather than assuming you are recent: one advisory reaches back to v5.4, and one of the fixes it lands exists because the previous fix could be bypassed.
Source: the Pi-hole v6.5 release notes and the published advisories.