The story is no longer simply the discovery of two critical flaws. It is the speed at which attackers are looking for systems that remain exposed. While a business works out who manages its server and when it can be updated, attempts may keep coming.

In our first PHP2Shell article, we explained why some websites were shut down as a precaution and why patching must be accompanied by a review of earlier activity. Today's update, 23 October, starts with figures reported the previous day and brings the question into day-to-day operations: who sees the signals, who receives them and who takes action in your business?

32 government services offline: risk is already an operational issue

According to the Guardian, UK cybersecurity minister Liz Lloyd told Parliament that 32 government services had been taken offline, largely as a precaution. Suspending a service to secure it has tangible consequences, even without a confirmed breach.

The Guardian reports statements by Matthew Prince, Cloudflare's chief executive: tens of thousands of attempts in the first 45 minutes after the announcement, hundreds of thousands within two hours and, by the time of the statement, millions.

This measures activity observed by Cloudflare, as reported by the newspaper. It does not mean millions of affected businesses, distinct servers or successful intrusions. In the same report, the UK's national cybersecurity centre said it had no reports of successful hacks resulting from the flaw: the situation known at that point, not a general assurance.

For a business, the useful lesson is how quickly the activity grew. After disclosure, waiting for routine maintenance can leave a window in which others are already looking for vulnerable systems. The absence of visible disruption is not enough to justify a delay.

A server flaw can put much more than the website at risk

The Guardian describes PHP as the language underpinning around 70% of websites. That reach does not mean all those websites are equally vulnerable. PHP is the component that executes code for many websites, portals and applications. Under certain conditions, PHP2Shell can let an unauthenticated outsider execute code on the server. The risks include data access, unauthorised changes and service disruption, not just a web page that stops loading.

The outcome depends on the configuration and the privileges of the affected service. This does not mean every installation can be exploited in the same way, but it makes checking the actual environment essential. The right question for your provider is: “Which of our services use PHP, and which fixes have you applied?”

The official PHP updates of 21 October remain the reference point. A web application firewall can filter malicious requests, but it does not fix the software defect. The AWS mitigation guidance, updated on 22 October, shows that dedicated protections are also evolving. Check which controls are actually active in your environment.

Updating quickly also means knowing where to act

“We have installed the patch” is useful only when the scope of that statement is clear. A business may have updated its main website while an old portal or a supplier-managed environment still needs checking. During an emergency, a few questions need documented answers:

  • Where are we exposed? Identify servers, applications and third-party services using PHP, particularly those accessible from the Internet.
  • What has been fixed? Confirm the update, the affected service and the vendor fixes. Some distributions apply patches while keeping the original version number.
  • What happened beforehand? Retain and analyse available events. Amazon had already observed an attempt against one of its decoy systems on 17 October: an investigation should not start only from the moment the patch was installed.
  • Who handles suspicious activity? Identify the technical contact, who decides on containment and who checks that services can safely resume.

If a system had been compromised before the update, the fix would not automatically remove anything an attacker might have left behind. A suspicious event needs investigation even on a machine that has now been patched.

Protection and visibility: both matter

Filtering traffic and reducing exposure help obstruct attempts. Collecting and analysing events helps determine whether something needs attention. These capabilities reinforce one another: having protection in place does not remove the need to check what is happening.

Imagine an unusual portal request followed by an unexpected program launch and a connection to an external destination. This is an example of a sequence worth investigating, not automatic proof of PHP2Shell. If the information is collected and usable, it can help determine which system to examine and with what priority.

That is what keeping an eye on the infrastructure means: continuously observing covered systems and making their signals useful. No service literally sees everything; it needs a known scope, incoming data and clear operational responsibilities.

ARGUS: monitoring already in place when an emergency starts

ARGUS — Managed Security Operations Center by Redaxer brings continuous monitoring, event analysis and operational notifications to a business without requiring it to build an internal SOC. It collects signals from connected systems and sources, analyses them and helps focus attention on events that warrant investigation.

In a case such as PHP2Shell, the business value is concrete: existing visibility into monitored systems and notifications that bring relevant signals to the operational contacts. This helps direct checks and coordinate with whoever must update the services, without starting from scratch once the vulnerability is already in the headlines.

In plans that include them, vulnerability management, threat hunting and incident timelines provide additional tools for setting priorities and investigating evidence. Any containment actions depend on the plan and agreed configuration. ARGUS does not automatically install PHP patches on behalf of the server administrator.

Coverage and retained data determine what can be observed and reconstructed. That is why the best time to define the service is before the emergency: when attempts increase, existing information and the ability to use it promptly matter.

Sources and references