Attackers are actively exploiting critical PHP vulnerabilities in internet-facing systems, according to SecurityWeek. The report says more than 22.6 million exposed instances could be potentially affected, and that the ongoing activity has led to root-level compromise on some Palo Alto firewall deployments. In the same reporting, WordPress environments did not appear to be successfully compromised in this particular attack chain.

For European businesses, the immediate issue is not limited to websites. PHP can sit inside web applications, hosting stacks, management interfaces and, in some cases, security or network products. That makes rapid asset identification and patching more important than treating this as only a website problem.

What happened

SecurityWeek reports that attackers have been targeting critical PHP flaws for more than a week. The article describes successful attacks against Palo Alto firewall environments, with root access achieved in some cases. It also states that WordPress instances did not fall to the same attacks, suggesting that exploitation conditions differ depending on how PHP is deployed and what protections are in place.

Based on the source provided, the key confirmed point is active exploitation of critical PHP flaws. The article headline and summary indicate differing outcomes across affected technologies: severe impact for some firewall deployments and unsuccessful compromise attempts against WordPress in this campaign.

Why it matters for European businesses

Many SMEs and mid-sized companies rely on PHP directly or indirectly through hosting providers, legacy applications, e-commerce platforms, web control panels and third-party products. If a vulnerable PHP component is exposed to the internet, attackers may use it to run code remotely, steal data, move laterally inside networks or disrupt operations.

The mention of firewall compromise raises the business risk further. Security appliances often sit at the edge of the network and may have privileged access or visibility across traffic. If such a device is compromised, the incident can affect more than one application or website. It may also complicate forensic review because perimeter devices are trusted components in many IT environments.

For European companies handling customer data, payment information or regulated workloads, a successful compromise can quickly become both an operational and compliance issue. Even when the vulnerable component is managed by a vendor or hosting provider, organisations may still need to assess exposure, document response steps and evaluate whether personal data or internal systems were put at risk.

Who may be affected

• Businesses running PHP-based web applications, including custom platforms, older internal tools and customer portals.
• E-commerce companies using PHP-dependent storefronts, plugins or middleware.
• IT teams responsible for firewalls, remote management interfaces, hosting stacks or internet-exposed admin systems.
• Companies using managed hosting or third-party platforms where PHP may be present in the underlying environment even if it is not visible to the business user.
• Organisations with legacy systems that are harder to patch quickly or may not have a complete inventory of exposed assets.

What companies should consider

• Identify exposed PHP systems across websites, applications, hosting environments and network or security products.
• Check vendor advisories immediately for PHP-based products and internet-facing appliances, including firewalls and management interfaces.
• Prioritise patching based on exposure. Internet-accessible systems should be reviewed first, especially those handling authentication, administration or sensitive business data.
• Review logs and endpoint telemetry for suspicious requests, unexpected processes, privilege escalation or administrative changes since disclosure of the flaws.
• Limit unnecessary exposure by restricting public access to admin panels and management interfaces where possible.
• Ask hosting providers and SaaS vendors for confirmation if they operate PHP components on your behalf and whether mitigation has been applied.
• Prepare an incident response path in case compromise is suspected, particularly for perimeter devices or systems connected to customer data.

The current reporting is most relevant as an operational warning: active exploitation is under way, and businesses should not assume that only traditional websites are in scope. European organisations with externally exposed PHP components, especially in security or infrastructure products, should review vendor guidance and patch status without delay.