PHP2Shell Explained: Who's at Risk and What to Do This Week

On 21 October 2026 the PHP team shipped emergency fixes for two critical flaws now known as PHP2Shell (CVE-2026-109618 and CVE-2026-109619). In plain words: a stranger on the internet could send carefully built requests to a website that runs on PHP and end up running their own code on that server. No password, no login.

I spent a major chunk of my career on banking and payment systems, where a failure costs real money. I worked on State Bank of India's core banking system as an engineer at TCS, then spent five years on eBay and PayPal's architecture team, working on PayPal's notifications: email, SMS, push and the payment messages merchants' servers rely on. Today I run Zunderdog, where we build and run software for businesses in India, Japan and the USA. This is the brief I'd give a client: what to tell your CEO, what to check and what to do this week.

The Short Version for Your CEO

• What happened: two critical flaws in PHP, the language behind most of the web, let attackers take over a web server without a password.
• Are we exposed? Yes, if any website, portal or tool we use runs on PHP and hasn't been updated since 21 October. That includes software our vendors and hosts run for us.
• How urgent is it? Very. Attackers started trying it before the fix came out and India's CERT-In has warned of large-scale exploitation.
• What we do: patch this week, check the patch really took effect, get written answers from every vendor and plan to move anything on PHP 8.1 or older to a supported version.
• Who owns it: one named person, with a deadline.

What PHP2Shell Is, in Plain Words

PHP is the language behind WordPress, Drupal, Magento and Laravel apps, plus countless custom portals built over the last twenty years. According to W3Techs (opens in a new tab), PHP runs 69.3% of the websites whose server-side language it can identify. More than a quarter of those PHP sites are still on PHP 7.

PHP2Shell is two separate bugs in PHP itself, not in any one app, plugin or theme:

• CVE-2026-109618 is about running out of memory. If PHP hits its memory limit at an awkward moment, it can leave a request half set up. The clean-up code then treats that half-built data as valid. An attacker who shapes the request can use that mistake to take control.
• CVE-2026-109619 is about leftovers. Some data from one request can survive after its memory has been freed. The next request handled by the same PHP process can then pick it up. An attacker sends one request to plant the leftovers and another to use them.

PHP rates both 9.2 out of 10, which is Critical. The result is the same for both: the attacker's code runs on your server with the web server's permissions. From there they can read your database passwords and API keys, plant a backdoor or move deeper into your network.

PHP's advisory (opens in a new tab) says the risk is highest for servers that run PHP inside the Apache web server (a setup called mod_php, common on older servers). There, researchers showed an attack that works before the website's own code even runs. So careful coding in your app won't save you. Calif (opens in a new tab), one of the research teams, says it confirmed working attacks against current versions of WordPress, Drupal, Joomla, Magento, phpMyAdmin and Nextcloud, plus apps built on Laravel and Symfony.

To be fair to the other side, Red Hat (opens in a new tab) rates the first flaw as Important rather than Critical for its default setup (PHP-FPM). It says a working attack there is difficult and typically needs the app to behave in unusual ways. I'd still patch.

How Urgent Is It?

Attackers didn't wait for the fix. Details leaked before the planned release and Cloudflare (opens in a new tab) says it saw attack traffic against its customers, with attackers changing their payloads to slip past its defences. In India, CERT-In's advisory of 22 October (opens in a new tab), written for small and mid-sized businesses, says multiple reports confirm large-scale exploitation in the wild and tells them to patch urgently.

To be precise: as of 24 October I haven't found a public report of a confirmed successful break-in. Hostinger says the exploit code that was circulating didn't work against its servers. CISA hasn't added either flaw to its Known Exploited Vulnerabilities catalogue (opens in a new tab), the US government's list of bugs seen in real attacks. I wouldn't bet a payments system on "yet". Now that the fix is public, anyone can compare the old and new code to see exactly what changed.

Are You Affected?

If a server answers web requests with PHP and hasn't been patched since 21 October, assume yes. PHP lists every common way of running it as affected: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed.

Three checks I'd do today:

