PHP2Shell: AI-Found PHP RCE Flaws Put Most of the Web at Risk
On 21 October 2026, Wiz Research published details of PHP2Shell, a set of critical vulnerabilities in the core PHP engine. Not in WordPress. Not in a plugin. In PHP itself, the language that Wiz estimates sits behind around 70% of websites. The same day, the PHP project shipped patched releases and told every PHP user to update immediately.
If your organisation is busy building AI assistants, agents and retrieval systems, it would be easy to file this under "web team problem" and move on. That would be a mistake. PHP2Shell is a useful lens on three things that matter for anyone building with AI right now: the old systems your new AI depends on, how quickly attackers can now weaponise a disclosure, and how much damage a compromised host can do once agents are connected to it.
You can read the full research on the Wiz blog. Here is the short version, and what we think it means for you.
The bugs are memory safety flaws in how PHP handles fatal errors during a request, particularly out of memory errors. When a request dies at the wrong moment, PHP can leave internal state pointing at memory that has already been freed. The next request handled by the same worker can then pick up that stale state. Depending on the path, an attacker can read chunks of the worker's memory or corrupt it badly enough to run their own code.
The issues are grouped under two CVEs, both rated CVSS v4.0 9.2 according to the PHP project:
PHPSESSID cookie, even if the application never starts a session.A few details stand out. Exploitation is unauthenticated. It happens below the application, so even a "Hello World" page on an affected PHP version can be vulnerable, and application logs may show very little. Wiz says every PHP release going back to 5.4 is affected by at least one of the issues, and it demonstrated pre-authentication remote code execution against the latest WordPress, Drupal and Joomla container images. The memory disclosure alone can expose passwords, tokens, API keys and certificates belonging to other requests.
The PHP project says the risk covers all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed, and it considers mod_php the highest risk.
Wiz credits the PHP team, Calif and OpenAI for discovery, coordination and patch verification, and a long list of cloud, CDN and hosting providers for preparing mitigations ahead of disclosure.
The most important line in the Wiz post is not about PHP. It is about effort. The vulnerable code had been sitting there for more than a decade. Turning it into a reliable exploit meant chaining several bugs and adapting to each target's memory layout, which is slow, specialist work. Wiz says frontier AI models made that practical, and that a single researcher did in about a week what would previously have taken a world class team months.
Wiz used AI to find and fix these bugs, which is good news for defenders. But the same capability is available to attackers. The practical consequence is simple: the gap between "a patch is released" and "working exploits are circulating" is getting shorter. Complexity used to buy you time. It buys you a lot less now.
If your patching cadence for internet facing systems is still measured in weeks, that is the first assumption to revisit.
Very few organisations build AI on a clean slate. The customer service agent reads from a CRM that has a PHP admin portal. The RAG pipeline indexes content from a WordPress intranet or a Drupal knowledge base. The internal tool that calls the model is a ten year old PHP app someone added an "Ask AI" button to. These are exactly the systems PHP2Shell targets, and they are often the least loved part of the estate.
The memory disclosure in PHP2Shell can leak API keys and tokens. On a server that talks to an AI platform, that may include your model provider keys, vector database credentials and service accounts for the tools your agents use. An attacker who lifts those does not just deface a website. They can run up your inference bill, read your embeddings, or impersonate your agent.
An agent with tool access is effectively a set of pre-authorised actions. If an attacker gets code execution on a host that the agent trusts, they can tamper with the data the agent retrieves, poison a knowledge source, or call the same downstream APIs the agent uses. If the agent also trusts the content it reads from that host, the compromise can travel further through prompt injection. The more tools you connect, the more a single compromised web server is worth.
Most organisations we talk to can list their AI use cases. Far fewer can list every system those use cases touch, with versions. When a bug like this lands, the first question is "where do we run PHP?", and the honest answer is often "we are not sure".
These steps come from the Wiz research and the PHP project's security advisory. Read both before acting.
session.upload_progress.enabled in server level configuration and restarting every worker, setting fatal_error_backtraces=0 on PHP 8.5, lowering post_max_size, and enforcing request size and multipart limits at the web server or proxy. These reduce exposure to known paths. They do not make you safe.PHPSESSID cookies, and unexplained PHP worker churn.Once the immediate fire is out, use it as a prompt to check your wider posture:
Most of the AI work we do is less about models and more about everything around them. PHP2Shell is a good example of why. The interesting part of your AI program is the model. The risky part is often a server nobody has looked at in years.
At TruFyre we help organisations in Australia and beyond navigate that:
If this week has you asking where PHP runs in your estate and what your agents can reach from there, we are happy to help you work it through. Get in touch with our team.
Source: PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet, Wiz Research, 21 October 2026. Patch and mitigation details from the PHP project's 21 October 2026 security advisory.
