---
title: "Security advisory: Critical remote code execution vulnerabilities, update now - Angryecho"
description: "PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix two critical vulnerabilities that can allow unauthenticated remote code execution."
canonical_url: "https://www.angryecho.com/c/php/p/P2TBBjkh0VSBvYz37Uixo"
meta:
  "og:description": "PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix two critical vulnerabilities that can allow unauthenticated remote code execution."
  "og:image": "https://www.angryecho.com/_og/d/c_Post%2Ctitle_~5ZCQ5qe9572R%2Cdescription_~5ZCQ5qe95LiA5LiL77yM5bCx5LiK5ZCQ5qe9572R44CC%2CpostId_P2TBBjkh0VSBvYz37Uixo%2Crevision_~MjAyNi0xMC0yNVQwMjo1Nzo1MC4xODM3Nzla%2Cp_Ii9jL3BocC9wL1AyVEJCamtoMFZTQnZZejM3VWl4byI%2Cs_iv1SppABBFLQen7k.png"
  "og:image:height": "630"
  "og:image:type": image/png
  "og:image:width": "1200"
  "og:title": "Security advisory: Critical remote code execution vulnerabilities, update now"
---

> Index of every page on this site: [llms.txt](https://www.angryecho.com/llms.txt)

# **Security advisory: Critical remote code execution vulnerabilities, update now**

**PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix two critical vulnerabilities that can allow unauthenticated remote code execution. All PHP users are strongly encouraged to update immediately.**

**Who is at risk:** all PHP installations serving web requests, including PHP-FPM, Apache with mod\_php, php-cgi, FrankenPHP and LiteSpeed. We consider the risk highest for mod\_php, with a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs.

**The vulnerabilities:**

- **RCE via OOM corruption**, CVE-2026-109618 ([GHSA-w8hw-w9fx-j79w](https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w)): out-of-memory handling can interrupt PHP while internal request data is only partially initialized. Request cleanup may then treat the invalid data as valid.
- **RCE via stale global state**, CVE-2026-109619 ([GHSA-6wmf-4rv5-p3rp](https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp)): request-owned internal state can survive after its backing memory has been freed. A later request handled by the same worker may use that stale state before normal initialization resets it.

**How to update:**

- Update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35. Source downloads are on our [downloads page](https://www.php.net/downloads.php?source=Y). Windows source and binaries are [on the same page](https://www.php.net/downloads.php?os=windows).
- Linux distributions and LTS vendors received the patches in advance, so check your vendor for updated packages.
- **PHP 8.1 and older** no longer receive updates from the PHP project. Some distributions and LTS vendors provide backported fixes, so contact your vendor for details, or upgrade to a supported version.
- Given the severity of these vulnerabilities, the PHP security team provided minimal source-backports for [PHP 7.4](https://github.com/php/php-src/tree/PHP-7.4-CVE-2026-109618-109619), [PHP 8.0](https://github.com/php/php-src/tree/PHP-8.0-CVE-2026-109618-109619), and [PHP 8.1](https://github.com/php/php-src/tree/PHP-8.1-CVE-2026-109618-109619) to help people building from source or without access to an LTS vendor.

**If you cannot update immediately:** while only an update is a complete solution, the following measures reduce exposure to specific attack paths but do not make an installation safe.

**RCE via OOM corruption (CVE-2026-109618):**

- Set `memory_limit=-1`, preferably in a way applications can't override, such as `php_admin_value` in the FPM pool or Apache configuration, and check that no pool, directory or application setting puts a finite limit back. This removes the controllable PHP memory limit failure, but an underlying allocation failure can still reach the vulnerable path.
- Set a low `post_max_size`. For applications that don't require file uploads, set `post_max_size = 8M`. If file uploads are necessary, set `post_max_size = 32M`. Keep `upload_max_filesize` below `post_max_size`. Consider enforcing limits at the web server or proxy level for decoded request size, input field count, multipart part count, header count, and nesting depth. These limits must also cover requests without a usable `Content-Length`.
- Use a container or cgroup limit as an availability boundary, preferably with a policy that kills only the affected worker. Do not substitute `RLIMIT_AS` or `RLIMIT_DATA`, as these can cause the vulnerable allocation failure.

**RCE via stale global state (CVE-2026-109619):**

- Set `session.upload_progress.enabled=0` and restart every worker. Use `php.ini`, an FPM pool or server configuration that applies before request parsing. Do not rely on `ini_set()` or FPM `.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 the confirmed fatal backtrace path only.
- Remove invalid or deprecated settings applied per request that emit diagnostics before initialization. Hiding diagnostics with `error_reporting`, `display_errors` or `@` does not help.
- Fix attacker-reachable fatal errors and execution timeouts, including failures in callbacks, upload or import processing and cleanup.

The advisories linked above have the full technical details.

> 原文： [PHP.net｜Security advisory: Critical remote code execution vulnerabilities, update now](https://www.php.net/archive/2026.php#2026-10-21-5)，2026-10-21

排序方式 :

### **成为第一条评论！**

Nobody's responded to this post yet. Add your thoughts and get the conversation going.

```json
{"@context":"https://schema.org","@graph":[{"@id":"https://www.angryecho.com/c/php/p/P2TBBjkh0VSBvYz37Uixo#post","@type":"DiscussionForumPosting","commentCount":0,"dateModified":"2026-10-25T02:57:50.183Z","datePublished":"2026-10-21T00:35:00.000Z","description":"PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix two critical vulnerabilities that can allow unauthenticated remote code execution.","headline":"Security advisory: Critical remote code execution vulnerabilities, update now","isPartOf":"https://www.angryecho.com/c/php","mainEntityOfPage":"https://www.angryecho.com/c/php/p/P2TBBjkh0VSBvYz37Uixo","text":"PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix two critical vulnerabilities that can allow unauthenticated remote code execution. All PHP users are strongly encouraged to update immediately.\n\nWho is at risk: all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. We consider the risk highest for mod_php, with a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs.\n\nThe vulnerabilities:\n\n\n\n\n\nRCE via OOM corruption, CVE-2026-109618 (GHSA-w8hw-w9fx-j79w): out-of-memory\nhandling can interrupt PHP while internal request data is only partially initialized. Request cleanup may then treat the invalid data as valid.\n\n\n\nRCE via stale global state, CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp): request-owned\ninternal state can survive after its backing memory has been freed. A later request handled by the same worker may use that stale state before normal initialization resets it.\n\nHow to update:\n\n\n\n\n\nUpdate to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35. Source downloads are on our downloads page. Windows source and binaries are on the same page.\n\n\n\nLinux distributions and LTS vendors received the patches in advance, so check your vendor for updated packages.\n\n\n\nPHP 8.1 and older no longer receive updates from the PHP project. Some distributions and LTS vendors provide backported fixes, so contact your vendor for details, or upgrade to a supported version.\n\n\n\nGiven the severity of these vulnerabilities, the PHP security team provided minimal source-backports for PHP 7.4, PHP 8.0, and PHP 8.1 to help people building from source or without access to an LTS vendor.\n\nIf you cannot update immediately: while only an update is a complete solution, the following measures reduce exposure to specific attack paths but do not make an installation safe.\n\nRCE via OOM corruption (CVE-2026-109618):\n\n\n\n\n\nSet memory_limit=-1, preferably in a way applications can't override, such as php_admin_value in the FPM pool or Apache configuration, and check that no pool, directory or application setting puts a finite limit back. This removes the controllable PHP memory limit failure, but an underlying allocation failure can still reach the vulnerable path.\n\n\n\nSet a low post_max_size. For applications that don't require file uploads, set post_max_size = 8M. If file uploads are necessary, set post_max_size = 32M. Keep upload_max_filesize below post_max_size.\nConsider enforcing limits at the web server or proxy level for decoded request size, input field count, multipart part count, header count, and nesting depth. These\nlimits must also cover requests without a usable Content-Length.\n\n\n\nUse a container or cgroup limit as an availability boundary, preferably with a policy that kills only the affected worker. Do not substitute RLIMIT_AS or\nRLIMIT_DATA, as these can cause the vulnerable allocation failure.\n\nRCE via stale global state (CVE-2026-109619):\n\n\n\n\n\nSet session.upload_progress.enabled=0 and restart every worker. Use php.ini, an FPM pool or server\nconfiguration that applies before request parsing. Do not rely on ini_set() or FPM .user.ini. This blocks the confirmed session paths but not other variants.\n\n\n\nOn PHP 8.5, set fatal_error_backtraces=0 and restart every worker. This blocks the confirmed fatal backtrace path only.\n\n\n\nRemove invalid or deprecated settings applied per request that emit diagnostics before initialization. Hiding diagnostics with error_reporting, display_errors\nor @ does not help.\n\n\n\nFix attacker-reachable fatal errors and execution timeouts, including failures in callbacks, upload or import processing and cleanup.\n\nThe advisories linked above have the full technical details.\n\n\n\n原文：PHP.net｜Security advisory: Critical remote code execution vulnerabilities, update now，2026-10-21","url":"https://www.angryecho.com/c/php/p/P2TBBjkh0VSBvYz37Uixo","author":{"@type":"Person","name":"UID:62402236","url":"https://www.angryecho.com/u/NGA62402236"},"interactionStatistic":[{"@type":"InteractionCounter","interactionType":"https://schema.org/LikeAction","userInteractionCount":0},{"@type":"InteractionCounter","interactionType":"https://schema.org/DislikeAction","userInteractionCount":0},{"@type":"InteractionCounter","interactionType":"https://schema.org/ViewAction","userInteractionCount":0},{"@type":"InteractionCounter","interactionType":"https://schema.org/ShareAction","userInteractionCount":0}]}]}
```

## Sitemap

See the full [sitemap](https://www.angryecho.com/sitemap.md) for all pages.