For some operators, suspending services was preferable to taking the risk. In reports on 22 October, PHP2Shell is already a business continuity issue: public websites and platforms temporarily unavailable while two critical PHP vulnerabilities are addressed.

The news also concerns businesses running an online shop, customer portal or management application. The questions for the IT team are immediate: “Do we use PHP? Has it been patched? Can we check what happened beforehand?”

Precautionary shutdowns: what today's reports say

Reuters, in its report available on Euronext on 22 October, describes European websites taken offline the previous day. France's Interior Ministry placed its websites under preventive maintenance; in Finland, public-sector provider Valtori announced precautionary network service suspensions. The Dutch national cybersecurity agency also disabled its website as a precaution.

RSI also reports that the administration of the Swiss canton of Ticino temporarily disabled some online services. These are precautionary measures: an offline website does not prove that it has been breached. They do show, however, that even a prudent response to a vulnerability can disrupt services used by citizens and businesses.

Both outlets report that artificial intelligence tools contributed to discovering the flaws. The issue remains in the PHP software; the priority for a business is to identify which services use it and whether they have been updated.

PHP: the problem may sit beneath the website

PHP is the software that runs the code behind many websites and applications on the server: from WordPress and online shops to custom-built portals. It is one of the components that keep a service working, even though users normally never see it.

The two vulnerabilities concern memory management. In simple terms, specially crafted requests can cause PHP to fail and, under certain conditions, allow an outsider to execute commands on the server. Consequences can include disruption, information exposure or system compromise.

The PHP Security Team identifies a particularly high risk for Apache with mod_php, one way of running PHP: the demonstrated attack path can be triggered before application code executes. Other configurations, such as PHP-FPM, also require attention. Actual exploitability must be assessed in the affected environment.

The practical consequence is straightforward: updating WordPress, a theme or a plugin does not patch the server's PHP software. Whoever administers that component must act, whether internally or at the hosting provider.

Attempts began four days before the announcement

According to Amazon Threat Intelligence, the first observed attempt dates to 17 October 2026. It was detected through MadPot, Amazon's network of decoy systems used to study malicious activity on the Internet.

On 21 October, before public disclosure, Amazon observed further attempts. Cloudflare also confirmed attack traffic targeting its customers, with variations in requests designed to bypass protections.

These observations do not establish that every attempt succeeded. Amazon states that the success of the earliest attempts against real systems remains uncertain. They do show how short, or even non-existent, the interval between a public announcement and attacker activity can be.

Patching closes the flaw. Investigation also looks back

On 21 October, the PHP Security Team released patched versions: 8.2.35, 8.3.36, 8.4.27 and 8.5.12. For branches no longer supported by the project, immediately check the relevant vendor's fixes or upgrade to a supported version.

A web traffic filter can reduce some attack paths, but it does not replace an update. The PHP developers state that there are no complete alternative mitigations to patching.

There is another crucial distinction. Imagine a server compromised on 19 October and patched on 22 October: fixing the vulnerability does not automatically remove access, files or changes left behind beforehand. Repairing a faulty door does not tell us whether someone has already walked through it.

This is why Amazon recommends reviewing activity from at least 17 October: suspicious web requests, unexpectedly launched programs and unusual file changes. That requires accessible, usable data; the absence of an alert alone does not prove that everything was fine.

What to check in your business now

  • Which systems use PHP? Include websites, portals, internal applications, containers and services managed by suppliers. Ask for the version actually running and the vendor fixes applied: some distributions patch the flaw while retaining the original version number.
  • Who applies the fixes? Prioritise Internet-facing services and ask the provider to confirm the update, including the installed version and the vendor fixes applied.
  • Which events have we retained? Check with your security team whether useful data exists from 17 October onwards and whether any signals need investigation.
  • Who handles suspicious activity? Identify the technical contact and responsibilities for investigation, any containment and recovery.

For a small or medium-sized business, this means getting concrete answers from those managing its systems, without having to reconstruct contacts and responsibilities during an emergency.

This is where a service such as ARGUS adds value

When news like this breaks, previously collected events and operational monitoring help guide the checks. That is the value of ARGUS — Managed Security Operations Center by Redaxer: a managed service that collects and analyses security signals from connected systems and sends operational notifications about relevant events.

For example, an unusual website request followed by an unexpected program launch and a file change may warrant investigation. Visibility into those steps helps put a suspicion in context and direct technical work.

We cannot claim that ARGUS would certainly have recognised PHP2Shell before disclosure. The practical benefit is facing an emergency with monitoring already operating and information available, depending on the systems monitored, the sources integrated and the data retained.

In plans that include them, threat hunting and tools for organising timelines and evidence support deeper investigation; containment depends on the plan and agreed configurations. Patching PHP remains the responsibility of whoever manages the server.

For a business without an internal SOC, ARGUS provides continuous security monitoring on which to build this capability. When the next vulnerability arrives without warning, existing visibility into the infrastructure can support faster, better-informed decisions.

Sources and references