On October 21, 2026, PHP shipped emergency fixes for CVE-2026-109618 and CVE-2026-109619, two unauthenticated remote code execution flaws that researchers nicknamed PHP2Shell. If any piece of your AI stack runs on PHP, the server holding your API keys and service identities could be taken over with a crafted web request. Patch to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, confirm the version the web server is really running, and then look hard at what that server’s identity can reach.
The gateway nobody filed under AI
Picture a firm that wanted Claude or Azure OpenAI wired into its document workflow quickly. Someone builds a small internal gateway in PHP, because the team knows PHP or because it bolts onto an existing intranet. The gateway stores an API key. It runs under an Entra app registration with Microsoft Graph permissions so it can pull SharePoint documents into prompts.
The firm also put prompt filtering and DLP in front of the AI traffic.
None of that helps here. PHP2Shell doesn’t attack the prompt or the model. It attacks the PHP interpreter, and on the most exposed configuration it does it before your application code runs at all. An attacker with code execution on that box doesn’t need to fool the model. They open the config file, copy the client secret, and call Graph as your app.
What PHP disclosed
Details leaked on October 20, ahead of a coordinated disclosure, and the PHP security team pulled its release forward and published its security advisory on October 21. Both flaws carry a CVSS v4.0 score of 9.2.
CVE-2026-109618 is remote code execution through out-of-memory corruption. Malformed multipart requests can drive PHP to run out of memory while request data is only partly set up, and the cleanup routine then treats that bad data as valid. Under Apache mod_php this happens during request startup, before any application script loads. PHP validated full code execution against mod_php with default memory and input limits.
CVE-2026-109619 is remote code execution through stale global state. State owned by one request survives into the next request handled by the same worker, after its memory has been freed. PHP confirmed code execution against both mod_php and PHP-FPM.
PHP lists every installation serving web requests as at risk, including PHP-FPM, mod_php, php-cgi, FrankenPHP and LiteSpeed, and rates mod_php highest. Versions 8.1 and older no longer get upstream releases. PHP did publish minimal source backports for 7.4, 8.0 and 8.1, and Linux distributions received the patches early, so your vendor may already have a package.
Exploitation status was still moving as of October 21. watchTowr reported exploitation attempts against both CVEs in its honeypot network. Huntress said it had not seen exploitation on partner systems as of that afternoon, and neither CVE was in CISA’s Known Exploited Vulnerabilities catalog. Attempts aren’t breaches. They do mean the patch window is short.
Is your vibe-coded app exposed?
Only if PHP is answering its requests. A Next.js front end, a Node API or a Python agent service isn’t touched by these CVEs.
The exposure tends to hide in places nobody thinks of as AI infrastructure. A WordPress intranet with an AI plugin that stores an OpenAI or Anthropic key. A PHP middleware layer that brokers between a document system and a model. A webhook receiver that takes calls from Power Automate or Make. A vendor appliance or SaaS product that runs PHP under the hood, which you can’t patch yourself and need to ask about today.
The useful question isn’t how the app was built. It’s which runtime sits on the network.
What an attacker gets is whatever you gave the server
Code runs as the web worker account. Everything that account can read is in play: environment files, wp-config.php, cached OAuth tokens, client secrets, connection strings.
From there the damage tracks the permissions. An app registration with tenant-wide SharePoint read can read every site. One with write access, or rights to edit agent instructions or flows, lets an attacker change what your AI does and come back later through a door that looks legitimate. It’s the blast radius question we keep asking about AI agents, and the same standing access problem that AI connectors create.
Running a vulnerable version isn’t evidence of compromise. An unpatched, internet-facing host means investigate, not announce.
A 15-minute triage for executives
Nobody needs to read the advisories to run this meeting. They need answers to seven questions.
- Which internet-facing systems run PHP? Include the public website, intranet, AI gateways and vendor appliances.
- What PHP version is the web process running on each, checked from that process or container rather than a package list?
- Who owns the patch for each one, and is it done today?
- Which of those servers hold an API key, client secret or token for Microsoft 365, Claude, Copilot or Azure OpenAI?
- What permissions do those identities hold? Flag anything tenant-wide or with write access.
- Is anything on PHP 8.1 or older, and does it have a vendor backport, an upgrade date or a plan to come off the internet?
- Who is reviewing logs from October 20 forward?
What IT should do now
Patch and prove it. Install the fixed release or your distribution’s backported package. Backported builds often keep an older version string, so check the vendor advisory rather than the number alone. Restart PHP-FPM or Apache so the new interpreter loads, then confirm the version from inside the running web container. A latest image tag doesn’t mean the image was rebuilt; check the digest.
Reduce exposure where you can’t patch yet. PHP lists interim settings, including an administratively enforced memory_limit=-1, a low post_max_size, and session.upload_progress.enabled=0. PHP says plainly these don’t make an installation safe. If a host can’t be patched, take it off the internet.
Don’t close the ticket on a WAF rule. Blocking multipart uploads on paths that never take files can cut noise at the edge. The flaw lives in the interpreter, so Cloudflare or any WAF is a speed bump, not the fix.
Hunt. Look for PHP worker crashes, web server processes launching shells or download tools, new PHP files in web roots and upload folders, and outbound connections that start after inbound POST requests. A clean scan is a data point, not a verdict.
Fix the identities. Give each AI integration its own app registration, scoped to the sites and actions it needs. If an exposed host held secrets and you can’t rule out access, rotate them and review the sign-in history for that app.
Where this leaves your firm
The fix for PHP2Shell is a patch. The lesson is about identity. Plenty of AI integrations went live fast, on whatever stack was handy, with permissions sized for convenience. The weakest runtime in that chain now sets the blast radius.
Patch today. Then spend an hour on the app registrations behind your AI tools.
If you want a second set of eyes on which AI connectors and integrations can reach which data, that’s part of what the AI Readiness Snapshot reviews.
Quick answers
What is PHP2Shell?
The nickname for CVE-2026-109618 and CVE-2026-109619, two critical PHP flaws that allow unauthenticated remote code execution. PHP fixed them on October 21, 2026.
Which PHP versions fix PHP2Shell?
PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Versions 8.1 and older need a vendor backport or an upgrade.
Are Node.js or Python AI apps affected?
Not by these CVEs. Only components running a vulnerable PHP runtime are in scope, including plugins, middleware and vendor products built on PHP.
Does a WAF or Cloudflare stop PHP2Shell?
It can block some attack traffic, but the flaw is in the PHP interpreter. Updating PHP is the only complete fix.
