PHP2Shell Is Under Attack: Why Updating Your CMS Is Not Enough

by Secuna Team

Your WordPress is up to date. Your plugins are up to date. Your site could still be wide open.

That is the uncomfortable message of PHP2Shell, a pair of critical flaws disclosed on October 21 in PHP itself, the programming language underneath 69.1 percent of the websites whose server-side language is known. Both are rated 9.2 out of 10 for severity, and both can let an unauthenticated attacker run code on a server. On October 26, CISA confirmed that attackers are exploiting them.

What Makes This Different From a Plugin Flaw

Most website vulnerabilities live in something you can update from a dashboard: a plugin, a theme, a CMS. PHP2Shell does not. The flaws are in the PHP engine, the runtime that executes your website's code.

Think of your CMS and plugins as the furniture and PHP as the foundation. You can replace every piece of furniture and the crack in the foundation is still there.

Wiz Research, which co-disclosed the flaws, describes memory-safety bugs in how PHP handles fatal errors, especially out-of-memory conditions, that can leave stale internal state behind for a later request to reuse. Because the weakness sits below the application, clean application code does not protect against it. As Sansec put it, the flaws are in the engine, so Magento, Shopware, and WooCommerce are affected even with clean application code.

CERT-PH, the Philippines' national incident response team, made the same point plainly: updating a CMS or website application without updating the underlying PHP installation does not remediate the vulnerability.

Here is how the flaws work. They are tracked as CVE-2026-109618 and CVE-2026-109619, and both come from PHP not cleaning up properly after errors. The first is a use-after-free in the upload-progress feature, which can let an attacker read memory from the process. The second involves a stale pointer left after a fatal error, plus a type confusion in OPcache, the component that caches compiled code. Together, they can turn a memory error into code execution.

Wiz demonstrated unauthenticated code execution against the latest WordPress, Drupal, and Joomla container images. The affected code dates back to PHP 5.4. JFrog notes that the upload-progress setting involved is on by default, and the PHP team rates the risk highest for Apache's mod_php, still common on older and shared hosting.

The Timeline Is the Alarming Part

The attacks did not wait for the patch.

According to The Register, AWS saw exploit attempts starting October 17, four days before public disclosure and before the October 21 patches. On October 21, Cloudflare said it observed attack traffic targeting its customers, with attackers mutating payloads to try to get past its protections. PHP released fixes that afternoon.

By October 24, researcher Adel Karimi of Perplexity reported 35 successful shell executions across three honeypots running PHP 8.4.26 under Apache mod_php, using memory exhaustion and disclosure to reach code execution. He cautioned that his setup favored the attacker and may not reflect production servers.

The Delft University Threat Intelligence Lab tracked more than 50,000 exploitation requests from over 600 IP addresses, and 171 of them sent exploit code or malware droppers rather than just probing. On October 26, CISA added both flaws to its Known Exploited Vulnerabilities catalog and gave U.S. federal agencies until October 29 to fix them. That deadline does not bind Philippine organizations, but it shows how urgently CISA rates the risk. For local organizations, the CERT-PH advisory is the closer benchmark.

Attempts began before most defenders knew the flaws existed, and exploit code was circulating within days. Any organization planning to "get to it next sprint" is working on a calendar the attackers have already overtaken.

PHP also runs in places that do not look like websites. Palo Alto Networks' Unit 42 added a confirmed case that shows how far PHP reaches: PHP2Shell was exploited against internet-exposed management interfaces of PAN-OS firewalls, with attackers reportedly chaining it with a Linux kernel flaw to gain root access. Palo Alto says the impact was limited, affecting about 0.02 percent of its installed base that had internet-facing management interfaces.

The share is small, but the lesson is large. A firewall is not a website, and it still had PHP behind its management page. The same applies to routers, storage appliances, and the admin panels of commercial software. If a device serves a web interface, ask what runs it.

The story has also had corrections, and they matter. Palo Alto Networks withdrew an earlier claim linking the flaws to an intrusion at a European government agency, and Unit 42 now says it cannot confirm that the initial access in that incident is associated with the PHP2Shell CVEs. Sophos revised its assessment to say its observed activity was scanning and failed attempts. Sansec reported that some public proof-of-concept exploits do not work against a default PHP installation, and said mass exploitation is less likely than it first expected. CISA has not named compromised organizations or said how many production systems were breached.

None of that is a reason to relax. Exploitation is confirmed, attempts are widespread, and reliability varies by configuration. A server that is hard to exploit today is not a patched server.

Who Is Exposed, and Why It Is Hard to Fix

All PHP installations that serve web requests are in scope, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed. The fixed versions are 8.5.12, 8.4.27, 8.3.36, and 8.2.35. For everyone else, the news is worse: PHP 8.1 and older no longer receive updates from the PHP project, and only minimal source backports were released for 8.1, 8.0, and 7.4. Organizations on those branches need a vendor-backported fix or an upgrade.

Recorded Future, citing Modat, reports that about 79 percent of PHP services with a readable version run unsupported branches. Censys estimates that more than 32 million PHP services still run an affected version, though that figure is an estimate of exposure, not a count of confirmed vulnerable or compromised servers.

