What you need to know about PHP2shell. Critical vulnerabilities in PHP (CVE-2026-109618, CVE-2026-109619)

Summary

# What you need to know about PHP2shell. Critical vulnerabilities in PHP (CVE-2026-109618, CVE-2026-109619) Written by Willem Delbare Published on: Oct 21, 2026 **Update, 15:00 CEST: Patches are...

Published: 2026-10-21 00:00
Collected: 2026-10-21 07:00

📦 Full-Text Content Snapshot

R2 Archive · Full Article Preserved165 lines · 12.0 KB

📄 Raw .md ⬇️ Download .md

Written by Willem Delbare · Published: Oct 21, 2026 · Updated: Oct 23, 2026 · Source: aikido.dev

PHP2Shell is the name for two critical remote code execution (RCE) vulnerabilities in PHP itself, CVE-2026-109618 and CVE-2026-109619. Both score 9.2 on the Common Vulnerability Scoring System (CVSS) v4.0, and either one can let an unauthenticated attacker run code on a server that handles PHP requests. Cloudflare reports that exploitation has started.

PHP released fixes on October 21 in versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35. If you run PHP anywhere in your stack, update now. If you deploy PHP in containers, Aikido publishes free patched PHP images that keep you on your current PHP version and backport the fixes.

How to fix PHP2Shell

Update PHP to a fixed version

Updating is the only complete fix. Update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, then restart every PHP process and rebuild any container images. Patching only a running container leaves the image exposed.

After you update, keep session.upload_progress.enabled=0. It’s a rarely used legacy feature, and it’s one confirmed way into CVE-2026-109619, so leaving it off removes that path even on a patched system. Set it in php.ini, a PHP-FPM pool or server configuration that applies before request parsing, then restart every worker.

Use patched Aikido Images

Patched Aikido Images are free on the Aikido public Amazon Elastic Container Registry (ECR). Pick your branch in the table below, then pull the latest patch in the variant you use, for example public.ecr.aws/aikido-dev/php:8.5.12-fpm. The base variant is the plain tag, such as php:8.2.35.

Where upstream has no fix, Aikido Images backport the fixes into the version you already run, so the tag keeps its version number.

Release line	Latest version in release line	Variants available
5.5	5.5.38	apache, cli, fpm
5.6	5.6.40	base, apache, cli, fpm
7.0	7.0.33	base, apache, cli, fpm
7.1	7.1.33	base, apache, cli, fpm
7.2	7.2.34	base, apache, cli, fpm
7.3	7.3.33	base, apache, cli, fpm, cli-bullseye
7.4	7.4.33	base, apache, cli, fpm
8.2	8.2.35	base, apache, fpm, alpine3.24, cli-alpine3.24, fpm-alpine3.24
8.3	8.3.36	apache, cli
8.4	8.4.27	base, apache, cli, fpm, trixie, fpm-trixie, alpine3.23, alpine3.24, fpm-alpine3.23, fpm-alpine3.24
8.5	8.5.12	base, apache, cli, fpm, trixie, fpm-trixie, alpine3.23, alpine3.24, cli-alpine3.23, cli-alpine3.24, fpm-alpine3.23, fpm-alpine3.24

Further images are being prepared. Until yours is available, update to the fixed PHP version directly.

Update through your operating system or vendor

Linux distributions and long-term support (LTS) vendors received the patches in advance, so check your vendor for updated packages. Vendors often backport fixes without changing the version number, so look for the CVE IDs in the package changelog (commands below).

PHP’s advisory noted that the volunteer-maintained Remi repository (rpms.remirepo.net) would not have updates on release day. Check its current status, or switch to distribution packages or build from source.

If you run PHP 8.1 or older

The PHP project no longer provides updates for these versions. Upgrade to a supported version or ask your vendor for a backported fix. PHP’s security team has also published minimal source backports for 7.4, 8.0 and 8.1 for teams that build from source. Aikido Images cover the 7.x series and PHP 5.5 and 5.6 (see the table above).

PHP 8.2 reaches end of life on December 31, 2026, so plan your move to a supported branch.

How to verify your PHP installation is patched

Confirm that the runtime serving web requests is the patched one:

Check your public URL. Aikido’s free PHP2Shell checker reports whether the site is vulnerable, mitigated or patched.
Find every PHP installation. Include parallel PHP branches, containers, CI/CD images, hosting panels such as cPanel and Plesk, and PHP bundled inside vendor software or Windows php.exe and php-cgi.exe binaries.
Don’t trust php -v alone. It reports the command-line binary, which can differ from the PHP-FPM pool or Apache module serving your site.
Check the vendor changelog for the CVE IDs. Replace the package name with yours:

