On October 21, the PHP project shipped emergency patches for two critical remote code execution vulnerabilities, CVE-2026-109618 and CVE-2026-109619, together known as “PHP2Shell.” Both vulnerabilities have been assigned CVSS 4.0 scores of 9.2.
What makes these vulnerabilities particularly dangerous is that the flaws are in the PHP engine itself, not in any single framework or library. That means an attacker with no credentials could potentially run code on almost any server that uses PHP to handle web requests. As a result, multiple organizations (including government bodies) took websites offline to protect against the threat.
PHP2Shell Background and Attack Mechanism
Although the PHP vulnerabilities weren’t publicly disclosed until this week, they were discovered over the summer. Security firm Calif (and later Wiz) discovered and reported the vulnerabilities to PHP in the summer. Following disclosure, a number of organizations and researchers (including OpenAI and PHP maintainers) collaborated on developing and releasing a fix.
PHP originally intended to disclose the vulnerability on Oct. 22. However, a leak on Oct. 20 necessitated a faster disclosure timeline; PHP moved its announcement up to Oct. 21.
Both CVEs are use-after-free memory bugs. CVE-2026-109618 abuses out-of-memory handling that interrupts PHP while it is still setting up a request. CVE-2026-109619 lets stale request state outlive its freed memory, so a later request on the same worker can reuse it. Either one can lead to memory corruption and code execution.
Aside from the massive blast radius (the vulnerabilities can impact every PHP installation that serves web requests, which Wiz estimates covers 70% of the internet), three things make PHP2Shell especially serious:
- Exploitation is unauthenticated and works over the network.
- Researchers have shown pre-auth RCE against WordPress, Drupal, Joomla, and Magento, even when the application code itself was clean.
- The affected versions reach back to PHP 5.4 and cover PHP-FPM, mod_php, php-cgi, FrankenPHP, and LiteSpeed.
Patching the PHP Vulnerabilities
Upgrade to PHP 8.5.12, 8.4.27, 8.3.36, or 8.2.35. Pull your distro’s updated package or rebuild container images on a patched base image. Then, restart every PHP worker, because processes that are still running keep the vulnerable code in memory.
Start with Apache mod_php deployments. If you run a branch older than 8.2, there’s no patch, so move to a supported branch. If you can’t patch right away, set session.upload_progress.enabled=0 (and fatal_error_backtraces=0 on 8.5), then restart. This only blocks one attack path, so it’s a stopgap, not a fix.
Safe versions: 8.5.12, 8.4.27, 8.3.36, and 8.2.35. Restart every worker after upgrading. Disabling session.upload_progress is only a partial stopgap.
Finding and Fixing PHP2Shell with FOSSA
FOSSA customers can use our platform to assist in patching the PHP vulnerabilities. Here’s how it works.
- Detect: Rescan your projects and container images (or turn on scheduled scans) so FOSSA can match them against the new advisories. Container scanning flags vulnerable PHP in base image layers. SBOM vulnerability detection catches it in third-party software you’ve imported. You can filter the Issues inbox by CVE ID to see every affected project at once.
- Prioritize: You can use the search function on the Issues -> Security page to determine whether you are impacted by the specific PHP CVEs. Or, you can filter by vulnerability discovery date, CVSS score, and/or package manager.
- Remediate: Remediation guidance points each project to the shortest upgrade path to a patched release or base image.
If you have questions about using FOSSA to assist with PHP vulnerability remediation, please reach out to your customer success contact, or get in touch with our team.