Two critical flaws, attacks that started before the patch, and how to find PHP beyond your website
On October 21, PHP released emergency fixes for two critical flaws now known as PHP2Shell. Both let someone who isn't logged in run their own code on a server, and both are rated 9.2 out of 10. Amazon reported an exploit attempt on October 17, four days before the patch existed. If you're keeping score at home, that's a four-day lead on a flaw the rest of us hadn't heard of yet.
Running code on a server means an attacker can read what's stored there and plant something that lets them come back later. They can also use that server to reach the rest of the network. The reach is what makes this a big week. PHP runs about 70 percent of the websites whose server-side language W3Techs can identify, and it also runs the admin pages on plenty of routers, backup appliances, phone systems and more.
So when the people you advise, colleagues, or even friends ask whether they're affected in some way, the answer is almost inevitably yes. Providing sound guidance to those folks on a path forward starts with how this unfolded and where PHP tends to hide, followed by three practical steps to take in building your remediation plan.
How PHP2Shell Unfolded
The flaws were found with help from AI. Calif found the first bugs in August and reported them to PHP, and Wiz Research reported the issues independently a few weeks later. Good researchers used AI to help find these. The reasonable flip side of that coin is that less friendly people are using the same tools to look for the next ones.
PHP's maintainers planned to announce the flaws on October 22, but details leaked online on October 20, forcing them to move the release up a day. By then, attackers were already busy. Patchstack and Cloudflare both saw exploitation attempts hours before the fix went out, and Cloudflare has since counted millions of attempts, with attackers reworking their payloads to get past its filters. Those attempts have started landing. On October 26, BleepingComputer reported the first confirmed successful exploitation, caught by a researcher's honeypot running PHP 8.4.26, one release behind the fix.
The fixed versions are PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. Anything older than 8.2 is end of life, meaning patches won't be coming. Servers running those versions need a backported fix from a vendor or an upgrade, and upgrades on older systems typically include timelines that inherently increase risk.
CISA has provided official confirmation, adding both flaws to its list of known exploited vulnerabilities on October 26 and giving federal agencies until October 29 to patch. Vendors are still checking their products, though, so expect further details to continue to emerge in the weeks ahead. The bigger unknown for many of us is in the places PHP runs that are easy to forget.
Where PHP Runs Beyond the Website
Websites are the logical place to start, including sites built on WordPress, Joomla, Drupal, and Magento. Sites hosted by an outside provider are easy to overlook, since the organization owns the risk without owning the server. A quick note asking the hosting provider whether they've patched is an important first step.
PHP also turns up in places that don't look like websites at all, such as the admin pages on wireless access points, NAS devices, backup appliances, and phone systems. Those devices rarely appear on a list of web servers, and their PHP usually gets updated through a firmware release on the vendor's schedule, so they tend to lag behind the rest of the environment.
It works a lot like the plumbing in an older building. The kitchen and bathrooms are easy to find, but there's usually one pipe running somewhere you forgot about, which turns out to be the one that floods the basement.
A patched website answers part of the question. Here are three steps to help answer the rest.
Three Steps That Get You to a Clear Answer
The time between a patch release and a rollout is the window attackers get to work with, so each of these is easier to do now than in the middle of the next advisory.
Step 1: Decide How Much Patching Risk Is Acceptable
Patching fast can interrupt a service, and patching slowly leaves a known weakness open, so somebody has to decide which risk they'd rather carry. That decision belongs to the people who make risk decisions for the organization, and if those folks are not clearly identified already, getting their names documented is a critical first step. Communicated in a way that educates these leaders on the risk and empowers a decision based on impact to the business, something like "Would you rather we patch tonight and risk an hour of downtime, or wait for the weekend and accept the exposure until then?". Some will say they don't want anything disrupted, and that's their call to make.
Once they've decided, putting it into a policy or procedure means the next emergency patch doesn't restart the conversation. A useful version spells out who can approve an emergency patch, how fast internet-facing systems get updated, and when some downtime is acceptable in exchange for closing a flaw attackers are already testing.
Step 2: Use Your Inventory to Find Where PHP Is Running
AI can make a meaningful difference here, but avoid free, publicly shared models. Stick with paid solutions that don't train its model on your business data. The hardware and software lists you already keep can go into the model you trust and prefer, with a request to find where PHP could be running. A prompt as simple as "Which of these products use PHP in their management interface or firmware? Cite vendor documentation for each answer" gives you an actionable target list to check. Expect an output that includes HVAC web interfaces, switches, routers, firewalls, and other connected equipment that has a management page somewhere.
Each confirmed result requires a next step. Some will have a vendor patch ready, some will be waiting on one, and some can come offline for a while without significant impact. For the ones that can't be patched yet, keeping their management pages off the open internet buys time, in line with CERT-EU's advice to isolate internet-facing PHP applications.
Step 3: Fold It Into Find, Fix, Verify, Repeat
This fits into the cycle we've been talking about for a couple of months. You find where you're weak, fix it, verify the fix, and repeat. Galactic can help with the finding and verifying, and a re-scan after patching confirms the fix did its job.
Verifying also means looking back because, while a patch closes the door, it doesn't remove anything an attacker already left behind. On any system that was exposed, look for files or accounts that weren't there before, such as an unfamiliar PHP file in a web folder or a new admin login. Then change the passwords and keys stored on or used by those systems, because anything that was readable before the patch should be treated as already in the attacker's hands. Lastly, don't skip the reboot after patching. Until the server or device restarts, it can keep running the old, vulnerable version of PHP, so the fix is sitting on disk without protecting anything yet.
Given the rapidly evolving nature of this threat, remain diligent in evaluating environments and consistent in educating stakeholders on the subsequent risk. If your "Find, Fix, Verify, Repeat" process has any gaps, reach out. We're here to help.
Where This Goes Next
This story will keep moving. Vendors are still checking their products. There's talk of more fixes, and a few items on your inventory will probably turn up in advisories over the coming weeks. We'll keep sharing what we learn so you don't have to chase every update alone. In the meantime, regular communication to the people you advise, covering what you've checked and what's still open, goes a long way while the headlines keep coming.
Attackers got a four-day head start on PHP2Shell. With these three steps done, you'll have a head start of your own the next time something like this happens, and the people you advise will get a clear answer from someone who was ready for it.
