Pi-hole v6.5 Update: 6 Breaking Changes and How to Fix Them
The Pi-hole v6.5 update arrived October 17, 2026 — Core v6.5, FTL v6.8 and Web v6.6.1, with the Docker image tagged 2026.10.0 landing on October 18 — and if you run Pi-hole on a Raspberry Pi or in Docker, do not postpone it. The release fixes five high-severity vulnerabilities (CVSS up to 7.8), including a command-execution flaw.
But it ships six breaking behavior changes — refused symlinked databases, silently reset config values, a first-night history purge, a 404 on custom landing pages, a new certificate authority, and no more arpflush. Below: the safe update workflow, a symptom → cause → fix for each breakage, a verification checklist, and rollback steps — all verified against Pi-hole's official release announcement.
Why This Pi-hole v6.5 Update Can't Wait: 5 High-Severity CVEs
Five fixes are rated HIGH severity:
| Advisory | CVSS | What was fixed |
|---|---|---|
| GHSA-cf36-4hhc-8398 | 7.8 | Command execution via crafted PID — getFTLPID() now only accepts PIDs of a running pihole-FTL. |
| GHSA-mff6-cjc4-5wq9 | 7.3 | Root writing to config-supplied paths — gravity.sh re-executes as pihole; log flush writes as pihole. |
| GHSA-xch2-4qxw-g5vj | 7.8 | Root following symlinks when writing the version file — no root-created files in pihole-owned /etc/pihole. |
| GHSA-j8vh-6fp9-cjcx | 7.8 | /opt/pihole hardened — read-only for the FTL service. |
| GHSA-2h7g-g549-hf74 | 7.7 | FTL document-root relocation via Teleporter import or symlink. |
Four medium fixes ship too, plus a notable low — FTL now refuses cross-site browser requests and unrecognized Host names on passwordless installs.
Patch discipline isn't only a Pi-hole problem: a critical Nextcloud flaw is being actively exploited right now, and disabling the vulnerable Collabora app doesn't fix it — here's the update-or-remove playbook for CVE-2026-110447.
Step 0: Back Up With Pi-hole Teleporter First
Take a Teleporter backup first — your safety net for the pi-hole teleporter backup restore path. Settings → Teleporter → download, or from the CLI:
pihole-FTL --teleporterStore the archive off the Pi — not the SD card. It is your way home if the update goes sideways.
How to Update Pi-hole to v6.5
Bare Metal: pihole -up
On bare metal, one command — run after your Teleporter backup:
pihole -upGive it a few minutes: Core migrates gravity to schema 21 (WITHOUT ROWID junction tables, listsCache next to gravity.db), then FTL and the web UI restart. Do not interrupt it or trigger gravity from a second session — concurrent runs now return a 409 (Fix 6).
Docker: Update to the 2026.10.0 Image
For a pi-hole docker update, pull the new tag and recreate:
docker compose pull
docker compose up -dConfirm the container reports 2026.10.0. This pull-and-recreate pattern is the standard safe way to update any compose service — the same approach in our Immich machine learning V2 update guide.
If the dashboard stays down after the recreate and Pi-hole sits behind a reverse proxy, suspect the proxy: our Nginx 502 Bad Gateway in Docker fix guide covers container-networking failures that masquerade as app problems.
6 Things That Break After the Pi-hole v6.5 Update — and How to Fix Each
Fix 1: FTL Refuses Your Symlinked Database or Log File
Symptom: FTL warns on every start about your symlinked pihole-FTL.db or FTL.log — the SD-card wear trick of moving the database to external storage.
Cause: hardening. FTL no longer hands symlinks to the pihole user, and a link target must already be owned by pihole.
Fix: either make the target owned by pihole:
# Substitute the path your symlink actually points to
sudo chown pihole:pihole /path/to/your/pihole-FTL.dbOr drop the symlink: copy the real file back under /etc/pihole (/var/log/pihole for the log), delete the link, restart FTL, and confirm the warning is gone.
Fix 2: Invalid pihole.toml Values Silently Reset to Defaults
Symptom: a setting you configured long ago is back to its default — with no UI error.
Cause: FTL v6.8 resets invalid pihole.toml values to defaults. Triggers include database.DBinterval = 0, webserver.tls.cert below the webroot, a non-base32 webserver.api.totp_secret, relative paths for files FTL writes, files.tmp_db naming another Pi-hole file, and webserver.api.maxHistory above 86400. Bad list entries are dropped individually.
Fix: audit /etc/pihole/pihole.toml after updating and re-apply each value in valid form — absolute paths, valid base32 secrets, sane intervals. A setting that keeps resetting has a bad value, not a bad update.
Fix 3: Long-Term Query History Gone the Morning After
Symptom: next morning, months of query history are missing from long-term data.
Cause: by design. On the first night after a start on the new version, FTL deletes queries older than database.maxDBdays in batches of 10,000 — a database that kept growing loses its whole backlog. Intentional housekeeping, not corruption. (v6.8 also fixes the old log-flush bug that wiped history and shifted the graph a day forward.)
Fix: nothing to repair — but screenshot stats you care about before updating, and lower database.maxDBdays if you do not need years of history.
Fix 4: Custom index.html Landing Page Returns 404
Symptom: http://<your-pi-ip>/ shows a 404 where your custom index.html used to be.
Cause: with webserver.serve_all = false, / on any host other than webserver.domain returns 404. The file is still on disk — just no longer served at the bare IP.
Fix: set webserver.domain to your browse hostname, or set webserver.serve_all = true in /etc/pihole/pihole.toml and restart FTL.
Fix 5: Browsers Reject Pi-hole's HTTPS Certificate
Symptom: after the self-signed certificate renews, browsers and pinned clients throw certificate errors.
Cause: a renewed self-signed certificate ships with a new certificate authority, so clients trusting the old CA fail validation.
Fix: export the new tls_ca.crt from your Pi-hole server and re-import it on each pinning client, then update any automation pinning the old fingerprint.
Fix 6: arpflush Is Gone, and Gravity Returns 409
Symptom: anything referencing arpflush fails, and triggering gravity from two places at once returns HTTP 409.
Cause: the deprecated arpflush action was removed in favor of networkflush, and POST /api/action/gravity now answers 409 while a gravity run is in progress — a guard against concurrent database writes. Web v6.6.1 also makes the Query Log show the real API error instead of a generic network message, so the 409 now names itself.
Fix: swap arpflush for networkflush. If a pi-hole gravity failed report is really a 409, do not retry in a loop — wait for the running update to finish, then run gravity once.
Post-Update Verification Checklist
Run these in order after updating:
pihole statusConfirm FTL is running, then verify DNS resolves through Pi-hole — a blocked ad domain should return 0.0.0.0:
dig @127.0.0.1 doubleclick.netCheck the Query Log for live queries and confirm the footer shows Core v6.5 / FTL v6.8 / Web v6.6.1 (or 2026.10.0 in Docker).
If Pi-hole FTL failed to start after the update, run pihole -d and work from the actual error lines — it can upload a diagnostic report to the Pi-hole forums, and the official Pi-hole FAQ covers the common findings.
Planning another major upgrade? Our n8n 3.0 pre-upgrade triage maps every breaking change — removed nodes, the 60-second Code timeout, the npm-to-Docker migration — symptom by symptom, verified against the official docs.
How to Roll Back
If the fixes above do not help, roll back instead of fighting the install:
- Bare metal: import the archive from Step 0 via Settings → Teleporter → Restore.
- Docker: change the image tag from
2026.10.0back to your previous tag, thendocker compose up -d.
Keep two Teleporter archives — before and after — so you can move either direction. The official Pi-hole release notes are the source of truth for version changes.
FAQ
Is the Pi-hole v6.5 update safe to install?
Yes — it fixes five high-severity vulnerabilities including a command-execution flaw. Take a Teleporter backup first: the six behavior changes above can surprise an unprepared setup.
Why did my Pi-hole query history disappear after updating?
On the first night after the update, FTL deletes queries older than database.maxDBdays in batches of 10,000 — intentional housekeeping, not corruption.
Why does Pi-hole warn about my symlinked database?
FTL v6.8 hardening: it no longer follows symlinked database or log files, and the link target must be owned by the pihole user. Chown the target to pihole or move the file off the symlink (Fix 1).
Should I use pihole -up or update the Docker image?
Use pihole -up on bare metal (Raspberry Pi, other Linux boxes). In Docker, pull the 2026.10.0 image and recreate with docker compose up -d. Never mix the two paths.
What does the 409 error on gravity mean?
Another gravity run is already in progress. FTL returns HTTP 409 for concurrent gravity requests to protect the database — wait for it to finish, then run gravity once.
Why does my browser reject Pi-hole's certificate now?
A renewed self-signed certificate ships with a new certificate authority, so clients trusting the old CA fail validation. Re-import the new tls_ca.crt on each client (Fix 5).
Keeping the rest of the homelab current too? The Mastodon 5.0 beta upgrade guide applies the same backup-first discipline to self-hosted fediverse servers.
The same snapshot-first update discipline applies to today's php2shell PHP emergency — our php2shell patch playbook covers the fixed versions and the restart-every-worker rule most people miss.
Comments
Post a Comment