>_ AYSOLI CYBERSECURITY
← Back to Advisories
CRITICALAYS-2026-008 · 2026-10-22

CVE-2026-109618 / CVE-2026-109619 – PHP2Shell: Critical RCE Flaws in PHP

Two vulnerabilities in the PHP core allow attackers to execute code without authentication on any server that uses PHP to handle web requests. Exploitation attempts were observed even before disclosure – patch immediately.

What happened?

Two critical flaws in the PHP core have become known under the name "PHP2Shell" (CVSS v4 9.2, rated "critical" by PHP). Both are triggered before any application code runs – logins, plugins or a particular CMS make no difference:

  • CVE-2026-109618: A crafted POST request makes PHP exceed its memory limit while parsing form data. This leaves a half-initialized entry behind that corrupts memory during cleanup.
  • CVE-2026-109619: After an error, a PHP worker keeps references to already freed memory (use-after-free) that a later request can use – reachable through session upload progress, which is enabled by default.

The details leaked prematurely on October 20, and patches were released on October 21. Amazon recorded first exploitation attempts as early as October 17; broad scanning for vulnerable servers is now under way.

Who is affected?

  • All PHP installations serving web requests: Apache with mod_php, PHP-FPM (nginx), php-cgi, FrankenPHP and LiteSpeed.
  • Typical SME systems: WordPress, online shops, Nextcloud, intranet applications and web hosting.
  • Hidden PHP installations: PHP bundled in appliances, container images and third-party software.
  • Outdated versions: PHP 7.4 to 8.1 are vulnerable too but no longer receive regular updates.

What needs to be done?

  1. Patch immediately: Update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 – or install the security update from your Linux distribution or hosting provider. Internet-facing systems first.
  2. Build an inventory: Where does PHP run, including inside appliances or containers? What matters is the PHP version used by the web server, not the command-line one.
  3. Interim mitigation if you cannot patch yet: Set session.upload_progress.enabled=0 (on PHP 8.5 also fatal_error_backtraces=0), limit request sizes at the reverse proxy or WAF, then restart all PHP workers. This reduces the risk but does not replace the patch.
  4. Check for compromise: Look for web server processes spawning a shell and for log entries "Allowed memory size … exhausted" with "Unknown on line 0" alongside very large POST requests.
  5. Isolate legacy systems: Disconnect systems that cannot be updated or still run PHP 8.1 or older from the internet.

This advisory is for informational purposes. For support in securing your web servers, contact us.

Ready to know your attack surface?

Tell us briefly about your project. We'll come back with a concrete proposal.

Request a first call