The PHP development team has shipped emergency updates for two critical flaws, together called
PHP2Shell, in the core of PHP, the language that runs around 70 per cent of all websites. The flaws let
an attacker who has no account and no password run their own code on a web server or read
passwords and keys out of its memory, and they affect the server regardless of how well the website’s
own code is written. The only full fix is to update PHP now. Hosts that cannot update at once should
apply the interim settings below and watch for the warning signs.
1. Vulnerability Details
Both flaws share one root cause: PHP can leave its internal memory in a corrupted state when a request ends
abnormally, and a later request on the same worker reuses that state. Wiz Research grouped four demonstrated bugs
under the two CVEs, including the upload-progress unserializer use after free, remote process-memory disclosure, the
fatal-error backtrace use after free, and an OPcache type confusion. The vulnerable code sits in the PHP engine, so a
server is at risk even when the application on top is secure, and other tracked and likely untracked variants fold under the
same two CVEs. Risk is highest for Apache mod_php, where an unauthenticated request can trigger the flaw before any
application code runs.
- CVE-2026-109618 (CVSS 9.2, CWE-416): RCE via OOM corruption. PHP uses longjmp() to abort a request on an out of-memory error. In some paths request memory is reachable before it is fully set up, so a failed allocation leaves it in an invalid state that request shutdown then reads or branches on. A crafted multipart request can drive memory use past the limit within the normal checks and trigger this. The result is unauthenticated remote code execution as the web worker account. Vector CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N.
- CVE-2026-109619 (CVSS 9.2, CWE-416): RCE via stale global state. PHP holds global state, such as error, session and extension state, that a worker keeps between requests but that points to one request’s memory. When a fatal error or a late diagnostic leaves that state in place after the request heap is freed, a later request on the same worker reads the stale value before normal start-up resets it, a use after free. This gives unauthenticated heap use after free, memory disclosure, and remote code execution with the web worker’s privileges. Same vector as above.
2. Affected Products
- PHP 8.5: versions below 8.5.12, fixed in 8.5.12
- PHP 8.4: versions below 8.4.27, fixed in 8.4.27
- PHP 8.3: versions below 8.3.36, fixed in 8.3.36
- PHP 8.2: versions below 8.2.35, fixed in 8.2.35
- PHP 7.4, 8.0 and 8.1: end of life, source backports only; use a distribution or LTS vendor fix
- PHP 5.4 to 7.3: end of life and affected, no project fix; migrate to a supported branch
- All web-serving modes affected: Apache mod_php, PHP-FPM, php-cgi, FrankenPHP and LiteSpeed
3. Observed Activity
- Coordinated disclosure (21 Oct 2026): Calif, OpenAI and Wiz Research reported the flaws; PHP released out-of band fixes at 14:00 UTC on 21 October 2026. Wiz built a single exploit, php2shell, and demonstrated pre authentication RCE against current WordPress, Drupal and Joomla container images, and application-agnostic remote memory disclosure.
- Details leaked before release: Technical details, pointing at the default-on session.upload_progress feature, leaked publicly hours before the patch. VirusTotal first saw the referenced archive submitted at 02:29 UTC on 21 October.
- Early attacks reported: Cloudflare’s CTO stated the company was already seeing early attacks against the two flaws before the patch, blocked by temporary WAF rules. There is no confirmed report of widespread exploitation yet. Attacks below the application layer leave little in application logs.
4. Recommendations
- Find every PHP host that serves web requests and upgrade to 8.2.35, 8.3.36, 8.4.27 or 8.5.12. This is the only complete fix, and risk is highest on Apache mod_php.
- For PHP 7.4, 8.0 or 8.1, apply your distribution or LTS vendor backport, or move to a supported branch. Versions older than 8.2 receive no fixes direct from the PHP project.
- If you cannot patch now, set memory_limit=-1 and a low post_max_size (8M, or 32M if uploads are needed) through php_admin_value, set session.upload_progress.enabled=0, and on PHP 8.5 set fatal_error_backtraces=0, then restart every worker.
- Until every host is patched, hunt for unusual multipart requests followed by memory-limit errors or repeated HTTP 500 responses, oversized or malformed PHPSESSID response cookies, and unexplained PHP worker churn.
- Keep WAF or CDN rules that block known PHP2Shell patterns in place as a temporary layer only, and do not treat them as a substitute for updating to a fixed PHP release.
5. Sources
- https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w
- https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp
- https://www.php.net/archive/2026.php#2026-10-21-5
- https://www.wiz.io/blog/php2shell-php-rce
- https://blog.virustotal.com/2026/10/sizing-php-exposure-window-for-cve-2026.html
- https://www.bleepingcomputer.com/news/security/php-ships-emergency-patches-for-critical-php
2shell-flaws/ - https://www.ncsc.gov.uk/news/critical-security-issue-affecting-php
Enjoyed reading this Threat Intelligence Advisory? Stay updated with our latest exclusive content by following us on Twitter and LinkedIn
No related posts found.