PHP2Shell (CVE-2026-109618 and CVE-2026-109619): What IT Teams Need to Do Now

Two critical PHP flaws, CVE-2026-109618 and CVE-2026-109619 (nicknamed PHP2Shell), let an attacker run code on a web server with a crafted request and no login. PHP shipped fixes on October 21, 2026, and CISA added both flaws to its Known Exploited Vulnerabilities catalog on October 26. If any system you run serves web pages through PHP, patch it this week, because updating is the only complete fix.

Your first three moves:

• Inventory every PHP install you own or depend on, including vendor-hosted and vendor-supplied software.
• Update to PHP 8.2.35, 8.3.36, 8.4.27, or 8.5.12, or to your vendor's patched build.
• Review web server logs back to October 17 for unusual requests and for web server or PHP processes launching shells, curl, or wget.

What are the PHP2Shell vulnerabilities, and which versions are affected?

PHP2Shell is a pair of flaws in the PHP engine itself, not in any single application, and both are rated 9.2 (critical) on the CVSS v4.0 scale. An unauthenticated attacker can exploit either one remotely.

• CVE-2026-109618 (out-of-memory corruption): PHP handles out-of-memory errors in a way that can leave request data half-initialized. Crafted multipart requests can trigger it, and with Apache mod_php it can happen before any application code runs.
• CVE-2026-109619 (stale request state): PHP keeps global state that points to memory owned by a request. A later request handled by the same worker can use that stale state before normal initialization.

Any PHP installation that serves web requests is in scope, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed. Applications built on PHP, such as content management systems, e-commerce platforms, and web frameworks, can be exposed through a vulnerable runtime.

Linux distributions and long-term-support vendors received the patches in advance, so check your vendor for updated packages. A version number alone can mislead when a vendor backports a fix, so confirm patch status in your vendor's security tracker. Source: runZero's summary of PHP's advisory.

Is PHP2Shell being exploited?

Yes. CISA added both flaws to its Known Exploited Vulnerabilities catalog on October 26, 2026, with an October 29 deadline for federal civilian agencies. That deadline doesn't bind private companies, but CISA urges organizations outside the federal government to prioritize the fix.

By October 27, researchers at Delft University had tracked more than 50,000 exploitation requests from over 600 IP addresses in 70 countries. Of those, 171 addresses went beyond probing and sent exploit code or malware droppers. The honeypots used a favorable single-worker setup, so the results don't show how reliably the exploit works against production servers.

Treat claims about specific victims with care. Some early reports of successful intrusions were later walked back. Source: The Register, October 27, 2026.

What should IT teams do this week?

Patching comes first, but you can only patch what you can find. Work through these steps in order.

• Find PHP everywhere. Check web servers, containers, content management systems, e-commerce sites, customer portals, and vendor-supplied software. Ask each vendor for written patch status.
• Patch. Update to PHP 8.2.35, 8.3.36, 8.4.27, or 8.5.12, or to your vendor's patched build, and restart services so the new version loads.
• Mitigate only if you can't patch yet. PHP's interim settings reduce exposure but don't make a system safe. For CVE-2026-109618, set memory_limit to -1 in a way applications can't override, set a low post_max_size, and enforce request size, multipart, header, and nesting limits at the web server or proxy. For CVE-2026-109619, set session.upload_progress.enabled to 0 and, on PHP 8.5, fatal_error_backtraces to 0, then restart all workers. Test first, because removing the memory limit lets a single request use all of a server's memory.
• Take unpatchable systems offline. If a system can't be patched or mitigated, remove it from the internet until it can be.
• Hunt for signs of compromise. Review web server logs back to October 17. Look for unusual requests, web server or PHP processes launching shells, curl, or wget, outbound connections from web servers to unknown hosts, and unexpected new files in web directories.
• Plan for PHP 8.1 and older. The PHP project no longer supports these versions, so migrate to a supported release or get a backport from your vendor.

Sources: runZero for the mitigations, and The Register for the guidance on taking unpatchable systems offline and the attacker behavior to look for.

How can 7 Layer Solutions help with PHP exposure?

Fixing this quickly depends on knowing where PHP runs and on spotting exploitation if it has already happened. Three of our services map to the steps above.

• Cybersecurity assessments and vulnerability scanning: find exposed and outdated PHP across your environment and rank what to fix first.
• Patch management through managed IT: roll out updates and track which systems are finished.
• 24/7 SOC with managed endpoint detection and response: watch for the behavior described above, such as web servers launching shells or reaching out to unknown hosts.

To see what round-the-clock monitoring looks like in practice, read how our SOC contained an active ransomware intrusion at a manufacturer in 17 minutes. That case is unrelated to PHP.

If you want help finding and prioritizing PHP exposure, contact our team.

Sources

• runZero: Critical RCE vulnerability in PHP
• The Register: CISA confirms PHP2Shell under attack
• CISA: Adds Two Known Exploited Vulnerabilities to Catalog, October 26, 2026