This article is written by Greg Garnett, Darwin’s Technology Director. Greg has held multiple senior technology positions within UK top 50 law firms. 

The recently disclosed PHP vulnerabilities have put PHP security firmly back on IT teams’ agendas. Carrying a critical CVSS score of 9.2 each, these flaws can allow unauthenticated attackers to remotely execute code on affected servers. Because PHP powers a large proportion of the web, spanning everything from legacy applications to modern enterprise platforms, their reach is significant.

For IT teams around the world, the disclosure triggered an immediate shift in priorities. Resources were diverted to scan estates, identify vulnerable instances and apply patches. Amazon Threat Intelligence has reported exploitation attempts, including activity before the public disclosure.

But alongside the technical response, a wider issue is coming into focus: the difference in how Security Operations Centres (SOCs) support their clients when a major vulnerability emerges.

The echoes of familiar flaws

We have been here before. PHP2Shell brings back reminders of Log4j, Heartbleed and Shellshock. These events share a common challenge: a vulnerability emerges in foundational software that may be scattered across an organisation’s estate.

IT teams may not have immediate visibility into exactly what versions of PHP are running, where they are hosted and what critical business functions might be affected by the patching process. Finding the vulnerability is often harder than fixing it. This is precisely when an organisation should be able to lean on its security partners.

The response does not always match what customers expect.

The “one pager” problem

I spoke with a customer recently who had spent days manually scanning their entire estate, hunting for vulnerable PHP-FPM, Apache mod_php, php-cgi and LiteSpeed instances. They were trying to map out a remediation plan while simultaneously keeping the lights on for their day job.

The surprising part? This customer pays for a fully managed SOC service with comprehensive estate coverage.

When I asked the natural question, “What has your SOC done to help you with this?”, they explained that they had received a one page advisory describing the vulnerability. It explained the issue, but left the customer to work out what it meant for their own environment and what to do next.

What a modern SOC should deliver in a crisis

If the support stops at a generic advisory, it is worth asking whether the service meets your needs. While remediation, the actual patching of servers, usually sits with the internal IT team or infrastructure provider, identification and proactive hunting should have clear owners within the agreed service.

Not every SOC contract includes vulnerability management. Where it does, and the necessary tools and data are connected, a proactive response to an event like PHP2Shell should include:

1. Automated estate querying: Using the telemetry from Endpoint Detection and Response (EDR) tools, vulnerability scanners and SIEM platforms, the SOC should quickly identify potentially affected systems and work with the relevant teams to verify their patch status.
2. Targeted asset lists: Instead of a generic advisory alone, the customer should receive a prioritised list based on the available evidence. For example: “We have identified these 14 servers running vulnerable versions of PHP. Two of them are public facing and should be your priority.” Any gaps in coverage should be made clear.
3. Compensating controls: If immediate patching is not possible, the SOC should help the responsible team assess and apply appropriate temporary controls within its remit. These might include access restrictions or relevant WAF rules, with their limitations explained. Temporary controls should not be presented as a complete fix for PHP2Shell.
4. Active threat hunting: SOC analysts should review the available logs and telemetry for indicators of compromise (IoCs) and suspicious activity associated with the exploits, helping assess whether systems may already have been compromised while the IT team prepares to patch.

Providing this level of actionable intelligence can reduce manual discovery work and help the internal IT team focus its effort. It depends on having the right visibility: the NCSC’s guidance on SOC log sources explains why the data available to a SOC matters for detection and incident response.

The fallacy of the “Silent SOC”

I frequently hear IT leaders say, “I rarely hear from my SOC, and I love it. It means things are quiet.”

Silence alone is not a reliable measure of effectiveness. A quiet environment may reflect good controls, but you should still understand what your SOC is monitoring, what it has investigated and where gaps remain.

Security services have evolved rapidly. Many now combine monitoring with Managed Detection and Response (MDR) capabilities and proactive threat hunting. The service label alone does not tell you what support you will receive.

A modern SOC should communicate clearly and regularly. It should demonstrate its value through the investigations it has carried out, the actions it has taken and the guidance it provides when new vulnerabilities emerge.

Looking beyond the immediate response

The PHP2Shell vulnerabilities require immediate attention. The PHP project has released fixes in PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. If you are relying on older versions, check the PHP security advisory and your distribution or support provider for applicable backported fixes, and plan your move to a supported release. Where a system cannot be patched promptly, agree appropriate access restrictions or temporary isolation with your security and infrastructure teams. The PHP project makes clear that temporary mitigations do not provide complete protection.

If your internal team managed to remediate this threat independently, take a moment to consider the support they received along the way. Review your SOC requirements and managed security contracts. Scan the market. The capabilities and commercial options available today may differ considerably from those negotiated half a decade ago.

Look for a SOC that works alongside your team and can demonstrate how its support helps you act.

How Darwin can help

Darwin helps organisations define their SOC and MDR requirements, review the market and compare security partners against their technical, operational and commercial needs. We bring structure and evidence to the decision, helping you understand what is included, where responsibilities sit and how each option would support your team in practice. Darwin provides this support at £0 cost to the customer, while remaining independent and impartial throughout the decision. If you are reviewing your managed security service, talk to Darwin.