Debian or Ubuntu:

bash

apt changelog php8.3-cli | grep -E "CVE-2026-109618|CVE-2026-109619"

RHEL, Rocky Linux or AlmaLinux:

bash

rpm -q php-cli --changelog | grep -E "CVE-2026-109618|CVE-2026-109619"

Restart or replace every worker. Restart PHP-FPM, Apache and any application workers, or redeploy containers, then confirm no worker is still running the old build.
Aikido Images: Use the latest patch listed in the table for your branch.
Restore emergency settings, but keep upload progress off. If you applied temporary mitigations, restore a finite memory_limit and review any upload limits once the patched runtime is confirmed. Leave session.upload_progress.enabled=0 in place.

If you can’t update immediately

These measures reduce exposure to specific attack paths. They do not make an installation safe, and each one covers a single vulnerability:

For CVE-2026-109618:

Set memory_limit=-1 in a way applications can’t override, such as php_admin_value in the PHP-FPM pool or Apache configuration, then confirm no pool, directory or application setting restores a finite limit. This removes the memory-limit failure an attacker can control, but an underlying allocation failure can still reach the vulnerable code, and with no cap a runaway request can exhaust the server.
Set a low post_max_size: 8M if your application doesn’t need file uploads, 32M if it does. Keep upload_max_filesize below it. Also enforce request size, field count, multipart part count, header count and nesting limits at the web server or proxy, including for requests without a usable Content-Length.
Use a container or cgroup memory limit as an availability boundary, ideally one that kills only the affected worker. Don’t use RLIMIT_AS or RLIMIT_DATA, which can trigger the vulnerable allocation failure.

For CVE-2026-109619:

Set session.upload_progress.enabled=0 in php.ini, a PHP-FPM pool or server configuration that applies before request parsing, then restart every worker. Don’t rely on ini_set() or .user.ini. This blocks the confirmed session paths but not other variants.
On PHP 8.5, set fatal_error_backtraces=0 and restart every worker. This blocks only the confirmed fatal-error backtrace path.
Remove invalid or deprecated per-request settings that emit diagnostics before initialization. Hiding messages with error_reporting, display_errors or @ doesn’t help.
Fix fatal errors and execution timeouts that an attacker can trigger, including failures in callbacks, upload or import processing and cleanup.

If your application doesn’t use multipart uploads, block multipart/form-data POST requests before they reach PHP.

After you patch: check for compromise

Look for unusual multipart requests followed by memory-limit errors or repeated HTTP 500 responses, and for oversized or malformed PHPSESSID cookies in responses. Then check for web shells, unexpected files, new admin users, modified PHP files, unexpected child processes spawned by PHP or your web server, and odd outbound connections.

Code execution gives an attacker everything the PHP process can read, including database credentials and API keys. If you suspect a compromise, rotate those on the affected systems.

What is PHP2Shell

PHP2Shell covers two memory-safety vulnerabilities in how PHP handles failures while processing a request, in particular running out of memory. The flaws sit in PHP’s runtime, so your application code can be sound and the server still vulnerable. PHP reports a demonstrated exploit against Apache with mod_php where an unauthenticated request triggers the attack before any application code runs.

Which PHP versions are affected by PHP2Shell?

Treat every unpatched PHP version as affected. PHP identifies any installation that serves web requests as at risk, including PHP-FPM (FastCGI Process Manager), Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. It rates the risk highest for mod_php, so patch those first, followed by any other internet-facing PHP.

PHP branch	Affected versions	Fixed in	Aikido patched image	Notes
8.5	Every release before 8.5.12	8.5.12	Available
8.4	Every release before 8.4.27	8.4.27	Available
8.3	Every release before 8.3.36	8.3.36	Available
8.2	Every release before 8.2.35	8.2.35	Available	End of life December 31, 2026
8.1 and 8.0	Treat all as affected	No upstream fix	In progress	Minimal source backports exist. Ask your vendor.
7.4	Treat all as affected	No upstream fix	Available	Minimal source backport exists.
7.0 to 7.3	Treat all as affected	No upstream fix	Available	Ask your vendor for a backported fix.
5.5 and 5.6	Treat all as affected	No upstream fix	Available	Ask your vendor for a backported fix.

CVE-2026-109618: PHP out-of-memory corruption

