PHP2Shell: Client Data, Breach Scope and Reporting

‍Status as of October 23, 2026: fixes are available, exploitation attempts are widespread, and no source cited here confirms a successful compromise. We will update this post as that changes.

TL;DR: PHP2Shell (CVE-2026-109618 and CVE-2026-109619) lets an unauthenticated attacker run code on a PHP web server or read data from its memory. Fixes shipped October 21; exploitation attempts began October 17. Patching closes the hole but does not show whether anyone got in first. If a server was exploited, your breach scope is everything it touches: the data people entered, the databases behind it, and the systems its keys unlock. Preserve evidence, patch, rotate every secret the server held, and determine whether you can prove you were not hit.

PHP released fixes on October 21, and its advisory calls updating “the only safe choice.” Amazon Threat Intelligence has since reported an exploitation attempt four days before that.

Patching is the urgent part, and most coverage stops there. This post covers what comes after: what exploitation looks like so far, how to evaluate exposure if a server was hit, why this flaw makes that hard to prove, what reporting responsibilities may follow, and what to do next. Clients, insurers, and possibly regulators will ask what happened between the first attempt and your patch, and PHP runs many of the websites, portals, stores, and tools that SMBs, midmarket organizations, and MSPs rely on.

What PHP2Shell is and which PHP versions fix it

PHP2Shell is two flaws in the PHP engine itself, both rated CVSS v4.0 9.2. CVE-2026-109618 is remote code execution triggered through out-of-memory handling. CVE-2026-109619 involves request state that survives after its memory is freed, and PHP lists its impact as memory disclosure and remote code execution with the web worker’s privileges. Because the flaws sit beneath the application, a well-built site on a vulnerable PHP build is still exposed. PHP says the risk covers all PHP installations serving web requests and is highest for Apache with mod_php, where a demonstrated exploit fires before any application code runs.

A version number alone will not confirm a fix, because distributions backport patches into packages that keep older numbers; Ubuntu’s fixed package for 22.04 still reads as PHP 8.1. Confirm the fix with each host or vendor in writing, treat PHP’s configuration workarounds as risk reduction rather than a fix, and restart every PHP worker after updating.

What exploitation looks like so far

Amazon’s MadPot honeypots recorded the first attempt on October 17, and attempts from multiple actors followed once proof-of-concept code appeared. A SecurityWeek roundup from October 23 adds detail: Sophos and others have tied attempts to a Mirai-style botnet, though the attempt Sophos analyzed was blocked, and SOCRadar and Hunt.io found an attacker server that probed more than 100 sites without a single success.

Reliable exploitation is proving harder than first feared. Sansec now says public exploits fail against default settings. That may not last: VulnCheck has built an exploit that defeats a key memory protection on production-style servers and expects attackers to catch up. Meanwhile, Qualys data cited by SecurityWeek shows roughly 71% of the PHP instances it observed run end-of-life versions that largely will never be patched.

No confirmed compromise is not the same as an all-clear. Attacks began before most organizations knew to patch, a server recruited into a botnet can be turned against other organizations, and an unpatchable server stays exposed for as long as it runs. Which raises the harder question: if one of your servers was exploited, what would that mean?

If a server was exploited, your breach scope is everything it touches

It is tempting to treat a compromised web server as one incident on one machine. In practice, it is a hub: it receives what people type into it, stores data, holds credentials to other business systems, and often shares a network with internal resources. Evaluating exposure means looking in four directions, each answering a different business question.

Inbound: data people submit, even data you never store

The memory disclosure flaw puts in scope whatever passed through the server while it was vulnerable: form entries, typed passwords, payment details, session tokens. Not storing card numbers does not take them out of scope. In business terms, this defines who may need to be notified: everyone who used the site during the window, not just the records in your database.

At rest: databases, uploads, and config files

Code execution runs with the web worker’s privileges, so whatever that account can read, an attacker can read: the site database, uploaded files, stray backups, and config files holding connection strings and API keys. This determines which data sets are in scope, and it is where regulated health or financial data is most likely to sit.

Outbound: the keys to other systems

Those keys reach the CRM, email platform, payment gateway, cloud storage, and SSO, and an attacker holding them no longer needs the web server. This is how a website incident quietly becomes a multi-system, multi-vendor incident, with data held by third parties and the contractual obligations that come with it.

Internal: the network behind the server

A domain-joined server on a flat network, or one whose service account passwords are reused elsewhere, is an entry point for lateral movement and ransomware. This decides whether the incident stays a website problem or becomes a company-wide one. For MSPs, every managed client site is a hub into that client. Start with servers nobody clearly owns, such as the site an agency built years ago, hosted elsewhere, and connected to the CRM by someone who has since left.

What you can and cannot prove after a memory disclosure flaw

Most breach investigations work backward from evidence, such as files accessed, queries run, and data sent out, to draw a boundary around what was taken. That boundary is what lets an organization say a specific set of records was affected and the rest were not.

A memory disclosure flaw breaks that model. The attacker reads whatever the server is handling at that moment, including other users’ requests, credentials, and tokens. Nothing is copied from disk, no query runs, and the application may log nothing. A log can show that a suspicious request arrived, but not what was in memory when it did. Amazon’s post lists indicators worth searching for, including POST requests containing PHP_SESSION_UPLOAD_PROGRESS, unexpected process execution, and file changes.

