Haydn Cowley

Write-ups

Responding to an NCSC alert the same day

The NCSC warned about two critical PHP flaws. My website doesn't use PHP, but one app on my Pi did.

2 min readBy Haydn
Goal
Work out if anything on my Pi was affected by the PHP warning, and deal with it
Result
Found and stopped the same day
Tools
Docker, PHP, Cloudflare WAF

What happened

On 21 October the UK's National Cyber Security Centre published a warning about two critical PHP flaws (CVE-2026-109618 and CVE-2026-109619). An attacker could use them to run their own code on a web server. The advice was to find every PHP install, starting with anything facing the internet, and update or take it offline.

Checking what was exposed

I went through everything on the Pi instead of assuming:

  • My website: no PHP at all. It's plain HTML and JavaScript served by Caddy.
  • Pi-hole: version 6 has its own web server and doesn't use PHP any more.
  • Cloudflare: my firewall rules already block any address with .php in it, so PHP attacks never reach the Pi.
  • Docker apps: this is where I found it. Speedtest Tracker is built on Laravel, a PHP framework.
# which PHP is inside the Speedtest container?
$ sudo docker exec speedtest-tracker php -v
PHP 8.5.11 (cli) (built: Sep 25 2026)

Built on 25 September, so before the fix. It's only reachable from my home network and Tailscale, never the internet, so the real risk was low. But low isn't zero.

What I did

I pulled the newest image to see if a patched version was out yet. It still had 8.5.11, so I stopped the container until there is one. A speed test every two hours isn't worth leaving a known hole open.

$ sudo docker compose pull
$ sudo docker exec speedtest-tracker php -v
PHP 8.5.11 # no fix yet
$ sudo docker stop speedtest-tracker

The next day I ran a full read-only check of the Pi for signs of anyone getting in: logins, user accounts, SSH keys, scheduled jobs, recently changed files, anything running from temp folders, and Speedtest's web logs. Nothing suspicious, and no PHP anywhere else.

What I learned

  • "I don't use PHP" wasn't quite true. Apps in Docker bring their own software, so you have to look inside the containers too.
  • Keeping services off the internet bought me time. If Speedtest had been public, this would have been urgent.
  • When there's no patch yet, stopping the service is a perfectly good fix.

How I used AI: Claude helped me work out what was affected and wrote the check script. I ran the commands and decided to stop the container. The full, unedited notes are in my build log.