All posts
Threat Intel·5 min read·By afarrell

PHP2Shell: 3 PHP Vulnerabilities Expose Web Servers to Remote Code Execution

PHP2Shell’s two critical PHP flaws are now exploited in the wild, so patch to the fixed releases, mitigate the third flaw, and check for compromise back to October 17.
PHP2Shell: 3 PHP Vulnerabilities Expose Web Servers to Remote Code Execution

Three recently disclosed vulnerabilities in PHP are raising serious security concerns for organizations operating websites, web applications, and other PHP-based services. Two of the vulnerabilities are rated critical, and new reporting indicates that attackers have successfully exploited the original flaws in the wild.

The vulnerabilities, collectively associated with the PHP2Shell security incident, include CVE-2026-109618, CVE-2026-109619, and CVE-2026-115560.

The first two vulnerabilities, disclosed on October 21, carry CVSS v4.0 scores of 9.2 and could allow unauthenticated attackers to execute malicious code on vulnerable web servers. A third vulnerability, disclosed on October 23, introduces an additional remote code execution risk under more specific configuration conditions.

Unlike security flaws affecting a particular website plugin or application, these vulnerabilities exist within PHP's underlying runtime and request-handling processes. As a result, they may affect a broad range of applications and hosting environments.

With exploitation activity already observed and public technical information available, organizations should prioritize identifying vulnerable PHP installations, applying available security updates, and investigating potentially compromised systems.

What Happened? A Timeline of the PHP2Shell Vulnerabilities

The PHP2Shell incident began with the discovery of two critical memory corruption vulnerabilities affecting PHP's request-handling processes. The PHP security team originally planned to disclose the vulnerabilities on October 22, 2026. However, after information began circulating publicly, the project accelerated its release schedule. On October 21, PHP published emergency security updates addressing CVE-2026-109618 and CVE-2026-109619.

According to the PHP Foundation's official security announcement, the vulnerabilities could allow remote code execution under certain conditions, including through unauthenticated requests.

The situation continued developing over the following days.

  • October 17: Amazon Threat Intelligence identified an attempted exploitation event in its honeypot telemetry, four days before public disclosure.
  • October 20: PHP announced an accelerated security release after information about the vulnerabilities began circulating.
  • October 21: PHP released emergency updates for CVE-2026-109618 and CVE-2026-109619. Both vulnerabilities received critical CVSS v4.0 scores of 9.2.
  • October 22: Security providers reported substantial increases in scanning and exploitation attempts targeting PHP-based infrastructure.
  • October 23: PHP disclosed CVE-2026-115560, a third remote code execution vulnerability requiring a separate mitigation.
  • October 26: New threat intelligence reporting indicated successful exploitation of the original PHP2Shell vulnerabilities in real-world environments.

The rapid progression from disclosure to exploitation highlights the limited response window organizations face when critical vulnerabilities become publicly known.

Understanding the Three PHP Vulnerabilities

Although the vulnerabilities are associated with the same security incident, each involves different technical conditions and remediation requirements.

CVE-2026-109618: Remote Code Execution Through Out-of-Memory Corruption

Severity: Critical | CVSS v4.0: 9.2

CVE-2026-109618 is a memory corruption vulnerability that occurs when PHP encounters an out-of-memory condition during request processing. Under certain circumstances, PHP may interrupt an operation before its internal data structures have been properly initialized. Subsequent cleanup operations may then access invalid memory, creating conditions that an attacker could potentially manipulate to execute arbitrary code.

Because the vulnerability affects PHP's internal request handling, exploitation may occur before application-level security controls are executed. Successful exploitation could allow an unauthenticated attacker to run malicious code with the permissions of the affected PHP process. Organizations running internet-facing PHP applications should treat this vulnerability as a high-priority remediation issue.

CVE-2026-109619: Remote Code Execution Through Stale Global State

Severity: Critical | CVSS v4.0: 9.2

CVE-2026-109619 involves a use-after-free condition within PHP's global request state. PHP uses internal references to manage information during request processing. Under certain circumstances, these references may remain accessible after the underlying memory has been released.

When subsequent operations interact with this stale memory, attackers may be able to trigger memory corruption and potentially execute arbitrary code. This vulnerability is especially concerning in environments where PHP worker processes handle multiple requests and internal state is reused.

Like CVE-2026-109618, exploitation does not necessarily require valid user credentials. According to Red Hat's PHP2Shell security bulletin, successful exploitation depends on factors including the PHP deployment model, memory behavior, and application configuration.

