Black October 2026: The PHP2Shell Crisis, Who Was Hit, and How to Protect Your Site

What is Black October 2026?

“Black October” is an informal name for the cyber crisis that began on October 21, 2026, when the PHP project patched two critical flaws nicknamed PHP2Shell (CVE-2026-109618 and CVE-2026-109619). Both let an attacker with no login run code on a web server. The NSA, CISA, the FBI, and agencies in the UK, EU, Malaysia, and Ghana urged immediate patching, and some government, school, and healthcare sites were pulled offline as a precaution.

The name is not official. It comes from commentary, including a widely shared video, that bundles the PHP crisis with other incidents from the same days. The PHP2Shell facts are corroborated by many independent outlets and by government alerts. The wider claims (27 major incidents in 48 hours, data exposure by Meta AI agents, certificate authority lapses) could not be verified from primary sources, so treat them as unconfirmed until you see a primary report.

If you searched “Black October” looking for the 1929 stock market crash, Black Monday 1987, Russia in 1993, or Bolivia in 2003, those are unrelated. This guide covers the 2026 cyber events only.

The short version

• What: two critical flaws in PHP itself, patched October 21, 2026. Both are rated CVSS 9.2 and allow unauthenticated code execution.
• Fixed in: PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35.
• Who is exposed: any server that runs PHP to serve web pages. That includes WordPress, Drupal, Joomla, Magento, and Laravel sites, plus a lot of vendor software that does not advertise it.
• Not fixed: PHP 8.1 and older get no official release.
• Why it matters beyond PHP: AI helped find the bugs, an exploitation attempt was reported four days before disclosure, and the details leaked early. This is the new pattern.
• What to do: patch PHP on the server (not your CMS), restart it, verify the build, then rotate secrets and check for backdoors.

PHP2Shell explained in plain English

What PHP is and why it matters

PHP is the server-side language that generates pages for a huge slice of the web. W3Techs put it at 70.2% of sites with a known server language in August 2026, and 65.9% among the top million. WordPress, Drupal, Joomla, and Magento all run on it.

What is broken

• Public reporting, including from Google’s Wiz, describes memory-safety flaws in PHP’s core engine, in memory management and error handling. Nearly every web request touches those parts.
• Security firm Sansec reports that the vulnerable code dates back to PHP 5.4 in 2012, so default configurations are exposed.
• On Apache with mod_php, one flaw can trigger before any application code runs. That means a security plugin inside your CMS never sees the request.
• The confirmed path for CVE-2026-109619 involves the session upload progress feature, which is on by default and rarely used. Published mitigations also focus on multipart upload requests.
• The NSA noted that these flaws often give attackers a direct path to the server’s file system or database, and expects them to be weaponized.

Which versions are fixed

One analysis counted about 371,000 internet-facing hosts on PHP 5.6 and 7.2 alone. Another, from CybelAngel, counted 2.24 million internet-facing PHP hosts and put 59% of them on versions with no fix coming. For old branches, one report says only a source patch exists, which you would have to build yourself.

Timeline

Details of the early leak, and whether public exploit code works on default installs, are reported inconsistently. Treat both as unsettled. The advice does not change: patch.

Who was hit, and why

Patching was slow at first. One monitoring service saw 0.08% of its sites on a fixed version shortly after release.

How AI changed the game

The flaws were found with AI help. Security firm Calif found one of them using an OpenAI model through its Patch the Planet initiative. Google’s Wiz used its Wiz Atlas AI agent with frontier models to find multiple PHP vulnerabilities. Cloudflare says it independently rediscovered the same issue the night of disclosure, using its own harness and a frontier model with a simple prompt.

The lesson is that discovery is now cheap and fast, while fixing is still slow and human. Bugs that hid in PHP for years can be surfaced in days, by defenders and attackers alike. Security leaders quoted in coverage warned that AI makes theoretical bugs cheap to weaponize, so nobody should assume their patch cycle will outrun attackers.

What went wrong around disclosure

• An exploitation attempt was recorded on October 17, four days before public release.
• Cloudflare reported thousands of exploit attempts in the 10 hours before disclosure.
• Details leaked ahead of the planned announcement, and the PHP Foundation reportedly called the delay a structural failure.
• A small non-profit team carries security for software that much of the web depends on.

The takeaway for site owners: assume that in the next incident attackers may know before you do, so build the ability to patch fast before you need it.

Am I affected?

Emergency playbook for any PHP server

