PHP2Shell: What the Critical PHP Vulnerability Means for Your Website

On 21 October 2026, the PHP project shipped emergency fixes for two critical flaws in PHP itself. Researchers call the pair PHP2Shell. Both let an attacker who is not logged in run code on a server that handles web requests. PHP powers most of the web, including WordPress, Drupal, Joomla, Magento, Laravel apps, and a lot of contact forms and admin panels on shared hosting. If your site runs PHP, treat this as a this-week job, not a next-quarter one.

Quick answer

• Fixed versions: PHP 8.5.12, 8.4.27, 8.3.36, or 8.2.35. Anything older on those branches is vulnerable.
• PHP 8.1 and older are end-of-life. There is no official release. Move to a supported branch.
• On shared hosting, switch the PHP version in your hosting panel or ask the host to confirm the patched build.
• If you cannot patch, the US cybersecurity agency CISA says to take the site offline until you can.
• After patching, check for signs of a break-in from 17 October onward, not only from the disclosure date.

What PHP2Shell is

The two flaws are tracked as CVE-2026-109618 and CVE-2026-109619. The PHP security team rates both 9.2 out of 10 (CVSS v4.0). One comes from how PHP cleans up when it runs out of memory partway through a request. The other leaves stale data behind after one request, which a later request on the same worker can reuse. Both sit in how PHP processes incoming form and upload data, which happens before your application code runs. That is why a perfectly written app can still be exposed: the problem is the runtime under it.

PHP says every installation serving web requests is at risk, including Apache with mod_php (the highest risk), PHP-FPM, php-cgi, FrankenPHP, and LiteSpeed. Researchers traced the affected code back to PHP 5.4, so these bugs have been in the language for over a decade. CISA’s alert: https://www.cisa.gov/news-events/alerts/2026/10/21/critical-vulnerabilities-php-require-immediate-patching

Why it was found now, and why that matters

TechCrunch reported that the flaws came to light through AI-assisted research. Security firm Calif found one while working on OpenAI’s “Patch the Planet” programme, and Wiz used its own AI tools to find more. Both worked with the PHP team on fixes before disclosure. Wiz also warned that AI models can help adapt an exploit to different PHP versions and server setups, which used to be the hard part. In other words, the skill barrier that kept old bugs quiet is lower now. Coverage: https://techcrunch.com/2026/10/21/php-armageddon-openai-googles-wiz-find-ancient-holes-panicking-the-internet/

Attacks are already happening. Tenable’s FAQ cites Amazon Threat Intelligence seeing an attempt on 17 October, four days before public disclosure, and broad exploitation attempts since. Cloudflare said it was seeing early attacks on 21 October. Tenable’s summary of versions and exploitation: https://www.tenable.com/blog/php2shell-cve-2026-109618-cve-2026-109619-frequently-asked-questions-about-critical-php-remote

Step 1: find out which PHP version you run

• Shared hosting (Hostinger, cPanel, Plesk): open the PHP configuration or PHP version page in the hosting panel. It shows the active branch and usually the exact version.
• Your own server or VPS: run php -v and also check the version used by the web server, which can differ from the command-line one.
• From outside: many servers send an “X-Powered-By: PHP/8.x.y” header. If you see a version below the fixed release for its branch, you are exposed. Hide that header after you patch.
• Do not forget the side systems: a WordPress blog on a subdomain, an old staging copy, a contact-form script, or a vendor admin panel all count. CISA notes PHP often hides inside other software.

Step 2: update to a fixed release

Updating is the only complete fix. On the 8.3 branch you need 8.3.36 or later; on 8.4, 8.4.27; on 8.5, 8.5.12; on 8.2, 8.2.35. If you use Linux distribution packages, install your vendor’s patched package, since distributions received the fix in advance. On shared hosting you often cannot install a patch yourself, so pick a fixed version in the panel if it is offered, or open a ticket and ask the host to confirm in writing that your account runs a patched build.

If you are still on PHP 7.x or 8.0/8.1, there is no simple update button. The PHP team published minimal source backports for 7.4 to 8.1 for people who build from source, but most businesses should move to a supported branch. That can break old code, so test on a staging copy first. Our guide to modernising legacy PHP software covers how to plan that move without a long freeze.

Step 3: if you truly cannot patch today

The official advice is blunt: if a site cannot be patched, take it off the public internet until it can. Short of that, PHP’s advisory lists configuration changes that reduce exposure to specific attack paths but do not make a server safe. They include setting session.upload_progress.enabled=0, setting memory_limit=-1 in a way applications cannot override, and on PHP 8.5 setting fatal_error_backtraces=0, then restarting every PHP worker. A web application firewall from Cloudflare, AWS, or your host can block known attack patterns while you schedule the update. Treat all of these as a bridge to the patch, not a replacement.

Step 4: check for signs of a break-in

Patching closes the door. It does not remove anyone who already got in. Look back to at least 17 October 2026.

1. Look for new or recently changed .php files, especially in upload, cache, or image folders where PHP files should never exist.
2. Check for new admin users in WordPress, your CMS, or your database that nobody on the team created.
3. Review server logs for PHP processes starting shell commands or downloading tools. CISA calls this out as a key warning sign.
4. Watch for unusual outbound traffic, spam sent from your domain, or sudden CPU spikes.
5. If anything looks wrong, rotate every secret the server could read: database passwords, SMTP and email app passwords, payment and API keys, and admin logins.

If you find evidence of compromise, restore from a known-clean backup taken before the break-in, then patch before you bring the site back online. Restoring an infected copy onto an unpatched server just repeats the problem.

What this does not change

PHP is still a sound choice for business software. WordPress has said the flaw is not WordPress-specific and site owners must patch their servers with their hosts. The real lesson is about upkeep: an unmaintained server running an end-of-life PHP version is the expensive part, not the language. A small monthly routine for updates, backups, and log checks would have made this a one-hour job. That is what our maintenance and support covers.

FAQ

Is my WordPress site affected?

If it runs on an unpatched PHP version, yes. Updating WordPress plugins does not fix it, because the flaw is in PHP itself. Update the server’s PHP version or confirm with your host that it is patched.

My site is behind Cloudflare. Am I safe?

Cloudflare deployed rules for known attack patterns, including on the free plan, and called them a stopgap. They only protect traffic that actually goes through Cloudflare. Patch anyway.

Does a static site have this problem?

Plain HTML pages do not run PHP. But many static sites still have a PHP contact form, a mail script, or an admin panel on the same hosting account. Those files are enough to make the server reachable.

Should I test an exploit on my own site to be sure?

No. Tenable warns that some public exploit code is fake or carries malware. Check the version number and patch. That is the reliable test.