Zscaler Blog

Get the latest Zscaler blog updates in your inbox

Security Research

CVE-2026-109618 and CVE-2026-109619: PHP Vulnerable to Unauthenticated RCE Attacks

image
>CVE-2026-109618 and CVE-2026-109619: PHP Vulnerable to Unauthenticated RCE Attacks

Introduction

On October 21, 2026, two critical remote code execution (RCE) vulnerabilities, CVE-2026-109618 and CVE-2026-109619, collectively referred to as “PHP2Shell,” were publicly disclosed. Both vulnerabilities carry a CVSS v4.0 score of 9.2 out of 10. The PHP security team has released emergency patches and strongly encouraged all PHP users to update immediately. These flaws reside in the PHP core language runtime and successful exploitation allows an unauthenticated remote attacker to achieve remote code execution on any server running a vulnerable version, potentially enabling unauthorized access, data theft, or further system compromise. Given PHP's pervasive deployment across web infrastructure globally - including applications like WordPress, Drupal, Joomla, and Magento, as well as embedded devices and similarly overlooked public-facing platforms - the attack surface is extraordinarily large. Critically, because exploitation requires no authentication and no user interaction, attacks can be fully automated and executed at internet scale with no preconditions. The potential for mass exploitation by both opportunistic and nation-state threat actors is therefore considered high.

Zscaler’s security team is actively analyzing this issue across both production and corporate environments and has ruled out any impact to the production environment. We will continue to update the Trust post with the latest information. 

Recommendations

Organizations running PHP should take the following actions:

  1. Patch immediately: Upgrade PHP to one of the fixed versions: 8.5.12, 8.4.27, 8.3.36, or 8.2.35. Linux package maintainers received patches in advance and may already have updated packages available. PHP packages for most Linux distributions may also include the patches backported to previous versions of the software, so consult the release notes for your specific installation to ensure your systems are covered.
  2. Deactivate unpatched instances: Consider fully disabling services for any PHP instance that cannot be immediately patched. While this may seem overly cautious, any unpatched instance could be targeted by opportunistic adversaries and result in shell-level access to the vulnerable host. Disabling the service is the only way to ensure the security of the instance.
  3. Inventory PHP deployments: Conduct an immediate inventory of all PHP installations across your environment, including standalone servers, vendor appliances, bundled software (WordPress, Magento, WooCommerce, Shopware), and hosting panels (cPanel, Plesk, etc).
  4. Migrate off EOL branches: Organizations running PHP 5.4+, 7.x, 8.0, or 8.1 must migrate to a supported branch immediately. No official binary patches will be released for these versions.
  5. Isolate EOL instances that cannot be immediately migrated: Migrating EOL instances is strongly recommended. If this is not possible, isolating unpatchable applications from the internet and other untrusted networks may provide some level of protection. This should be considered a high-risk mitigation and reserved only for business and mission-critical applications while implementing aggressive monitoring of these instances.
  6. Monitor for exploitation: Audit web server logs (including but not limited to Apache, Nginx, etc.) for unusual segmentation faults, crash dumps, or abnormal memory usage patterns that may indicate active exploitation attempts.
  7. Mitigate risk through PHP settings: While not a definitive fix, mission critical applications that cannot be disabled or immediately patched may benefit from reviewing and tightening memory_limit and max_execution_time settings in php.ini to avoid triggering OOM conditions. Consult additional guidance regarding mitigations through setting session.upload_progress.enabled = Off and disabling multipart uploads at the service edge.


Affected Versions

All PHP versions from 5.4 onward are vulnerable. Only currently supported branches received patches, but package maintainers may also backport the security patches to previous versions. Carefully review the instructions and release notes from the maintainers of your PHP installations to determine what version and release includes the necessary patch.

PHP Branch

Vulnerable Versions

Patch Available

PHP 8.5

8.5.0 – 8.5.11

Yes (8.5.12)

PHP 8.4

8.4.0 – 8.4.26

Yes (8.4.27)

PHP 8.3

8.3.0 – 8.3.35

Yes (8.3.36)

PHP 8.2

8.2.0 – 8.2.34

Yes (8.2.35)

PHP 8.1

All versions (EOL)

No (EOL — upgrade required)

PHP 8.0

All versions (EOL)

No (EOL — upgrade required)

PHP 7.x

All versions (EOL)

No (EOL — upgrade required)

PHP 5.4+

All versions (EOL)

No (EOL — upgrade required)

Table 1: CVE-2026-109618 and CVE-2026-109619 Affected PHP Versions and Patch Availability

How It Works