Work in this order. If you run many sites, finish step 1 for all of them first.

Step 1: Inventory

List every server and site that runs PHP, including forgotten staging sites, old client projects, and vendor software that bundles PHP. Record the PHP version and the web stack (Nginx with PHP-FPM, Apache with mod_php, LiteSpeed). You cannot patch what you did not know you had.

Step 2: Find the PHP your website really uses

Command-line PHP and web-serving PHP can be different installs. Check the one that serves requests.

# CLI version (may NOT be what your website uses)
php -v

# PHP-FPM version actually serving requests (adjust the number)
php-fpm8.3 -v

Linux distributions often backport fixes without changing the upstream version number, so a version string can mislead in both directions. Check the package changelog for the CVE IDs:

# Debian/Ubuntu
apt changelog php8.3-fpm | grep -i -E 'CVE-2026-109618|CVE-2026-109619'

# RHEL/Alma/Rocky
rpm -q --changelog php-fpm | grep -i -E 'CVE-2026-109618|CVE-2026-109619'

If neither the version (8.2.35, 8.3.36, 8.4.27, 8.5.12 or newer) nor the changelog confirms the fix, treat the server as unpatched.

Step 3: Patch

• Managed host: ask for explicit confirmation of the PHP build and its build date. Anything built before October 21, 2026 needs a question.
• Control-panel servers (RunCloud, cPanel, Plesk, and similar): check that the panel’s PHP packages received the fixed builds before assuming an auto-update covered it.
• Self-managed VPS: automatic OS updates may skip PHP if it came from a third-party repository, so upgrade the PHP packages explicitly.

sudo apt update

sudo apt install --only-upgrade php8.3-fpm php8.3-cli php8.3-common php8.3-mysql
# adjust to the PHP branch and extensions you actually use

If your repository has not published fixed builds yet, check again. Slow propagation was normal in the first days.

Only install patches from official sources. Security leaders warned that a rush to patch is exactly when attackers push malicious patches and phishing lures.

Step 4: Restart and verify

A patched package does nothing while the old process is still running.

sudo systemctl restart php8.3-fpm
# for Apache mod_php
sudo systemctl restart apache2

Then repeat the checks from step 2.

Step 5: If you cannot patch yet, reduce exposure

These are stopgaps. Multiple sources stress that none of them replaces the patch.

1. Disable session upload progress. Reporting ties the confirmed CVE-2026-109619 path to this rarely used default feature. It must be set in a PHP config file, because ini_set() cannot change it at runtime.

; e.g. /etc/php/8.3/fpm/conf.d/99-php2shell.ini
session.upload_progress.enabled = Off

For PHP-FPM pools, you can use php_admin_flag[session.upload_progress.enabled] = off instead. Reload PHP and verify the setting took effect.

1. Restrict multipart POST requests at the web server or CDN on sites that do not need uploads. Published rule sets exist for Nginx, Apache, Caddy, ModSecurity, and Cloudflare. Blocking too broadly breaks forms, logins, and uploads, so test first.
2. Keep your CDN or WAF on. Cloudflare enables its protections by default and still says to patch.
3. Isolate or take the site offline. The EU’s CERT and the UK’s NCSC advised organizations that cannot patch to isolate exposed apps or take them offline.

Do not test with public exploit code. Proof-of-concept code circulating before the patch may be unreliable or unsafe on your own systems.

After patching: assume-breach checklist

Experts quoted in coverage made a point many guides skip: one path involves memory disclosure and needs no code execution, so a clean malware scan and a successful patch prove nothing about leaked secrets. If a server was reachable and unpatched between October 17 and your patch time, work through this list.

Rotate secrets first

• Database password, then update the application config
• Application keys and salts (in WordPress, the security keys in wp-config.php, which also logs everyone out)
• Payment gateway, SMTP, CDN, storage, and third-party API keys
• SFTP and SSH credentials and deploy keys
• Administrator passwords, with two-factor authentication switched on

Verify file integrity

# WordPress: compare core and plugin files with official checksums
wp core verify-checksums
wp plugin verify-checksums --all

# PHP files changed since the exposure window began
find /var/www -name '*.php' -newermt '2026-10-17' -not -path '*/node_modules/*' | head -200

# PHP files inside WordPress uploads should rarely exist
find wp-content/uploads -name '*.php'

Also inspect wp-content/mu-plugins, .htaccess, and theme functions.php for code you did not write.

Audit accounts, persistence, and logs

