CVE-2026-35518: Pi-hole FTL Engine RCE Vulnerability

CVE-2026-35518 Overview

A Remote Code Execution (RCE) vulnerability has been identified in FTLDNS (pihole-FTL), the core engine that provides an interactive API and generates statistics for Pi-hole's Web interface. The vulnerability exists in the DNS CNAME records configuration parameter (dns.cnameRecords) and allows authenticated attackers to inject arbitrary dnsmasq configuration directives through newline character injection, ultimately achieving command execution on the underlying system.

Critical Impact

Authenticated attackers can achieve complete system compromise through command injection in the DNS CNAME configuration, potentially leading to full control of Pi-hole servers and lateral movement within networks.

Affected Products

• Pi-hole FTL versions 6.0 through 6.5
• FTLDNS (pihole-FTL) before version 6.6
• Systems running vulnerable Pi-hole deployments with API access

Discovery Timeline

• 2026-04-07 - CVE-2026-35518 published to NVD
• 2026-04-08 - Last updated in NVD database

Technical Details for CVE-2026-35518

Vulnerability Analysis

This vulnerability is classified as CWE-78 (OS Command Injection), where the Pi-hole FTL engine fails to properly sanitize user input within the dns.cnameRecords configuration parameter. The vulnerability stems from inadequate input validation that allows newline characters (\n) to be injected into configuration values. Since Pi-hole FTL uses dnsmasq as its underlying DNS server, attackers can leverage this injection point to append arbitrary dnsmasq directives that are subsequently executed by the system.

The attack requires authentication to the Pi-hole API, meaning an attacker must first obtain valid credentials or exploit another vulnerability to gain API access. However, once authenticated, the impact is severe—allowing complete command execution on the host operating system with the privileges of the FTL service.

Root Cause

The root cause of this vulnerability lies in insufficient input sanitization of the dns.cnameRecords configuration parameter. When processing CNAME record configurations, the FTL engine writes values directly to dnsmasq configuration files without properly escaping or filtering special characters, particularly newline sequences. This allows attackers to break out of the intended configuration context and inject arbitrary dnsmasq directives, including those that can execute system commands.

Attack Vector

The attack is network-based and requires low privileges (authenticated API access) with no user interaction needed. An authenticated attacker can craft a malicious API request to the Pi-hole FTL engine containing specially crafted CNAME configuration values with embedded newline characters. These characters allow the attacker to inject arbitrary dnsmasq configuration directives that are written to the configuration file. When dnsmasq reloads or restarts, the injected directives are processed, potentially executing system commands with the privileges of the dnsmasq/FTL process.

The attack flow typically involves:

1. Authenticating to the Pi-hole API
2. Sending a crafted request to modify dns.cnameRecords with embedded newline characters
3. Injecting malicious dnsmasq directives that execute system commands
4. Achieving code execution when the configuration is processed

For detailed technical analysis and proof-of-concept information, refer to the GitHub Security Advisory.

Detection Methods for CVE-2026-35518

Indicators of Compromise

• Unexpected newline characters or escape sequences in Pi-hole configuration files
• Unusual dnsmasq configuration entries not matching standard CNAME record formats
• Unexpected process execution originating from the FTL or dnsmasq service
• API requests containing encoded newline characters (%0a, %0d, \n, \r\n) in CNAME parameters

Detection Strategies

• Monitor Pi-hole API logs for requests modifying dns.cnameRecords with suspicious character patterns
• Implement file integrity monitoring on dnsmasq configuration files to detect unauthorized modifications
• Deploy network intrusion detection rules to identify API requests with newline injection attempts
• Review authentication logs for unusual API access patterns or credential usage

Monitoring Recommendations

• Enable verbose logging on Pi-hole FTL API endpoints to capture full request payloads
• Implement alerting for configuration file changes outside of normal administrative windows
• Monitor process execution chains to detect commands spawned by dnsmasq or FTL processes
• Track and alert on failed authentication attempts that may indicate credential brute-forcing prior to exploitation

How to Mitigate CVE-2026-35518

Immediate Actions Required

• Upgrade Pi-hole FTL to version 6.6 or later immediately
• Audit Pi-hole API authentication credentials and rotate if potentially compromised
• Review dnsmasq configuration files for any unauthorized or suspicious entries
• Restrict network access to the Pi-hole API to trusted management networks only

Patch Information

This vulnerability has been fixed in Pi-hole FTL version 6.6. The patch addresses the command injection vulnerability by implementing proper input sanitization for the dns.cnameRecords configuration parameter, preventing newline injection attacks. Users should upgrade to version 6.6 or later by following the standard Pi-hole update procedures. Detailed patch information is available in the GitHub Security Advisory.

Workarounds

• Implement network segmentation to restrict API access to trusted administrative networks only
• Use a reverse proxy with input validation rules to filter requests containing newline characters
• Temporarily disable API access if not required for normal operations until patching is complete
• Enable authentication rate limiting to slow potential credential attacks that may precede exploitation

# Restrict Pi-hole admin interface access via firewall
# Example using iptables to limit access to management VLAN
iptables -A INPUT -p tcp --dport 80 -s 192.168.1.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -j DROP
iptables -A INPUT -p tcp --dport 443 -s 192.168.1.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j DROP