CVE-2026-109618 and CVE-2026-109619: PHP Vulnerable to Unauthenticated RCE Attacks Jithin Prajeev Nair (Director, Threat Research)

IntroductionOn 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.  RecommendationsOrganizations running PHP should take the following actions: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.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.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).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.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.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.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 VersionsAll 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 BranchVulnerable VersionsPatch AvailablePHP 8.58.5.0 – 8.5.11Yes (8.5.12)PHP 8.48.4.0 – 8.4.26Yes (8.4.27)PHP 8.38.3.0 – 8.3.35Yes (8.3.36)PHP 8.28.2.0 – 8.2.34Yes (8.2.35)PHP 8.1All versions (EOL)No (EOL — upgrade required)PHP 8.0All versions (EOL)No (EOL — upgrade required)PHP 7.xAll 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 WorksBoth 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 UseCVSS v4.0: 9.2 – CriticalRoot 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 ExecutionCVE-2026-109619: Use-After-Free / Stale Memory AccessCVSS v4.0: 9.2 – CriticalRoot 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 ConclusionPHP2Shell 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 HelpThe following table shows the typical attack stages and the mitigations recommended by Zscaler.Attack StageRecommended MitigationMinimize the external attack surfaceIdentify and fix any vulnerable PHP applications with Zscaler Exposure ManagementEliminate externally exposed PHP assets by leveraging a Zero Trust architecture.Prevent compromiseDetonate unknown second-stage payloads with Advanced Cloud Sandbox.Route server egress through ZIA to detect/block post-compromise activity.Enable SSL/TLS inspection for all traffic, including trusted sources.Enable Advanced Threat Protection to block known C2 domains.Use Advanced Cloud Firewall, to extend C2 controls across all ports/protocols, including emerging C2.Prevent lateral threat movementUse 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 lossInspect 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 downloadersNIX-WEBSERVER-SPAWN-RECON — Web servers spawning reconnaissance commandsPSX-WEBSERVER-CREATE-PHP-SCRIPT — Web servers creating inline PHP scripts in web directories  

​[#item_full_content] IntroductionOn 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.  RecommendationsOrganizations running PHP should take the following actions: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.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.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).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.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.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.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 VersionsAll 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 BranchVulnerable VersionsPatch AvailablePHP 8.58.5.0 – 8.5.11Yes (8.5.12)PHP 8.48.4.0 – 8.4.26Yes (8.4.27)PHP 8.38.3.0 – 8.3.35Yes (8.3.36)PHP 8.28.2.0 – 8.2.34Yes (8.2.35)PHP 8.1All versions (EOL)No (EOL — upgrade required)PHP 8.0All versions (EOL)No (EOL — upgrade required)PHP 7.xAll 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 WorksBoth 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 UseCVSS v4.0: 9.2 – CriticalRoot 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 ExecutionCVE-2026-109619: Use-After-Free / Stale Memory AccessCVSS v4.0: 9.2 – CriticalRoot 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 ConclusionPHP2Shell 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 HelpThe following table shows the typical attack stages and the mitigations recommended by Zscaler.Attack StageRecommended MitigationMinimize the external attack surfaceIdentify and fix any vulnerable PHP applications with Zscaler Exposure ManagementEliminate externally exposed PHP assets by leveraging a Zero Trust architecture.Prevent compromiseDetonate unknown second-stage payloads with Advanced Cloud Sandbox.Route server egress through ZIA to detect/block post-compromise activity.Enable SSL/TLS inspection for all traffic, including trusted sources.Enable Advanced Threat Protection to block known C2 domains.Use Advanced Cloud Firewall, to extend C2 controls across all ports/protocols, including emerging C2.Prevent lateral threat movementUse 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 lossInspect 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 downloadersNIX-WEBSERVER-SPAWN-RECON — Web servers spawning reconnaissance commandsPSX-WEBSERVER-CREATE-PHP-SCRIPT — Web servers creating inline PHP scripts in web directories