PHP2Shell: What CVE-2026-109618 and CVE-2026-109619 Mean for Security Teams
by David Allen, CTO//
On October 21, 2026, the PHP project released emergency security updates for two critical remote code execution vulnerabilities, CVE-2026-109618 and CVE-2026-109619. Researchers call the pair PHP2Shell. Both are rated 9.2 under CVSS v4.0, and both sit in the PHP runtime itself, so the exposure follows PHP wherever it runs.
Remote code execution (RCE) means an attacker can run their own code on an affected server. PHP runs a large share of the web. Content management systems such as WordPress and Drupal depend on it, and so do many online stores, hosting control panels and web interfaces built into commercial products. That reach explains why general news outlets were covering the story within hours of the release.
Two details set this disclosure apart. Researchers used AI to find the flaws, and news of the vulnerabilities leaked before the scheduled fix. Both point to the question security teams are working through right now: how quickly can you find where PHP runs and get the right owner moving toward risk reduction?
How PHP2Shell came to light
Researchers at security firm Calif identified the flaws with help from an OpenAI model during an audit in August, and researchers at Wiz independently found exploit paths, according to TechTarget. OpenAI said the group working on the fix, which included PHP maintainers and security vendors, needed about two months because the change reached deep into the PHP engine.
On October 20, an anonymous online post claimed two critical PHP RCE flaws were about to be announced. The PHP security team responded the same day with an advance notice and moved its release forward to October 21 at 14:00 UTC. Fixed versions shipped on schedule: 8.2.35, 8.3.36, 8.4.27 and 8.5.12.
What the vulnerabilities do
Both flaws involve memory safety in PHP's core engine.
CVE-2026-109618 sits in PHP's error handling for requests that exceed their memory allowance. When PHP aborts such a request, it can leave some of its internal bookkeeping in an inconsistent state, and an attacker can force that condition deliberately.
CVE-2026-109619 involves a state that outlives the request it belongs to. PHP worker processes handle many requests in sequence, and this bug lets a worker hold on to memory that was already released, a classic use-after-free condition.
The PHP security advisory's update guidance covers the common ways PHP serves web traffic: PHP-FPM, php-cgi, Apache's mod_php module, FrankenPHP, and LiteSpeed. The advisory singles out Apache's mod_php on internet-facing servers as the riskiest setup. In that configuration, according to PHP, an attacker without credentials can trigger the flaw before the website's own code ever runs. Technical details are in the GitHub advisories for each CVE:
What we know about exploitation
Reports are still settling. SecurityWeek reported that security vendors observed attack traffic both before and after the patches were published. Some vendors have gone further and reported successful exploitation.
Seeing attack traffic is different from confirming that an attack succeeded, and how exploitable a given server is depends on its configuration. Treat internet-facing PHP as the priority either way, and check official sources for the latest exploitation status.
Why PHP2Shell is challenging to scope
The difficult part of this response is building the list of affected systems. PHP tends to live in corners that no single inventory covers, such as a campaign microsite an agency built three years ago, a base image that dozens of containers inherit, a build server, the admin panel on a hosting account, or a vendor appliance whose software you never see.
Each of those systems can have a different person holding the fix, such as an application team, platform engineering, a hosting provider, or a product vendor. The version string can be misleading too. Some Linux distributions patch PHP without changing the version number it reports, so check your distribution's security notice before marking a server as safe or exposed.
Older branches complicate things further. The PHP project has stopped maintaining 8.1 and earlier, which leaves fixes for those versions to Linux distributions and commercial support vendors. PHP 8.2 joins that list at the end of 2026.
How to identify and remediate PHP2Shell-exposed systems
Organize your response around four questions: what can someone reach, who owns the fix, how will you fix it, and how will you know it worked?
1. What can someone reach?
- Build the list from every source you have: scanner results, cloud and container inventories, hosting accounts and vendor product documentation. Expect gaps, and track the systems you can’t yet confirm.
- Put internet-facing PHP at the top, starting with servers running Apache’s mod_php.
2. Who owns the fix?
- Name an owner for each system and settle who controls its PHP version. For hosted sites and vendor products, ask the provider directly whether they are patching and when.
3. How will you mitigate and remediate?
- For systems you control, move to the fixed release for your PHP branch. The update only takes effect once the web server and PHP worker processes restart, so schedule that step with the patch.
- Where a patch has to wait, use the interim settings in PHP’s advisory and any WAF protections your providers offer. PHP considers these partial measures, so treat them as a bridge to the update.
- For PHP 8.1 and older, choose between upgrading, applying a backported fix from your distribution or vendor, or pulling the system off the internet until one of those happens.
4. How will you know it worked?
- Rescan or check versions after each fix, and keep a record of any system granted an exception.
- Monitor for warning signs of compromise, such as a web server process suddenly launching a command shell or downloading files.
Software a vendor maintains calls for its own coordination. Bring the internal service owner and the vendor into the conversation early so both sides can confirm the exposure, agree on a remediation plan and see it through to completion. The last step matters as much as the first, so confirm the fix worked before calling the system closed.
How Brinqa helps teams scope and close PHP2Shell exposure
The Brinqa Platform is built around the same questions:
- Reach: In the data layer, Brinqa connects to more than 300 security and IT tools and correlates scanner findings, cloud inventories and asset records in the CyberRisk Graph™. Teams can see where affected PHP versions appear, which of those systems face the internet and where records disagree.
- Ownership: In the AI layer, Brinqa's AI Attribution Agent helps identify the responsible owner for each affected asset, and business context helps rank which owners need to move first.
- Verification: In the orchestration layer, SmartFlows turns each finding into a work item for the team that owns it and keeps it open until data from your connected tools shows the exposure has been addressed.
Brinqa works with the detection data your existing tools provide, so as scanners publish detections for these CVEs, those findings land in the same view.
PHP2Shell (CVE-2026-109618 and CVE-2026-109619) was publicly announced on October 21, with fixes in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. The first question most teams ask is where PHP actually runs in their environment. This sample Brinqa dashboard answers it with data teams already have, including assets still carrying older PHP CVEs, findings scanners have already confirmed, and who owns each fix. Dashboard shown with sample data.
The takeaway
PHP2Shell shows what AI-assisted vulnerability research looks like at internet scale. Discovery is getting faster, and the response still rests on the same fundamentals, which include having an accurate picture of where software runs, clear ownership, and confirmation that fixes worked.
Responding to PHP2Shell while the facts keep shifting is hard work, and every step forward counts. Contact Brinqa to talk through your next one, whether that’s scoping exposure, confirming owners, or verifying fixes, our team is here to help.
