PHP has issued emergency security updates for two critical remote code execution vulnerabilities, referred to as PHP2Shell, after exploit attempts were reported. According to the source, the flaws affect the PHP runtime itself rather than a specific CMS, plugin or custom application, which means a business can be exposed even if its own website code is well maintained.

The available fixes are included in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. The PHP team said that updating is the measure that fully protects affected servers.

What happened

The vulnerabilities reportedly allow an attacker to execute code on a web server without needing an account. That makes them especially serious for internet-facing systems, because exploitation may be possible before an attacker has authenticated to an application.

A key point for businesses is that the issue is described as being in the PHP language runtime. In practice, that is the software layer used to execute PHP applications. If the runtime is vulnerable, risk may exist across multiple websites and services on the same infrastructure, regardless of whether the business uses a custom-built site, an e-commerce platform, or a content management system that relies on PHP.

Why it matters for European businesses

PHP remains widely used across company websites, online stores, customer portals and internal business applications. For European SMEs, this creates a direct operational risk: a runtime-level vulnerability can potentially affect public websites, lead-generation forms, e-commerce systems, and integrations connected to CRM, ERP or marketing tools.

If exploited, remote code execution can allow attackers to run commands on the server. The business impact may include website defacement, malware installation, theft of customer or business data, credential compromise, service disruption, or a broader breach affecting connected systems.

This also matters from a compliance and governance perspective. If a vulnerable PHP server processes personal data, any compromise could trigger incident-response and data-protection obligations depending on the facts of the incident. For regulated businesses and suppliers with contractual security commitments, delayed patching may also increase commercial and audit risk.

Who may be affected

• Companies running PHP-based websites or applications, including corporate sites, portals and booking systems.
• E-commerce businesses using PHP-dependent platforms or custom storefronts.
• Agencies and hosting providers managing multiple customer websites on shared or managed infrastructure.
• IT teams and DevOps teams responsible for Linux web servers, containers or cloud instances with PHP installed.
• Businesses relying on third-party vendors for website maintenance, application hosting or managed commerce environments.

Even businesses that do not directly manage their own infrastructure may still be affected if a hosting provider, software vendor or digital agency is responsible for the underlying PHP environment.

What companies should consider

• Identify where PHP is running across public websites, e-commerce systems, APIs, customer portals and internal web applications.
• Check installed versions and compare them with the patched releases named in the advisory: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.
• Prioritise patching internet-facing systems first, especially servers handling payments, forms, logins or customer data.
• Contact hosting providers or web partners immediately if your business does not control server updates directly, and request confirmation of remediation.
• Review logs and monitoring data for unusual web requests, unexpected processes, new scheduled tasks or outbound traffic that could indicate attempted exploitation.
• Validate backups and recovery plans in case a server needs to be rebuilt or restored.
• Limit follow-on risk by reviewing privileged accounts, restricting unnecessary server access and separating critical systems where possible.

For most organisations, the practical message is simple: this is infrastructure-level patching, not a routine application update that can be postponed. Businesses using PHP should confirm quickly whether affected versions are present and whether their websites or applications have already been updated.