{"id":3322,"date":"2026-10-22T02:29:22","date_gmt":"2026-10-22T02:29:22","guid":{"rendered":"https:\/\/wpauthors.com\/blog\/?p=3322"},"modified":"2026-10-22T02:30:11","modified_gmt":"2026-10-22T02:30:11","slug":"php2shell-php-vulnerabilities","status":"publish","type":"post","link":"https:\/\/wpauthors.com\/blog\/php2shell-php-vulnerabilities\/","title":{"rendered":"PHP2Shell Explained: Critical PHP Vulnerabilities Every WordPress Site Owner Should Know About"},"content":{"rendered":"\n

Two critical PHP security flaws could allow attackers to execute code on vulnerable web servers without logging in. Here is what WordPress site owners need to know and how to protect their websites.<\/strong><\/p>\n\n\n\n

On October 21, 2026, the PHP development team released urgent security updates for two critical vulnerabilities known as PHP2Shell<\/strong>: CVE-2026-109618 and CVE-2026-109619.<\/p>\n\n\n\n

Both vulnerabilities have a CVSS v4.0 severity score of 9.2 out of 10. Under certain conditions, an attacker can exploit them to execute malicious code on a server running a vulnerable version of PHP. Depending on the server’s permissions, this could expose sensitive information, compromise website files, or disrupt services.<\/p>\n\n\n\n

This is particularly important for WordPress websites because PHP is the server-side language that powers WordPress itself.<\/p>\n\n\n\n

The good news is that patches are available. The important part is ensuring that the PHP runtime actually serving your website has been updated.<\/p>\n\n\n\n

What is PHP2Shell?<\/h2>\n\n\n\n

PHP2Shell is the name commonly used for two related vulnerabilities in PHP’s handling of memory and request processing.<\/p>\n\n\n\n

PHP receives HTTP requests, processes submitted data, executes application code, and returns responses to visitors. During this process, it allocates and releases memory to store information about each request.<\/p>\n\n\n\n

The newly disclosed vulnerabilities involve what happens when PHP encounters errors during this work.<\/p>\n\n\n\n

In one case, PHP can be interrupted while internal request data is only partially initialized. In the other, internal state can retain references to memory that has already been released.<\/p>\n\n\n\n

These conditions may allow an attacker to manipulate how PHP handles memory and, ultimately, execute code on the server.<\/p>\n\n\n\n

The PHP security team published fixes for both vulnerabilities on October 21, 2026. The official PHP security advisory<\/a> identifies the affected versions, corrected releases, and temporary mitigation measures.<\/p>\n\n\n\n

Why should WordPress website owners care?<\/h2>\n\n\n\n

WordPress is built on PHP, meaning a vulnerability in the PHP runtime can put an entire website at risk, regardless of whether its WordPress core, themes, and plugins are up to date.<\/p>\n\n\n\n

There are three important implications.<\/p>\n\n\n\n

1. Your WordPress installation may not need a vulnerable plugin.<\/strong><\/p>\n\n\n\n

These flaws exist in PHP itself, rather than in a particular WordPress plugin or theme. An attacker may be able to target the vulnerable PHP runtime without exploiting a WordPress-specific security flaw.<\/p>\n\n\n\n

2. A WordPress login is not necessarily required.<\/strong><\/p>\n\n\n\n

The vulnerabilities can allow unauthenticated remote code execution. This means an attacker may not need a legitimate account or administrator credentials to attempt exploitation.<\/p>\n\n\n\n

3. Updating WordPress alone will not fix the problem.<\/strong><\/p>\n\n\n\n

Installing the latest WordPress release, updating your plugins, changing administrator passwords, or adding another WordPress security plugin does not repair vulnerable PHP internals.<\/p>\n\n\n\n

The required fix is a patched PHP runtime.<\/p>\n\n\n\n

The PHP security advisory identifies internet-facing PHP installations using Apache’s mod_php<\/code>, PHP-FPM, php-cgi<\/code>, FrankenPHP, and LiteSpeed as relevant deployment types. The demonstrated exploit discussed in the official advisory involved Apache’s mod_php<\/code>; exact exploitability and reliability depend on the PHP deployment and configuration. Other configurations should not be considered safe simply because they use a different PHP handler.<\/p>\n\n\n\n

Sources: PHP security advisory<\/a>, CERT-EU security advisory<\/a>.<\/p>\n\n\n\n

Understanding the two PHP2Shell vulnerabilities<\/h2>\n\n\n\n

Although the vulnerabilities are related, they involve different memory-management problems.<\/p>\n\n\n\n

CVE-2026-109618: Remote code execution through out-of-memory corruption<\/h3>\n\n\n\n

PHP enforces memory limits to prevent an individual request from consuming excessive resources. When a request runs out of available memory, PHP must stop the operation and clean up the resources it has been using.<\/p>\n\n\n\n

The problem is that certain error-handling paths can interrupt PHP while internal request data is still being initialized.<\/p>\n\n\n\n

If cleanup subsequently treats that incomplete data as valid, PHP may access invalid memory or perform an unsafe memory operation. Under suitable conditions, an attacker can use this behavior to achieve remote code execution.<\/p>\n\n\n\n

In simple terms, PHP starts preparing data for a request, runs out of memory at an unsafe point, and then incorrectly handles the unfinished work.<\/p>\n\n\n\n

This vulnerability is tracked as CVE-2026-109618<\/strong>, with the official advisory titled RCE via OOM corruption<\/a>.<\/p>\n\n\n\n

CVE-2026-109619: Remote code execution through stale global state<\/h3>\n\n\n\n

The second vulnerability involves information that PHP retains internally while processing requests.<\/p>\n\n\n\n

Some PHP worker processes handle multiple requests over their lifetime. Although information belonging to a completed request should no longer be used, certain error conditions can leave internal references pointing to memory that has already been released.<\/p>\n\n\n\n

A later request handled by the same worker may encounter this stale state before PHP has properly initialized the new request.<\/p>\n\n\n\n

This is a form of use-after-free<\/em>: software attempts to use memory after that memory has been released. Such errors can cause crashes, data exposure, or security-critical behavior, depending on how the invalid memory is used.<\/p>\n\n\n\n

This vulnerability is tracked as CVE-2026-109619<\/strong>, documented in the official stale global state advisory<\/a>.<\/p>\n\n\n\n

Both vulnerabilities have a CVSS v4.0 score of 9.2. Neither score means exploitation is guaranteed on every server. However, the possibility of remote code execution without authentication makes both issues urgent.<\/p>\n\n\n\n

Which PHP versions are vulnerable?<\/h2>\n\n\n\n

As of October 22, 2026, the PHP project has published the following corrected releases for its maintained branches.<\/p>\n\n\n\n

PHP branch<\/th>Vulnerable versions<\/th>First fixed release<\/th><\/tr>
PHP 8.5<\/td>Earlier than 8.5.12<\/td>8.5.12<\/strong><\/td><\/tr>
PHP 8.4<\/td>Earlier than 8.4.27<\/td>8.4.27<\/strong><\/td><\/tr>
PHP 8.3<\/td>Earlier than 8.3.36<\/td>8.3.36<\/strong><\/td><\/tr>
PHP 8.2<\/td>Earlier than 8.2.35<\/td>8.2.35<\/strong><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

These are the minimum fixed versions for the respective upstream branches, not a recommendation to remain on an older PHP branch indefinitely.<\/p>\n\n\n\n

What about PHP 8.1 and older?<\/strong><\/p>\n\n\n\n

Older branches are also affected, but they no longer receive regular security updates directly from the PHP project. Some Linux distributions and long-term support vendors provide backported security fixes.<\/p>\n\n\n\n

A backported fix means a vendor applies a security correction to an older software branch without necessarily changing its version to the same number as the latest upstream release.<\/p>\n\n\n\n

If your hosting provider still runs PHP 8.1 or an older version, ask whether it has applied a verified fix. Where practical, move to a supported PHP branch.<\/p>\n\n\n\n

One additional consideration: PHP 8.2 is scheduled to reach end of life on December 31, 2026. Although version 8.2.35 addresses these vulnerabilities, website owners should plan their longer-term upgrade accordingly.<\/p>\n\n\n\n

The official PHP security advisory<\/a> should be treated as the primary reference for the release thresholds and vendor guidance.<\/p>\n\n\n\n

How to protect your WordPress website<\/h2>\n\n\n\n

The recommended response is to confirm which PHP runtime your website uses, apply the appropriate security update, and verify that the updated runtime is active.<\/p>\n\n\n\n

1. Check your current PHP version<\/h3>\n\n\n\n

For a WordPress website, you can begin by visiting:<\/p>\n\n\n\n

WordPress Dashboard \u2192 Tools \u2192 Site Health \u2192 Info \u2192 Server<\/strong><\/p>\n\n\n\n

Look for the PHP version information.<\/p>\n\n\n\n

You can also check the PHP version assigned to your domain in your hosting control panel. If your hosting provider manages the PHP installation, its support team can confirm whether the security fix has been installed.<\/p>\n\n\n\n

Be aware that a server may have multiple PHP versions installed. The PHP version reported by a command-line terminal is not necessarily the version handling your website’s HTTP requests.<\/p>\n\n\n\n

2. Update to a patched PHP release<\/h3>\n\n\n\n

If your site runs a vulnerable release, arrange an update to the appropriate corrected version.<\/p>\n\n\n\n

On managed WordPress hosting or shared hosting, you may need to select the PHP version through your hosting dashboard or ask your provider to update its server packages.<\/p>\n\n\n\n

On a self-managed server, the update must be applied through the relevant package manager, PHP distribution, or deployment process.<\/p>\n\n\n\n

Before making changes, check your backups and confirm that your theme and plugins support the intended PHP version. Test important functionality after updating, particularly if your website has an online store, membership system, booking system, or other business-critical features.<\/p>\n\n\n\n

Do not assume that changing a version selection in a control panel automatically updates every PHP pool, container, or domain on the server.<\/p>\n\n\n\n

3. Restart and verify the running PHP workers<\/h3>\n\n\n\n

Installing the updated package is only part of the process.<\/p>\n\n\n\n

Where applicable, restart or reload the PHP workers, rebuild and redeploy affected containers, and confirm that no old workers are continuing to handle requests.<\/p>\n\n\n\n

Verify the PHP version serving the website after the change. A successful package installation alone does not prove that the public-facing site is using the corrected runtime.<\/p>\n\n\n\n

4. Use temporary protections only as a bridge<\/h3>\n\n\n\n

What should you do if your hosting provider cannot patch PHP immediately?<\/p>\n\n\n\n

The PHP project publishes temporary mitigation guidance for both vulnerabilities. Depending on the deployment, these measures include server-level memory and request-size controls and disabling specific PHP request-processing features associated with known exploitation paths.<\/p>\n\n\n\n

For example, disabling session.upload_progress.enabled<\/code> can block certain confirmed paths associated with CVE-2026-109619. However, it does not eliminate all possible exploitation paths or fix CVE-2026-109618.<\/p>\n\n\n\n

Some additional mitigations have operational trade-offs and must be configured at the correct server level before request processing begins. They should be applied by someone who understands the hosting environment.<\/p>\n\n\n\n

Do not treat a configuration change, a firewall rule, or a smaller upload limit as a permanent fix.<\/strong> PHP explicitly states that updating to a corrected release is the only complete mitigation.<\/p>\n\n\n\n

If the server cannot be patched promptly, contact the hosting provider and consider restricting public access to affected applications until the fix is applied. Review the official PHP advisory<\/a> for the complete temporary mitigation instructions.<\/p>\n\n\n\n

5. Keep your web application firewall enabled<\/h3>\n\n\n\n

A web application firewall (WAF) can provide an additional layer of protection by blocking suspicious requests before they reach the PHP application.<\/p>\n\n\n\n

On October 21, Cloudflare announced protections against PHP2Shell for customers using its managed WAF. Cloudflare also reported observing attack traffic targeting customers before public disclosure.<\/p>\n\n\n\n

This is useful defense in depth, especially while a server update is being arranged.<\/p>\n\n\n\n

However, firewall rules can evolve as attackers change their techniques. WAF protection should therefore complement, rather than replace, a PHP security update.<\/p>\n\n\n\n

Read the Cloudflare PHP2Shell security update<\/a> for its explanation of the vulnerability and its protective measures.<\/p>\n\n\n\n

How can you tell whether a WordPress site has been compromised?<\/h2>\n\n\n\n

A vulnerable PHP version does not automatically mean that your website has been hacked. Equally, a website that appears to work normally is not necessarily free from compromise.<\/p>\n\n\n\n

During a security review, useful warning signs to investigate include:<\/p>\n\n\n\n