• Quick Facts
• What is Pi-hole FTLDNS?
• Vulnerability Deep Dive
  • Understanding the Architecture
  • The Injection Point
  • From Newline to Shell — The Kill Chain
  • The Full Family — Five Injection Vectors
• Impact Analysis
• Affected Versions
• Who is at Risk?
• Detection
  • Python Scanner
  • Nmap NSE Script
  • Manual Version Check
• Indicators of Compromise
• Remediation
• References
• Author

Quick Facts

What is Pi-hole FTLDNS?

Pi-hole is one of the most widely deployed DNS sinkholes in the world. It sits on your network, handles DNS queries, and blocks ads and trackers at the DNS level before they ever reach your browser. It's used everywhere from single Raspberry Pi setups in apartments to enterprise deployments protecting thousands of devices.

FTLDNS (Faster Than Light DNS) is Pi-hole's core engine. It's a custom fork/wrapper around dnsmasq, the well-known DNS and DHCP server. FTLDNS handles:

• DNS query resolution and caching
• DNS-level blocking (the core Pi-hole function)
• DHCP server functionality
• Query logging and statistics
• The API that the web interface talks to

Here's the key detail: FTLDNS generates dnsmasq configuration files from user-supplied settings through its API. If you change the upstream DNS server in the Pi-hole admin panel, FTLDNS writes that value into a dnsmasq configuration file and restarts the service. That write path is where the vulnerability lives.

Vulnerability Deep Dive

Understanding the Architecture

When an admin changes the upstream DNS servers through the Pi-hole web UI or API, the flow is:

1. The web UI sends a request to the FTLDNS API with the new upstream DNS value
2. FTLDNS validates the input (or rather, fails to validate it properly)
3. FTLDNS writes the value into a dnsmasq configuration directive
4. dnsmasq is restarted and reads the new configuration

The Injection Point

The dns.upstreams parameter is intended to accept DNS server addresses like 8.8.8.8 or 1.1.1.1. FTLDNS writes these into the dnsmasq config as server= directives:

The problem: FTLDNS does not sanitize newline characters in the input. An attacker can inject \n to break out of the intended server= directive and inject entirely new configuration lines:

This alone would be concerning (DNS hijacking via DHCP option injection). But it gets worse.

From Newline to Shell — The Kill Chain

dnsmasq supports a configuration directive called dhcp-option that can reference external scripts, and more critically, it supports several directives that can execute commands in specific scenarios. The exploitation chain looks like this:

The key insight is that this isn't about exploiting a dnsmasq vulnerability, dnsmasq is working as designed. The vulnerability is that FTLDNS lets untrusted input bleed into the configuration file, turning a configuration management API into an arbitrary config injection point.

The Full Family — Five Injection Vectors

The researcher (T0X1Cx) discovered that the same newline injection pattern affects five different FTLDNS configuration parameters. This is a systemic issue — the code lacked input sanitization across the board:

Each of these parameters writes to dnsmasq configuration files, and each failed to sanitize newline characters. The fix in FTL v6.6 added proper input validation that rejects newline characters (and other control characters) across all configuration parameters.

Impact Analysis

On the Pi-hole host:

• Full command execution with the privileges of the FTLDNS process (typically root or pihole user)
• Since Pi-hole often runs on dedicated devices (Raspberry Pi) or as a privileged container, this frequently means root access
• File read/write access to the host filesystem
• Persistence via cron jobs, SSH keys, or modified system files

On the network (downstream impact):

• DNS hijacking — redirect all DNS queries to attacker-controlled servers
• DHCP poisoning — push malicious DNS, gateway, or NTP settings to all DHCP clients
• Man-in-the-middle positioning — by controlling DNS, the attacker can redirect traffic for any domain
• Credential harvesting — redirect authentication endpoints to phishing servers
• Malware distribution — redirect software update domains to serve malicious payloads

Risk amplification factors:

• Pi-hole is often the only DNS server on the network compromise it, and you control name resolution for every device
• Many Pi-hole installations use default or weak admin passwords
• Pi-hole instances are frequently exposed to the entire local network, not just admins
• CSRF attacks against the Pi-hole web interface could trigger exploitation without direct authentication

Affected Versions

To check your version:

Who is at Risk?

High risk:

• Pi-hole instances accessible from untrusted network segments
• Deployments using default or weak admin passwords
• Pi-hole exposed to the internet (surprisingly common on Shodan)
• Shared hosting environments where multiple users access the same network

Moderate risk:

• Pi-hole instances in well-segmented home networks with strong passwords
• Deployments behind VPN with multi-factor authentication

Lower risk (but still patch):

• Air-gapped or fully isolated Pi-hole instances
• Read-only or API-disabled deployments

Detection

Python Scanner

The Python script detects vulnerable Pi-hole instances through version-based analysis.

How it works:

1. Fingerprinting — Identifies Pi-hole via admin interface indicators (page content, headers)
2. API Version Query — Queries both Pi-hole v5 and v6 API endpoints for FTL version info
3. Version Comparison — Parses the FTL version string and checks against the vulnerable range (6.0 ≤ v < 6.6)
4. Related CVEs — If vulnerable, flags all five related newline injection advisories

No injection payloads are sent. The test is entirely read-only and safe.

Usage:

Options:

Example output:

Nmap NSE Script

Example Nmap output:

Manual Version Check

If you have SSH access to the Pi-hole host:

If the FTL version is between 6.0 and 6.5 (inclusive), you are vulnerable.

Indicators of Compromise

What to look for:

• Unusual dnsmasq configuration entries — Check /etc/dnsmasq.d/ and /etc/pihole/ for unexpected directives
• Modified upstream DNS settings — Verify your configured upstream servers haven't been changed
• Unexpected API calls — Review Pi-hole's query log and API access logs for configuration change requests
• Anomalous DNS behavior — Clients resolving domains to unexpected IP addresses
• New cron jobs or SSH keys — If the host has been compromised via command execution
• Process anomalies — Unexpected child processes spawned by dnsmasq or pihole-FTL

Commands to investigate:

Remediation

Immediate action - upgrade now:

If you can't upgrade immediately:

1. Restrict API access — Configure Pi-hole to only accept API connections from trusted IPs
2. Change the admin password — Use a strong, unique password: pihole -a -p
3. Network isolation — Ensure the Pi-hole admin interface is only accessible from a management VLAN
4. Disable remote API — If you only use the local web UI, restrict the API to localhost

Post-patch actions:

5. Audit DNS configuration — Review all dnsmasq config files for injected directives
6. Verify upstream servers — Confirm your DNS upstream settings are correct
7. Check for persistence — Look for unauthorized cron jobs, SSH keys, or modified system files
8. Review DHCP leases — If DHCP is managed by Pi-hole, verify lease configurations
9. Monitor DNS behavior — Watch for anomalous resolution patterns over the next few days

References

• GitHub Security Advisory — GHSA-23w8-7333-p9fj (dns.upstreams)
• GitHub Security Advisory — GHSA-wxhv-w77q-6qwp (dns.hostRecord)
• GitHub Security Advisory — GHSA-28g5-gg88-wh5m (dns.cnameRecords)
• GitHub Security Advisory — GHSA-fqv2-qhfh-ghcj (dhcp.leaseTime)
• GitHub Security Advisory — GHSA-vfmq-jrx3-wv3c (dhcp.hosts)
• Pi-hole FTL v6.6 Release Notes

Author

Kerem Oruç - Cybersecurity Engineer

• GitHub: @keraattin
• Twitter: @keraattin