• List administrators (wp user list –role=administrator) and scheduled tasks (wp cron event list). Look for unknown admins and unfamiliar jobs.
• Check ~/.ssh/authorized_keys and system cron entries for additions.
• Search access logs from October 17 onward for unusual multipart POSTs, repeated hits on one endpoint, and spikes from single IPs. Check PHP error logs for crashes around those times.

If you find a compromise

Do not just delete the one file you found. Isolate the server, take a forensic copy, rebuild from a known-good state (a backup from before October 17, on patched PHP), rotate every secret again, then restore content. Attackers often leave more than one door.

The WordPress angle

WordPress is one part of this story, but a big one, because it powers so much of the PHP web. WordPress itself has no PHP2Shell bug. It runs on the engine that does.

Why updating WordPress does nothing

WordPress.org said in its security release post that the flaws are not specific to WordPress and affect any server hosting a PHP application, and that no WordPress update is required or planned. Ghana’s cyber authorities added that updating themes or plugins alone will not fix the underlying PHP flaw. “WordPress sites are at risk” really means “WordPress sites on unpatched PHP are at risk.”

If you want to know about other WordPress security issues, please read our guide WordPress Casino Hack: How to Find It, Clean It Permanently

Why so many WordPress sites are exposed

• Old PHP is everywhere. WordPress.org usage data cited by several trackers shows about 35% of WordPress sites on a PHP branch the PHP project no longer supports, including around 16% on PHP 7.4. WordPress recommends 8.3 or newer but has long listed far older versions as compatible.
• The dashboard will not warn you. Site Health shows a PHP version but cannot tell you whether the build includes the October 21 fixes. Some hosts patched without changing the version string shown.
• Plugin-level security cannot help with mod_php. One flaw can fire before WordPress loads, so a security plugin never sees the request.
• A site on PHP 8.3 stays exposed until the host installs 8.3.36. The branch alone is not enough.

What to do for a WordPress site today

1. Confirm the PHP build with your host or server (steps 2 to 4 above). Do not rely on the dashboard.
2. If you are on PHP 8.1 or older, plan an upgrade to 8.3 or 8.4. Test your theme and plugins on staging first, and upgrade WordPress and PHP together if needed.
3. Rotate the database password, security keys, and any API keys stored in wp-config.php or the options table.
4. Run the integrity checks above and review administrator accounts.
5. Keep a WAF or CDN in front as an extra layer, never as the fix.

WordPress hardening that limits the damage next time

No setting makes a runtime-level flaw harmless, but good hardening limits what an attacker can do and speeds recovery.

// wp-config.php
define('DISALLOW_FILE_EDIT', true);   // no theme/plugin editor in the dashboard
define('FORCE_SSL_ADMIN', true);

• Block PHP execution in wp-content/uploads with a web server rule. Uploaded files should never run as code.
• Give each site its own system user and PHP-FPM pool, so one compromised site cannot read another’s files.
• Restrict the database user to its own database with only the privileges WordPress needs.
• Use sensible permissions (files 644, directories 755) and lock wp-config.php down as far as your host allows.
• Disable XML-RPC if unused, rate-limit wp-login.php, and enforce two-factor authentication for every admin and editor.
• Remove unused plugins and themes entirely instead of just deactivating them.
• Prefer well-maintained plugins, subscribe to a vulnerability feed (Patchstack, Wordfence Intelligence, WPScan, or similar), and test updates on staging before deploying.
• Keep offsite, versioned backups your web server cannot overwrite, and test a restore every quarter.

Other CMS and framework sites

Drupal, Joomla, Magento and Laravel sites face the same situation: the fix is at the PHP level. The same playbook applies. Laravel Forge, for one, told customers its automatic updates do not patch PHP.

For agencies and IT teams

1. Build a one-page matrix: site, host, PHP version, patched yes or no, date confirmed, secrets rotated yes or no.
2. Patch by blast radius: stores and membership sites first, then lead-generation sites, then brochure sites.
3. Tell clients early, in plain language: what happened, what you did, what they must do, and when you will report back.
4. Standardize PHP across the fleet so the next emergency is one command, not forty investigations.
5. Retire what you can. Abandoned sites are the easiest targets.
6. Keep a timestamped incident log. It protects you contractually and speeds any later investigation.

Future-proofing: security habits for the AI era

Black October or PHP2Shell will not be the last event like this. When AI can discover serious bugs at machine speed, urgent patches multiply while your team stays the same size.

