How to Find and Prioritize Exposed PHP Servers After PHP2Shell (CVE-2026-109618, CVE-2026-109619)

By Tuskira Research

The PHP project gave a day’s notice on Tuesday, October 20. The details leaked anyway, according to SecurityWeek, the fixes went live a little before 10 AM Eastern on Wednesday, and security firms were reporting exploitation attempts before the patches were out. Reuters reported the Port of Rotterdam, Dutch government portals, and public services in Finland and Denmark going offline as a precaution.

The two bugs, CVE-2026-109618 and CVE-2026-109619, are both rated 9.2 and both give an attacker code execution on the server. Wiz Research, which found and reported them, also showed an attacker reading passwords, tokens, and API keys out of the PHP process without code execution at all. Fixes landed in PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. CERT-EU puts the affected range back to PHP 5, and anything on 8.1 or older gets no upstream fix, so those servers depend on a vendor backport if one exists.

The PHP release notes say it plainly. There are no complete mitigations. Updating is the only safe choice.

01The advice everyone got

By Wednesday afternoon every security team had the same three instructions from CERT-EU, the NCSC, and their own vendors. Find every system running PHP. Patch the internet-facing ones first. Take offline anything you can’t patch. It’s the right advice. The advisory tells everyone what must be done. It can’t tell your organization which system creates the most immediate path to impact, because it doesn’t know which of your PHP servers an attacker can reach today or where the account on that server can go once someone owns it. Those two questions decide how the next 48 hours go, and only you can answer them.

Picture the team that gets the call. The CISO wants to know whether they’re exposed, and the first answer anyone can give is “we’re checking,” because PHP often lives in places the current inventory missed. The vulnerability scanner knows about the main web tier. It doesn’t know about the marketing microsite a contractor stood up in 2019, the vendor appliance with a PHP admin console baked into its firmware, the containers and CI runners that pull a PHP base image, or the Drupal box from a campaign that ended three CMOs ago. Half an hour in, the list is longer than anyone expected and most of it is on versions that stopped getting fixes years back.

Then the questions start arriving in order, and each one depends on the last. Of all those servers, which ones can the internet reach right now, through a load balancer, a forgotten DNS record, or a port someone opened for a demo? Of the reachable ones, which run under an account that can reach something that matters? Which do we patch tonight, and which do we pull off the network because they’re on PHP 7.4 and a patch isn’t coming? Teams that can answer those questions from a model they already have get through the list the same day. Teams building that context after disclosure lose time precisely when the response window is shortest.

02One server, followed all the way

Take a hypothetical Drupal box, the kind that turns up on most of these lists. It’s on PHP 7.4, it’s reachable from the internet because it still has a public DNS entry, and it runs under a service account that was created in 2019 and never reviewed. An attacker who lands on it gets a shell with that account’s permissions. The account was given read access to a shared file server so the campaign could pull assets, and that share sits on the corporate domain. From there, the same account has a role in the cloud account where the campaign’s analytics ran, and that role was scoped generously because somebody was in a hurry. The role can list and read from a storage bucket, and the bucket holds a nightly export from the customer database.

Nothing on that path is a vulnerability in the usual sense. It’s a service account with too much reach, a share that was never cleaned up, and a cloud role nobody re-scoped. The PHP flaw is just the front door, and the path behind it crosses a web server, a domain file share, and a cloud account, each watched by a different tool and none of them seeing the whole route. This is the question Kairo was built to answer, where an identity on a given server can go and what it unlocks, across identity, network, and cloud at once. When you can see that path on Wednesday morning, the Drupal box moves from “patch eventually” to “pull it now,” and the service account gets its permissions cut before anyone has to argue about it.

03Six questions, in order