Fixing this is also harder than patching a plugin. A plugin update is one click for the site owner. A PHP update is rarely that simple, because the layer belongs to someone different in almost every setup. On shared hosting, the provider controls it. In containers, the fix means rebuilding and redeploying the image. In vendor software and appliances, the vendor decides when a fix ships. On older branches, there may be no official fix at all.

In each case, "we are patched" can be true for the application and false for the runtime. For leaders, that makes this partly a vendor-management problem.

The Philippine Context

CERT-PH issued an advisory on October 22, as reported by Newsbytes.ph, telling government and private-sector organizations to review their PHP environments, apply patches, monitor logs for unauthorized access or code execution, and activate incident response if a compromise is suspected. The reporting noted concern for government registration portals and other online transactions. It also said the sources reviewed did not establish that any Philippine organization has been compromised. No Philippine-specific exposure figures were available, so treat the local picture as unmeasured rather than safe.

CERT-PH's guidance stresses the places organizations forget: outsourced websites, shared hosting, and commercial software that contains PHP. Singapore's Cyber Security Agency, whose alert covers all versions of PHP, gave similar direction: identify every system running PHP, prioritize internet-facing ones, and check for PHP in third-party components even where the main site does not use it.

What to Do Now

Update PHP itself. Move to 8.5.12, 8.4.27, 8.3.36, or 8.2.35, or obtain a vendor-backported fix for older branches. Restart PHP workers afterward. Ask your hosting provider directly, because on shared hosting you may not control it.

Build an inventory of every PHP system. Include public websites, portals, internal tools, outsourced sites, and appliances with web management interfaces.

Treat temporary mitigations as temporary. Disabling upload progress and adjusting memory and upload limits help, but none fully prevents exploitation, and PHP core developers say patching is the only permanent defense. A web application firewall adds a layer, but Cloudflare itself advises patching even with its protections in place.

Look for signs of compromise. Wiz lists unusual multipart requests followed by memory-limit errors, repeated HTTP 500 responses, unusually large or malformed session cookies, and unexplained PHP worker churn. CERT-PH notes that repeated server errors alone do not prove an attack. Because attempts began before the patch, a server exposed between October 17 and its update date deserves a log review, not just an update.

Keep watching. On October 23, the PHP project published a further advisory, CVE-2026-115560, in the same session upload-progress feature. It requires a specific configuration, and as of the reporting reviewed here the October 21 releases did not fix it. Disabling session upload progress is the recommended mitigation meanwhile. Check the current PHP advisories before assuming you are done.

For leaders who are not running the servers, four questions move this forward this week:

  • Which PHP versions run our websites, portals, and outsourced systems, and who owns each?
  • Which were patched, and how do we know?
  • Have our vendors and hosting providers confirmed their status in writing?
  • If a server was exposed before it was patched, who is reviewing its logs?

Vague answers are the finding. They show where an attacker would look first.

Find the PHP You Forgot About

PHP2Shell is a vulnerability, but it also exposes a visibility problem. Patching only works on systems you know about, and a forgotten system is an unpatched one. The old marketing site, the vendor-hosted portal, and the appliance with an internet-facing management page are where attackers look first.

Closing that gap takes an internal inventory and an outside view of what is actually reachable. An independent assessment provides the second: a view of real internet-facing exposure from an attacker's position, which helps teams decide what to fix first and confirms that what was supposed to be updated actually was.

That is the role of Secuna Pentest: manual, scoped testing of web applications, networks, cloud infrastructure, mobile apps, and APIs to identify exploitable weaknesses. Secuna is a DICT-recognized VAPT provider under the D-TAP program.

Penetration testing does not replace patching, and it does not guarantee that every forgotten system is found. It works alongside patching and inventory, not instead of them.

The patch for PHP2Shell exists, and attackers are already using the flaws. The organizations that come out intact will be the ones that updated the layer beneath their websites, not just the layer on top, and knew every system that was running it.

To learn more, reach out to our team at sales@secuna.io or explore our services at secuna.io.

Sources: PHP2Shell: AI Uncovers Critical RCE Vulnerabilities Affecting 70% of the Internet, Wiz · PHP2Shell: PHP RCE (CVE-2026-109618, CVE-2026-109619), Sansec · PHP2Shell: All You Need to Know About CVE-2026-109618 and CVE-2026-109619, JFrog Security Research · PHP Ships Emergency Patches for Critical PHP2Shell Flaws, BleepingComputer · CISA Confirms PHP2Shell Under Attack as Researchers Clock Successful Exploits, The Register · CISA Confirms Active Exploitation of Two PHP2Shell Flaws, The Hacker News · Threat Brief: Critical Vulnerabilities in PHP, Unit 42 · Cloudflare Deploys Protections Against php2shell Vulnerability, Cloudflare · PHP2Shell Vulnerability Exploitation, Recorded Future · Critical Vulnerabilities in PHP (PHP2Shell), Cyber Security Agency of Singapore · DICT Cybersecurity Unit Warns of Critical PHP Flaws, Newsbytes.ph · DICT Calls for PHP Updates to Protect Philippine Websites, Back End News · A New PHP CVE Was Announced. Here's What You Need to Know, Server Side Up · Usage Statistics and Market Share of PHP for Websites, W3Techs