Critical PHP Flaws Put Internet-Facing Servers On High Risk

Executive Summary

A vulnerability in the software powering a website can become a gateway to the wider environment and the latest critical PHP vulnerabilities highlight just how quickly that risk can escalate.

Two critical flaws, tracked as CVE-2026-109618 and CVE-2026-109619 and collectively referred to as PHP2Shell, could allow unauthenticated attackers to execute arbitrary code on vulnerable web servers. Both vulnerabilities have a CVSS v4.0 score of 9.2, placing them in the critical severity category.

The vulnerabilities reside in the PHP runtime rather than in individual applications. This means that a website may remain exposed even if its application code is properly maintained and has no known security

flaws.

Understanding the Threat

Remote code execution is particularly dangerous because it can allow an attacker to move beyond sending malicious requests and execute code on the targeted server.

The two PHP vulnerabilities affect request processing and can expose vulnerable systems to attacks without requiring the attacker to authenticate first. The precise exploitation path and potential impact depend on the server configuration and the vulnerability involved.

A successful attack could enable an adversary to:

• Execute unauthorised commands within the privileges of the affected PHP process.
• Access sensitive information, including application data, credentials, authentication tokens and other secrets available to the process.
• Modify website files or introduce malicious scripts.
• Establish a foothold for further attacks, depending on the server's permissions and network access.
• Disrupt services, compromise customer information or affect connected systems.

The risk is especially significant for internet-facing servers. Certain Apache configurations using mod_php have been identified as particularly exposed, although other PHP request-processing environments are also affected.

The key concern: An attacker may not need to exploit a separate application vulnerability to target the underlying PHP runtime.

Why Organisations Should Pay Attention

The vulnerabilities present a challenge because PHP is widely used across websites, content management platforms, business applications and other internet-facing services.

The Dutch Parliament's website was taken offline as a precaution following a cybersecurity warning. Other public services and organisations in the Netherlands also restricted access while assessing their exposure.

These actions do not establish that the affected organisations were successfully compromised. Instead, they demonstrate how a critical vulnerability can trigger emergency operational decisions even before an incident is confirmed.

For organisations, the exposure may extend beyond the primary website. PHP installations can exist across production servers, cloud workloads, containers, legacy applications and third-party-hosted environments. Without a reliable asset inventory, security teams may struggle to determine the full scope of exposure.

The incident reinforces an important security principle: A vulnerability in a shared technology can create risk across multiple systems, regardless of whether those systems were developed or managed by the same team.

Affected Systems and Fixed Versions

The vulnerabilities affect PHP installations serving web requests, including deployments using Apache mod_php, PHP-FPM, php-cgi, FrankenPHP and LiteSpeed.

The following fixed releases were announced

Recommendation

Security teams should take the following steps to protect affected systems:

1. Identify vulnerable systems: Check servers, websites, cloud environments and containers running PHP, especially those accessible from the internet.

2. Apply security updates: Upgrade affected PHP installations to the appropriate fixed versions and confirm that all systems have been updated.

3. Limit exposure: If patching cannot be completed immediately, restrict public access to vulnerable systems until they are secured.

4. Verify the fixes: Re-scan affected systems to confirm that the vulnerabilities have been addressed and no exposed, unpatched instances remain.

5. Respond to suspected compromise: Preserve relevant logs, isolate affected systems where necessary, check for exposed credentials and investigate possible access to connected systems