---
title: PHP Releases Emergency Patches for Two Critical Unauthenticated RCE Vulnerabilities
url: https://sammy.hk/en/php2shell-patches/
author: Sammy Fung
published: 2026-10-22T10:43:52+08:00
modified: 2026-10-22T11:31:14+08:00
description: "PHP Patches Two Critical Vulnerabilities: Unauthenticated Remote Code Execution Possible — Official Urges Immediate Update The PHP project has issued an emergen…"
categories: [Uncategorized]
source: https://sammy.hk
---
**PHP Patches Two Critical Vulnerabilities: Unauthenticated Remote Code Execution Possible — Official Urges Immediate Update**

[![](https://sammy.hk/wp-content/uploads/2026/10/php2shell-sammy.hk-en-1024x572.jpg)](https://sammy.hk/wp-content/uploads/2026/10/php2shell-sammy.hk-en.jpg)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](https://www.hkcert.org/security-bulletin/php-multiple-vulnerabilities_20261022) 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](https://ubuntu.com/security/notices/USN-8948-1) (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)](https://www.php.net/index.php)

\[2\] [PHP Official Security Advisory — CVE-2026-109618 (GHSA-w8hw-w9fx-j79w)](https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w)

\[3\] [PHP Official Security Advisory — CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp)](https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp)

### 相關文章：

1. [Request for Release of Hong Kong Government Budget Data as Open Data on data.gov.hk](https://sammy.hk/en/request-for-release-of-hong-kong-government-budget-data-as-open-data-on-data-gov-hk/ "Request for Release of Hong Kong Government Budget Data as Open Data on data.gov.hk")