Before the signatures: what a SOC saw of PHP2Shell

Interview with Miguel Mur, SOC Manager at 4Elitech.

PHP2Shell, two critical flaws in the PHP runtime, was patched on 21 October 2026. Exploitation attempts had been seen in honeypots four days earlier.
Most of the advice since has concerned patching: finding every PHP runtime, ranking it, fixing it. Less has been said about the period before a fix exists, when nobody has a detection rule and attackers are still working out who is vulnerable.

Miguel Mur, SOC Manager at 4Elitech, an Allurity company, explains what a security operations centre watching many clients could see in those first days, why patterns across clients mattered more than signatures, and what organisations should make sure their SOC can see before the next one.

1. When PHP2Shell became public, what did your SOC do in the first 24–48 hours?

Even before notifying anyone, we were already searching our vulnerability management platforms to see which clients were running PHP and which versions. On 21 October, after PHP’s official bulletin, we notified our clients.
In parallel, we scanned the clients where we have vulnerability management visibility, for example, critical infrastructure. In a multi-client SOC, not every client has the same scope, so we started where we could see the most and where the impact would be greatest.

We also reviewed the previous 10 days of logs as a first pass, to look for trends rather than isolated events. That window had one advantage: it covered the date when the first attempts were publicly observed, 17 October, four days before the patch. If someone had started probing before the announcement, we wanted to see it.

2. Before specific signatures were available, what could a SOC realistically detect? Which signals or anomalies were worth watching?

The most useful signal a multi-client SOC has before signatures exist is correlation across clients. An odd request against one client’s server is noise. The same request, with the same pattern and from the same sources, hitting servers belonging to several different clients within a few hours is no coincidence. It is someone testing something new at scale. Nobody had a PHP2Shell rule, but a pattern repeating across clients that have nothing in common stands out.

It works the other way round too: what we see at one client becomes a hunt across all the others. An indicator at one client is a warning for the rest.

And it is worth being clear: vendor detection rules for PHP2Shell detect activity after a successful compromise; they do not detect or prevent the initial exploitation. Those rules also only cover clients on that vendor’s platform. In a heterogeneous environment, every detection has to be translated into each client’s technology.

3. How early did exploitation attempts show up in monitoring, and what did they look like?

There was a widespread increase in malicious activity across our clients. We saw it when reviewing the 10 days before the bulletin and in the days after the announcement. Fortunately, we have not had to deal with any active exploitation.

The fact that it was widespread is what matters. As a multi-client SOC we monitor very different infrastructures, across different sectors and spread geographically. When activity rises at the same time in environments that have nothing in common other than exposed services, our reading is that these are not attacks aimed at a specific client. It is someone searching at scale for who is vulnerable.

4. What makes detection hardest in a case like this: noise, logging gaps, or PHP running on systems the SOC doesn’t see at all?

In a multi-client SOC, heterogeneity. It is not one problem but three, multiplied across every client:

PHP we cannot see. Every client has a different map: their own servers, managed hosting, third-party appliances with PHP inside, websites run by an external agency… Sometimes the client does not even know they are running PHP. And whatever is outside the service scope, we do not monitor.

Uneven visibility. At one client we have web server error logs and process telemetry; at another, only firewall logs. The same vulnerability has different detection coverage depending on the client. We have to accept that and be transparent with each client about what we can and cannot see.

We do not control remediation. We can prioritise and warn, but patching depends on each client’s teams, their maintenance windows, their suppliers and their pace. In the meantime, the SOC’s job is to watch whatever is still unpatched more closely.
Noise exists, but it is the most manageable part. In fact, the number of clients we see helps us tell generic mass scanning apart from something targeted.

5. What should organisations make sure their SOC can see before the next vulnerability like this?

If your SOC is an external provider, the key question is: what are you actually sending it?

1. A shared, up-to-date inventory, including what third parties manage: hosting, agencies, appliances. If your SOC does not know it exists, it cannot watch it.
2. The logs that matter: the web server error log, not just access logs and the WAF.
3. Telemetry from exposed servers, with an agent or EDR that can see processes.
4. Vulnerability scanning correlated with live activity. A vulnerability scan that ends up as a PDF report protects nobody. What makes the difference is cross-referencing it in real time with what the SIEM sees. If your SOC cannot make that connection, what you have is two tools that do not talk to each other, not a detection service.
5. An escalation channel that works out of hours, with someone on the other end able to decide and patch. Detection is not much use if the alert sits in an inbox.

6. If you could tell every team one thing about PHP2Shell, what would it be?

Vulnerable, exposed and being probed: when all three apply, it is no longer a patch. It is an emergency.

A vulnerable server is a patching task. A vulnerable, internet-facing server is a priority. A vulnerable, internet-facing server receiving suspicious requests right now is an emergency, and should be treated as one within minutes, not in the next patch cycle. In a multi-client SOC, correlation goes one step further: if the same pattern reaches several clients, the ones that have not received it yet are next.