Is PHP2Shell being exploited? Attempts vs compromise

PHP2Shell attempts are documented, a confirmed compromise is not. AWS honeypots logged an attempt on 17 October, four days before disclosure, and watchTowr and Cloudflare report attack traffic since, while the Canadian Cyber Centre had identified none at its 23 October update. No primary source we found names a hacked site. The action is the same either way: run a patched PHP, restart the workers, and check your logs from 17 October.

What counts as "exploited" here?

Three different things get called exploitation in headlines. They need different words.

"Exploited in the wild" is a fair label for the second row if you say what it rests on. It is a stretch for the third. We use "attempts" for attempts and keep "compromised" for a site where someone has evidence.

What do the primary sources actually say?

Each line is a source speaking about its own data. AWS, watchTowr, Cloudflare and Patchstack describe their own telemetry, so treat those as vendor-claimed. The government bodies publish assessments and advisories, not observations of their own.

• AWS (21 October): its MadPot honeypot telemetry dates activity to 17 October, from an IP address associated with a commercial anonymization network. AWS says it remains unclear how the actor got exploit information before disclosure, and that it is unclear whether any attempt would have succeeded on a real system. It says PHP2Shell is now seeing broad exploitation attempts in the wild after public proof-of-concept exploits appeared within hours of disclosure.
• watchTowr (updated 22 October): its Attacker Eye honeypot network observed exploitation of both CVEs in the wild (vendor-claimed). The page names no victim.
• Cloudflare (21 October, updated 23 October): it observed attack traffic targeting its customers and says attackers were mutating the attack to try to bypass its protections. It says customers should patch their PHP even with WAF protection.
• Patchstack: its timeline records hosting partners reporting multiple active exploitation incidents, then a later entry saying its own telemetry showed only probing attacks with no hard evidence of breaches yet.
• CERT-EU (v1.2, 23 October): initial proofs of concept have begun to circulate, which raises the likelihood that attackers are already exploiting the vulnerabilities. That is an assessment, not an observation.
• The PHP project: its notice and advisories describe the bugs and the fixes. They contain no statement about attacks in the wild.
• Canadian Cyber Centre (AL26-026, updated 23 October): says it was not identifying active exploitation at that time and that this can change quickly. It notes open-source reporting of a public proof of concept. That differs from the vendor telemetry above, which is why this page separates attempts from confirmed compromise.
• UK NCSC and Dutch NCSC (21 October): both describe the flaws as exploitable and neither claims that exploitation is happening.

Why does "no confirmed victim" not mean "nothing happened"?

AWS advises detections that do not rely on a signature for a specific CVE, because first exploitation often precedes signatures. A known request pattern is not a complete test.

So read "no named victim" as a statement about what has been published at one date. It says nothing about your server.

Who is affected?

Any site served by PHP. The PHP project says all PHP installations serving web requests are at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed, and considers the risk highest for mod_php. WordPress, WooCommerce, Magento, Shopware, Drupal, Joomla and Laravel run on PHP. Cloudflare says website code or plugin updates alone do not fix these flaws and administrators need to update the PHP runtime. The full picture is on the PHP2Shell page, the fixes are in the other PHP2Shell guides, and whether a WAF changes any of this has its own answer.

PHP 8.1 and older no longer receive updates from the PHP project. The PHP security team provided minimal source backports for 7.4, 8.0 and 8.1, and some distributions and LTS vendors provide backported fixes. Treat an old branch as exposed until your vendor names the fix.

Why does a version number not prove a fix?

A backported fix can keep its old version number, because some distributions and LTS vendors provide backports. So "we are on 8.4" proves nothing in either direction. The table of fixed builds is on the fixed versions page, and the limits of an outside check are on what a checker can confirm.

How do I fix it?

What do I do if a host manages PHP for me?

If you are on shared hosting, what else to ask your provider is on its own page. Send support this and keep the reply:

For [your domain], is the PHP runtime that serves web requests patched for CVE-2026-109618 and CVE-2026-109619? Please give the fixed package, build or backport identifier, confirm that all PHP-FPM, CGI or Apache workers serving it have been restarted or replaced, and say whether I need to redeploy or change a setting.

• Get the build or package identifier in writing
• Get the time the workers were restarted or replaced
• Ask whether the host kept logs from 17 October that you can see

What do I do if I manage the server myself?

• Install the fixed PHP from your distribution or vendor, then restart PHP-FPM or Apache
• Rebuild and redeploy every container image that bundles PHP
• Check each virtual host and each PHP version separately
• Apply the PHP project's temporary measures only as a stopgap. The notice says only an update is a complete solution and the measures do not make an installation safe

Am I affected?

What should I look for if I was exposed since 17 October?

AWS recommends starting the review on 17 October, not on the disclosure date. It points to web server logs, POST requests in form uploads that carry the PHP session upload progress field name, unexpected process execution and unexpected file changes. That field name alone does not prove an attack, because legitimate applications can use the feature.

AWS says upgrading is the only complete remediation for both CVEs. Patching does not tell you whether anything ran before it, so the log review above still applies. If something looks wrong, how to tell whether a site was hit is covered separately.

What is the third PHP notice?

On 23 October the PHP project published an informational advisory naming CVE-2026-115560 in session upload progress, with a full advisory promised for the next release. PHP says it needs an unusual combination of configuration and application code, and suggests setting session.upload_progress.enabled=0 until the next bugfix release. For CVE-2026-109619, PHP's advisory lists the same setting as a mitigation for the session lifecycle path only. It says the setting does not mitigate the other lifecycle paths and that updating is the only reliable mitigation. The 23 October notice makes no statement about attacks. It is a different issue from the two PHP2Shell CVEs.

What does the free scan show here?

The free scan identifies the technologies your site serves, looks each version up in public vulnerability records, and says whether a version is affected. It is a lookup. It cannot see a vendor backport, which runtime serves a virtual host, or whether workers restarted, and it cannot tell you whether anyone attempted anything on your server. The wider October context is on the security meltdown tracker.