keraattin/cve-2026-35517Detection scripts for Pi-hole FTLDNS RCE (CVE-2026-35517) via newline injection, including Python scanner and Nmap NSE script for version-based vulnerability assessment.
A Remote Code Execution vulnerability in Pi-hole's FTLDNS engine (versions 6.0 through 6.5) allows an authenticated attacker to inject arbitrary dnsmasq configuration directives by embedding newline characters (\n) into the dns.upstreams API parameter. Since dnsmasq supports directives that execute shell commands, this newline injection directly translates to full command execution on the host system.
This isn't just a single bug, it's a class of injection that affects five different configuration parameters, all patched together in FTL v6.6.
| Field | Detail |
|---|---|
| CVE ID | CVE-2026-35517 |
| Vendor | Pi-hole Project |
| Product | FTLDNS (pihole-FTL) |
| Affected Versions | 6.0 to < 6.6 |
| CVSS v3.1 | 8.8 (High) |
| CWE | CWE-93 — Improper Neutralization of CRLF Sequences |
| Attack Vector | Network |
| Authentication | Required (Pi-hole admin/API access) |
| User Interaction | None |
| Published | April 7, 2026 |
| Patched In | FTL v6.6 (released April 3, 2026) |
| Discovered By | T0X1Cx |
| Related Advisories | GHSA-23w8-7333-p9fj, GHSA-wxhv-w77q-6qwp, GHSA-28g5-gg88-wh5m, GHSA-fqv2-qhfh-ghcj, GHSA-vfmq-jrx3-wv3c |
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:
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.
+------------------+ +------------------+ +------------------+
| Admin Panel | API/Web | FTLDNS Engine | Config Write | dnsmasq |
| (Web UI) | ---------> | (pihole-FTL) | ------------> | (DNS/DHCP) |
+------------------+ +------------------+ +------------------+
| |
Reads settings, Reads config,
writes to config serves DNS/DHCP
files on disk to network
When an admin changes the upstream DNS servers through the Pi-hole web UI or API, the flow is:
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:
# Normal input: "8.8.8.8"
# Generates:
server=8.8.8.8
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:
# Malicious input: "8.8.8.8\ndhcp-option=6,evil.dns.server"
# Generates:
server=8.8.8.8
dhcp-option=6,evil.dns.server
This alone would be concerning (DNS hijacking via DHCP option injection). But it gets worse.
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:
Step 1: Attacker authenticates to Pi-hole
(default creds, weak password, CSRF, compromised session)
Step 2: Attacker sends API request to update dns.upstreams:
POST /api/dns/upstream
{
"upstreams": ["8.8.8.8\n<malicious dnsmasq directive>"]
}
Step 3: FTLDNS writes the value to the dnsmasq config file
without sanitizing the newline
Step 4: The injected dnsmasq directive is parsed as a
legitimate configuration option
Step 5: Depending on the directive injected, the attacker achieves:
- DNS hijacking (redirect all DNS queries)
- DHCP poisoning (push malicious configs to clients)
- Command execution via dnsmasq's scripting capabilities
- File write to arbitrary paths
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 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:
| Advisory | Parameter | What It Controls |
|---|---|---|
| GHSA-23w8-7333-p9fj | dns.upstreams | Upstream DNS servers |
| GHSA-wxhv-w77q-6qwp | dns.hostRecord | Custom DNS host records |
| GHSA-28g5-gg88-wh5m | dns.cnameRecords | CNAME record mappings |
| GHSA-fqv2-qhfh-ghcj | dhcp.leaseTime | DHCP lease duration |
| GHSA-vfmq-jrx3-wv3c | dhcp.hosts | Static DHCP host assignments |
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.