Critical PHP Vulnerabilities: Patch Your Web Servers Now

On 21 October 2026 the PHP project released emergency security updates for two critical vulnerabilities. Both allow an attacker to run code on a web server without logging in, and both are rated 9.2 (critical) under CVSS v4.0. Details leaked online a day before the planned disclosure, and working exploits against popular platforms such as WordPress, Drupal and Joomla have since been demonstrated publicly.

If you run, host or manage anything built on PHP, treat this as urgent.

What the vulnerabilities are

• CVE-2026-109618. If PHP runs out of memory while it is setting up the data for an incoming request, that data can be left half built. The clean-up code then treats it as valid, which opens a route to running code.
• CVE-2026-109619. Some information about a request can survive after the memory behind it has been freed. When the same PHP worker handles the next request, it can read that stale information, which can lead to leaked memory contents and code execution.

The PHP project says the risk is highest with Apache and mod_php, where a demonstrated attack needs no login and runs before any application code is reached. Other set-ups that serve web requests, including PHP-FPM, php-cgi and LiteSpeed, should also be treated as at risk. Leaked memory could include passwords, API keys, tokens and certificates.

Which versions fix it

Update to one of these versions, or later:

• PHP 8.5.12
• PHP 8.4.27
• PHP 8.3.36
• PHP 8.2.35

PHP 8.1 and older no longer receive official updates. The PHP project has published minimal fixes for 7.4, 8.0 and 8.1 for people who build PHP themselves, and Linux distributions and long-term support vendors may provide their own updated packages. Note that PHP 8.2 reaches end of life on 31 December 2026, so plan to move off it soon.

What to do now

1. Find every copy of PHP. It is often hidden inside hosting control panels, vendor appliances, Windows software and content management systems. Don't forget staging and old sites that nobody looks after any more.
2. Patch internet-facing systems first. Use your operating system's packages or your hosting provider's updates where you can, and restart the web server and PHP services afterwards.
3. Ask your suppliers. If a hosting company, website agency or software vendor runs PHP for you, ask them to confirm in writing when they have patched.
4. If you can't patch straight away, reduce the risk while you plan the upgrade. In php.ini (not ini_set() or .user.ini), set session.upload_progress.enabled=0 and restart every PHP worker. Keep post_max_size low, put request size limits on your web server or web application firewall, and consider taking older systems off the internet or behind a VPN. These steps reduce exposure but are not a complete fix.
5. Watch for signs of attack. Alert on web server or PHP processes starting shells, scripting languages or download tools, and on unexpected outbound connections from web servers.

If you think you have been compromised

Isolate the server, keep the web server and PHP logs, and look for web shells or new files in the website folders, new scheduled tasks or cron jobs, and new user accounts. Because memory may have been exposed, change any passwords, API keys and certificates the server held.

If you need help, our 24x7 emergency incident response team is available on 01223 921 300.

For MSPs

This is a good test of your patching process across clients. Check your RMM for PHP across every estate, and remember the web servers your clients host with third parties. Our vulnerability scanning and remediation service can find vulnerable PHP versions across your clients' internet-facing systems and give you a prioritised list to fix.

Sources

• PHP: security releases and advisory, 21 October 2026

If you would like a second pair of eyes on your exposure, get in touch.