Skip to content
All posts

· by NetProtector Security Team

PHP2Shell: Critical PHP Vulnerabilities Under Active Exploitation

Two critical vulnerabilities in the PHP core, collectively dubbed “PHP2Shell”, allow attackers to execute code on web servers without authentication. Patches have been available since October 20, 2026 – and attacks are already being seen in the wild. If you run PHP applications, you should act now.

What it is about

The vulnerabilities are CVE-2026-109618 and CVE-2026-109619, both rated 9.2 under CVSS 4.0. They are memory corruption bugs in the PHP core, not in an individual application or framework:

  • CVE-2026-109618: If PHP aborts a request due to memory exhaustion, request data is left only partially initialized. During request cleanup, it is nevertheless treated as valid – allowing an attacker to introduce invalid memory.
  • CVE-2026-109619: Global state of a request survives the freeing of its memory. A subsequent request on the same worker reads it before it is reset (use-after-free). This can also be used to read worker memory – including any passwords, tokens or API keys currently held there.

All installations that serve web requests are at risk: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. How easily the vulnerabilities can be exploited depends on configuration and application; one confirmed attack path uses the Session Upload Progress feature.

Why this is urgent

The vulnerabilities became known earlier than planned: hints circulated in forums before the patch date, and a video containing a proof of concept was accidentally made public in advance. Exploit scripts are now publicly available, and several security firms are observing active exploitation. PHP runs on a large share of all web servers – so attackers are scanning broadly.

What you should do now

  1. Update. The fixed versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Distributions often backport fixes and keep the old version number – the security advisory from your vendor is authoritative. PHP 8.1 and older no longer receive regular updates; the only remedy here is an upgrade.
  2. Check what is actually running. php -v on the command line does not necessarily show the version the web server is using. Restart PHP-FPM or Apache after the update and verify the version of the running workers.
  3. Apply interim mitigations if an update is not immediately possible (the PHP project stresses that only the update fully closes the vulnerabilities):
    • Set session.upload_progress.enabled = 0 in php.ini or the FPM pool configuration and restart the workers – setting it via ini_set() or .user.ini is not sufficient.
    • On PHP 8.5, additionally set fatal_error_backtraces = 0.
    • Set tight size and upload limits (post_max_size, upload_max_filesize, max_file_uploads) and block multipart requests at the reverse proxy where they are not needed.
    • Where possible, disconnect the service from the internet or filter traffic upstream.
  4. Look for traces. Check web server logs for suspicious multipart and upload requests as well as PHP worker crashes since mid-October. Successful attacks often reveal themselves through new files in the web directory or unusual outbound connections from the web server.

Our assessment

PHP2Shell is a textbook example of how quickly the window between disclosure and exploitation closes. Up-to-date patch management remains the most important measure. On the network side, intrusion prevention helps block known attack patterns at the perimeter, and anomaly detection notices when a web server suddenly establishes connections it has never made before – a typical sign of a successful compromise.

Sources