Attackers were already trying to exploit PHP2Shell before details of the vulnerabilities emerged publicly on October 20, 2026. The two critical vulnerabilities affect PHP, which many websites and business applications rely on, and allow threat actors to execute code on vulnerable servers without needing login credentials.
The early exploitation attempts put organizations on the back foot, with little time to pinpoint affected systems and apply security updates.
For organizations running affected PHP installations, the immediate concern is identifying exposed systems and fixing them before attackers do.
What makes PHP2Shell so dangerous?
PHP2Shell refers to two critical remote code execution (RCE) vulnerabilities, CVE-2026-109618 and CVE-2026-109619. Both involve memory-handling flaws in PHP, although they affect different parts of its operation.
CVE-2026-109618 involves memory corruption during out-of-memory handling. CVE-2026-109619 involves stale memory references that persist between requests.
Attackers can exploit these weaknesses to execute code without authenticating to the affected server.
Both vulnerabilities received a Common Vulnerability Scoring System (CVSS) version 4.0 score of 9.2.
The problem isn’t limited to websites running a particular content management system. The affected configurations include PHP FastCGI Process Manager (FPM) and Apache mod_php, putting different types of PHP applications at risk.
This PHP2Shell FAQ explains the technical differences, affected versions, and available security updates.
An attacker who compromises a PHP server gains the privileges of the affected process. Depending on how the server is configured, those privileges may provide access to application data or credentials that open the door to other systems.
How quickly did attackers respond?
Attackers were investigating PHP2Shell before the public disclosure. Amazon Threat Intelligence reported an exploitation attempt against its honeypot infrastructure on October 17. Subsequent activity involved different payloads and infrastructure, indicating interest from multiple attackers.
Criminal forums also reacted quickly. Some underground forum administrators took their services offline or restricted registrations, while others moved communications to alternative platforms to limit their exposure.
These forums hold information their operators have good reason to protect. A successful compromise could expose private conversations or give rival criminals access to accounts and infrastructure.
The reaction shows us that criminal operators were prepared to interrupt their own services rather than leave vulnerable PHP systems exposed.
Organizations don’t always have that freedom. A customer-facing application may need to remain available while administrators investigate the risk and arrange updates. Attackers have no reason to wait for that work to finish.
Why aren’t critical CVSS scores enough to prioritize remediation?
Two servers can have the same critical vulnerability and present very different risks.
A public-facing PHP server handling customer records needs immediate attention. An isolated test server running the same vulnerable version may pose a much smaller threat, particularly if attackers have no way to reach it.
CVSS describes the technical severity of a vulnerability. It doesn’t account for where an organization runs the affected software or what an attacker would gain from compromising it.
Vulnerability management teams need to establish whether attackers can reach the affected service and whether exploitation is already happening. They also need to understand what the server connects to.
A PHP application with access to a production database deserves closer scrutiny than one running in a restricted environment. The same applies to servers that hold credentials with broad permissions.
The Cybersecurity and Infrastructure Security Agency (CISA) added both PHP2Shell vulnerabilities to its Known Exploited Vulnerabilities (KEV) catalog on October 26. That confirms documented exploitation in the wild and gives security teams a concrete reason to move affected systems up the remediation queue.
What does PHP2Shell reveal about the patch gap?
The patch gap is the period during which attackers can exploit a vulnerability before an organization successfully patches or mitigates its affected systems.
With PHP2Shell, exploitation attempts preceded public disclosure. Organizations had less time to respond than the advisory date alone suggests.
PHP released security updates for supported branches on October 21. But installing those updates across an organization takes work.
Teams first need to locate affected installations. Some may run applications that require compatibility testing before an update. Others may belong to external providers or sit outside the systems that central security teams routinely scan.
Unsupported PHP versions complicate matters. Organizations running older applications may need vendor-supported backports or upgrades to maintained PHP releases.
Even after administrators install an update, they need to check that the running service uses the corrected version. An updated package won’t protect an application if an old PHP process is still running.
What should security teams do now?
Check internet-facing PHP servers first, particularly those running critical business applications. Next, review internal systems to see where attackers could use a compromised application to reach production infrastructure.
Security teams should take the following steps:
- Find affected installations. Check asset inventories and vulnerability scan results against the affected PHP versions. Include externally hosted applications and systems outside routine patch management.
- Establish which systems attackers can reach. Prioritize vulnerable internet-facing services and investigate their access to sensitive information or other infrastructure.
- Apply the appropriate fixes. Follow official PHP and distribution-specific advisories. Check for vendor backports where applications depend on older releases.
- Check for exploitation. Review web server logs for suspicious requests and investigate any unusual processes running on affected servers.
- Limit access until patches are available. Restrict connections to vulnerable services and apply temporary protections where necessary.
- Verify the fixes. Make sure the updated PHP version is running and rescan affected systems to confirm the vulnerabilities are no longer present.
CISOs need to know which critical systems are still vulnerable, who is responsible for fixing them, and when the work will be completed. If patching is delayed, security teams should explain why and confirm what they’re doing to protect those systems in the meantime.
Information Security Buzz News Editor
Kirsten Doyle has been in the technology journalism and editing space for nearly 24 years, during which time she has developed a great love for all aspects of technology, as well as words themselves. Her experience spans B2B tech, with a lot of focus on cybersecurity, cloud, enterprise, digital transformation, and data centre. Her specialties are in news, thought leadership, features, white papers, and PR writing, and she is an experienced editor for both print and online publications.
The opinions expressed in this post belong to the individual contributors and do not necessarily reflect the views of Information Security Buzz.