PHP flaw reinforces why self-hosting became a risky bet for developers

A flaw that caused no trouble at all

Ben Thompson writes, in Stratechery's October 26, 2026 edition, that a critical remote code execution (RCE) vulnerability was found in every version of PHP the week before the piece was published. For most sites running PHP without specialized management, that means racing against time between discovery and patch.

For Stratechery, which still runs on WordPress, the episode went unnoticed. The site is managed by Pressable, a company under the Automattic group, and was patched even before the vulnerability was publicly disclosed. Thompson didn't have to do anything.

He recalls that in 2003, to publish his own blog, he had to learn to set up a MySQL database and a PHP environment from scratch, without really knowing what he was doing. It worked, and that was fine. Today, he says, it would be insane to operate that way.

This wasn't an isolated case

Thompson lists other flaws revealed the same week, not as a curiosity, but as a pattern:

• Private keys of intermediate CAs compromised (due to incompetence, not an AI attack, according to him)
• Serious vulnerabilities in Node.js, GitLab, Java and Cisco products
• Supply-chain breaches at LiteLLM and at the Railway development platform

None of these flaws is exotic. They're infrastructure pillars that engineering teams use every day to run and ship software. Thompson's point is that all software is built on a human, inherently fragile foundation: the historical quality bar has always been "did it work?", not "is it secure against any possible privilege escalation or race condition?".

Why attacking got cheaper than defending

Before, attackers and defenders competed under the same constraint: time and human ingenuity were limited for both sides. AI breaks that symmetry, because it gives the attacker unlimited time and the ability to replace sophistication with sheer repetition of attempts.

It was already a dodgy proposition to stand up your own site or app, which was the very promise of the Internet, given the hacking risks; in the age of AI it's madness.

Ben Thompson, Stratechery

Thompson's reading is harsh, but it's worth taking seriously as a working hypothesis, not as absolute truth: he himself acknowledges that the defensive side also gains AI agents running patches and continuous monitoring. The race got faster on both sides, not just for attackers.

The counterpoint: outsourcing doesn't make risk disappear

Here the counterpoint offered by that same week's material is worth noting: Railway and LiteLLM, two platforms companies use precisely to outsource deployment and model inference, were also targeted in breaches in the same batch of incidents. Migrating to a managed provider doesn't eliminate risk, it concentrates risk.

If Pressable is compromised, the side effect hits every WordPress client in its portfolio, not just Stratechery. The same goes for any PaaS, any certificate manager, any hosted LLM provider. The question that used to be "can I apply the patch in time?" becomes "do I trust my vendor's blast radius?".

This doesn't invalidate Thompson's thesis, but it changes the job of whoever decides on infrastructure: vendor due diligence replaces, to a large extent, the routine of manual patching. It's a different kind of work, not less work at all.

What this reshapes in the stack of whoever builds today

In practice, the cumulative effect of these flaws is that the default is no longer "I spin up my own server and think about security later." It became "I pick a managed provider and assess its security posture before any other technical decision."

This simplifies part of the work: fewer infrastructure-team hours spent patching the operating system, updating PHP or keeping a CA certificate current. But it shifts the complexity elsewhere: assessing vendor supply chains, security SLA contracts and the blast radius of each external dependency.

For anyone building something that will be exposed to the public internet, the standard path today is managed hosting, a PaaS with automatic patching, and third-party dependency monitoring as an architecture item, not as a compliance checklist item after launch.

The real bet: building small instead of public

Thompson's most interesting argument, however, isn't defensive: it's economic. He describes how Stratechery has already built several internal applications (podcast production, task management, scheduling) that will never be made public, plus personal apps for managing his own household and following sports.

Before, the fixed cost of creating software was only justified if there was an audience large enough to dilute that cost. AI changes that math: it's viable, today, to build software for one person or a small team, without ever needing to publish it.

In short: if the software is never publicly exposed, it doesn't enter the same risk equation as the flaws listed above. That's not just savings in effort, it's savings in attack surface.

For developers, the practical implication is twofold: reserve managed hosting and full hardening for what truly needs to be public, and use AI to create disposable, restricted-use internal tools, where the security bar can be much simpler because the audience is too. Infrastructure got cheaper on both ends, just for opposite reasons: one because it's outsourced, the other because it never leaves home.