As has been widely reported, two critical remote code execution flaws have been discovered within PHP, a widely-used scripting language.
The developers behind PHP have now released two emergency patches today (Wednesday 21st October) as of 15:00 BST. Given the widespread nature of PHP across websites and CMS platforms such as Wordpress, Drupa, and Adobe Commerce, PureCyber strongly recommends organisations identify their PHP systems now, so that internet-facing servers can be patched with the fixes now published. Please read through the details below to ensure your organisation is protected, and contact us directly if you have any concerns.
What’s happened?
On Tuesday 20th October, details of two critical PHP vulnerabilities were posted online ahead of their coordinated disclosure. The post was removed, but screenshots circulated widely.
Security researchers at watchTowr confirmed the vulnerabilities are genuine and reproduced CVE-2026-109618. The PHP security team then brought its security release forward by a day, to 21 October, and said it may release sooner if details go public or exploitation is seen.
Earlier today (Wednesday 21st October), PHP released fixed versions and published the technical details. The two flaws are:
CVE-2026-109618, RCE via out-of-memory corruption (GHSA-w8hw-w9fx-j79w): if PHP runs out of memory while setting up a request, cleanup can treat half-built internal data as valid.
CVE-2026-109619, RCE via stale global state (GHSA-6wmf-4rv5-p3rp): internal state from one request can survive after its memory is freed, and a later request on the same worker can use it.
PHP has demonstrated an exploit against Apache mod_php in which an unauthenticated request triggers the attack before any application code runs. With full details now public, expect exploit code and mass scanning quickly.
Who is affected?
PHP confirms that every PHP installation serving web requests is at risk, whichever way it is run: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP or LiteSpeed. PHP rates mod_php as the highest risk. PHP that is installed but only used from the command line, with no web server passing it requests, is not exposed to these attack paths, but should still be updated or removed.
Common places PHP runs include:
Websites and CMS platforms: WordPress, Drupal, Joomla, Magento / Adobe Commerce, WooCommerce
Hosting control panels such as cPanel and Plesk, and shared hosting platforms
Vendor appliances and Windows software that bundle php.exe or php-cgi.exe without advertising it
Third-party or supplier-hosted sites, which you may need to check with the provider
End-of-life PHP is the highest risk. PHP 8.1 and older receive no official release. Some Linux distributions and LTS vendors provide backported fixes, so check with your vendor. PHP has also published minimal source backports for 7.4, 8.0 and 8.1 for those who build PHP themselves. Otherwise, upgrade to a supported version or take the system off the internet.
Remi repository users: PHP warns that rpms.remirepo.net will not have updates today. Switch to your distribution's packages or build from source.
How can I check if I’m affected?
Most organisations can find their PHP versions quickly using the checks below. Record each system, its PHP version and whether it is internet-facing. Please refer to the table below for details.
We strongly recommend that you do not rely on website response headers (such as X-Powered-By) to rule out PHP, as these are often hidden. If you need assistance with identifying PHP assets, contact PureCyber to assist you.
Recommended actions
With the fixes released by developers, we advise that the priority is to be ready to patch now, starting with internet-facing systems.
Patch now
Update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 from the official advisory, or install your Linux distribution's or hosting provider's patched package.
Patch internet-facing systems first, then restart every PHP-FPM pool and web server so no worker keeps running the old code.
Verify the version on every host with php -v, and check the version the web server is actually serving, as servers often run several PHP versions.
For PHP 8.1 and older, apply a vendor backport, upgrade to a supported branch, or take the system off the internet.
Ask hosting providers and suppliers who run PHP on your behalf to confirm they have patched.
Remove PHP from servers that do not need it.
If you cannot update immediately
PHP lists the measures below. They reduce exposure to the known attack paths but do not make a system safe, so treat them as a stopgap until you patch.
CVE-2026-109618 (out-of-memory corruption)
Set memory_limit=-1 in a way applications cannot override, such as php_admin_value in the FPM pool or Apache configuration, and check that no pool, directory or application sets a finite limit again.
Set post_max_size = 8M (32M if the application needs file uploads), keep upload_max_filesize below it, and enforce request size, field count and multipart part limits at the web server or proxy, including for requests without a Content-Length.
Use container or cgroup memory limits to contain resource use; do not use RLIMIT_AS or RLIMIT_DATA, which can trigger the vulnerable failure.
CVE-2026-109619 (stale global state)
Set session.upload_progress.enabled=0 in php.ini, the FPM pool or the server configuration (not ini_set() or .user.ini), then restart every worker.
On PHP 8.5, also set fatal_error_backtraces=0 and restart every worker.
Remove invalid or deprecated per-request settings that emit warnings during start-up; hiding errors with error_reporting, display_errors or @ does not help.
Fix fatal errors and timeouts that attackers can trigger, including in upload, import and clean-up code.
If you suspect compromise
Isolate the server and preserve web server and PHP logs
Do not rebuild or wipe the system before evidence is captured
Concerned? Contact PureCyber
PureCyber is on hand to provide the vital, expert assistance you need to manage these PHP vulnerabilities and safeguard your organisation. Click the button below to get in touch with us.