Cybersecurity

PHP2Shell: What watchTowr Reports About Active Attacks

watchTowr dates its PHP2Shell attack observations to 21 October. Its evolving FAQ shows how patch advice changed during disclosure.

Listen to the audio analysis

Create your own

Written for builders and creators.

watchTowr reports observing PHP2Shell exploitation in its Attacker Eye honeypot network from October twenty-first, twenty twenty-six. PHP released its fixes on that same date.

Editor's note

Why this matters now

watchTowr says it observed exploitation of PHP2Shell, the 2 critical PHP flaws, in its Attacker Eye honeypot network from 21 October. That puts reported attacks on the same day PHP released fixes.

Its FAQ also shows how quickly advice fell behind events. An updated section lists patched versions, while the answer to “How do I fix” still says no confirmed patch exists. PHP’s 21 October release notice settles that contradiction. Fixes are available.

The source

What it says

Distilled from the original. The notes above and below are the editor's own.

What watchTowr Observed

The company attributes its attack observations to its own honeypot network. Its FAQ covers CVE-2026-109618 and CVE-2026-109619, the flaws grouped under the PHP2Shell name. It provides no count of compromised production sites or way to establish whether a reader’s own server was attacked.

The underlying vulnerabilities can allow unauthenticated code execution with the web worker’s privileges. PHP has demonstrated attacks against Apache mod_php and PHP-FPM. In the confirmed PHP-FPM session attack, the application has to leave session state behind after a fatal error, and a later upload request must reach the same worker.

Fixes Are Available Despite the FAQ’s Older Advice

The FAQ’s update section names 8.2.35, 8.3.36, 8.4.27 and 8.5.12 as fixed releases. Its older waiting-for-a-patch instructions describe the period before those releases. The PHP maintainers’ notice confirms their availability.

Older installations have some options too. Distributions and long-term-support vendors may supply backported fixes. PHP also released exceptional minimal source backports for 7.4, 8.0 and 8.1, without resuming regular upstream support for those branches.

Editor's note

What to do with this

For an exposed server, the report leaves a specific question unanswered: did an attack succeed before the update? A deployment record can show when patched PHP went live. Investigating earlier activity requires evidence from the server and its monitoring. Even clean logs have limits, because PHP can encounter the vulnerable behavior before application code runs or before an error is logged.

The original

All posts