In short: The confirmed PHP2Shell facts include the two CVE numbers, the CVSS v4.0 9.2 rating, the fixed PHP versions and the interim measures from php.net. The BSI's (German Federal Office for Information Security) warning level orange is also confirmed. Not confirmed are a CVSS 10 rating, confirmed successful attacks on a broad scale and a list of indicators. Anyone who keeps these three levels apart makes better decisions.
Why a fact check on PHP2Shell is needed
Few security vulnerabilities in recent years have generated so many headlines so quickly. Even before the PHP team released the updates on 21 October 2026, forum posts, screenshots and alleged details were reportedly circulating. Official warnings, vendor blogs, counts of exposed servers and a flood of tips followed.
For operators this means that not every figure and not every piece of advice is of the same quality. Some of it comes from primary sources, some from reliable reporting, some from speculation. This article sorts out what you can use as established for your decisions. The basics of the vulnerability itself are explained on the page What is PHP2Shell?.
Which sources carry which weight
A simple ranking helps when reading any report:
- php.net: The PHP project is the primary source for CVE numbers, ratings, affected operating modes, fixed versions and interim measures. How the project handles security announcements in general is described in our article on the PHP security process.
- Authorities: The BSI provides the assessment of the situation in Germany and recommendations for action; CERT-EU and CERT-Bund (the German government CERT) add to it.
- Distributions and vendors: Debian, Ubuntu, Red Hat, hosting providers and platform services speak with authority only about their own packages and services.
- Security companies: Cloudflare, Unit 42, CybelAngel and others report from their own measurements. Valuable, but each with its own method.
- Media and social networks: Good for speed, weak on detail. Statements from there need confirmation from higher up this list.
Confirmed, reported, unconfirmed: the overview
The following table classifies the most common statements. "Confirmed" means: primary source or authority. "Reported" means: from media or vendor statements, not independently confirmed.
| Statement | Classification | Basis |
|---|---|---|
| Two vulnerabilities, CVE-2026-109618 and CVE-2026-109619 | confirmed | php.net |
| Rated CVSS v4.0 9.2, critical | confirmed | php.net |
| Rated CVSS 10 | untenable | reportedly from a forum post before the announcement |
| Fixed in 8.5.12, 8.4.27, 8.3.36, 8.2.35 | confirmed | php.net |
| mod_php at highest risk, exploit shown before application code | confirmed | php.net |
| Almost all versions down to PHP 5.4 affected | reported | trade press |
| First attack attempt on 17 October | reported | media reports citing Amazon |
| More than 22.6 million exposed instances | reported | Unit 42, according to TechTarget |
| Successful attacks on a broad scale | unconfirmed | initially not known according to the BSI |
| Confirmed indicators of compromise | do not exist | none published |
| Interim measures protect completely | false | php.net expressly calls them incomplete |
It is striking how early figures take on a life of their own. The 10.0 rating from the forum post still turned up in articles days later, even though the PHP team had long since published 9.2.
Where the uncertainty really lies
The biggest open question is not technical but one of timing: what happened between the first reported attack attempt and the patch on individual servers? There is no general answer to that. Cloudflare and Patchstack reported attack attempts, and watchTowr says it reproduced CVE-2026-109618. Huntress, in turn, saw no attacks in partner environments at the time of its report.
These statements do not contradict each other. They describe different slices: a large proxy service, a plugin security company, a research team and a company with its own customer base. No overall picture emerges from them.
It is similar with the question of which versions are affected. For 8.2 to 8.5 the situation is clear. For older branches there are minimal source backports for 7.4, 8.0 and 8.1, but no official releases. According to the trade press, almost everything before that is affected. For your planning this makes hardly any difference: a server with PHP 8.1 or older without a confirmed backport should be treated as at risk.
The absence of evidence of attacks is not evidence of safety. Because there are no confirmed indicators, an attack on an individual server can only be assessed by examining behaviour, not by checking against a list.
What to take from this for your servers
A few clear steps follow from the confirmed facts. From the unconfirmed ones follows, above all, caution.
- Check the patch level: fixed version or a backport confirmed by the vendor. The displayed version number alone is not enough.
- Restart all PHP processes: New files only take effect once no old processes are running any more.
- Preserve logs from 20 October onward: The trade press advises this so that a later examination remains possible.
- Check for traces: New PHP files in upload folders, unknown cron jobs, web server processes with a shell. The page Have I already been compromised? guides you through the check.
- Cross-check advice: Implement tips from forums and social networks only if they can be traced back to php.net or an authority. Which recommendations are currently doing harm is collected in the article Dangerous bad advice on PHP2Shell.
The same separation helps with internal communication. Anyone who presents "confirmed", "reported" and "open" separately to management avoids both alarmism and false all-clears.
How does PHP SOS help?
- Situation for your systems: We apply the confirmed facts to your servers and document separately what was measured, what was reported and what is still open.
- Patch and proof: We check the package status and restart of every PHP service and record it in writing.
- Trace check: We preserve logs from 20 October onward and look for unusual behaviour until the incident is closed and documented.
- Ongoing assessment: We assess new announcements for you before they turn into measures.
The process is described on the page PHP2Shell immediate help.
Conclusion
PHP2Shell is serious, and that is well documented. That is precisely why a sober look is worthwhile: the primary sources are enough for all the important decisions. What circulates beyond them is often faster than it is accurate. Patching, restarting, preserving logs and checking for traces remains the answer, regardless of which figure is currently doing the rounds.
Frequently asked questions
Is PHP2Shell rated CVSS 10?
No. According to reports, the figure 10 comes from a forum post that circulated before the official announcement. The PHP team rates both vulnerabilities at CVSS v4.0 9.2. That is still the critical category.
Is there a list of indicators for PHP2Shell attacks?
Not so far. There are no published, confirmed indicators of compromise. Anyone who wants to check whether a server was affected has to look for unusual behaviour, such as web server processes that start a shell or new PHP files in upload folders.
Which source is the most reliable for PHP2Shell?
For the technical facts, the announcements on php.net; for the situation assessment in Germany, the BSI. Media reports and vendor blogs complete the picture, but they should be labelled as reports and read against the primary source.
Are all PHP versions from PHP 5 onward really affected?
The situation is confirmed for the 8.2 to 8.5 branches, for which updates exist. According to the trade press, almost all versions down to PHP 5.4 are affected; CERT-EU reportedly considered versions from PHP 5 onward possible. There are no official updates for older versions, so you should treat them as at risk in any case.