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, reports exploitation in the wild.
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
- 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.
- 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.
- 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.
- 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 tolerateIf 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
Written by Nikita Huttenlocher, founder and lead engineer at Huttenlocher Technologies, a cybersecurity and software firm in Myrtle Beach, South Carolina. This is general guidance, not a review of your systems.