1. Find every PHP server, not just the website. The main site is the one everyone knows about. The vendor portal, the old admin panel, the blog someone set up in 2018 and the box that sends statements every night are the ones that get you.
2. Check the version the right way. The PHP your team sees on the command line can differ from the one that actually serves your web pages. Check what the web server runs too. And the version number alone often won't tell you. Ubuntu, Plesk and many hosts patch their own packages and keep the old number. A patched Ubuntu 24.04 server, for example, still reports PHP 8.3.6. Check the package's build date or changelog against your vendor's notice: Ubuntu (opens in a new tab), Debian (opens in a new tab) or Red Hat (opens in a new tab).
3. Ask every vendor and host in writing. Big hosts such as Hostinger (opens in a new tab) and GoDaddy (opens in a new tab) say they've patched their managed plans. On a VPS or your own server, patching is your job. The questions to ask are below.

What to Do This Week

1. Patch. Update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35. On an older version, install your vendor's or host's fixed package. Then make sure PHP and the web server have restarted, because old processes keep running the old code until they do.
2. Verify. Check the version again from the web side, not just the command line. CERT-In's advisory says the same thing: confirm the updated PHP is the one actually in use.
3. If you truly can't patch today, use the stopgaps. Put admin panels and internal tools behind a VPN or an allow-list of your own IP addresses. Your tech team should also apply the measures in PHP's advisory: switch off session upload progress (session.upload_progress.enabled=0 in the server's PHP settings, not in the app), keep post_max_size low and limit request sizes at the web server. If your firewall provider has published rules for PHP2Shell, switch them on. PHP is blunt about all of this: there are no complete mitigations and updating is the only safe choice. Stopgaps buy you days, not months.
4. Look for signs someone got in first. Check for new or changed PHP files in upload and cache folders, admin users nobody remembers creating, unusual outbound connections from the web server and PHP crashing in your logs. If anything looks wrong, assume the worst and change every password and key that server could read. In India, report it to CERT-In: its 2022 directions give organisations six hours to report a cyber incident once they notice it.
5. Keep the evidence. Write down what you found, when you patched and how you checked. If you're regulated, it's what your auditors will ask for.
6. Book the upgrade. If you were on PHP 8.1 or older, PHP2Shell is your warning shot. I've written a separate guide on moving from PHP 7 to PHP 8: the plan, the timeline and what drives the cost.

One more tip for your tech team: leave session upload progress switched off even after you patch. On 23 October PHP announced a third, less likely flaw (opens in a new tab) in that feature, which the new releases don't fix yet.

Questions to Ask Your Vendors and Host

If a vendor built or runs any of your PHP software, you can't patch it yourself. Send them these questions today and keep the replies:

1. Which PHP version and build runs our application and on which servers?
2. Have you applied the PHP2Shell fixes (CVE-2026-109618 and CVE-2026-109619)? On what date? How did you confirm the patched PHP is the one serving our traffic?
3. If we're on PHP 8.1 or older, whose patched build are you using? When will you move us to a supported version?
4. Does our application use encoded modules (ionCube or similar) that hold back a PHP upgrade? When will you have a release that runs on PHP 8.4 or 8.5?
5. Have you checked our servers for signs of compromise in the last few weeks? What did you find?
6. Who tested the update and can we see the results?

A vendor who can't answer these quickly is telling you something.

Why It Won't Be the Last One

PHP2Shell was found with frontier AI models doing a lot of the heavy lifting, in code that had sat inside PHP for more than a decade. According to OpenAI (opens in a new tab), Calif found a critical flaw with OpenAI's GPT-5.6 Sol model, as part of OpenAI's Patch the Planet programme. Wiz (opens in a new tab) independently found and reported both flaws and says it used Google's Gemini 4 Argon and GPT-5.6 Sol throughout.

Take the vendor claims with a pinch of salt: every company involved has a stake in the story. Calif's researcher says no model finds every bug from a simple prompt and that his own knowledge of PHP drove the work. But he also says the first discovery used no special setup and no models that weren't available to everyone. That's the part that matters, because the same tools work for attackers. In November 2025 Anthropic (opens in a new tab), the company behind Claude, reported that a group it assessed as Chinese state-sponsored had used its Claude Code tool to do 80 to 90% of the work in a hacking campaign. The targets were about 30 organisations, financial institutions among them. The group got into a small number. In June, Anthropic's own red team reported (opens in a new tab) that its most capable model, which isn't public, built eight working exploits from recent Firefox security fixes in about 12 hours in a lab test.

Two lessons from my own career apply here.

On State Bank of India's core banking system, I learned that when every change is a risk, change gets slow. At TCS I tuned the database behind the bank's most-used transactions. When branches across the country depend on one system, every change is tested hard and released in a planned window. That discipline is right. The risk is that a critical security fix then has to wait for its slot. The answer isn't to skip testing. It's to automate testing and release so well that a security fix gets the same checks in days, not weeks.

At PayPal, the rule was to verify, not trust. I worked on PayPal's notifications, including IPN, the message PayPal sends to a merchant's server when a payment goes through. PayPal's IPN guide (opens in a new tab) tells merchants to send every message back to PayPal, which answers VERIFIED only if it matches the one it sent. The reason is simple: anyone can send a fake one to your server. Patching works the same way. "We're on 8.4" isn't a fact until someone has checked which 8.4, on which server, serving which site.

Finding flaws is getting cheap and fast. Fixing them is now the bottleneck. That's why I think banking will have to change the way it works: how it tests, how fast it releases and how it holds its vendors to account. Fintech isn't untouched either. Newer systems still sit on the same open-source building blocks and AI is finding flaws in those just as fast. Over the past month I've been talking to major banks about exactly this: what has to change and how to put it into practice. I've set out what I'd change first in a separate piece on AI and banking.

How We Can Help

At Zunderdog we build and run software for businesses that can't afford downtime. For PHP2Shell and what comes after it:

• Patch and verify: we patch, restart and check that the fix is live on the servers that actually serve your traffic, working inside your change process.
• Upgrade old PHP: we move apps from PHP 7.x or 8.1 to a supported 8.4 or 8.5, with tests around the money paths first. Testing changes to systems that move money is home ground for us. Our custom software team does this work.
• Pipelines that make patching routine: automated tests, dependency alerts and quick rollbacks through our Backend, Cloud and DevOps practice.

Nobody can honestly promise you'll never be hacked and I won't. What we can do is make patching routine instead of a scramble.

If you'd like a second opinion on your setup, book a 30-minute call with me or tell us what you run. If you work in a bank or a fintech and you're facing the same questions, I'd be glad to compare notes.

Quick Answers

What is PHP2Shell? Two critical flaws in PHP itself, CVE-2026-109618 and CVE-2026-109619, fixed on 21 October 2026. They can let an attacker run code on a web server without logging in.

Is WordPress affected? The flaws are in PHP, not WordPress. Any WordPress site on an unpatched PHP version is at risk. Updating plugins won't fix this. Updating PHP will.

Is PHP2Shell being exploited? Attackers have been trying it at scale since before the fix came out and India's CERT-In says multiple reports confirm large-scale exploitation. As of 24 October I haven't found a public report of a confirmed successful break-in and it isn't on CISA's list of vulnerabilities known to be used in attacks. That can change any day. Patch now.

Does a web application firewall protect me? Partly and for a while. A firewall rule can block known attack patterns. PHP still says updating is the only safe choice.

Sources

• PHP: security release and advisory of 21 October 2026 (opens in a new tab), with GitHub advisories for CVE-2026-109618 (opens in a new tab) and CVE-2026-109619 (opens in a new tab)
• PHP: supported versions (opens in a new tab)
• CERT-In: advisory CIAD-2026-0052 on PHP2Shell (opens in a new tab)
• Calif: PHP2Shell write-up (opens in a new tab)
• Wiz: PHP2Shell research (opens in a new tab)
• OpenAI: Patch the Planet coordinated disclosure (opens in a new tab)
• Cloudflare: WAF protection for the PHP vulnerabilities (opens in a new tab)
• Vendor notices for CVE-2026-109618: Ubuntu (opens in a new tab), Debian (opens in a new tab) and Red Hat (opens in a new tab)
• Hosts: Hostinger (opens in a new tab) and GoDaddy (opens in a new tab)
• CISA: Known Exploited Vulnerabilities catalogue (opens in a new tab)
• W3Techs: usage statistics of PHP (opens in a new tab)
• Anthropic: disrupting an AI-orchestrated espionage campaign (opens in a new tab) and research on turning patches into exploits (opens in a new tab)
• PayPal: IPN implementation guide (opens in a new tab)