CVE-2026-115560: Remote Code Execution Through Session Upload Progress

Severity: Not yet assigned | Patch pending as of October 26

On October 23, PHP disclosed CVE-2026-115560, a third remote code execution vulnerability associated with PHP's session upload progress functionality. Unlike the original two vulnerabilities, this issue requires an uncommon combination of application behavior and PHP configuration settings.

Potential exposure exists when an application:

  • Configures session.serialize_handler as php_binary or php_serialize.
  • Changes the session serialization handler to php during runtime using ini_set().
  • Makes that change before calling session_start().
  • Leaves PHP's session upload progress functionality enabled.

According to the PHP project's October 23 advisory, this configuration is considered uncommon, making exploitation less likely across typical PHP installations. However, the vulnerability remains relevant for organizations running customized applications or legacy configurations.

Importantly, CVE-2026-115560 is not addressed by the October 21 PHP security updates, and as of October 26, PHP has not published a CVSS score or a dedicated patched release for this issue. A fix is expected in a subsequent routine update.

Until then, organizations with potentially affected configurations should disable session upload progress: session.upload_progress.enabled=0

This mitigation should be applied through the appropriate PHP or server configuration and followed by restarting affected PHP worker processes.

Why Are These PHP Vulnerabilities So Significant?

PHP is widely used to power websites, content management systems, e-commerce applications, and custom business platforms. The vulnerabilities therefore create potential exposure across a broad range of organizations, including those that may not directly manage their PHP infrastructure.

Several factors make this incident particularly concerning.

  • Unauthenticated remote code execution: The original two vulnerabilities may allow attackers to execute malicious code without obtaining valid credentials.
  • Application-independent exposure: Because the vulnerabilities exist in the underlying PHP runtime, updating a website plugin or changing application code does not necessarily address the underlying security weakness.
  • Potential access to sensitive information: Successful exploitation may expose application data, authentication tokens, credentials, or other information accessible to the compromised PHP process. Researchers have also demonstrated the potential for disclosure of sensitive PHP worker memory.
  • Opportunities for further compromise: Attackers who gain code execution may attempt to establish persistence, deploy malware, access connected systems, or use the compromised server as a foothold for additional attacks.
  • Challenges identifying affected systems: Organizations may operate PHP through externally hosted websites, third-party applications, legacy systems, containers, and development environments that are not consistently represented in asset inventories.

The extent of the risk depends on the affected PHP version, deployment configuration, accessibility, and existing security controls.

Are Attackers Actively Exploiting PHP2Shell?

Threat intelligence reporting indicates that attackers began targeting PHP2Shell before the official security patches became publicly available. Amazon Threat Intelligence identified an attempted exploitation event on October 17, demonstrating that malicious activity was already occurring before the October 21 disclosure.

Following the release of technical details, security providers observed a substantial increase in exploitation attempts. Cloudflare reported that attack activity increased rapidly following disclosure, reaching millions of attempted requests by October 22. Researchers also observed attempts to deploy malware, including a Mirai botnet variant, against potentially vulnerable systems.

While early reporting primarily documented scanning and unsuccessful exploitation attempts, October 26 reporting from BleepingComputer indicates that the original PHP2Shell vulnerabilities have now been successfully exploited in the wild.

These developments reinforce the importance of investigating potentially vulnerable systems, even after patches have been applied.

It is also important to distinguish the vulnerabilities. The reported exploitation activity concerns CVE-2026-109618 and CVE-2026-109619. As of October 26, there are no confirmed public reports of active exploitation of CVE-2026-115560.

Which PHP Versions Are Affected?

The PHP project released emergency security updates on October 21 addressing CVE-2026-109618 and CVE-2026-109619.

Organizations should update affected installations to the following versions or later supported releases:

  • PHP 8.5: Update to version 8.5.12 or later.
  • PHP 8.4: Update to version 8.4.27 or later.
  • PHP 8.3: Update to version 8.3.36 or later.
  • PHP 8.2: Update to version 8.2.35 or later.

PHP 8.1 and older versions are no longer supported by the PHP project and may remain vulnerable. Organizations using these versions should prioritize migration to a maintained release or verify whether their vendor provides security backports.

Affected deployment models include Apache with mod_php, PHP-FPM, php-cgi, FrankenPHP, and LiteSpeed.

The PHP security team identifies Apache with mod_php as particularly high risk because exploitation has been demonstrated through unauthenticated requests before application code executes.

