We Patched 23 PHP Sites in 9 Hours: the 4 That Would Not Budge Told Me Who to Hire

The advisory landed at 13:34 UTC on a Wednesday and told us precisely what to do, which is the best case for this kind of work. There was no guesswork about the affected component, no debate about severity, and no waiting for a vendor. By the end of the day 19 of our 23 production PHP services were running a fixed engine. Four were not, and they are the reason I am writing this instead of filing the incident and moving on. All four failed for the same reason, that reason had nothing to do with security, and it is a hiring problem rather than a tooling problem.

What was published, in the words of the maintainers

Two defects, both in the PHP engine itself, both marked critical. The first, CVE-2026-109618, is tracked as GHSA-w8hw-w9fx-j79w and summarised by the maintainers as remote code execution via out-of-memory corruption. The second, CVE-2026-109619, is GHSA-6wmf-4rv5-p3rp, remote code execution via stale global state, which is a use-after-free. Both advisories were published at 13:34 UTC on 21 October 2026. The researchers at Wiz who reported them gave the pair the name php2shell, and that is the name the industry has adopted.

The fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, which you can confirm yourself in the official PHP 8 ChangeLog. For a stopgap, session upload progress is enabled by default and is a documented path to the second flaw, so turning it off narrows exposure. It does nothing for the first flaw. The maintainers are unambiguous that updating is the only complete remedy, and CERT-EU published advisory 2026-018 saying the same.

One detail deserves more attention than it is getting. These are engine defects, not framework defects. No amount of reviewing your own application code would have surfaced them, and no firewall rule is equivalent to the fix. That matters for how you staff, because it means the control that saved us was not a security control at all. It was the ability to change a runtime version and redeploy.

The nine hours, honestly accounted for

Here is how the window actually went, because the shape of it is the argument. Reading the advisory and deciding took under 30 minutes. Identifying which services ran which PHP branch took close to two hours, which is already longer than it should be and is a symptom in its own right. Patching the 19 services that had a working build-and-deploy path took about four hours including verification, most of it waiting on pipelines. The remaining three hours went entirely on the four services that had no such path, and at the end of those three hours all four were still unpatched. We finished them over the following two days.

Read that last line again, because it is the whole article. The four stragglers were 17 per cent of the estate. They consumed a third of the window and delivered nothing inside it. If the attacker window had been six hours rather than nine, the outcome for those four services would have been identical, and no additional security hire would have changed it.

Why the four would not patch

I expected four different stories. I got one story four times. In each case the service could not have its runtime version changed and be redeployed on demand, for a reason that was recorded nowhere:

• A client portal whose container image was built once, by hand, by someone who left in 2024. The Dockerfile in the repository no longer produced a working image.
• A reporting service pinned to PHP 8.1, a branch that gets no vendor patch, because a dependency had never been upgraded. The remediation was not a patch, it was a migration.
• A marketing site on managed hosting where the PHP version was a dropdown in somebody else’s control panel, and nobody on the team had the credentials.
• An internal tool with no pipeline at all, deployed by copying files, where nobody was confident that redeploying would preserve its configuration.

Not one of these is a security finding. Every one is an ownership and build-path finding. The pattern is so consistent that I now think of emergency patch readiness as a deployment capability that happens to be tested by security events, which is why it is usually owned by nobody until a Wednesday afternoon.

The three roles, in the order we are opening them

The order matters more than the list, and it is probably not the order a security incident would suggest.

1. Platform engineer who owns a build path for every service

This is the first hire, and it is deliberately not a security role. The constraint on day one was the number of services that could have a runtime version changed and be redeployed on demand. Nineteen could, four could not, and closing that gap is reproducible-build work: every production service builds from source in a pipeline, no hand-built images, no runtime version that lives only in a hosting control panel. A good interview question is to ask a candidate how they would find every service in an estate whose deployed artefact cannot be rebuilt from its repository today. Strong candidates ask what the deployment inventory looks like before proposing a tool. Weak ones name a product. If you are mapping this role against the rest of your infrastructure hiring, our guide on building a DevOps capability in the UAE covers the adjacent ground, and how to hire a DevOps engineer in Dubai covers the sequence.