Both vulnerabilities are use-after-free memory safety flaws in PHP's core request-handling engine. All PHP applications are affected regardless of application-level security controls. The vulnerabilities can allow unauthenticated attackers to execute code on affected servers or read sensitive process memory; that memory may contain passwords, authentication tokens, API keys and certificates belonging to other requests or the server itself.

CVE-2026-109618: OOM Corruption / Uninitialized Memory Use

  • CVSS v4.0: 9.2 - Critical

  • Root Cause: PHP uses longjmp() to abort a request when it hits its configured memory limit. When a web application receives form input, PHP records new entries in its internal POST data structure before finishing their initialization. If an out-of-memory (OOM) error fires while internal request data is only partially initialized, longjmp() bypasses normal control flow, leaving memory in an inconsistent/uninitialized state. During request cleanup, PHP misinterprets this invalid data as valid and follows an attacker-controlled code pointer, yielding control of execution.

  • Exploit Vector: An attacker can intentionally trigger specific OOM conditions (e.g., via large memory allocations, deeply recursive calls, or maliciously crafted request payloads) to corrupt state and achieve unauthenticated RCE.

  • Impact: Unauthenticated Remote Code Execution

CVE-2026-109619: Use-After-Free / Stale Memory Access

  • CVSS v4.0: 9.2 - Critical

  • Root Cause: When PHP encounters a fatal error and calls zend_bailout() (via longjmp()), request-owned internal state can survive in global memory after its backing allocation has been freed. PHP workers process multiple requests in sequence, and certain internal pointers persist between requests. If a request crashes or exhausts memory at the right moment, those pointers are left pointing to already-recycled memory. A subsequent request processed by the same worker may access this stale memory before re-initialization occurs.

  • Exploit Vector: This vulnerability is chainable with CVE-2026-109618. The partial initialization in CVE-2026-109618 allows an attacker to shape the freed memory contents and gain control of the instruction pointer, enabling highly reliable RCE. Chaining these two CVEs requires no authentication and no user interaction.

  • Impact: Unauthenticated Remote Code Execution and memory/credential disclosure

Conclusion

PHP2Shell represents one of the most significant PHP vulnerabilities disclosed in recent years, given both the technical severity of the flaws and the unprecedented scale of the affected install base. The combination of CVE-2026-109618 and CVE-2026-109619 provides a reliable, unauthenticated path to full server compromise with no user interaction required.

Organizations are strongly urged to treat this as an emergency patching event. Systems running EOL PHP branches must be migrated without delay. Where patching cannot be completed immediately, network-layer controls should be applied as an interim measure.

ThreatLabz will continue to monitor active exploitation campaigns and update Zscaler platform protections as new indicators emerge.

Zscaler is assessing the potential impact on its products in the Trust post.

How Zscaler Can Help

The following table shows the typical attack stages and the mitigations recommended by Zscaler.

Attack Stage

Recommended Mitigation

Minimize the external attack surface

  • Identify and fix any vulnerable PHP applications with Zscaler Exposure Management
  • Eliminate externally exposed PHP assets by leveraging a Zero Trust architecture.

Prevent compromise

Prevent lateral threat movement

  • Use ZPA to enforce least-privilege user-to-app segmentation for crown-jewel apps (employees and third parties).
  • Use ZPA inline inspection to block exploitation attempts against private apps from compromised users.
  • Use Zscaler Deception to detect and contain lateral movement or privilege escalation with decoy assets and accounts.
  • Use Zscaler MDR and Threat Hunting to detect and respond to early stage threat activity.

Prevent data loss

  • Inspect outbound traffic across channels with Zscaler DLP.

Zscaler MDR's behavioral detection analytics also provide generic coverage for this class of web application RCE. The following active detection analytics are candidates for identifying post-exploitation activity that may result from these vulnerabilities:

  • NIX-WEBSERVER-SPAWN-SUSPICIOUS-COMMAND — Linux web servers spawning suspicious commands including reconnaissance utilities and downloaders
  • NIX-WEBSERVER-SPAWN-RECON — Web servers spawning reconnaissance commands
  • PSX-WEBSERVER-CREATE-PHP-SCRIPT — Web servers creating inline PHP scripts in web directories
form submtited
Thank you for reading

Was this post useful?

Disclaimer: This blog post has been created by Zscaler for informational purposes only and is provided "as is" without any guarantees of accuracy, completeness or reliability. Zscaler assumes no responsibility for any errors or omissions or for any actions taken based on the information provided. Any third-party websites or resources linked in this blog post are provided for convenience only, and Zscaler is not responsible for their content or practices. All content is subject to change without notice. By accessing this blog, you agree to these terms and acknowledge your sole responsibility to verify and use the information as appropriate for your needs.

Get the latest Zscaler blog updates in your inbox

By submitting the form, you are agreeing to our privacy policy.