PHP2Shell: Critical PHP Vulnerabilities Could Let Attackers Take Over Web Servers Without Logging In

Airvyb Cybersecurity Alert | October 23, 2026

Two critical vulnerabilities in PHP's core engine have put web servers running affected PHP versions at risk of remote code execution. Tracked as CVE-2026-109618 and CVE-2026-109619, the flaws could allow unauthenticated attackers to execute commands on vulnerable servers or access sensitive process memory.

The vulnerabilities, collectively referred to as PHP2Shell, were disclosed on October 21, 2026. Both carry a reported CVSS v4.0 severity score of 9.2 out of 10.

What makes this incident particularly serious is that the weaknesses exist in PHP itself. An application does not necessarily need to contain a vulnerable endpoint or a coding mistake for the underlying PHP engine to be exposed.

For developers, hosting providers, and businesses operating PHP-based websites, checking the PHP runtime version and applying the appropriate security updates should be an immediate priority.

Sources: OffSec's technical analysis and NHS England's security alert.

What is PHP2Shell?

PHP2Shell refers to two related memory-safety vulnerabilities affecting the PHP engine, which executes server-side PHP code.

PHP powers a wide range of web applications, including WordPress, Drupal, Joomla, and many custom-built business platforms. When a vulnerability affects the underlying runtime, the potential exposure extends beyond a single application or plugin.

The vulnerabilities involve improper handling of memory and internal state during exceptional request-processing conditions. Under specific circumstances, memory that has been released or incorrectly initialized may subsequently be accessed.

Researchers have demonstrated that these conditions can lead to remote code execution.

In practical terms, a successful attack could allow an attacker to execute commands with the privileges of the affected web server process. Depending on the server's permissions and configuration, this could expose application data, credentials accessible to the process, or other connected resources.

The two vulnerabilities explained

CVE-2026-109618: Out-of-memory corruption

This vulnerability involves PHP's handling of memory-allocation failures.

When PHP runs out of available memory while processing a request, it can abort the current operation. Under vulnerable conditions, internal data structures may be left in an invalid state, which can cause unsafe memory access during subsequent cleanup.

Researchers have demonstrated that this behavior can potentially be exploited to achieve remote code execution.

CVE-2026-109619: Stale global state

The second vulnerability involves PHP's internal state persisting incorrectly across request processing.

Some global state may continue to reference memory belonging to a request after that memory has been freed. If subsequent processing uses that stale reference before the state is properly initialized, a use-after-free condition can occur.

This can create another path to memory corruption and potentially remote code execution.

Both vulnerabilities are particularly concerning because exploitation can occur before an application-level authentication mechanism or ordinary application code has an opportunity to reject the request.

Which PHP versions are affected?

According to the published advisories, affected releases include:

Important: These are the reported fixed release thresholds for the PHP2Shell vulnerabilities. Verify the official PHP security advisories before deploying an update, and use a supported PHP branch wherever possible.

Sources: Official PHP security advisories and the second PHP advisory.

Does this affect WordPress and other PHP websites?

Potentially, yes.

PHP2Shell is a vulnerability in the PHP runtime rather than a defect specific to WordPress, Drupal, Joomla, or another individual content management system.

If a website runs an affected PHP version in a vulnerable server configuration, changing its CMS version alone will not fix the underlying PHP engine.

Potentially affected environments include:

• WordPress and other PHP-based content management systems.
• Custom PHP applications and APIs.
• PHP-FPM deployments.
• Apache servers using mod_php.
• Other web-server configurations that execute affected PHP versions.

The actual exposure depends on the PHP version, runtime configuration, and deployment environment. Administrators should inventory all exposed PHP services rather than checking only their main website.

How to protect your website

1. Check the PHP runtime version

If you have shell access to the server, run:

php -v

This reports the PHP version used by the command-line interface.

However, the command-line version may differ from the version serving your website. Check the PHP-FPM service, Apache module, hosting control panel, or other web-serving runtime as appropriate.

Do not leave a publicly accessible diagnostic page containing PHP configuration information on a production server.

2. Upgrade to a fixed PHP release

Update to the applicable patched release or a later supported release:

• PHP 8.2.35 or later in the 8.2 branch.
• PHP 8.3.36 or later in the 8.3 branch.
• PHP 8.4.27 or later in the 8.4 branch.
• PHP 8.5.12 or later in the 8.5 branch.

Where possible, plan migration away from unsupported PHP branches. Test application compatibility and dependencies, but do not let routine testing become an indefinite reason to leave an exposed service unpatched.

3. Do not rely on configuration workarounds

Some temporary mitigations have been discussed, including disabling PHP session upload-progress functionality. However, researchers have warned that such measures do not comprehensively address the vulnerabilities.

Configuration changes may reduce particular attack paths, but they are not substitutes for installing the security fixes.

If patching cannot be completed promptly, assess exposure, consult your hosting or security provider, and consider taking vulnerable services offline until they can be secured.

4. Investigate suspicious activity

Updating prevents exploitation through the known vulnerabilities in the fixed runtime, but it does not establish whether a server was compromised before the update.

Security teams should investigate relevant logs and telemetry for:

• Unexpected memory-exhaustion errors during request processing.
• Unusual or malformed multipart HTTP requests.
• Unexpected shell or child-process creation by PHP workers.
• Suspicious outbound connections.
• Unusual changes to application files, scheduled tasks, accounts, or credentials.

These indicators are not conclusive on their own. Legitimate requests can produce errors, and a lack of obvious errors does not prove that a server was never compromised.

If compromise is suspected, preserve relevant evidence, isolate the affected system as appropriate, investigate the incident, and rotate potentially exposed credentials from a clean environment.

Why this vulnerability matters to developers

PHP2Shell illustrates an important security principle: application-level defenses cannot compensate for every weakness in the software runtime beneath them.

A website may have strong passwords, carefully written business logic, and updated plugins while still relying on a vulnerable PHP engine.

Security therefore needs to cover the complete application stack:

• The operating system and server configuration.
• The language runtime and its dependencies.
• Application code, authentication, and authorization.
• Secrets, credentials, and database permissions.
• Monitoring, patch management, and incident response.

Developers should treat runtime updates as part of routine maintenance rather than an optional task performed only when application code changes.

Final thoughts

PHP2Shell is a reminder that vulnerabilities in widely deployed infrastructure can have consequences far beyond an individual application.

The combination of unauthenticated attack paths, potential remote code execution, and widespread PHP usage makes these vulnerabilities a serious concern for administrators of exposed systems.

The immediate priority is straightforward: identify affected PHP runtimes, deploy the appropriate security updates, and investigate any credible signs of previous exploitation.

Do not assume that updating WordPress or another application automatically patches PHP itself. Verify the runtime that actually serves requests.

For organizations running PHP in production, patch verification should be treated as an operational security requirement.

Airvyb | Technology for the modern world

Cybersecurity insights, technology analysis, and practical guidance for building and protecting digital systems.

Technical references

1. OffSec — PHP2Shell: Critical Vulnerabilities in PHP Core
2. PHP source repository — GHSA-w8hw-w9fx-j79w
3. PHP source repository — GHSA-6wmf-4rv5-p3rp
4. NHS England — Critical Vulnerabilities in PHP