Attackers appear to have moved quickly from testing to active exploitation of the so-called PHP2Shell vulnerabilities, according to a SecurityWeek report citing honeypot observations. The reported activity indicates that internet-facing PHP environments may already be at risk where patches, mitigations or temporary access controls have not been applied.

What happened

SecurityWeek reported that attackers successfully exploited PHP2Shell flaws against honeypots and launched 35 shells from two IP addresses on October 24. In practical terms, this means researchers observed intruders not just scanning for vulnerable systems, but obtaining command execution on exposed targets.

A web shell is commonly used to give an attacker remote access to a compromised server. Once deployed, it can be used to run commands, move further into the environment, steal data, alter website content or install additional malware.

Why it matters for European businesses

The shift from reconnaissance to successful shell deployment is important because it usually signals that exploitation has become operational. For businesses, that changes the risk from a theoretical vulnerability management issue into a live incident-response concern.

European SMEs often rely on PHP-based websites, e-commerce platforms, customer portals and internal web applications, whether self-hosted or managed by agencies and hosting providers. If vulnerable components are exposed to the internet, attackers may be able to gain server access before routine patch cycles are completed.

This matters beyond IT teams. A compromised PHP server can affect website availability, customer data, order processing, lead generation and brand trust. If personal data is involved, organisations may also need to assess GDPR-related obligations, depending on the facts of the incident.

Who may be affected

• Businesses running internet-facing PHP applications, especially older or lightly maintained web environments
• E-commerce companies whose storefronts, plugins or custom integrations depend on PHP infrastructure
• Digital agencies and managed service providers responsible for maintaining client websites and hosting stacks
• Internal IT and DevOps teams managing Linux web servers, virtual machines or shared hosting environments
• Regulated businesses that must evaluate potential data exposure and incident reporting requirements if compromise occurs

What companies should consider

• Identify exposure quickly. Review whether any public-facing PHP systems use affected components or configurations linked to PHP2Shell reporting.
• Apply vendor fixes and mitigations. Where patches or official mitigation guidance are available, prioritise them on internet-facing systems first.
• Restrict access where patching is delayed. Consider temporary controls such as WAF rules, IP restrictions, disabling unnecessary services or removing external exposure.
• Check for signs of compromise. Review web server logs, process activity, unusual outbound traffic, newly created files, scheduled tasks and indicators of web shell deployment.
• Coordinate with hosting and web partners. SMEs using external developers, agencies or managed hosts should confirm whether defensive action has already been taken.
• Prepare incident response steps. If exploitation is suspected, isolate affected servers, preserve logs and forensic evidence, rotate credentials and assess whether customer or employee data may have been accessed.

For many companies, the immediate lesson is that once public exploitation begins, patching should be treated as urgent rather than routine. Businesses with revenue-generating websites or customer-facing PHP applications should verify their exposure and response status without delay.