For the business, that means three things:  

1. The affected systems and scope may be hard to define or determine, so you may have to plan for the worst case.
2. Notification and response costs scale with that population.
3. And regulators, insurers, and clients are unlikely to accept the absence of evidence as proof, especially for a flaw known to leave little behind.  

Stolen session tokens add another layer of consequence and complexity, since an attacker posing as a logged-in admin or customer can look normal in logs. If you cannot show a server was not exploited during the window, plan and scope as though it was.

Beyond remediation: business risk and how long you have to report

Once the server is patched and credentials are rotated, the incident may be technically closed. From a business standpoint, the most consequential work often starts there. The questions shift to what the organization owes, and to whom, and those decisions belong to leadership, counsel, and the insurer as much as to IT.

The exposure window runs from when a server was vulnerable and reachable until patching and credential rotation are both complete, and given Amazon’s report, it should not start at the patch date. Many notification laws turn on acquisition of data; Washington, for example, defines a breach as unauthorized acquisition that compromises personal information. With a memory read that leaves no record and signs of exploitation present, counsel may conclude acquisition is a reasonable assumption. Stolen integration keys can also trigger contractual notice duties between you, your clients, and their vendors.

Obligations that may apply, which generally start at discovery or determination:

This is not legal advice; confirm your obligations with legal counsel first. It is important to treat reporting as a business risk decision as not notifying carries risk if evidence surfaces later, and broad notification carries its own costs. Either way, a documented rationale grounded in preserved evidence is what lets you defend the decision. Our ransomware response playbook covers running these clocks in parallel, and our HIPAA compliance checklist for MSPs goes deeper on healthcare deadlines.

What organizations should do next

These steps put an organization in a position to answer what clients, insurers, and regulators will ask, whether or not there is any sign of compromise.

Preserve evidence before you patch and rebuild

Restrict access to affected servers, then capture web server and PHP error logs, a server snapshot, active sessions, and the credentials and integrations configured on each, stored outside the affected system. Rebuilding first can destroy the only evidence of whether data was taken. Then apply the fixed build, confirm it against the changelog, and restart every PHP worker. If a system cannot be updated right away, the UK NCSC advises considering taking it offline. Timestamp every step for historical review, evidence gathering, and auditability.

Tighten internal controls

Rotate secrets in dependency order, payment and identity first, then CRM and email, then everything else, and invalidate all active sessions. Hunt for rogue admins, new files in web roots, and unexpected outbound connections, and rebuild if you find persistence. Longer term, isolate web servers from internal networks, limit database accounts and API keys to the job they do, end password reuse, restrict outbound connections, and put admin panels behind zero trust network access.

Determine the scope of a potential breach and where to reassert control

Work through the four directions for each affected server. Identify who used the site during the window, which becomes the potential notification population. List the data sets the web worker could read and flag regulated ones. Inventory every key the server held, confirm rotation, and review the audit logs of the systems those keys reach, asking vendors for that review in writing. Check reachable internal systems for lateral movement. The result is a scope record per server covering what was exposed, what evidence supports or rules out compromise, where control has been reasserted, and what remains open. Counsel will rely on it, and clients and insurers will ask for it.

Questions every organization should ask

Exposure: What do we run or rely on that uses PHP, who patches it, and is the fix confirmed in writing? What does each server connect to, and whose data passed through it during the window?

Containment: Are these servers isolated with least-privilege access? When were secrets rotated and sessions invalidated? Did we preserve evidence before patching?

Reporting: Can we show we were not exploited, and if not, is counsel engaged? Which regulatory, contractual, and insurance clocks apply, and has the insurer been notified? See how cyber insurance is forcing MSPs to get serious about GRC.

For MSPs: Which client hubs sit on infrastructure we manage, are any of our own tools built on PHP, and can we give each client an evidence package with patch date, rotation date, and log review findings?

Why PHP2Shell evidence has to exist before the patch and how Todyl Supports Your Investigation and Proof

Most of this is work you can do this week. Two pieces cannot be done after the fact: logs from before October 21 either exist somewhere searchable or they do not, and someone has to turn that evidence into answers quickly, across every affected client, while patching is still underway.

Todyl’s AI-Powered Managed SIEM retains log data from endpoints, users, networks, cloud services, and applications in a multi-tenant console with Janus SIEM Search, and Todyl MXDR puts a 24/7 analyst team on investigation and response. Together, they let you give a client, their insurer, and their lawyer a record of what happened before and after the patch.

Here is how Todyl capabilities map to the three outcomes this post covers: understanding exposure, containing it, and supporting reporting decisions.

Talk to your Todyl partner manager about confirming log coverage before the next disclosure.

Frequently asked questions about PHP2Shell

Is PHP2Shell being exploited?

Attempts began October 17 and have since been tied to a Mirai-style botnet, but as of October 23 no source cited here confirms a successful breach, and CISA has not added the flaws to its Known Exploited Vulnerabilities catalog.

Do we have to notify if we patched quickly?

It depends on whether the server was vulnerable and reachable before you patched, what data it handled, and what your evidence shows. Bring counsel in early and have your patch date, rotation date, and log review findings ready. That review depends on logs retained before the patch, which is what a SIEM provides.