PHP Releases Emergency Patches for Two Critical Unauthenticated RCE Vulnerabilities

PHP Patches Two Critical Vulnerabilities: Unauthenticated Remote Code Execution Possible — Official Urges Immediate Update

The PHP project has issued an emergency announcement on its official website stating that PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35 patch two critical vulnerabilities that allow unauthenticated attackers to execute code remotely. It strongly urges all PHP users to update immediately.

Scope of Risk

The official notice states that all PHP installations that handle web requests are affected, including PHP-FPM, Apache’s mod_php, php-cgi, FrankenPHP, and LiteSpeed. Officials consider mod_php to carry the highest risk, and have demonstrated that an unauthenticated request can trigger the attack before any malicious code is executed.

The Two Vulnerabilities

The official technical causes of the two vulnerabilities are:

• CVE-2026-109618 (RCE via OOM exhaustion): Out-of-memory handling can interrupt PHP’s internal request resources when they are only partially initialized. Subsequent request cleanup may then treat invalid resources as valid.
• CVE-2026-109619 (RCE via residual global state): Request-owned internal state can continue to exist after its underlying memory has been freed. Subsequent requests handled by the same worker process may use this residual state before normal initialization resets it.

Full technical details are available in the official security advisories (GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp).

Real-World Impact: Any Website, Including WordPress, Can Be Compromised

The most critical characteristic of these two vulnerabilities is that they enable unauthenticated remote code execution. The attack occurs during PHP’s request-parsing stage — before any application code (including WordPress, Drupal, Joomla, or Magento) has even started running.

Researchers have successfully demonstrated full remote code execution against the latest versions of WordPress, Drupal, and Joomla running in containers. Even if the website application itself contains no vulnerabilities, an unpatched PHP version is enough for an attacker to take control.

Additionally, CVE-2026-109619 can also cause memory leaks. An attacker may be able to read sensitive data belonging to other requests from the same PHP worker process, including passwords, API keys, and session data. Therefore, even if an immediate update is not possible, rotating important credentials is strongly recommended.

Important reminder: Updating WordPress, themes, or plugins alone will not fix these vulnerabilities. The underlying PHP runtime itself must be updated.

How to Check Whether You Are Affected

The most direct way is to confirm the actual PHP version running on your website:

1. Create a temporary file named phpinfo.php containing <?php phpinfo(); ?>. Open it in a browser and look for the “PHP Version” value. Delete the file immediately after checking.
2. Inspect the X-Powered-By header in the HTTP response (if it is present).
3. Use online passive scanning tools (such as php2shell.xyz or the free checker provided by Brandefense). These tools can determine the version range without actively sending attack traffic.

If your version is lower than 8.2.35, 8.3.36, 8.4.27, or 8.5.12, you are within the affected range. Official binary updates are no longer available for PHP 8.1 and earlier. You should upgrade to a supported branch as soon as possible, or check with your distribution / LTS vendor for backported patches.

Local Situation in Hong Kong

Many small and medium-sized enterprises, personal websites, and shared hosting environments in Hong Kong still run PHP 7.x, 8.0, or 8.1. These versions are no longer officially supported and face particularly high risk from the PHP2Shell vulnerabilities. If local shared hosting providers have not yet applied automatic updates, administrators should proactively contact them and request an upgrade.

Recommendations for local website administrators:

• Immediately check the PHP version of all publicly accessible websites
• Prioritize servers using Apache mod_php (officially identified as the highest-risk configuration)
• If a website was publicly accessible and not updated promptly, consider rotating database passwords, API keys, and administrator account credentials
• Monitor the latest announcements from HKCERT and major hosting providers

How to Update

Official recommendations:

