PHP2Shell: Why Leaving PHP Won't Solve Your Security Problems

On 21 October 2026, the PHP project shipped emergency fixes for two critical flaws in PHP itself, CVE-2026-109618 and CVE-2026-109619, nicknamed PHP2Shell. Details had leaked, so the PHP team moved the release a day earlier. Within hours, government agencies in several countries told site owners to take unpatched servers offline, and many did. In Germany, the federal security agency BSI noted that several websites in the country had become unreachable as operators disconnected them.

The obvious question followed fast, and it is a fair one. If a single flaw in the language can take government websites offline, should companies still build on PHP?

Our short answer: this is an ordinary industry security incident at an unusual scale. A full rewrite can take years and creates delivery risk of its own. It also does not protect you from the next incident of this kind, because every platform gets critical flaws. What PHP2Shell does expose is how many companies run PHP: old versions, no inventory, slow patching. That is what deserves a rethink. None of the advisories we read recommends abandoning PHP: not PHP's own, not those of CERT-EU, the UK's NCSC, Germany's BSI, Cloudflare or Red Hat.

Below are the questions we keep hearing, answered from primary sources – including what PHP2Shell means for companies that build and run financial products.

How much of the web still runs on PHP?

Most of it, by a wide margin. According to W3Techs, PHP runs on 69.3% of websites whose server-side language can be identified, in a sample of more than 20 million sites. JavaScript, the runner-up, is at 8.1%. The share is falling, but slowly: 79.1% in January 2021, 72.4% in January 2026, 69.3% today. There has never been a sudden drop, including after earlier critical PHP flaws.

WordPress alone runs on 39.6% of all websites. PHP also runs WooCommerce, Magento (Adobe Commerce), Drupal, Joomla, Moodle and Nextcloud. It runs MediaWiki, the software behind Wikipedia, and the Laravel and Symfony frameworks. Together they cover most of the web's content management, a large part of its online shops, and a great deal of custom business software.

PHP is also embedded where few people look: hosting control panels, firewall appliances such as pfSense and OPNsense, and packaged business systems. The Dutch NCSC keeps a public list of affected products for this reason.

One correction to a common belief: Facebook does not run on PHP. Meta runs Hack, its own language, on its own engine, which dropped PHP support years ago. Slack moved to Hack as well.

How serious is PHP2Shell?

Serious, for three reasons.

It sits below your application. Both flaws let an attacker run code on the server without logging in. In the confirmed attack scenario for CVE-2026-109618 on Apache with mod_php, the attack runs inside the PHP runtime – the program that executes a site's code – before the site's own code starts. In other configurations, exploitation depends on additional conditions and on how the application behaves. Either way, updating WordPress, Drupal or your own code does not close the flaw; only the fix to the runtime does. The PHP security team rates Apache with mod_php as the highest-risk setup. Red Hat considers an attack harder, but not impossible, on the PHP-FPM setup typical for its systems.

One of the flaws leaks memory. Wiz, one of the teams that found the flaws, calls it "Heartbleed-style". An attacker can read the memory of the server process, where database passwords, API keys and session tokens live. That kind of theft leaves no reliable trace in logs.

It hits almost every PHP application. Calif, another of those teams, broke into eleven applications in its tests without logging in: WordPress, Drupal, Joomla, MediaWiki, Roundcube, Magento, phpMyAdmin, Nextcloud, Laravel, Symfony and WHMCS. These are the researchers' own results, not proof that every installation is equally exposed. They do show that the attack is not limited to unusual setups.

PHP rates both flaws 9.2 out of 10 on CVSS v4.0, the industry's standard severity scale. Germany's BSI rated its warning 3 on its 4-level scale, meaning action is needed without delay.

Exploitation is now confirmed. On 24 October, a researcher recorded successful remote code execution against honeypot servers – decoy systems – running Apache with mod_php on an unpatched PHP 8.4.26. On 26 October, CISA, the US cybersecurity agency, added both flaws to its catalogue of known exploited vulnerabilities, giving federal agencies until 29 October to patch. The honeypot results do not by themselves prove mass breaches of production sites, but the window between "theoretical" and "exploited" has closed.

One more flaw is still open. On 23 October, PHP disclosed a separate issue, CVE-2026-115560, linked to the session upload progress feature. It depends on a rare combination of server settings and application code, and the 21 October fixes do not cover it; as of this writing, its fix is expected in the next regular PHP release. The PHP advisory describes how to reduce exposure in the meantime. Installing the 21 October patches is necessary, but it is not the end of the PHP security news for this month.

For a business, the real risks are concrete. An attacker can take customer data from the database or inject a card skimmer into a checkout page. They can leave a backdoor for later, or steal keys that keep working after the server is patched.

A note on how the flaws were found, since it has been widely retold. The teams at Wiz, Calif and OpenAI used AI models in their research, and Wiz names its tools. People from three teams found the flaws with those tools; no model found them alone.

What PHP2Shell means for financial products

For fintech companies, banks and payment businesses, the general risks above take a sharper form.

A compromised backend can put payment flows at risk. In a payment or lending product, the PHP application often sits between the customer and the systems that move money. An attacker inside that process can alter what is shown to the customer, tamper with payment instructions before they leave, or plant a skimmer on a checkout page, putting payment-card data at risk.

Stolen keys outlive the patch. The memory leak matters most where the server holds credentials for other systems: API keys for payment providers, banking partners, KYC services and core platforms. Patching PHP does not revoke a key that was copied before the fix. Rotating integration credentials belongs on the same checklist as updating the runtime.