2. Senior PHP engineer who can own a version upgrade, not just features

The PHP 8.1 service needs somebody who has taken a real codebase across major PHP versions and can estimate it honestly. This is a different skill from writing application features, and it is the skill most often missing on teams whose PHP work has been outsourced feature by feature. Ask a candidate to walk through the last runtime upgrade they led, specifically what broke that they had not predicted. Anyone who says nothing broke has not done one. For Dubai teams running Laravel in particular, the context in our Laravel development in Dubai guide and in hiring a Laravel and PHP team in Dubai is the practical starting point.

3. Application security engineer, third rather than first

This role is genuinely needed, and putting it third is a sequencing argument rather than a dismissal. On 21 October the security knowledge required was already supplied by the advisory. What a security engineer adds is everything around the next event: an inventory that answers the version question in minutes rather than two hours, a monitored feed so you hear about an advisory when it publishes, a documented stopgap that includes its own expiry date, and the judgement to tell you when a mitigation is buying hours rather than solving a problem. Hire this role to shorten the next window, and read it alongside building an incident response team in Dubai.

The readiness test worth running before the next advisory

You do not need an incident to get this number. Pick three production services at random, and for each one ask a single question: can we change the runtime version and redeploy, today, without finding a specific person? Record the answer as yes or no, with no partial credit. The result generalises to the estate better than any audit, because it measures the capability an advisory actually tests.

What this means for Dubai employers specifically

PHP carries an unusually large share of the regional web estate, including a long tail of SME sites, portals and internal tools built by agencies over the last decade and handed over with varying degrees of documentation. That tail is exactly where unsupported branches and hand-built deployments live. If your organisation grew by commissioning sites and tools from multiple suppliers, your version-and-redeploy number is probably worse than ours was, and nobody currently owns improving it.

The useful framing for a hiring conversation is not that you need security headcount because a critical flaw was published. It is that you need one person who can state, with evidence, how fast every production service can change its runtime version. That capability pays on ordinary Tuesdays as well, in dependency upgrades, cost moves and platform migrations. The security event simply made it legible, and gave it a deadline.

Frequently asked questions

What exactly are CVE-2026-109618 and CVE-2026-109619?

Two separate memory-safety defects in the PHP engine, both critical, both published as php-src advisories at 13:34 UTC on 21 October 2026. CVE-2026-109618 (GHSA-w8hw-w9fx-j79w) is described by the maintainers as remote code execution via out-of-memory corruption. CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp) is remote code execution via stale global state, a use-after-free. Wiz published them as php2shell. Because they sit in the engine rather than in a framework, application code review would not have found them and a firewall rule is not a substitute for the fix.

Which PHP versions fix the flaws, and what about PHP 8.1 and older?

PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, per the official PHP 8 ChangeLog. PHP 8.1 and earlier are end of life and receive no vendor patch. Community source backports exist and distribution vendors such as AlmaLinux shipped patched packages, but relying on them means depending on a third party for engine security. For an end-of-life branch the honest remediation is a version upgrade, which is a project rather than a patch window.

Is disabling session upload progress a real mitigation?

It is a stopgap for one confirmed path, not a fix. Session upload progress is enabled by default and is a documented route to CVE-2026-109619, so disabling it narrows exposure while you schedule the upgrade. It does nothing for CVE-2026-109618, and the maintainers state that updating is the only complete remedy. Put the real patch deadline in the same ticket so the stopgap does not become the plan.

Which role should we hire first after this?

A platform or infrastructure engineer who owns a build-and-deploy path for every production service, ahead of a security specialist. The nine-hour window was not limited by security knowledge, because the advisory supplied it. It was limited by how many services could change runtime version and redeploy on demand. Four could not, and each failed for a missing deployment path rather than a missing security control.

Sources: PHP 8 ChangeLog, php-src advisories GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp, and CERT-EU advisory 2026-018. Figures for our own patching window are from our internal incident record of 21 and 22 October 2026.