PHP2Shell—I Patched Mine. Have You Patched Yours?

My first reaction to this one wasn't "interesting research." It was "well, there goes my evening."

I run a handful of personal WordPress sites on AWS Lightsail. They're small. They're not particularly exciting. They're exactly the kind of sites people forget about, and exactly the kind of sites attackers love, because nobody is watching them.

On October 21, PHP shipped emergency patches for two vulnerabilities that are being called "PHP2Shell". An unauthenticated request can get code running on your web server. Not "after a user clicks something." Not "if an admin is logged in." Just a request.

So I patched mine. It took about 15–20 minutes per site: snapshot, update PHP in place to a fixed release (8.5.12, 8.4.27, 8.3.36 or 8.2.35), restart, click through the site and check the logs. Not glamorous. Not hard.

But that's the easy version. I own those servers, I know every site on them, and I knew exactly where PHP was running.

Most organizations can't say that. PHP isn't just "the website." It's buried inside platforms, appliances and vendor products you'd never think to check.

What PHP2Shell Actually Is

Two bugs, one similar root cause: PHP can leave memory corrupted when a request ends abnormally. Researchers from Calif, Wiz and OpenAI found ways to turn that into code execution.

• CVE-2026-109618 — a chain of weaknesses that triggers out-of-memory corruption, ending in remote code execution as the web server's worker account.
• CVE-2026-109619 — a stale global state flaw that allows an unauthenticated heap use-after-free. Translation: memory disclosure and remote code execution, no login required.

If you run Apache with mod_php, you're at the top of the risk list. PHP's own team says an unauthenticated request can trigger the attack before any application code runs, and that there's a demonstrated exploit for mod_php. Your WAF rules, your plugin hardening, your "we use a strong admin password" — none of it is in the path.

And this isn't theoretical. Cloudflare's CTO said they were already seeing early attacks against both flaws before the patches shipped. The UK's NCSC told organizations to update immediately or take affected systems offline. When a national cyber agency says "or take it offline," pay attention.

How big is this?

Big. PHP powers an estimated 75–80% of websites. VirusTotal estimates more than 5.1 million PHP hosts are exposed online, with roughly 3.8 million showing at least one open port.

Every way PHP serves web requests is affected: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed. Now think about everything built on top of that. If any of these run on an unpatched PHP version, they're in scope:

• Websites and CMS: WordPress (and WooCommerce), Drupal, Joomla, TYPO3, MediaWiki
• E-commerce: Magento / Adobe Commerce, PrestaShop, OpenCart
• Business apps: Moodle, Nextcloud, SuiteCRM, Mautic, osTicket, GLPI, Matomo, Roundcube webmail
• Custom apps: anything your developers or vendors built on Laravel, Symfony or CodeIgniter
• Admin and monitoring tools: phpMyAdmin, Zabbix, Cacti
• Appliances with web admin panels: pfSense, FreePBX and plenty of NAS, VoIP and network gear. You can't patch PHP on these yourself; you wait on the vendor
• Hosting and cloud images: shared hosting, one-click and marketplace images (Bitnami on Lightsail, cloud marketplaces), and the Docker php base images your containers were built from months ago

That last one is the sneaky one. A container image doesn't patch itself. If it was built before today, it's vulnerable until someone rebuilds and redeploys it.

Here's the part that worries me most. Official fixes only exist for PHP 8.2 and newer. PHP 7.4, 8.0 and 8.1 got minimal source backports for people who compile PHP themselves, which is almost nobody running a small business site. If you're on PHP 7 or older, you're not patching, you're migrating.

In my experience, the sites still on old PHP are the ones nobody owns: the marketing site from three agencies ago, the intranet app, the appliance with a web admin page. Those are the ones that get popped.

Where does your PHP version stand?

• PHP 8.5: fixed in 8.5.12
• PHP 8.4: fixed in 8.4.27
• PHP 8.3: fixed in 8.3.36
• PHP 8.2: fixed in 8.2.35
• PHP 7.4, 8.0, 8.1: source backports only. Check with your OS/LTS vendor, or upgrade
• PHP 7.3 and older: no fix. Migrate to a supported release

What to do today

1. Find every PHP site you own. Websites, client portals, intranets, staging sites, vendor apps. If you don't know whether something runs PHP, assume it does until someone proves otherwise.
2. Patch to a fixed release: 8.5.12, 8.4.27, 8.3.36 or 8.2.35. Snapshot or back up first, then restart PHP-FPM and/or Apache so the old workers are actually gone.
3. Prioritize mod_php and internet-facing sites. Those go first. Internal-only can follow, but not next month.
4. Can't patch tonight? Apply the interim mitigations (below), and treat them as a tourniquet, not a cure.
5. Look for signs you were already hit. Attacks started before the patches. Check for new PHP files in web directories, new admin users in your CMS, unexpected outbound connections from web servers, and odd crashes or worker restarts in your logs.
6. Plan the migration for anything on PHP 8.1 or older. No official fix is coming.

Interim mitigations from the PHP team (these reduce risk, they don't remove it):

• For CVE-2026-109618: set memory_limit=-1 (ideally via php_admin_value so apps can't override it), set a low post_max_size (8M without uploads, 32M with), and use container or cgroup memory limits so only the affected worker gets killed.
• For CVE-2026-109619: set session.upload_progress.enabled=0 and restart all workers. On PHP 8.5, also set fatal_error_backtraces=0.
• Clean up invalid or deprecated per-request settings that throw diagnostics, and fix attacker-reachable fatal errors and timeouts.
• Hiding errors with display_errors, error_reporting or @ does not help.
• WAF rules (Cloudflare has some) buy time. PHP core developer Gina Peter Banyard was clear that only the official patches are a permanent fix.

If you don't manage the server yourself

Most business owners don't, and that's fine. But "the host handles it" is an assumption, not a control. Here's who should be asking what:

• Business owners: Email your web host, developer or IT provider today and ask three questions. What PHP version are our sites on? Has it been updated to a fixed release for CVE-2026-109618 and CVE-2026-109619? If not, when, and what are you doing in the meantime? Get the answer in writing.
• Shared or managed hosting: Check your control panel for the PHP version. Many hosts will patch the underlying servers, but some leave the version selection to you, and some still let you sit on PHP 7 indefinitely.
• IT teams: Treat this like a perimeter appliance zero-day. Inventory, patch, hunt, verify. Don't forget the PHP you didn't install yourself — vendor appliances and third-party apps with a web interface.
• Vendors and SaaS: Ask your vendors whether their products are affected and when they'll patch. If they can't answer that question this week, that tells you something too.
• MSPs: Your clients are going to assume you've got this. Make sure you do, and tell them before they ask.

Bottom line

I patched mine because I'd be a hypocrite if I told you to patch yours while my own sites sat exposed. The patch is out, the attacks are already happening, and the window between "disclosed" and "exploited at scale" keeps getting shorter.

The individuals scanning for this don't care whether your site is a Fortune 500 storefront or a blog about blacksmithing. They care whether it answers on port 443 and runs PHP.

If you're not sure where you stand, or you need help figuring out what's exposed in your environment, feel free to reach out. I'd much rather answer a question now than help clean up an incident later.

Source: BleepingComputer — PHP ships emergency patches for critical PHP2Shell flaws

Interested in Aqueity's services?  Click here to learn more.