When a zero day like this lands, Tuskira works it as a sequence of validation stages, and each one shrinks the list the last one produced. The first four are the questions Quell asks about every vulnerability. Hunt. Is it real, and where does it live? Both CVEs are matched against the customer’s environment model, the one built from their scanners, asset inventory, endpoint agents, and cloud accounts before any of this started, to find every affected PHP host the connected sources know about. Reachability. Can it be reached or triggered? Of those hosts, which ones the internet can get to today, through a load balancer, a public DNS record, or an open port. Defensibility. Is it already covered by a control? For each reachable host, whether a WAF rule, a firewall policy, or an endpoint agent the customer already runs blocks the exploit path, tested against the control rather than assumed from a config. Recon-Ability. Can an attacker truly exploit it? A probe against the host from outside, the way an attacker would check, rather than a version match.

The next two are Kairo’s. Breach paths. Where the account on each exploitable, undefended host can go, across identity, network, and cloud. Crown jewels. Which of those paths end at data or systems the business can’t afford to lose.

What falls out the bottom is a short list in order. A host that is reachable, undefended, exploitable, and one hop from a customer database is the first item. A host nobody outside can reach, or one where an existing control already stops the exploit, drops to the patch window where it belongs.

04Contain, then close the path

Partial measures may interrupt specific exploit paths, but none resolves both vulnerabilities, and PHP’s guidance is unambiguous. Update to a fixed release. For anything that can’t be patched tonight, containment means cutting who can reach it, and the fastest way to do that is usually a control the customer already owns. A WAF rule or a next-generation firewall policy in front of the affected host restricts the traffic that can get to it while the patch rolls out. Where that isn’t possible, pull the public DNS entry, close the port, or take the end-of-life box offline. None of this fixes the bug. It shrinks the number of people who can reach it, which is the only lever you control until the patch lands.

Then close the path behind it. The hypothetical Drupal box was dangerous because of a service account with read access to a domain share and a role in a cloud account, so the service account loses the share, the cloud role gets re-scoped, and the route from that server to the customer database no longer exists even if the server itself is compromised tomorrow. Tuskira recommends, stages, or executes those changes through the system that owns each control, according to the customer’s policy, and Vector re-tests from outside once the change is made.

05What Tuskira customers saw on Wednesday

Both CVEs were loaded into Quell on Wednesday morning and run through those stages against each customer’s environment. The result identified affected PHP hosts reachable from the internet through the connected environment data, with the account each one runs under and what that account can get to. Hosts on end-of-life versions with a path to something that matters sat at the top, the first candidates to contain and pull offline. Hosts nobody can reach from outside sat at the bottom until the patch window gets to them.

One limit worth saying out loud. Tuskira ranks what your sources already know about. A PHP server that no scanner, inventory, or external discovery pass has ever seen won’t be on the list, and this week is a good time to find out how many of those you have.

06AI shortened the gap

Wiz said building the exploit meant chaining several flaws together, and that “frontier AI models substantially reduced that barrier, turning a longstanding flaw into an exploit.” AI helped find the bugs as well. What changed is how fast someone can turn a disclosure into working code. Tuskira Research measured the same shift from the other direction earlier this year. AI discovery outpaces safe patching by roughly 16.5x (The Emerging Patch Gap). Discovery is getting cheaper on both sides of the fence, and the window between a disclosure and the first exploit attempt is now measured in hours.

Scanners still matter and coordinated disclosure still works. The work that decides outcomes has moved earlier. Knowing where PHP runs, which servers the internet can reach, and what each one’s identity unlocks is work you do before the advisory arrives, so that when it does, you’re answering questions instead of building the list.

07The next advisory will ask the same questions

The patches arrived Wednesday morning. The teams best positioned to respond were the ones already able to answer three questions. Where is the affected software? What can an attacker reach from it? Is the path still open after we act? The next critical advisory may involve a different runtime, and those questions will be the same.

Sources: PHP advance notice (Oct 20, 2026) and security release (Oct 21, 2026); Wiz Research, “PHP2Shell”; Reuters, Oct 21, 2026; SecurityWeek, Oct 21, 2026; Help Net Security, Oct 21, 2026; CERT-EU advisory; Tuskira Research, “The Emerging Patch Gap,” June 2026.