When an out-of-memory error interrupts PHP while it is setting up request data, that data is left partially initialized. PHP’s request cleanup then treats the invalid data as valid, which creates a path to remote code execution without authentication. PHP tracks this one as GitHub Security Advisory GHSA-w8hw-w9fx-j79w.

The temporary measures that reduce exposure are limits on memory and request size, listed above.

CVE-2026-109619: PHP stale global state

PHP keeps request-owned internal state alive after the memory behind it has been freed. A later request handled by the same worker can use that stale state before PHP’s normal initialization resets it. PHP tracks this one as GHSA-6wmf-4rv5-p3rp.

PHP’s session upload progress feature, which is enabled by default, is one confirmed path to this flaw. On PHP 8.5, fatal-error backtraces are another. Disabling those two features blocks only the confirmed paths.

PHP2Shell disclosure and update timeline

October 20, 2026: The PHP security team publishes an advance notice after details of the vulnerabilities leak ahead of the planned disclosure date.
October 21, 2026: Independent researchers confirm the flaws are real, and PHP releases 8.5.12, 8.4.27, 8.3.36 and 8.2.35 ahead of its original schedule.
October 21, 2026: Cloudflare reports that exploitation in the wild has started.

📦 Full-Text Markdown Snapshot archived by Phying News · Original source: aikido.dev

---
id: 10169
canonical_url: "https://phying.com/item/10169"
title: "What you need to know about PHP2shell. Critical vulnerabilities in PHP (CVE-2026-109618, CVE-2026-109619)"
type: "vulnerability"
cve: "CVE-2026-109618, CVE-2026-109619"
cvss: 9.2
severity: "critical"
vendor: "PHP Group"
product: "PHP"
affected_versions: "PHP < 8.2.35, < 8.3.36, < 8.4.27, < 8.5.12"
source_domain: "aikido.dev"
source_url: "https://www.aikido.dev/blog/critical-vulnerabilities-in-php-php2shell"
published_at: "2026-10-21T00:00:00Z"
snapshot_at: "2026-10-26T05:52:00Z"
archived_by: "Phying News (https://phying.com/item/10169)"
lang: "en"
---

# PHP2Shell: Critical PHP vulnerabilities, affected versions and fixes