The October 21 updates address the original two vulnerabilities but do not resolve CVE-2026-115560. Organizations must separately evaluate and mitigate that issue.

For additional information, review the PHP release archive and Red Hat's security guidance.

What Should Organizations Do Now?

Given the severity of the vulnerabilities and evidence of active exploitation, organizations should prioritize both immediate remediation and investigation of potential compromise.

1. Identify All PHP Deployments

  • Inventory PHP installations across internet-facing websites, application servers, cloud environments, containers, and third-party hosted infrastructure.
  • Identify the installed PHP version, deployment configuration, external accessibility, and business criticality of each system.
  • Pay particular attention to legacy applications, externally managed infrastructure, and systems that may fall outside standard vulnerability management processes.

2. Apply Available Security Updates

  • Immediately update affected PHP installations to the fixed versions addressing CVE-2026-109618 and CVE-2026-109619.
  • Verify that the patched runtime is active and restart affected services or worker processes as necessary.
  • For unsupported PHP versions, prioritize migration or verify that an appropriate vendor-supported security backport is available.
  • Organizations unable to patch immediately should consider restricting external access or temporarily isolating affected systems.

Temporary configuration changes and web application firewall protections may reduce exposure to certain exploitation techniques, but they do not provide complete remediation for the original vulnerabilities.

3. Mitigate CVE-2026-115560

  • Review whether applications use PHP's session upload progress functionality and modify session serialization handlers during runtime.
  • For affected configurations, disable session upload progress: session.upload_progress.enabled=0
  • Restart PHP worker processes to ensure the configuration change takes effect.
  • Monitor the PHP project's security announcements for the forthcoming security update.

4. Investigate Potential Exploitation

  • Review available security telemetry dating back to at least October 17, 2026.
  • Prioritize internet-facing PHP servers that were accessible before security updates were deployed.
  • Look for suspicious web requests, unexpected PHP process execution, unusual memory-related errors, unauthorized file modifications, and abnormal outbound network connections.
  • Correlate web server activity with endpoint, network, and identity telemetry to identify potential post-exploitation behavior.

If suspicious activity is detected, follow established incident response procedures to contain affected systems, preserve evidence, and determine the extent of any compromise.

5. Validate Security Controls and Continue Monitoring

  • Confirm that endpoint detection, network monitoring, security logging, and relevant web application protections are functioning as expected.
  • Continue monitoring for additional exploitation techniques, updated security advisories, and newly released patches.

Organizations should also review whether their vulnerability management processes provide sufficient visibility into exposed assets and whether newly identified vulnerabilities can be quickly connected to active threat intelligence.

What PHP2Shell Reveals About Modern Vulnerability Management

PHP2Shell demonstrates how quickly a critical vulnerability can become an active security threat. Within days, organizations were confronted with multiple vulnerabilities, emergency patches, exploitation attempts, and an additional disclosure requiring separate mitigation.

The challenge for security teams extends beyond knowing that a vulnerability exists.

Organizations must determine which systems are affected, whether those systems are exposed to attackers, what business processes depend on them, and whether suspicious activity has already occurred. That requires coordination across asset management, vulnerability intelligence, threat detection, and incident response.

When these capabilities operate independently, security teams may have access to vulnerability data without the operational context needed to prioritize action. A critical finding in a vulnerability scanner does not automatically reveal whether the affected system is internet-facing, whether attackers are targeting it, or how a compromise could affect the broader environment.

Effective vulnerability management requires connecting security intelligence with continuous visibility, risk prioritization, and coordinated response.

PHP2Shell reinforces why organizations need to operationalize their security rather than rely on disconnected tools and reactive patching alone.

Operationalize Vulnerability Management with ArmorPoint

Critical vulnerabilities like PHP2Shell put security teams under immediate pressure to identify exposure, understand potential threats, and respond before attackers can take advantage.

ArmorPoint helps organizations operationalize their security by bringing asset visibility, vulnerability management, threat intelligence, and 24/7 security monitoring together in a unified security operations ecosystem.

Backed by a 24/7 U.S.-based SOC, ArmorPoint helps security teams connect newly identified vulnerabilities with activity across their environments, prioritize security risks, investigate suspicious behavior, and coordinate response.

Because identifying a critical vulnerability is only the first step. Understanding where you're exposed, recognizing when threats become active, and knowing how to respond are what turn vulnerability management into effective security operations.

See How ArmorPoint Operationalizes Your Security

Sources and References

Official vulnerability advisories

Threat intelligence and technical research

Government and cybersecurity authority guidance