The patch landed at 10 A.M..
Two critical flaws in the software underneath half the web, fixed in a single hour. What it means for the growing number of people building with AI who cannot read the code they ship.
Updated 22 October 2026 — added what we found inside our own estate, what we changed, and the standing arrangement that came out of it.
At 10:00 A.M. Eastern on Wednesday, October 21, the PHP project shipped an emergency release for two vulnerabilities rated 9.2 out of 10. Both are remote code execution. Both had enough detail circulating publicly beforehand that the release was pulled a day earlier than planned, with the maintainers reserving the right to ship sooner still if exploitation appeared in the wild.
If you do not write software, you have probably never thought about PHP. You have almost certainly used it today.
You are running it whether you know it or not
PHP is the language underneath WordPress, WooCommerce, Drupal, Joomla, Magento and Laravel. It runs a large share of shared hosting and control panels. It is the thing your hosting company installed before you picked a theme, and the thing nobody has mentioned to you since.
The practical advice from one hosting provider's guidance on this release was about as blunt as it gets: if you run a site or app on PHP, assume you are affected until you are updated to a fixed version. Not “check whether you are affected.” Assume.
This is the part of the internet that has no product manager. It works, quietly, for years. Then one Tuesday it becomes the most important piece of software on your machine.
What actually changed: the window
The vulnerability itself is not the story. Vulnerabilities of this severity have always existed, and the teams that maintain this software have always fixed them. What changed is the window between disclosure and exploitation.
Historically a serious flaw gave defenders weeks. The patch shipped, administrators applied it over a maintenance window, and attackers spent that time reverse-engineering the fix. That window has been compressing for a decade, and two forces are now squeezing it hardest.
The first is leaking. When technical detail escapes before a fix exists, every attacker gets a head start and every defender gets nothing to install. This release moved a day earlier because of exactly that risk. The vendor's own language, that they will ship sooner if details become public or exploitation appears, is a description of a race, not a schedule.
The second is AI assistance on the attacker's side. Reading a patch and reconstructing an exploit used to be skilled, slow work. It is now something a competent person can accelerate dramatically with a model that reads the diff, drafts the payload, and iterates against a test environment. I am not going to quote a study at you here, because the honest version is that the direction is obvious and the exact multiplier is not the point. An exploit that took a week of expert attention can now be attempted in an afternoon by someone who could not have written it alone.
The new owner class, and the gap underneath it
Here is the uncomfortable connection to AI, and it is not the one you expect.
AI has made it possible for someone with no engineering background to stand up a real website, a real internal tool, a real customer portal. That is genuinely good. I do it for a living and I have watched non-technical founders ship things that would have cost them $80,000 and six months two years ago.
But the same shift created a new class of software owner: people responsible for systems they cannot inspect, running dependencies they have never heard of, on a hosting account they set up once and forgot. When a 9.2 drops, that person is not on a vendor mailing list. They find out when their site starts redirecting to a pharmacy.
The failure is not that AI wrote the code. The failure is that nobody owns the maintenance. Building is a moment. Keeping something patched is a habit, and habits do not come bundled with a prompt.
Five things worth doing tonight
None of these require you to understand PHP. They require you to know what you own.
1. Write down every site and app you are responsible for. Domain, host, and who has the login. Most people cannot produce this list from memory, and a list you cannot produce is a list you cannot protect. A spreadsheet is fine. Doing it with an AI assistant in ten minutes is fine too.
2. Find out whether updates are automatic. Most managed hosts patch the runtime for you. Most cheap shared hosts do not, or they patch slowly. Check the host's status page or ask support one question: “do you apply PHP security releases automatically, and how quickly?” The answer tells you whether you have a job to do tonight.
3. Back up before you update. This is the step people skip at 11 p.m. and regret at 11:20. A backup is a file you could restore from if the update breaks the site, and “the host does backups” is not the same as “I have a copy I have tested.”
4. Remove what you are not using. Abandoned plugins and themes are the single most common way a patched site still gets owned. If it has not been updated in two years and you cannot say what it does, it is not a feature, it is a door.
5. Make the credentials worth stealing. A unique password per service and two-factor on the accounts that can publish to your site. Passkeys where offered. If your hosting login is the same as your email login, fix that before you fix anything else.
And the one that is not a task: if you cannot patch something, take it offline. An unmaintained site running known-vulnerable software is not a marketing asset. It is a liability with your name on the invoice.
The 11 p.m. call
A developer I follow made the sharpest point about this release, writing in Japanese about the same patch landing at 23:00 his time. His framing, translated: the people who delivered a site and walked away will not be calling their clients tonight. Only the ones who maintain what they built can protect it.
That is the whole thing, and it applies far beyond web development. The person who built your site with AI and handed you a login has finished the job they were paid for. What you bought was a moment. The vulnerability does not care about the invoice.
It also reframes what maintenance is worth. Two days ago, “we keep your stack patched” sounded like an upsell. This morning, with a 9.2 in the wild and a leaked write-up, it is the difference between a scheduled upgrade and a very bad week.
What this means going forward
This will happen again. Not because PHP is uniquely broken, but because the internet is built on a small number of enormously load-bearing things that most of us never see, and attackers only need one of them to be unpatched somewhere.
The defensible position is not vigilance. Nobody sustains vigilance. It is small systems that survive being ignored for a month: automatic updates where you can have them, a backup you have actually restored once, an inventory short enough that you remember it exists, and fewer things running than you strictly need.
If you build with AI, add one habit to the workflow: at the end of every build, before you hand over the link, write down what it runs on and who is going to patch it. If the answer is nobody, that is the finding, and it is better to have it today than on the morning of the next 9.2.
What we did in the first twelve hours
We treat an advisory like this as an operational event, not as news. The reading is the easy part. What follows is the part that decides whether the next forty-eight hours are boring.
We went to the primary source first. The advisory itself, then the vendor's own guidance, then the host-level notices. Commentary is useful for context and actively harmful for decisions: it is written at the speed of attention, and it is frequently wrong about scope in the first day.
We inventoried before we patched. Patching fast is worthless if you patch the wrong thing and assume the rest. So the first pass is always the same question asked of every system we operate or maintain on someone's behalf: what is actually running here, who built it, and who is responsible for it this quarter. Half the value of an incident like this is the inventory it forces you to produce.
We verified state instead of trusting settings.“Automatic updates are on” is a setting. A version number, read back from the system itself, is a fact. We check the fact. Where something could not be updated in place, we treated it as compromised until proven otherwise rather than as pending.
We gave the adjacent layers the same scrutiny. Code is the obvious surface. The certificate stores and the credentials that let systems talk to each other are quieter and just as consequential, and they are usually the last thing anyone checks. Ours got the same treatment as the application layer.
We accepted that we had drifted. Two of our own internal rails had quietly gone stale in the past month. Neither was a breach. Both were corrected within the day, and both are now watched by an automated check that reports to us before anyone outside would notice. Any firm that tells you nothing drifted during a week like this is telling you they did not look.
We made the fix verifiable, not just done. An API returning success is a claim. Reading the change back from the system, independently, is proof. Every remedy from this week was confirmed the second way, and that is now the standing rule rather than a habit that depends on who is awake.
Why this matters more for the small operator
A large company has a security team whose entire job is to spend a day like this. A twenty-person business, or someone running four sites built with AI tools on a Tuesday, has nobody. The advisory is public, the fix is available, and the gap is that no one is assigned to read either.
That gap is not closed by caring more. It is closed by something that happens whether or not anyone remembers: an inventory that exists, a check that fails loudly, and a decision made in advance about what gets shut off when a genuinely critical flaw lands and there is no patch yet.
The standing version of what we did this week
Sentinel is the arrangement we built after enough of these mornings: continuous watching of the advisories that actually affect the systems you run, a maintained inventory so nobody is guessing under pressure, verification that patches landed rather than being scheduled, and a named person who responds when something critical has no fix yet.
It is deliberately unglamorous. Most of the value arrives on the days nothing happens, and the day it pays for itself is the one where you find out from us instead of from a customer.
Ask about Sentinel →Sources
- 01PHP.net — official security release announcement, October 2026 archivethe emergency security release and its timing; the two vulnerabilities and the 9.2 severity rating
- 02BleepingComputer — PHP warns admins of two critical flaws, emergency patches coming tomorrowthe 14:00 UTC / 10:00 A.M. Eastern release time, both flaws rated 9.2 under CVSS v4.0, and the maintainers' commitment to release sooner if details went public or exploitation appeared
- 03GoDaddy — Important PHP security update: what website owners need to doboth vulnerabilities being remote code execution, the affected platforms (WordPress, WooCommerce, Drupal, Joomla, Magento, Laravel), and the 'assume you are affected until updated' guidance
- 04Huntress — php2shell, leaked critical PHP vulnerabilities (CVE-2026-109618, CVE-2026-109619)the report that technical detail circulated before the fix and that the release was moved earlier than the original embargo
Every source above was checked at the primary document, not a second-hand summary.