· via dev.to (home feed)
Critical PHP RCE bugs push one developer to a rule: no same-day patch, no self-hosting
Two unauthenticated PHP vulnerabilities that allow remote code execution drew a CISA alert this week, and one developer's response — keeping WordPress on managed hosting — illustrates the operational cost of self-hosting.

Two critical vulnerabilities in PHP, tracked as CVE-2026-109618 and CVE-2026-109619, were disclosed this week, and both allow an attacker to run code on an affected server without logging in. That account comes from a post on dev.to, which cites the PHP project's advisory alongside a CISA alert published on 21 October that calls for immediate patching. The author also reports an email from his provider, Hetzner, stating that because his server is self-managed, applying the update is his job — a reminder that prompted him to audit his own setup. Hetzner's status page carries a related incident notice, which the post cites as well.
What the author found
His websites run WordPress on managed hosting, so the provider applies PHP security updates on his behalf. After the disclosure, the only check required on his side was confirming the build date of the PHP version in use.
His Hetzner server, by contrast, runs no PHP at all. Nothing on it was exposed to this week's flaws.
The migration that did not happen
The timing was instructive. Only days earlier, the author had been weighing a move of his WordPress sites onto the Hetzner machine to save money. The week's disclosures made the hidden cost visible: on a self-managed server, patching falls to him — the same day a fix ships, possibly in the middle of the night.
There was also a blast-radius argument. The Hetzner box runs his automation, and a compromised WordPress installation beside it would turn one vulnerable site into a foothold for everything else on the machine.
His conclusion: the WordPress sites stay on managed hosting, and the server remains reserved for agent workloads. The rule he drew from the episode is simple — if he cannot patch a piece of software the same day a critical fix lands, he does not host it himself.
Why it matters
The anecdote is small, but the trade-off it describes sits at the centre of every self-hosting decision. An unauthenticated remote code execution flaw in a language runtime is about as severe as software defects get: no credentials required, full server compromise, and a vast installed base of PHP applications to aim at. When CISA tells operators to patch immediately, someone has to be awake, available and able to do it.
Managed hosting is, among other things, a way of buying that availability. The monthly fee pays for an operations team that tracks advisories and ships updated builds. Self-hosting recovers the money but transfers the obligation in full — and, as the Hetzner email underlines, providers of raw infrastructure are explicit about that transfer.
The post also illustrates a quieter principle: separate workloads by risk. Internet-facing PHP applications belong to a different risk class than the automation running on a private server, and co-locating them means the weakest component defines the security of everything around it.
The author closes with a question worth borrowing: do you actually know who patches PHP on your sites, and how fast? If the answer is uncertain, this week's pair of vulnerabilities is a good reason to find out before the next disclosure arrives.
- #php
- #security
- #self-hosting
- #wordpress
- #vulnerabilities