PHP2Shell – how we closed the critical PHP vulnerability for our clients in under 24 hours

On 21 October 2026 the PHP project released out-of-band security updates: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. They fix two flaws known as "PHP2Shell" – CVE-2026-109618 and CVE-2026-109619, both rated 9.2 out of 10. Exploitation attempts were observed within hours of the release.

We closed both flaws on every client system we look after in less than 24 hours after disclosure – on Docker environments as well as on plain Ubuntu servers.

What happened

• 20 October: details leaked early; the PHP project announced a security release for the next day.
• 21 October, 14:00 UTC: the patched versions were released.
• The same afternoon security firms reported the first exploitation attempts against both flaws.

Why these flaws are so dangerous

• They are in PHP itself, not in your application. Updating WordPress, Laravel or a shop system does not help – PHP itself has to be updated.
• No login required. In the worst case an attacker can run code on the server remotely, and data from other requests – passwords, tokens, API keys – may be exposed.
• Almost every installation is affected: nearly all PHP versions back to 5.4 and every web-serving mode – PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed. Apache mod_php is at highest risk.

How we approached it

1. Know what runs where. Every system we support is documented with its PHP version and mode, so we knew within minutes which systems were affected – internet-facing ones first.
2. Interim measures where useful, as recommended by the PHP project – including session.upload_progress.enabled = 0 and tight request size limits.
3. Docker: rebuild the image instead of patching the container. We raised the PHP base image to the patched version, rebuilt it through the CI pipeline, tested it and replaced the running containers. Updating a running container is not enough – the next restart would bring back the vulnerable image.
4. Ubuntu servers: install the security updates and restart every PHP process – PHP-FPM, Apache and long-running workers.
5. Check what actually runs. php -v only shows the command-line version, which can differ from what PHP-FPM or Apache serve. Distribution packages may also carry fixes under older-looking version numbers – the package changelog listing both CVE IDs is what counts.
6. Follow-up. The fix introduces a hard memory limit, so we reviewed memory_limit and post_max_size and checked logs for suspicious patterns.

What you should check now

1. Is a patched version running – at least 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or a distribution package whose changelog lists both CVEs?
2. Were all PHP processes restarted after the update?
3. Were container images rebuilt, not just running containers updated?
4. Are you still on PHP 8.1 or older? There are no official updates for those versions anymore, and PHP 8.2 only receives security fixes until 31 December 2026.
5. Any signs of compromise? If in doubt, rotate credentials, tokens and keys stored on the server.

Unsure where your systems stand, or still running an outdated PHP version? Software rescue & upgrade is exactly what we do – get in touch.

Sources: php.net announcements, 20–21 October 2026 · The Hacker News · watchTowr FAQ · Aikido