*Written by Willem Delbare · Published: Oct 21, 2026 · Updated: Oct 23, 2026 · Source: [aikido.dev](https://www.aikido.dev/blog/critical-vulnerabilities-in-php-php2shell)*

**PHP2Shell** is the name for two critical remote code execution (RCE) vulnerabilities in PHP itself, **CVE-2026-109618** and **CVE-2026-109619**. Both score **9.2** on the Common Vulnerability Scoring System (CVSS) v4.0, and either one can let an unauthenticated attacker run code on a server that handles PHP requests. [Cloudflare reports that exploitation has started](https://x.com/dok2001/status/2112811965735202970).

[PHP released fixes on October 21](https://www.php.net/archive/2026.php#2026-10-21-5) in versions **8.5.12, 8.4.27, 8.3.36 and 8.2.35**. If you run PHP anywhere in your stack, update now. If you deploy PHP in containers, Aikido publishes free patched PHP images that keep you on your current PHP version and backport the fixes.

---

## How to fix PHP2Shell

### Update PHP to a fixed version

Updating is the only complete fix. Update to **PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35**, then restart every PHP process and rebuild any container images. Patching only a running container leaves the image exposed.

After you update, keep `session.upload_progress.enabled=0`. It’s a rarely used legacy feature, and it’s one confirmed way into CVE-2026-109619, so leaving it off removes that path even on a patched system. Set it in `php.ini`, a PHP-FPM pool or server configuration that applies before request parsing, then restart every worker.

### Use patched Aikido Images

Patched [Aikido Images](https://help.aikido.dev/autofix-and-remediation/aikido-images) are free on the [Aikido public Amazon Elastic Container Registry (ECR)](https://gallery.ecr.aws/aikido-dev/php). Pick your branch in the table below, then pull the latest patch in the variant you use, for example `public.ecr.aws/aikido-dev/php:8.5.12-fpm`. The base variant is the plain tag, such as `php:8.2.35`.

Where upstream has no fix, Aikido Images backport the fixes into the version you already run, so the tag keeps its version number.

| Release line | Latest version in release line | Variants available |
| :--- | :--- | :--- |
| **5.5** | 5.5.38 | apache, cli, fpm |
| **5.6** | 5.6.40 | base, apache, cli, fpm |
| **7.0** | 7.0.33 | base, apache, cli, fpm |
| **7.1** | 7.1.33 | base, apache, cli, fpm |
| **7.2** | 7.2.34 | base, apache, cli, fpm |
| **7.3** | 7.3.33 | base, apache, cli, fpm, cli-bullseye |
| **7.4** | 7.4.33 | base, apache, cli, fpm |
| **8.2** | 8.2.35 | base, apache, fpm, alpine3.24, cli-alpine3.24, fpm-alpine3.24 |
| **8.3** | 8.3.36 | apache, cli |
| **8.4** | 8.4.27 | base, apache, cli, fpm, trixie, fpm-trixie, alpine3.23, alpine3.24, fpm-alpine3.23, fpm-alpine3.24 |
| **8.5** | 8.5.12 | base, apache, cli, fpm, trixie, fpm-trixie, alpine3.23, alpine3.24, cli-alpine3.23, cli-alpine3.24, fpm-alpine3.23, fpm-alpine3.24 |

Further images are being prepared. Until yours is available, update to the fixed PHP version directly.

### Update through your operating system or vendor

Linux distributions and long-term support (LTS) vendors received the patches in advance, so check your vendor for updated packages. Vendors often backport fixes without changing the version number, so look for the CVE IDs in the package changelog (commands below).

PHP’s advisory noted that the volunteer-maintained Remi repository (`rpms.remirepo.net`) would not have updates on release day. Check its current status, or switch to distribution packages or build from source.

### If you run PHP 8.1 or older

The PHP project no longer provides updates for these versions. Upgrade to a supported version or ask your vendor for a backported fix. PHP’s security team has also published minimal source backports for 7.4, 8.0 and 8.1 for teams that build from source. Aikido Images cover the 7.x series and PHP 5.5 and 5.6 (see the table above).

PHP 8.2 reaches end of life on December 31, 2026, so plan your move to a supported branch.

### How to verify your PHP installation is patched

Confirm that the runtime serving web requests is the patched one:

1. **Check your public URL.** Aikido’s [free PHP2Shell checker](https://php2shell.aikido.io/?utm_source=blog&utm_medium=how_to_fix_link&utm_campaign=php2shell) reports whether the site is vulnerable, mitigated or patched.
2. **Find every PHP installation.** Include parallel PHP branches, containers, CI/CD images, hosting panels such as cPanel and Plesk, and PHP bundled inside vendor software or Windows `php.exe` and `php-cgi.exe` binaries.
3. **Don’t trust `php -v` alone.** It reports the command-line binary, which can differ from the PHP-FPM pool or Apache module serving your site.
4. **Check the vendor changelog for the CVE IDs.** Replace the package name with yours:

Debian or Ubuntu:
```bash
apt changelog php8.3-cli | grep -E "CVE-2026-109618|CVE-2026-109619"
```

RHEL, Rocky Linux or AlmaLinux:
```bash
rpm -q php-cli --changelog | grep -E "CVE-2026-109618|CVE-2026-109619"
```

5. **Restart or replace every worker.** Restart PHP-FPM, Apache and any application workers, or redeploy containers, then confirm no worker is still running the old build.
6. **Aikido Images:** Use the latest patch listed in the table for your branch.
7. **Restore emergency settings, but keep upload progress off.** If you applied temporary mitigations, restore a finite `memory_limit` and review any upload limits once the patched runtime is confirmed. Leave `session.upload_progress.enabled=0` in place.

### If you can’t update immediately

These measures reduce exposure to specific attack paths. They do not make an installation safe, and each one covers a single vulnerability:

**For CVE-2026-109618:**
- Set `memory_limit=-1` in a way applications can’t override, such as `php_admin_value` in the PHP-FPM pool or Apache configuration, then confirm no pool, directory or application setting restores a finite limit. This removes the memory-limit failure an attacker can control, but an underlying allocation failure can still reach the vulnerable code, and with no cap a runaway request can exhaust the server.
- Set a low `post_max_size`: 8M if your application doesn’t need file uploads, 32M if it does. Keep `upload_max_filesize` below it. Also enforce request size, field count, multipart part count, header count and nesting limits at the web server or proxy, including for requests without a usable `Content-Length`.
- Use a container or cgroup memory limit as an availability boundary, ideally one that kills only the affected worker. Don’t use `RLIMIT_AS` or `RLIMIT_DATA`, which can trigger the vulnerable allocation failure.

**For CVE-2026-109619:**
- Set `session.upload_progress.enabled=0` in `php.ini`, a PHP-FPM pool or server configuration that applies before request parsing, then restart every worker. Don’t rely on `ini_set()` or `.user.ini`. This blocks the confirmed session paths but not other variants.
- On PHP 8.5, set `fatal_error_backtraces=0` and restart every worker. This blocks only the confirmed fatal-error backtrace path.
- Remove invalid or deprecated per-request settings that emit diagnostics before initialization. Hiding messages with `error_reporting`, `display_errors` or `@` doesn’t help.
- Fix fatal errors and execution timeouts that an attacker can trigger, including failures in callbacks, upload or import processing and cleanup.

If your application doesn’t use multipart uploads, block `multipart/form-data` POST requests before they reach PHP.

### After you patch: check for compromise

Look for unusual multipart requests followed by memory-limit errors or repeated HTTP 500 responses, and for oversized or malformed `PHPSESSID` cookies in responses. Then check for web shells, unexpected files, new admin users, modified PHP files, unexpected child processes spawned by PHP or your web server, and odd outbound connections.

Code execution gives an attacker everything the PHP process can read, including database credentials and API keys. If you suspect a compromise, rotate those on the affected systems.

---

## What is PHP2Shell

PHP2Shell covers two memory-safety vulnerabilities in how PHP handles failures while processing a request, in particular running out of memory. The flaws sit in PHP’s runtime, so your application code can be sound and the server still vulnerable. PHP reports a demonstrated exploit against Apache with `mod_php` where an unauthenticated request triggers the attack before any application code runs.

### Which PHP versions are affected by PHP2Shell?

Treat every unpatched PHP version as affected. PHP identifies any installation that serves web requests as at risk, including PHP-FPM (FastCGI Process Manager), Apache with `mod_php`, `php-cgi`, FrankenPHP and LiteSpeed. It rates the risk highest for `mod_php`, so patch those first, followed by any other internet-facing PHP.

| PHP branch | Affected versions | Fixed in | Aikido patched image | Notes |
| :--- | :--- | :--- | :--- | :--- |
| **8.5** | Every release before 8.5.12 | 8.5.12 | Available | |
| **8.4** | Every release before 8.4.27 | 8.4.27 | Available | |
| **8.3** | Every release before 8.3.36 | 8.3.36 | Available | |
| **8.2** | Every release before 8.2.35 | 8.2.35 | Available | End of life December 31, 2026 |
| **8.1 and 8.0** | Treat all as affected | No upstream fix | In progress | Minimal source backports exist. Ask your vendor. |
| **7.4** | Treat all as affected | No upstream fix | Available | Minimal source backport exists. |
| **7.0 to 7.3** | Treat all as affected | No upstream fix | Available | Ask your vendor for a backported fix. |
| **5.5 and 5.6** | Treat all as affected | No upstream fix | Available | Ask your vendor for a backported fix. |

---

### CVE-2026-109618: PHP out-of-memory corruption

When an out-of-memory error interrupts PHP while it is setting up request data, that data is left partially initialized. PHP’s request cleanup then treats the invalid data as valid, which creates a path to remote code execution without authentication. PHP tracks this one as GitHub Security Advisory [GHSA-w8hw-w9fx-j79w](https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w).

The temporary measures that reduce exposure are limits on memory and request size, listed above.

---

### CVE-2026-109619: PHP stale global state

PHP keeps request-owned internal state alive after the memory behind it has been freed. A later request handled by the same worker can use that stale state before PHP’s normal initialization resets it. PHP tracks this one as [GHSA-6wmf-4rv5-p3rp](https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp).

PHP’s session upload progress feature, which is enabled by default, is one confirmed path to this flaw. On PHP 8.5, fatal-error backtraces are another. Disabling those two features blocks only the confirmed paths.

---

### PHP2Shell disclosure and update timeline

- **October 20, 2026:** The PHP security team publishes an advance notice after details of the vulnerabilities leak ahead of the planned disclosure date.
- **October 21, 2026:** Independent researchers confirm the flaws are real, and PHP releases 8.5.12, 8.4.27, 8.3.36 and 8.2.35 ahead of its original schedule.
- **October 21, 2026:** Cloudflare reports that exploitation in the wild has started.

---
> 📦 **Full-Text Markdown Snapshot** archived by [Phying News](https://phying.com/item/10169) · Original source: [aikido.dev](https://www.aikido.dev/blog/critical-vulnerabilities-in-php-php2shell)

Back