What is the CVSS score of CVE-2026-41489?

CVE-2026-41489 has a CVSS 3.1 base score of 8.8 (High). CVSS vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H. EPSS exploitation probability: 0.0%.

Which versions of Pi-hole are affected by CVE-2026-41489?

Pi-hole versions 6.0-6.4.1 (Core) and 6.0-6.6.0 (FTL) contain a local privilege escalation vulnerability allowing users with pihole system account privileges to gain full root access.. A patch is available.

How to fix or mitigate CVE-2026-41489?

Within 24 hours, identify all systems running affected Pi-hole versions (Core before 6.4.2 or FTL before 6.6.1) and audit current SSH authorized_keys for unauthorized entries; restrict shell login capabilities for the pihole user account. Within 7 days, upgrade all affected installations to Pi-hole Core 6.4.2 or later and FTL 6.6.1 or later per vendor documentation. Within 30 days, verify all systems have been upgraded, re-audit SSH keys and logs for unauthorized access attempts, and review access control policies for the pihole account.

Pi-hole CVE-2026-41489

EUVD-2026-29295 HIGH

Incorrect Permission Assignment for Critical Resource (CWE-732)

2026-05-11 GitHub_M

Privilege Escalation Pi Hole

8.8

CVSS 3.1 · GitHub Advisory

Severity by source

GitHub Advisory PRIMARY

8.8 HIGH

AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H

vuln.today AI

8.8 HIGH

Local config-only vector (AV:L) needing existing pihole account (PR:L); low complexity; scope changes as pihole privilege escalates to root, yielding full C/I/A impact.

3.1 AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H

4.0 AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H

Primary rating from GitHub Advisory.

CVSS VectorGitHub Advisory

Attack Vector

Local

Attack Complexity

Low

Privileges Required

Low

User Interaction

None

Scope

Changed

Confidentiality

High

Integrity

High

Availability

High

Lifecycle Timeline

Analysis Generated

Jul 23, 2026 - 23:35 vuln.today

Patch available

May 11, 2026 - 22:18 EUVD

CVE Published

May 11, 2026 - 20:21 nvd

HIGH 8.8

DescriptionGitHub Advisory

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.

AnalysisAI

Local privilege escalation in Pi-hole (Core 6.0 through before 6.4.2, FTL through before 6.6.1) lets a user with pihole privileges gain root by injecting an arbitrary path into the unvalidated files.pid config value, which root-run systemd hooks (pihole-FTL-prestart.sh and pihole-FTL-poststop.sh) use in privileged install and rm -f operations. On a default install this enables root-level write access via SSH authorized_keys manipulation. SSVC rates technical impact as total, but there is no public exploit identified at time of analysis and EPSS is negligible (0.01%).

Technical ContextAI

Pi-hole is a self-hosted DNS sinkhole; FTL is its embedded DNS/DHCP resolver daemon (pihole-FTL) managed by systemd. The flaw is a CWE-732 (Incorrect Permission Assignment / trust of an untrusted-writable resource) issue: the systemd unit's ExecStartPre (pihole-FTL-prestart.sh) and ExecStopPost (pihole-FTL-poststop.sh) helper scripts run as root and read the files.pid path from Pi-hole's configuration without validating or canonicalizing it. Because a lower-privileged pihole account can write that config value, the attacker controls a path that root then feeds into install and rm -f. The systemd hardening ProtectSystem=full protects most system directories but leaves paths such as /root writable to these hooks, which is the pivot the exploit relies on.

RemediationAI

Vendor-released patch: upgrade to Pi-hole Core 6.4.2 and FTL 6.6.1 or later, which fix the unvalidated files.pid handling - apply both since the issue spans Core scripts and the FTL config parser; see the advisory at https://github.com/pi-hole/pi-hole/security/advisories/GHSA-6w8x-p785-6pm4. Where immediate patching is not possible, reduce exposure by tightly restricting who can obtain pihole privileges and write to the Pi-hole config (the files.pid value), and by monitoring the config for changes to files.pid pointing outside the expected runtime directory; as a hardening measure you can further constrain the pihole-FTL systemd unit (e.g. add ReadWritePaths/ProtectHome=true or a stricter ProtectSystem) so its root hooks cannot touch /root, with the trade-off that overly strict paths may break legitimate PID/socket file creation and require testing. Do not rely on network controls - this is a local escalation, so the priority is limiting local pihole account access.