• Update to PHP 8.5.12, 8.4.27, 8.3.36, or 8.2.35. Source code and Windows builds are available on the official download page.
• Linux distributions and LTS vendors have received the patches in advance; check with your vendor for updated packages.
• PHP 8.1 and older versions are no longer supported with updates by the PHP project. Some distributions and LTS vendors provide backported patches — contact your vendor or upgrade to a supported version.
• Due to the severity, the PHP security team has even provided minimal source-code backports for PHP 7.4, 8.0, and 8.1 for those who build their own or cannot use LTS vendor packages.

Update Methods for Major Linux Distributions

Ubuntu / Debian

# Update package lists
sudo apt update

# Check current PHP version
php -v

# Install the latest security updates (adjust according to the PHP version in use)
sudo apt install --only-upgrade php8.2 php8.2-fpm php8.2-cli   # or php8.3 / php8.4, etc.

# Restart related services
sudo systemctl restart php8.2-fpm   # or apache2
sudo systemctl restart apache2      # if using mod_php

Reference: Ubuntu Security Notice – USN-8948-1: PHP vulnerabilities (21 Oct 2026)

Red Hat Enterprise Linux / AlmaLinux / Rocky Linux

sudo dnf update php php-fpm php-cli

# Or specify the module version (depending on system configuration)
sudo dnf module reset php
sudo dnf module enable php:8.2   # or another supported version
sudo dnf update php

sudo systemctl restart php-fpm
sudo systemctl restart httpd

Oracle Linux

Oracle Linux is highly compatible with RHEL. The update process is largely the same:

sudo dnf update php php-fpm

# Or use Oracle’s official PHP package repository (if enabled)
sudo dnf update --enablerepo=ol8_appstream php*

sudo systemctl restart php-fpm
sudo systemctl restart httpd

Always Verify After Updating

php -v
# Confirm the version is at least 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 or higher

Mitigations If Immediate Update Is Not Possible

The official statement emphasizes that only updating provides a complete solution. The following measures only reduce exposure for specific attack paths and do not make an installation secure.

For the OOM exhaustion path:

• Set memory_limit=-1, preferably in a way that cannot be overridden (e.g., via FPM pool or Apache php_admin_value settings), and ensure no pool, directory, or application configuration re-imposes a finite limit. This removes controllable PHP memory-limit failures, but underlying configuration failures may still trigger the vulnerability path.
• Set a lower post_max_size: 8M for applications that do not need core uploads, 32M for those that do, and ensure upload_max_filesize is lower than post_max_size.
• Consider enforcing limits at the web server or proxy layer on request size, number of input variables, number of multipart parts, number of headers, and nesting depth. These limits must also cover requests without a usable Content-Length.
• Use container or cgroup limits as an availability boundary, preferably configured to terminate only the affected worker process. Do not use RLIMIT_AS or RLIMIT_DATA as substitutes, as they can induce the configuration-failure path of the vulnerability.

For the residual global state path:

• Set session.upload_progress.enabled=0 and restart all worker processes. This must take effect before request parsing via php.ini, FPM pool, or server configuration; it cannot rely on ini_set() or FPM’s .user.ini. This blocks the confirmed session path but not other variants.
• On PHP 8.5, set fatal_error_backtraces=0 and restart all worker processes; this only blocks the confirmed fatal backtrace path.
• Remove invalid or deprecated settings that are used per-request and emit diagnostics before initialization. Hiding diagnostics with error_reporting, display_errors, or @ does not help.
• Fix attacker-triggerable fatal errors and execution timeouts, including those in callbacks, upload or deprecated logic, and the cleanup phase.

The official notice also states that the fourth release candidate (RC4) of PHP 8.6.0 already includes fixes for both vulnerabilities, and urges anyone using earlier 8.6.0 builds to update immediately.

Other Reports

Media reports mention that PHP indicated vendor Chainguard had early access to vulnerability details. Regarding related legal media coverage, this article does not cite those sources.

References

[1] PHP Official Website — Security Advisories and Downloads (21 October 2026)

[2] PHP Official Security Advisory — CVE-2026-109618 (GHSA-w8hw-w9fx-j79w)

[3] PHP Official Security Advisory — CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp)