PHP2Shell Explained: The Web Flaw Everyone Is Rushing to Patch

If your website, online shop or company portal runs on PHP, this week’s headlines are about you. Security teams are calling it one of the biggest web vulnerabilities in years. The jargon is thick, so here is what you actually need to know.

What Is PHP?

PHP is the programming language behind a huge slice of the web, including WordPress, Drupal, Joomla and countless custom business applications. On 21 October, the PHP project released emergency fixes for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619. Together they are nicknamed PHP2Shell.

In plain terms, both flaws can let attackers run their own code on a web server without logging in. This is called remote code execution, and it is as bad as it sounds. Picture someone walking up to your shopfront and, without a key, being handed the till, the stockroom and the back office.

The flaws sit deep in how PHP manages memory. One involves out-of-memory handling that can interrupt PHP while request data is only half set up. The other involves leftover internal state that survives after the memory behind it has been freed. You do not need to follow the mechanics. What matters is that PHP can be tricked into trusting something it should not.

Why the Alarm?

Three reasons:

First, the scale. Every PHP installation that serves web requests is affected, whether it runs on PHP-FPM, Apache, LiteSpeed or similar. Wiz researchers say every PHP version of the last decade is affected, going back to version 5.4.

Second, the age. The underlying bugs had reportedly been there for years. Wiz notes that exploiting them required an exceptionally complex chain of steps, and that frontier AI models substantially reduced that barrier. A long-dormant flaw became practical to weaponise partly because AI made the hard part easier. That deserves its own article.

Third, the speed. Details leaked on social media on 20 October, ahead of the planned disclosure date. Worse, Amazon’s honeypot network recorded an exploitation attempt on 17 October, four days before public disclosure. Attackers may have had a head start.

“The danger lies in the fact that the vulnerabilities are directly in PHP, which is used by a vast number of websites and online stores running WordPress, Drupal, Joomla, or Magento, as well as shared hosting platforms, cPanel and Plesk control panels, and a wide range of commercial software,” noted Jiří Kohout, Cyber Risk & Security Strategist at Check Point Software Technologies. “The vulnerabilities could allow attackers to remotely execute their own code on a vulnerable server, even without logging in. This could result in data theft, attacks on other systems, or service outages.

Who Should Be Worried?

You should be concerned if any of these apply:

• You run a WordPress, Drupal, Joomla or Laravel site, or any custom PHP application, on your own server or VPS.
• You manage web servers for clients or your employer.
• Your site runs on PHP 8.1 or older, including 7.x and 5.x. The PHP project no longer supports these versions, so there is no standard fix for them.
• You depend on network appliances or vendor products built on PHP. Palo Alto Networks has confirmed that all versions of PAN-OS and Panorama are affected, with fixed releases not yet shipped at the time of writing. Fortinet and Cisco are still checking their product lines.

You are probably in better shape if you use managed hosting. Providers such as InMotion Hosting have been applying protective measures ahead of the patch. Still, ask your host what PHP version you are on and whether it is patched. Do not assume.

What Should You Do?

According to Don Smith, VP of Threat Intelligence at Sophos Counter Threat Unit, “the immediate challenge is not simply installing a patch, but finding and managing every instance where PHP is running.

“The use of PHP is pervasive, it can sit beneath public websites, content management systems, hosting platforms and third-party products, sometimes without even being obvious to the organisation using it,” he said. “Security teams should prioritise internet-facing systems, confirming which versions are affected as soon as the official advisory is published, and apply the updates without delay. And in line with the advice from NCSC, any vulnerable system that cannot be patched should be isolated from the internet until it can be secured.”

“Threat actors move fast, especially with the help of AI and this will likely be a priority target for them over the coming hours and days so it is crucial organisations monitor PHP and web-server processes for unusual processes, command execution or other signs that an attacker may already have gained a foothold,” he added.

Taking off from Smith’s advice, consider taking the following steps:

1. Find out your PHP version. Your hosting dashboard or your developer will know.
2. Update to a fixed release. The patched versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. If you installed PHP through your operating system’s package manager, check your vendor for updated packages.
3. Do not assume automatic updates cover you. Laravel Forge warns that its automatic security updates do not patch PHP, so servers must be updated by hand. Plenty of other setups work the same way. laravel
4. If you are on PHP 8.1 or older, move to a supported version. Some Linux distributions and long-term support vendors offer backported fixes. The PHP team has also released minimal source backports for PHP 7.4, 8.0 and 8.1 for people who build from source.
5. If you cannot patch yet, reduce exposure. The UK’s National Cyber Security Centre is urging organisations to consider taking unfixable systems offline. Cloudflare has deployed initial firewall rules for known exploit routes, available to all customers including free ones. That is a stopgap, not a cure.
6. Check whether you are exposed. Searchlight Cyber has released an open-source scanner that tests whether a host is vulnerable.
7. Restart after updating. SentinelOne advises restarting Apache, PHP-FPM and any long-running workers. Updating the package without a restart can leave the old code running.
8. Patching doesn’t tell you whether you were already hit. As one report put it, installing the patch closes the door to future exploitation, but does not establish whether anyone has already walked through it. Exposed servers should be checked for signs of compromise, especially given the exploitation seen before the patch landed.

Therein lies the rub, too. Patching isn’t necessarily straightforward. In fact, it can be complicated, according to Satnam Narang, Senior Staff Research Engineer at Tenable, with the complexity depending on a number of factors.

“The complexity of patching is dependent on which group an organisation falls into. Linux distributions and long-term support vendors were given advance notice, so we expect them to provide updated packages quickly, which means fixes could be released within hours to days,” Narang pointed out. “For less mainstream package sources, it could take days (the PHP project said the volunteer-maintained remirepo wouldn’t have updates on release day). For systems running end-of-life versions of PHP, it could take weeks or months, or these systems may never get updates. Products that bundle PHP are where the long tail lives, because organisations must wait for those vendors to ship these updates. Cloud-hosted systems get patched more readily, while self-hosted and on-premises applications require admins to schedule those fixes.”

Matt Psencik, Threat Research Engineer at Tanium, adds that patching also needs to happen alongside investigation. “Reviewing web server logs for unexplained crashes and unusual upload requests could uncover activity that predates the fix,” he said. “After updating, teams should restart the affected services and confirm they’re running the patched version. A successful deployment report alone doesn’t establish that the vulnerable code has stopped running.”

What This Means for Southeast Asia

For this region, PHP2Shell is not a distant Western headline. Singapore’s Cyber Security Agency (CSA) has treated it as an emergency. Its alert warns that the flaws can let an unauthenticated remote attacker execute arbitrary code, and that widespread exploitation attempts have been reported. Commissioner Gwenda Fong’s message to organisations was short: “do not wait.”

The CSA says it is working with government agencies, critical information infrastructure owners, major enterprises and industry partners to accelerate patching. Its guidance is to audit all systems running PHP, prioritise internet-facing servers, and check whether internal applications bundle vulnerable components indirectly. That last point is easy to overlook. You may be running PHP without knowing it.

In the Philippines, attention has turned to government websites. The questions agencies must answer are which systems use the affected software, whether they have been repaired, and whether anyone got in before the repair. So far, the advisories reviewed do not identify a Philippine government website confirmed to have been breached. A warning is not proof of a hack, but it is a reason to check.

The SME Problem

The CSA has singled out the group most likely to be caught out. Fong cautioned that small businesses relying on outsourced IT and hosting providers could be exposed without realising it. The agency is trying to reach them through industry associations and cybersecurity providers.

That concern fits the region’s web landscape. Southeast Asia has a vast population of small businesses, agencies and local institutions running WordPress or custom PHP sites built years ago, often by a freelancer or vendor who has since moved on. In many cases nobody clearly owns the patching. Add the fact that PHP 8.1 and earlier get no standard fix, and the risk compounds quickly.

There is also a knock-on effect. A compromised small-business site is not only that business’s problem. It can become a foothold into larger partners, suppliers and customers.

What Regional Readers Should Do

Beyond the general steps, three actions matter most here:

1. Ask your hosting provider, in writing, which PHP version your site runs and whether it has been patched. Do not accept a verbal assurance.
2. Check your vendors and appliances. PHP can sit inside products you did not build. Palo Alto Networks has confirmed all PAN-OS versions are affected.
3. Follow your national cyber agency or CERT. Singapore’s CSA has published guidance. If you are elsewhere in the region, check your own authority for local advisories.

PHP2Shell does not discriminate by geography. But a region full of lightly maintained, outsourced and forgotten websites is a generous hunting ground. The attackers are scanning now, which means businesses need to keep pace. Otherwise, attackers will get a considerable headstart, noted Jake Moore, Global Security Advisor at ESET.

“When vulnerabilities are leaked before a patch is available, it is usually a scramble to do whatever is possible to mitigate the damage, but the sheer scale of PHP across the internet makes this far more serious than the usual exploit. A serious vulnerability in technology used by millions of websites could immediately give cybercriminals an enormous number of potential targets,” Moore explained. “A situation like this gives attackers a huge head start. Criminals are known to be extremely quick to exploit any given opportunity, and even a short delay in patching could leave lots of businesses exposed. Businesses should try to identify their vulnerable systems and apply the patch immediately.”

The Bottom Line

The fix exists, and for most people the job is simple: update PHP. The danger is the long tail. Security researcher Kevin Beaumont predicted a mass of incidents, and forensics expert Hal Pomeranz pointed to forgotten, unmaintained apps and embedded systems that will never be patched.

That is the real risk. Not the server you are actively managing, but the old one in the corner that nobody remembers owning. Go and find it before an attacker does.

(This is a fast-moving story. Vendor advisories and patch availability are still being updated, so check your own vendor’s guidance before acting.)