Security alert · 23 October 2026

PHP2Shell explained: why websites went offline worldwide, and what to do now

On 21 October 2026, government websites across the world went dark on purpose. Two critical flaws in PHP, the language behind roughly 70% of websites, were found with AI and leaked before the patch. Here is what happened, in plain English, and a step-by-step plan to protect your business.

What actually happened

This was not a classic outage. No cloud region failed and no DNS broke. Instead, a security emergency forced site owners to choose: stay online with a door anyone could open, or go offline until they patched.

1. AI found the bugs. Researchers from Calif, OpenAI and Wiz used AI models to dig through PHP, code the security community has studied for decades. They found two flaws that let a stranger run their own code on a web server.
2. The secret leaked. PHP planned a coordinated release for 21 October at 14:00 UTC. A day early, the CVE numbers surfaced on Hacker News and social media.
3. Governments acted. The US NSA told organisations to take PHP systems offline if they could not update right away. Japan's prime minister made the same public request. Agencies across Europe and Australia followed.
4. The patch landed. PHP shipped fixed versions, and sites came back one by one as admins upgraded and restarted their servers.

So when people said "the internet broke", what they saw was thousands of sites switched off deliberately. That was the healthy response. The real worry is the sites that stayed online without patching.

How a PHP2Shell attack works

Both flaws live in the PHP runtime, the engine that reads every web request before your website code sees it. That is why your login page, your security plugin and your strong passwords cannot stop this attack.

On Apache with mod_php, the PHP security team confirmed the attack works without login, before any application code runs. On PHP-FPM, used by most Nginx sites and many managed hosts, the risk depends on the application, but popular CMSs do the session handling the attack needs. Wiz says it chained both flaws and ran them in its lab against current WordPress, Drupal and Joomla.

Is your website affected?

If your site runs on PHP and has not been updated since 21 October 2026, assume yes. PHP says every installation serving web requests is at risk: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed.

The long tail is the real problem. Check Point counted about 884,000 internet-facing hosts showing PHP 8.1 or older on 20 October. Many belong to small businesses that do not know which PHP version their site runs.

On shared hosting? Your host patches PHP, not you. Some large hosts patched managed WordPress plans on day one but left VPS customers to update themselves. Ask your host in writing which PHP build your site runs and whether it carries the fix.

Timeline: ten weeks of secrecy, four days of attacks

The researchers reported the bugs privately in August. Attackers had a working exploit before the patch shipped.

Why so many websites went offline at once

A few hours offline costs far less than a breached server. With no login needed and exploit code circulating, governments chose to switch their own sites off.

The lesson for business owners: taking a site offline is a legitimate security control. If you cannot patch tonight, a maintenance page beats a compromised server leaking customer data for months.

Are hackers already using PHP2Shell?

Yes, attempts are widespread, though confirmed breaches are still thin on the public record. As of 23 October 2026:

• Amazon caught a first exploit attempt in its honeypots on 17 October and now calls PHP2Shell broadly exploited.
• Cloudflare reports attack traffic against its customers, with attackers changing payloads to slip past its rules.
• watchTowr and Hadrian report active exploitation, mostly through the session upload progress path.
• NCSC-NL is investigating first signs of successful misuse; HKCERT says both CVEs are exploited.

Public proof-of-concept code exists, so automated scanners are already sweeping the internet for unpatched PHP.

What to do right now

Follow this path. It takes most small business sites under an hour, if you or your host move today.

Step 1: Find every PHP runtime

List every server, container, control panel and appliance that ships PHP. Then check the version your web server actually loads, not just the command line one:

php -v
php-fpm -v
php -i | grep -i session.upload_progress
curl -sI https://yourdomain.com | grep -iE "^(server|x-powered-by):"

A missing X-Powered-By header does not mean you are safe. It only means PHP is not advertising itself.

Step 2: Patch internet-facing servers first

Upgrade to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or install your Linux distribution's fixed package. Distribution packages keep their own version numbers, so check the vendor notice:

• Ubuntu: USN-8948-1 and USN-8948-2 (older releases through Ubuntu Pro ESM)
• Debian 13: DSA-6574-1 (php8.4 8.4.27-1~deb13u1)
• Red Hat Enterprise Linux 9: RHSA-2026:87072 (php:8.2 module to 8.2.35)

Step 3: Restart PHP

This step gets missed constantly. Running PHP-FPM workers keep the old, vulnerable code in memory until you restart them. Restart PHP-FPM or Apache, then confirm the version again.

Step 4: Can't patch tonight? Reduce the risk

PHP says no workaround makes you fully safe. These settings only close the known attack paths:

Set these in php.ini, the PHP-FPM pool or the web server configuration, never with ini_set() or .user.ini, and restart every worker. A web application firewall adds a layer, but attackers are already varying payloads to get past them. Still cannot patch? Take the site offline.

Step 5: Look for signs of compromise

Check logs back to at least 17 October for:

• PHP worker processes (php-fpm, httpd, apache2, php-cgi) starting shells or tools such as sh, bash, python, perl, curl or wget
• Bursts of malformed upload requests followed by memory errors or repeated HTTP 500 responses
• Unusually large or malformed PHPSESSID cookies
• Commands such as whoami, id or uname -a run by the web server user
• New files in the web root, new scheduled jobs or new admin accounts

Patching closes the door. Backups get you back.

If a server was breached between 17 October and the moment you patched, upgrading PHP does not remove the attacker. The safe path is to rebuild from a backup you know is clean.

That plan only works if three things are true:

• You have backups from before 17 October that an attacker on the server could not reach or alter, kept offsite or immutable.
• Those backups actually restore, and you have tested a restore recently.
• You know how long a full restore takes, and the business can live with that downtime.

This is where many small businesses get caught out. A backup job that shows a green tick every night is not the same as a restore that works on the day you need it.

The bigger lessons

AI has changed the speed of security

PHP is one of the most studied codebases on earth, and the researchers did not expect to find anything critical. AI found it anyway. The same tools are available to attackers, so the gap between "bug found" and "bug exploited" is shrinking from months to days.

"Set and forget" websites are a liability

If nobody in your business can say which PHP version your site runs within five minutes, that is the first risk to fix. Note that support for PHP 8.2 ends on 31 December 2026, and active support for 8.4 ends the same day.

Patching is a process, not a button

Breaches happen in the gap between "we updated" and "we are safe": the forgotten staging server, the worker never restarted, the vendor appliance with its own PHP. You need an inventory, a priority order and a check afterwards.

Decide on downtime before the emergency

Governments chose to go offline for hours. Could your business? A simple maintenance or failover plan, agreed in advance, turns a panic into a routine change window.

Sources

• PHP security advisories (GitHub)
• CISA: Critical Vulnerabilities in PHP Require Immediate Patching
• Brandefense: PHP2Shell analysis and timeline
• watchTowr: PHP2Shell FAQ
• Tenable: php2shell FAQ
• University of Washington IT: Critical PHP vulnerabilities
• Axios: How AI exposed the PHP flaw
• Fortune: The race to patch PHP
• Al Jazeera: World leaders warn of PHP flaws
• PBS NewsHour: The rush to patch
• ABC7: Websites shut down globally

This article reflects public information as of 23 October 2026. Check your vendor's advisory for the latest package versions.