A Critical PHP Vulnerability Went Public Today. Here's What We Did About It.
On October 21, 2026 the PHP project released emergency security fixes for two critical bugs, CVE-2026-109618 and CVE-2026-109619, that the security community has nicknamed "php2shell". Both are rated 9.2 out of 10. If you run a website on WordPress, Drupal, Joomla, WooCommerce, Magento, Laravel or almost any other PHP based platform, this one applies to you.
What it is, in plain terms
PHP is the language that runs roughly three quarters of the websites on the internet. The bug is in how PHP reads form submissions that include a file upload (the "multipart" format every contact form and media uploader uses). An attacker can send a specially built request to a site and, in the worst case, run their own code on the server. No login is needed. The settings that make a site vulnerable are on by default, so most sites were exposed the moment the details leaked, which happened a few hours before the fix was ready.
A working exploit tool was already circulating when the advisory went out. That is why we treated this as a same-day job rather than a next-update job.
Which versions are fixed
PHP released patched versions today: 8.5.12, 8.4.27, 8.3.36 and 8.2.35.
Anything older than 8.2 will not get a fix. PHP 8.1, 8.0, 7.x and 5.x are past end of life and remain vulnerable permanently. The only real answer for a site on one of those is to upgrade PHP, which usually means some testing and sometimes some code work.
What CodeBru did today
For every site we host or maintain:
- Applied the recommended hardening within hours of the advisory. This limits the size of upload requests PHP will accept and turns off the session feature the exploit leans on. It closes the known attack path while the real fix is being rolled out, and it works even on PHP versions that will never be patched. We verified each site is serving normally afterwards.
- Checked every server's update path. The fixed PHP builds are being published to the package repositories our servers use. We have automated monitoring watching for them and will install the patched build on each server as soon as it lands, usually within a day of release.
- Flagged the sites on end of life PHP. A few of the sites we maintain run older PHP versions that will not receive this fix. The hardening above protects them for now. We are reaching out to each of those clients separately with an upgrade plan.
- Confirmed which sites are not affected. Sites built on HubSpot, Wix, Shopify and similar managed platforms do not run PHP on servers we control, and those vendors are patching on their side. Our non PHP applications are unaffected.
If you are a current client with an affected site, you will have an email from us today with the status of your site specifically.
If we don't manage your site
Ask your host or developer two questions: which PHP version is the site running, and has the php2shell fix been applied. If the answer to the first is anything below 8.2, the site cannot be patched and needs an upgrade. If you would like us to check a site, email support@codebru.com and we will take a look.
Technical notes
For the people who want the specifics: the vulnerabilities are in PHP's multipart/form-data parser. The interim mitigation is to lower post_max_size (8M for sites without uploads, 32M for sites with them), set session.upload_progress.enabled = 0 and session.use_strict_mode = 1, and reload PHP-FPM. Lowering the web server's request body limit (client_max_body_size in nginx) adds a second layer in front of PHP. These are reversible config changes, not code changes. The permanent fix is the patched PHP release.
References:
