PHP2Shell is being exploited: CISA added both PHP flaws to its list on October 26. Here’s what to do today.

Update, October 27: CISA confirms attacks

On October 26, 2026 the U.S. Cybersecurity and Infrastructure Security Agency (CISA) added both flaws to its Known Exploited Vulnerabilities catalog, the list of vulnerabilities it has evidence are being used in real attacks. CISA lists CVE-2026-109618 as the PHP Memory Corruption Vulnerability and CVE-2026-109619 as the PHP Stale Internal Request-State Vulnerability. Same two flaws, same fixes; there is no new PHP release beyond the October 21 ones.

CISA gave federal agencies until October 29 to fix them, three days. A deadline that short is rare, and it is a fair measure of how seriously to take this: if your host hasn’t confirmed the update, ask today rather than this week.

What happened

On October 21, 2026 the PHP project released PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 as critical security releases. They fix two vulnerabilities that the project says can allow unauthenticated remote code execution: someone on the internet, with no account, getting a web server to run their code. Both are rated 9.2 out of 10 on the current CVSS scale, and PHP's own announcement says all users are strongly encouraged to update immediately.

Both flaws live in PHP itself, not in WordPress or a plugin. CVE-2026-109618 comes from how PHP handles running out of memory partway through a request: internal data can be left half-built and then trusted during cleanup. CVE-2026-109619 lets internal state from one request outlive its memory, so a later request on the same worker can use it. Aikido Security, which named the pair PHP2Shell, reported exploitation in the wild at the time, and CISA confirmed it on October 26.

Who this affects here

PHP runs WordPress, WooCommerce, Joomla, Drupal and most cPanel-style shared hosting. Most of the Grand Strand business sites we audited this month are WordPress: restaurants, law offices, contractors, shops.

You are probably affected if your site is WordPress, WooCommerce or another PHP application on shared hosting, a VPS or your own server, and nobody has updated PHP since October 21. Every PHP version before the fixed releases is affected.

You are probably not affected if your site is on Wix, Squarespace, Shopify or a similar hosted builder, where you never had your own copy of PHP to update. Our own stack does not run PHP.

Managed WordPress hosts usually update PHP for all their customers at once. On shared hosting or your own server, it often doesn’t happen until someone asks, so ask.

What to do today

1. Ask your host, in writingSend your hosting company this: “Is my site running PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 or newer, or a distribution package that includes the fixes for CVE-2026-109618 and CVE-2026-109619? If not, when?” Keep the answer.
2. If you’re on PHP 8.1 or older, plan the moveThe PHP project no longer ships updates for 8.1 and older. It has published source backports for 7.4, 8.0 and 8.1, but most hosts will not build those for you. If your site is on one of these, moving to a supported version should happen this month.
3. If you run the server, update and restartInstall the fixed release (or your distribution’s patched package; look for the two CVE numbers in the changelog), then restart PHP-FPM or Apache so no worker is still running the old code, and rebuild any container images. Aikido notes that some third-party package repositories had not shipped the fix yet; check before you assume.
4. Confirm it on the serverCheck the version on the server itself (php -v, and the PHP version shown in your hosting panel). An outside scan cannot reliably see which PHP a site runs.

If you can’t update right away

PHP’s announcement is clear that there is no complete mitigation: updating is the only full fix. It lists two settings that reduce the risk in the meantime. Set them where applications cannot override them, then restart every PHP worker:

; php.ini (partial mitigation only, per the PHP project)
session.upload_progress.enabled = 0
post_max_size = 2M   ; as low as your site can tolerate

If your site never takes file uploads or form posts with attachments, your host or firewall can also block multipart form posts to it. Ask before you do this on a site with a contact form that takes files.

After you patch

Updating closes the hole, but it won’t remove anything an attacker already left behind. If your site ran unpatched after October 21, have someone check for the signs Aikido lists:

• Unusual multipart (file-upload style) requests in the access logs, especially to pages that don’t take uploads
• Bursts of “allowed memory size exhausted” errors or repeated 500 errors
• Malformed PHPSESSID cookies and worker processes restarting for no clear reason
• PHP files that changed when nobody deployed, unfamiliar files in upload folders, or new administrator accounts

If you find any of that, change the site’s passwords, API keys and database credentials, and plan on a full cleanup of the server, not just deleting the odd file. Our incident response team handles exactly this.

A note to other local web shops

If you manage PHP sites for businesses around here and you’re short on hands this week, give us a call. We can help with patching, log reviews or a cleanup, and we won’t contact your clients unless you ask us to.

Sources

• PHP project: critical security releases, October 21, 2026 (php.net)
• GHSA-w8hw-w9fx-j79w: CVE-2026-109618 (php-src on GitHub)
• GHSA-6wmf-4rv5-p3rp: CVE-2026-109619 (php-src on GitHub)
• Aikido Security: PHP2Shell, affected versions and fixes
• CISA Known Exploited Vulnerabilities catalog (CVE-2026-109618 and CVE-2026-109619 added October 26, 2026)
• CVE-2026-109618 (National Vulnerability Database)
• CVE-2026-109619 (National Vulnerability Database)