1. Set patch targets. For example: actively exploited critical flaws within 24 hours, high-severity flaws within 7 days, and the rest on the monthly cycle. One country’s agencies were given seven days for PHP2Shell.
2. Automate upgrades with scripts or configuration management, starting with a staging canary.
3. Keep one dependency list: PHP version, web server, control panel, major plugins, CDN.
4. Subscribe to primary alerts: PHP’s security announcements, WordPress.org security posts, your host’s status page, and your national CERT.
5. Run on supported PHP only. Track end-of-life dates at php.net/supported-versions, and plan your move off 8.2 before December 31, 2026.
6. Keep a rollback path. Fast patching is only safe if you can undo a bad update quickly.
7. Run drills once or twice a year: “patch PHP on every site in four hours.” You will find the real bottlenecks before an attacker does.
8. Shrink what is exposed. Static pages, CDN caching, least-privilege accounts, and removing dead sites all cut attack surface.
9. Plan for early leaks. Assume attackers may learn of a flaw before the public announcement.

Common mistakes

• Updating WordPress and calling it done
• Trusting the dashboard’s PHP version
• Forgetting to restart PHP-FPM or Apache
• Patching CLI PHP but not the PHP that serves the site
• Skipping secret rotation because a malware scan came back clean
• Installing “patches” from emails, social posts, or unofficial mirrors
• Leaving old branches in place and hoping a WAF covers them
• Blocking all POST traffic as a stopgap, breaking the site, then removing the rule without patching

Quick checklist

Today

• Inventory every PHP site and server
• Confirm the PHP build on each (version and changelog)
• Patch to 8.2.35, 8.3.36, 8.4.27 or 8.5.12 or newer, or move off unsupported branches
• Restart PHP and re-verify
• Apply stopgaps or take the site offline where patching is delayed

This week

• Rotate database, keys, API, SFTP, SSH, and admin credentials
• Run checksum and recent-file scans; review users, cron, and logs from October 17
• Turn on two-factor authentication and block PHP execution in uploads
• Brief clients and document what you did

This quarter

• Standardize PHP across your fleet and plan the move off 8.2
• Set patch targets, automate upgrades and test restores
• Subscribe to vulnerability feeds and run an emergency drill

FAQ

What is Black October 2026?

 An informal name for the October 2026 cyber crisis centered on the PHP2Shell flaws. It is not an official designation.

Is it over?

The fix is out, but unpatched servers, especially on PHP 8.1 and older, stay exposed. Reports of attacks and mitigations were still evolving at the time of writing.

Is my WordPress site hacked because of this?

 Not necessarily. It was potentially exposed if its server ran unpatched PHP. Patch first, then run the checklist above.

I’m on managed hosting. Do I need to do anything?

Get written confirmation that PHP was updated and restarted. If your host was unpatched for a while and you store payment or API credentials, consider rotating them.

Will a security plugin protect me?

 It will not stop a PHP-level flaw. Keep it for other threats, but patch PHP.

My host says PHP 8.1 or 7.4 is fine. What should I do?

Ask whether they backport the CVE-2026-109618 and CVE-2026-109619 fixes to that branch. The PHP project shipped none. The safer path is migrating to a supported version after testing.

Should I leave WordPress or PHP?

This incident alone is not a reason. It is a reason to run supported runtimes, patch fast, and reduce exposure. A hosted platform just moves the patching to someone else, which is only sensible if that provider’s claims hold up.

Sources and further reading

Check these directly, since details may change after publication:

• NSA advisory: Critical Patches Recommended for PHP Vulnerabilities (nsa.gov press room)
• CISA alert: Critical Vulnerabilities in PHP Require Immediate Patching (cisa.gov, October 21, 2026)
• PHP project release announcements and PHP Foundation security notice (php.net)
• WordPress.org: Critical PHP Security Release (October 21, 2026)
• Automattic’s PHP2Shell statement on its hosted properties
• Cloudflare’s php2shell post on WAF protections
• SecureWorld: Patch PHP Vulnerability Now or Take It Offline, NSA Warns
• Computing, Moneylife, Lowyat.NET and Ghana’s CSA and NITA for international government responses
• PHP version-share analyses: mySites.guru, Digidop, CybelAngel, and the WordPress.org stats API
• Mitigation write-ups: ComputingForGeeks and the open php2shell-hardening rule repository

This guide is informational and not a substitute for professional incident response. If you believe a production system holding sensitive data was compromised, involve a qualified security responder.