Your inventory includes your vendors. Admin panels, merchant portals, back-office tools and packaged systems from third parties may run PHP you never deployed yourself. Ask each vendor and partner for written confirmation of their patch status, the same way you would for your own servers.

Taking a system offline has a price. The advice to disconnect unpatched servers is sound, but in financial services an outage means failed payments, missed settlement windows and support queues. The operational goal is to patch quickly without unnecessary downtime. That requires an accurate inventory, a tested update process, and a way to move traffic to patched instances.

What should companies running PHP do?

Patching closes the vulnerability. It does not undo a compromise that may have happened before the fix. Here is the order that covers both.

• Find every PHP instance. Not only your websites: containers, hosting panels, internal tools, and products that bundle PHP inside.

• Update the runtime. The fixed releases are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. For 7.4, 8.0 and 8.1, the PHP team published changes to the source code but no new releases. Linux distributions and commercial long-term support vendors ship their own fixed packages for older versions.

• Restart every PHP process. A patched package does nothing while the old process keeps running.

• Check the package, not the version number. Distributions put the fix into the existing version. So `php -v` can look unpatched on a fixed system, and the reverse. Compare the package version with your distribution's advisory.

• Rebuild containers. A Docker image keeps the PHP it was built with.

• If you cannot patch today, apply the temporary settings from the PHP advisory or take the site offline. BSI, CERT-EU and NCSC all say the temporary settings reduce the risk but do not remove it.

• Address the separate open issue. Review your exposure to CVE-2026-115560 and apply PHP's recommended configuration mitigation where needed while awaiting the fix.

• After patching, look for signs of a breach and change passwords and keys. Details leaked before the fix shipped. Check every server that was exposed before patching, and change its passwords and keys whatever the check finds.

Should you migrate to another language instead? Not because of this. The migration that matters is between PHP versions. By our estimate from W3Techs data, roughly half of PHP websites run on versions the PHP project no longer supports. When PHP 8.2 reaches end of life on 31 December 2026, that becomes about two thirds. On a day like 21 October, those sites get no official release. They depend on whoever adapts the fix to their old version.

Who updates PHP when there is no in-house team?

Everything above assumes someone in the company knows where PHP runs. Many smaller businesses do not: a site or a web shop was built years ago, it works, and nobody has asked what it runs on since. Being small does not make them safe – watchTowr saw PHP2Shell exploited in its honeypots, decoy servers hit only because they answered.

Responsibility depends on where the system lives. On hosted website platforms, the provider manages the underlying runtime; confirm separately who maintains any custom apps or external integrations. On shared hosting, the hosting company does – cPanel, for example, shipped fixed builds for PHP 7.4 through 8.5 on 21 October. Under a support contract, it is the agency or developer, who should confirm the fix in writing. The dangerous case is a server set up years ago by someone who has since left: then nobody updates it unless the company arranges it. If nobody can say who updates PHP on a system, that is the finding – and rebuilding the site in another language would not change it.

When does moving off PHP make sense?

The serious alternatives are well known: Node.js with TypeScript, Python (Django, FastAPI), Go, Java or Kotlin with Spring, .NET, Ruby on Rails. Each has its strengths, and each has had its own critical incidents. Log4Shell hit Java's most popular logging library in 2021. The npm package registry for JavaScript has seen repeated attacks through third-party packages. Changing the language changes which advisories you read, not whether you need to patch.

Moving is justified when the reason would exist without PHP2Shell:

• The system is being rewritten anyway, because the product or the data model has outgrown it.

• There is no PHP team and there will not be one, and the rest of the company works in another stack.

• The workload no longer fits the current architecture, and another stack offers a demonstrably better operational fit.

• The code is old PHP 5 without tests, where lifting it to PHP 8 costs about as much as rewriting. That choice is then made on the merits of the system, not the headline.

What a business runs into when it moves:

• The rewrite itself. While the team builds the new system, the old one still needs maintenance, and new features mostly stop. Netscape's decision to rewrite its browser from scratch is the classic warning.

• The platform, not just the language. For WordPress, WooCommerce, Magento or Moodle, leaving PHP means leaving the platform, its plugins, integrations and contractor market.

• New operations. A new stack brings new ways to deploy, monitor and update. Those are exactly where breaches usually start.

Patch, modernize or rebuild: how to decide

Once the emergency work is done, the long-term question is not "PHP or not PHP". It is: do we know where our PHP runs, which versions it is, and how fast we can update it? If the answers are "no", "old" and "slowly", that is the risk, and it would follow you to any other stack. The answers put each system in one of three situations.

Patch and move on when the system runs a supported PHP version, you know where every instance is, and the update went through without drama. The incident confirmed that your process works. Keep the inventory current and rehearse the next update.

Plan a PHP modernization when the system has no reliable security support, its support window is closing, or updates are delayed because nobody knows what will break. The fix here is an upgrade path to a supported PHP version, test coverage around critical flows, and an automated deployment that makes the next emergency patch routine.

Consider a rebuild only when one of the reasons in section 5 already applies: the product has outgrown the system, the team has no PHP skills and never will, the workload no longer fits the current architecture, or the legacy code costs as much to lift as to replace. Then the decision is driven by the system's future, with PHP2Shell as a prompt rather than the reason.

At Itexus, we help fintech companies, banks and wealth management firms modernize the platforms they already run – from legacy assessment to step-by-step upgrades and release processes that make critical patches routine. Contact Itexus to assess your legacy platform and plan a phased modernization around your critical business workflows.