Security advisory · updated 22 Oct 2026
PHP2Shell at a glance
Two flaws in the PHP engine itself can allow unauthenticated remote code execution. The PHP project released fixes on 21 October 2026. If a server runs PHP for websites, its runtime needs checking, whatever application sits on top.
Update to at least:
- PHP 8.5.12
- PHP 8.4.27
- PHP 8.3.36
- PHP 8.2.35
- Confirmed Official patches and advisories published by the PHP project.
- Demonstrated Unauthenticated RCE shown by researchers against WordPress and Drupal in a lab.
- Not reported Exploitation in the wild, as of 22 October 2026.
01 — Introduction
Why the PHP2Shell vulnerability matters
Most security alerts concern a single plugin, theme or app. The PHP2Shell vulnerability is different: it sits in the PHP engine itself, the runtime underneath WordPress blogs, WooCommerce shops, Laravel APIs, CodeIgniter dashboards, Drupal portals and countless custom business systems.
On 21 October 2026 the PHP project released PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 to fix two critical flaws, CVE-2026-109618 and CVE-2026-109619. Both are rated 9.2 on CVSS v4.0. The PHP team's words are direct: they "can allow unauthenticated remote code execution", and all PHP users are encouraged to update immediately [1].
The flaws were found by Wiz Research, which says frontier AI models played a significant part in finding them, building working exploits and validating the fix [2]. This is one of the most prominent cases so far of AI-assisted research uncovering critical bugs in a widely used language runtime.
What "millions" means
69.3%
of websites whose server-side language is known use PHP, according to W3Techs (22 Oct 2026) [6]. That is why the reach is measured in millions.
What it does not mean
Using PHP is not the same as being vulnerable. No credible count of sites that are actually exploitable has been published. Exposure depends on the PHP version, whether a vendor patch is installed, and how PHP is run. Many hosts received patches in advance and may already be protected. Nobody has reported mass compromise.
02 — Discovery
Who discovered the vulnerabilities?
Three groups played distinct roles. Keeping them apart helps when you are working out which source to trust for which fact.
Researchers
Wiz Research: Sagi Tzadik, Shir Tamari, Nir Ohfeld and Tomer Schwartz wrote the PHP2Shell report. Wiz also credits OpenAI for "discovery, coordination and patch verification".
Maintainers
PHP security team: received the reports, developed the fixes and published the advisories. The GitHub advisories credit arnaud-lb, iluuu1994, bukka and ndossche with the remediation [3].
Amplifiers
Vendors, CDNs and security agencies publish their own alerts and mitigations afterwards. They did not do the research. Read them for guidance specific to your platform.
Disclosure was coordinated. Wiz reported the issues to the PHP security team on 24 August 2026. PHP acknowledged them and began work on fixes on 21 September. Linux distributions and long-term-support vendors received patches before the public release [1], which is why many managed hosts could patch on day one. The GitHub advisories list the reporters as lcfr-hax, sagitzadik-wiz, tomash-areion and amyb-oai.
03 — AI-assisted research
How AI helped discover the vulnerabilities
The Wiz report names three systems used in the research: Wiz Atlas, Gemini 4 Argon and GPT-5.6 Sol [2]. It credits Gemini 4 Argon with an "invaluable contribution to finding the vulnerability, exploit development, attack detection, and validation of the patch".
“Frontier models substantially reduced that barrier, turning a longstanding flaw into an exploit.”
What Wiz credits to AI
- Helping find the bugs in complex, low-level code paths
- Exploit development, including adapting exploits to different PHP versions and memory layouts through "repeated testing and debugging"
- Attack detection and validating the patch
- Speed: Wiz says one researcher did in a week what "previously would have taken a world-class team months"
What humans did
- Directed the research and decided what to investigate
- Confirmed exploitability against real applications
- Reported privately and coordinated disclosure with PHP
- Wrote, reviewed and shipped the fixes: PHP core developers
What the evidence does not support: the claim that an AI system autonomously found, verified, disclosed and fixed these flaws. Wiz itself describes AI as speeding up human researchers. OpenAI has published its own account of its role. We have not reviewed it for this article, so this article does not describe that role in detail.
04 — The basics
What is PHP2Shell?
Researchers use "shell" to mean being able to run commands on a server. PHP2Shell describes the outcome: a crafted web request to PHP that ends with the attacker running code on the machine. Remote code execution (RCE) is the most serious class of web vulnerability, because the attacker gets whatever the PHP process can reach.
Terms in plain English
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
- AV:N attackable over the network
- PR:N / UI:N no privileges, no user interaction
- AC:H exploitation is technically complex
- AT:P some conditions must be present on the target
- VC:H / VI:H / VA:H high impact on confidentiality, integrity and availability of the vulnerable system
"High complexity" is no reason to relax. It means an exploit is hard to build, and Wiz's point is that AI made building one much easier.
05 — Technical analysis
Technical analysis of each vulnerability
Both bugs are about memory that PHP's request lifecycle fails to clean up correctly. This is a defensive explanation based on the official advisories. It deliberately leaves out exploitation detail.
RCE via out-of-memory (OOM) corruption
longjmp() to bail out when an allocation fails. If that happens while internal request data is only partly initialised, request cleanup can later "treat the invalid data as valid" [1].RCE via stale global state (use-after-free)
How bad is it, and since when? Wiz says the flaws affect "every PHP version released in the last decade", going back to PHP 5.4 [2]. The official advisories list every supported branch below the fixed versions as vulnerable [3][4]. The PHP project also published minimal source backports for 7.4, 8.0 and 8.1, which confirms that those older branches are affected too.
06 — Platforms
Which websites and platforms could be affected?
The flaw is in the PHP runtime, not in any one application. Wiz describes it as "in PHP itself, independent of the application running on top of it". So the key question for every platform below is the same: which PHP build is serving its web requests, and is it patched?
WordPress
DemonstratedEvery page of a WordPress blog, business site, membership site or WooCommerce store is generated by PHP. Wiz confirmed unauthenticated RCE against WordPress in its lab on 21 August 2026. That shows the attack is reachable on a standard install running vulnerable PHP. It does not mean WordPress's own code is flawed.
- Updating WordPress core, plugins or themes does not patch PHP.
- On shared or managed hosting, the host usually controls the PHP build. Ask them.
- Tools → Site Health → Info → Server shows the PHP version and SAPI serving the site.
Laravel
Runtime-dependentLaravel APIs, SaaS products, dashboards and shops all run on PHP. Laravel's CSRF protection, validation and query escaping guard against application bugs. This is an engine bug, which can be triggered before Laravel's code even runs. Neither source names Laravel specifically, but nothing in the advisories suggests a framework changes the exposure.
composer updatedoes not change the PHP engine.- Check production, staging, queue workers, Docker images and CI images separately.
php artisan aboutreports the CLI PHP, which may differ from FPM.
CodeIgniter
Runtime-dependentCodeIgniter is popular for business apps, admin dashboards, custom websites and APIs, and it is often found on older servers. Your CodeIgniter version, 3 or 4, tells you nothing about this issue. What matters is the PHP runtime underneath it and whether the relevant advisory has been applied.
- Legacy CodeIgniter 3 apps often run on PHP 7.x, which has no upstream fix release.
- Confirm the runtime first, then plan an upgrade or apply a vendor backport.
Other PHP platforms
- Drupal Demonstrated : Wiz confirmed RCE on 20 Aug 2026.
- Joomla Demonstrated : listed by Wiz among the applications it exploited.
- Magento / Adobe Commerce, PrestaShop Runtime-dependent : not named in the sources. Shops handle payments and customer data, so prioritise them.
- Custom, legacy and internal PHP apps and APIs Runtime-dependent : often the hardest to patch, because they tend to run on old, unsupported PHP versions.
07 — Infrastructure
Which hosting providers and server configurations are at risk?
According to the PHP project, the people at risk are "all PHP installations serving web requests". That covers every common way of running PHP behind a web server. Risk still varies by configuration.
By server API (SAPI)
| How PHP runs | Official status | What to know |
|---|---|---|
| Apache + mod_php | Highest risk | PHP says a demonstrated exploit can fire "before any application code runs". After patching, restart Apache. |
| Nginx / Apache + PHP-FPM | Affected | Long-lived workers serve many requests, which is the setting CVE-2026-109619 describes. Restart every FPM pool after updating. |
| php-cgi | Affected | Still common on older shared hosting. Update the CGI binary itself. |
| LiteSpeed (LSAPI) | Affected | Widely used by shared hosts. The PHP builds (lsphp / alt-php) are packaged separately and must be updated as well. |
| FrankenPHP | Affected | PHP is embedded in the server. You need a FrankenPHP binary or image built with a fixed PHP. Updating the OS php package may not be enough. |
By hosting type: who has to act?
Shared hosting
The host patches PHP. Customers usually can't, but they can often select a PHP version. Confirm with the host.
Managed WordPress
The provider owns the runtime. Look for their status page or advisory.
VPS and dedicated
You patch. Install the distro or PPA update, then restart services.
Cloud and PaaS
Depends on the service: managed runtimes are patched by the provider, VMs by you. Check which applies to you.
Docker and Kubernetes
PHP is baked into the image. Patching the host does nothing. Pull a fixed base image, rebuild, redeploy, and confirm old pods are gone. Check sidecars, cron jobs and queue workers too.
Wiz says Cloudflare, Fastly, Google Cloud, AWS, Vercel, Akamai, Microsoft, Automattic and Imperva prepared "out-of-the-box mitigations" or guidance [2]. The report does not say what those mitigations do. Treat them as a useful extra layer, not a replacement for patching.
08 — Impact
What could happen if the vulnerabilities are exploited?
Successful exploitation gives an attacker the same power as the PHP process: the user it runs as, and everything that user can read or write.
Commands run with the privileges of the PHP worker
Leakage of worker memory: Wiz says this can include "passwords, tokens, and API keys" from other users' requests
Theft of .env secrets, wp-config.php and database credentials
Changes to website files and defacement
Planting of web shells, card skimmers or spam scripts
A foothold for attacking the rest of the server or network
What limits the damage: a dedicated, unprivileged PHP user per site, separate FPM pools, container isolation, read-only code directories, database accounts with minimal rights, and egress filtering. None of these prevents exploitation, but each one limits what an attacker can do afterwards.
Demonstrated is not the same as attacked: Wiz built working exploits in a controlled environment. As of 22 October 2026 no real-world attacks had been reported. The PHP team said it would release early if exploitation appeared in the wild.
09 — Patches
Affected PHP versions and official security patches
Versions below are taken from the official PHP announcement and GitHub advisories [1][3][4].
| PHP branch | Affected versions | Fixed version | Recommended action |
|---|---|---|---|
| 8.5 | < 8.5.12 | 8.5.12 | Update now |
| 8.4 | < 8.4.27 | 8.4.27 | Update now |
| 8.3 | < 8.3.36 | 8.3.36 | Update now |
| 8.2 | < 8.2.35 | 8.2.35 | Update now, and plan to move off 8.2 before its end of life on 31 Dec 2026 |
| 7.4, 8.0, 8.1 | All | No upstream release | Use a vendor backport, or the PHP team's minimal source patches if you build from source. Then upgrade. |
| 5.4 – 7.3 | Affected, according to Wiz | None from PHP | Upgrade to a supported branch, or use a commercial LTS vendor if one covers you |
Backports change the numbers
Debian, Ubuntu, RHEL and similar distributions often patch their own version, e.g. "8.3.x-1ubuntuN", so the version won't read 8.3.36. Check the package changelog for the CVE IDs instead.
CLI and web can differ
A server can have several PHP builds installed. php -v in SSH may not be the build that FPM or Apache runs.
Framework updates don't help
WordPress, Laravel, CodeIgniter and Composer packages don't contain the PHP engine. Updating them is good practice, but it doesn't fix these CVEs.
10 — Verify
How to check whether a website is vulnerable
Your goal is to identify the PHP build that is actually serving traffic. These checks read version information only. Package and service names vary by distribution, so adjust 8.3 to your version.
# 1. CLI version (a hint only, not proof)
php -v
# 2. The PHP-FPM binary, and when its workers last restarted
php-fpm8.3 -v # Debian/Ubuntu naming; RHEL: php-fpm -v
systemctl status php8.3-fpm # "active since" should be after you patched
# 3. Is Apache loading mod_php?
apachectl -M 2>/dev/null | grep -i php
# 4. Did the distro backport the fix? Look for the CVE IDs
apt changelog php8.3-fpm | grep -E "CVE-2026-10961[89]" # Debian/Ubuntu
rpm -q --changelog php-fpm | grep -E "CVE-2026-10961[89]" # RHEL family
# 5. Containers: check the image you deploy, not the host
docker run --rm --entrypoint php your-image:tag -v
kubectl exec deploy/your-app -- php -vHosting panels
In cPanel, open MultiPHP Manager or Select PHP Version. In Plesk, go to Websites & Domains → PHP. These show the branch you selected, but not always whether the host's build includes the fix. Ask the host to confirm.
From the web request itself
WordPress Site Health shows the PHP version and SAPI used by the web server. Elsewhere, use an authenticated admin page that prints PHP_VERSION and PHP_SAPI.
Don't leave a public phpinfo() page online, even briefly. It exposes paths, modules and environment variables, which can include secrets. Don't paste version output containing hostnames or keys into public forums either.
11 — Remediate
How to fix and protect PHP websites
A prioritised checklist for anyone who manages servers:
- 1
Inventory every PHP runtime
Servers, every installed version, FPM pools, containers, CI images, staging and forgotten sites.
- 2
Install the fix
PHP 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35, or your vendor's patched package. Start with internet-facing mod_php hosts.
- 3
Restart the services
Running workers keep the old code in memory. Restart PHP-FPM, Apache, LiteSpeed or FrankenPHP after updating.
- 4
Rebuild and redeploy containers
Pull fixed base images, avoid cached layers, roll every replica, and pin the patched tag.
- 5
Verify production
Re-run the checks in section 10 against the live service, not just one SSH session.
- 6
Fix your pipelines
Update Dockerfiles, CI images, Ansible or Terraform templates, so the next deploy doesn't bring the old version back.
- 7
Review logs for signs of exploitation
Wiz's suggested signals include unusual multipart requests followed by memory-limit errors or repeated HTTP 500s, unexpectedly large or malformed
PHPSESSIDcookies in responses, and unexplained PHP worker churn [2]. - 8
Rotate secrets if you suspect compromise
Database passwords, API keys, app keys, payment gateway credentials and admin sessions.
- 9
Restore or escalate
If you find evidence of compromise, follow your incident-response plan and restore from a known-good backup taken before the intrusion.
- 10
Watch future advisories
Subscribe to php.net news, your distro's security list, and your host's status page.
Can't patch today? Temporary workarounds
The PHP project calls these workarounds incomplete and says updating is the only safe choice [1]. Test them first. Some affect how your application behaves.
CVE-2026-109618
- Set
memory_limit=-1withphp_admin_valuein the FPM pool or Apache config. Pair this with container or cgroup memory limits and a worker-kill policy, so that memory is capped outside PHP. - Lower
post_max_size: 8M with no uploads, 32M with uploads, and keepupload_max_filesizebelow it. - Don't use
RLIMIT_ASorRLIMIT_DATAinstead.
CVE-2026-109619
- Set
session.upload_progress.enabled=0and restart every worker. - On PHP 8.5, also set
fatal_error_backtraces=0and restart. - Remove invalid or deprecated settings applied per request that emit diagnostics.
- Fix fatal errors and execution timeouts that attackers can trigger.
WAF rules and CDN mitigations are useful stop-gaps, but they can be bypassed and don't fix the engine. Patch anyway.
13 — Outlook
AI and the future of cybersecurity
PHP2Shell is a concrete example of what Wiz describes: flaws that were hard to exploit were turned into working attacks much faster with AI help. That cuts both ways.
Benefits
- Faster analysis of large, complex C codebases
- Help spotting subtle lifecycle and memory mistakes
- Faster reproduction and patch validation, which Wiz credits AI with here
- Better triage of what is really exploitable
Limits and risks
- False positives and wrong exploit hypotheses waste time
- Human verification is still essential
- Attackers can use similar tools, so the time from patch to exploit may shrink
- None of this replaces secure coding or fast patching
Note: the Wiz report focuses on what AI made possible. It does not discuss false positives or failed hypotheses, so the "limits" column reflects general industry experience rather than findings from this research. The practical lesson for site owners is simple: assume the gap between a patch and a working exploit is getting shorter.
14 — Timeline
Timeline of discovery and disclosure
-
19 Aug 2026
Wiz Research makes the initial discovery.
-
20–21 Aug 2026
Unauthenticated RCE confirmed in the lab against Drupal (20 Aug) and WordPress (21 Aug).
-
24 Aug 2026
Reported privately to the PHP security team.
-
21 Sep 2026
PHP acknowledges the reports and begins fix development. Distributions and LTS vendors get patches ahead of release.
-
20 Oct 2026
php.net gives advance notice of a critical release: two CVSS 9.2 flaws, scheduled for 21 Oct, 14:00 UTC.
-
21 Oct 2026
PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 released. GitHub advisories and the Wiz PHP2Shell report published.
-
31 Dec 2026 (upcoming)
PHP 8.2 reaches end of life and stops receiving security fixes.
15 — Key takeaways
Key takeaways and security checklist
- Two critical PHP engine bugs (CVSS 9.2) can allow unauthenticated RCE. mod_php is at highest risk.
- It is a runtime problem: app, plugin and framework updates do not fix it.
- AI sped up the research. Humans led it, disclosed it and fixed it.
- PHP is everywhere, but no count of affected sites and no in-the-wild exploitation has been reported.
FAQ
Frequently asked questions
What is the PHP2Shell vulnerability?
PHP2Shell is Wiz Research's name for two critical PHP engine flaws, CVE-2026-109618 and CVE-2026-109619. Both are rated CVSS v4.0 9.2 and can allow unauthenticated remote code execution on unpatched PHP runtimes.
Does updating WordPress, Laravel or CodeIgniter fix it?
No. The flaws are in PHP itself. Update the PHP runtime, or install your vendor's patched package, and restart the services that run it.
Which PHP versions are fixed?
PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, released 21 October 2026. PHP 8.1 and older receive no upstream release. Use a vendor backport or upgrade.
Is it being exploited in the wild?
As of 22 October 2026, neither PHP nor Wiz had reported exploitation in the wild. Working exploits were demonstrated in the lab, so patching should not wait.
Did AI find the vulnerabilities on its own?
No. Wiz credits AI models with major help in discovery, exploit development, detection and patch validation. Human researchers led and disclosed the work, and PHP core developers wrote the fixes.
16 — Sources
References and further reading
- [1] PHP Group, "Critical Remote Code Execution Vulnerabilities" security release, 21 Oct 2026, and advance notice, 20 Oct 2026. php.net/archive/2026.php
- [2] Wiz Research (S. Tzadik, S. Tamari, N. Ohfeld, T. Schwartz), "PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet", 21 Oct 2026. wiz.io/blog/php2shell-php-rce
- [3] php-src security advisory GHSA-w8hw-w9fx-j79w, "RCE via OOM corruption" (CVE-2026-109618), 21 Oct 2026. github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w
- [4] php-src security advisory GHSA-6wmf-4rv5-p3rp, "RCE via stale global state" (CVE-2026-109619), 21 Oct 2026. github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp
- [5] CVE records: CVE-2026-109618 and CVE-2026-109619. NVD entries may lag behind the vendor advisories.
- [6] W3Techs, "Usage statistics of PHP for websites", accessed 22 Oct 2026. w3techs.com/technologies/details/pl-php
- [7] PHP supported versions and end-of-life dates. php.net/supported-versions.php
- [8] National advisories: check your national CERT, for example the Canadian Centre for Cyber Security or CISA. At the time of writing we could not confirm a specific PHP2Shell advisory from these agencies.
Not sure which PHP is running your site?
I can help identify the runtime behind your WordPress, Laravel or CodeIgniter project, plan an upgrade off unsupported PHP, and check your deployment pipeline so the fix sticks.