CVE-2026-41489

High

Published: 11/05/2026(UTC)Translated: 15/06/2026(UTC)NVD NIST

Summary

Pi-hole, a DNS sinkhole system, has a vulnerability in shell scripts that perform file operations with root privileges without validating paths. An attacker with Pi-hole privileges can exploit this flaw to escalate privileges to root by manipulating SSH keys.

Risk Assessment

The organization may be exposed to local privilege escalation, potentially leading to unauthorized access to the system and malicious actions.

Recommendation

It is recommended to upgrade to Core 6.4.2 and FTL 6.6.1 to mitigate this vulnerability and review system configuration and permissions.

Other vulnerabilities in Pi-hole

CVE-2026-50130High
A vulnerability in Pi-hole versions 6.0 to 6.4.2 allows a user with code execution as the unprivileged pihole user to escalate privileges to root by replacing the /etc/pihole/logrotate file. The file is then processed by pihole-FTL-prestart.sh, which changes its ownership to root:root, and subsequently executed as root by the daily pihole flush cron, enabling arbitrary code execution with administrative privileges.

Original NVD description (English source)

Pi-hole is a DNS sinkhole that protects devices from unwanted content without installing any client-side software. From 6.0 to before Core 6.4.2 and FTL 6.6.1, two shell scripts executed as root by systemd (pihole-FTL-prestart.sh and pihole-FTL-poststop.sh) read the files.pid path from this config without validation and use it in privileged file operations (install and rm -f). By writing an arbitrary path into files.pid, an attacker with pihole privilege can cause root to delete and then recreate any file on the system outside the ProtectSystem=full-restricted directories, gaining write access to it. On a default Pi-hole installation this yields local privilege escalation to root via SSH authorized keys manipulation. If /root/.ssh/authorized_keys does not exist (default on fresh installs), only ExecStartPre is required. If the file exists, ExecStopPost deletes it first, and the same restart triggers both hooks in sequence. This vulnerability is fixed in Core 6.4.2 and FTL 6.6.1.