Zscaler Blog
Erhalten Sie die neuesten Zscaler Blog-Updates in Ihrem Posteingang
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:
- 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 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 |
|
Prevent compromise |
|
Prevent lateral threat movement |
|
Prevent data loss |
|
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
War dieser Beitrag nützlich?
Haftungsausschluss: Dieser Blog-Beitrag wurde von Zscaler ausschließlich zu Informationszwecken erstellt und wird ohne jegliche Garantie für Richtigkeit, Vollständigkeit oder Zuverlässigkeit zur Verfügung gestellt. Zscaler übernimmt keine Verantwortung für etwaige Fehler oder Auslassungen oder für Handlungen, die auf der Grundlage der bereitgestellten Informationen vorgenommen werden. Alle in diesem Blog-Beitrag verlinkten Websites oder Ressourcen Dritter werden nur zu Ihrer Information zur Verfügung gestellt, und Zscaler ist nicht für deren Inhalte oder Datenschutzmaßnahmen verantwortlich. Alle Inhalte können ohne vorherige Ankündigung geändert werden. Mit dem Zugriff auf diesen Blog-Beitrag erklären Sie sich mit diesen Bedingungen einverstanden und nehmen zur Kenntnis, dass es in Ihrer Verantwortung liegt, die Informationen zu überprüfen und in einer Ihren Bedürfnissen angemessenen Weise zu nutzen.
Erhalten Sie die neuesten Zscaler Blog-Updates in Ihrem Posteingang
Mit dem Absenden des Formulars stimmen Sie unserer Datenschutzrichtlinie zu.



