URGENT ADVISORY: Update PHP NOW

The PHP development team and third-party security researchers have alerted the community to two critical Remote Code Execution (RCE) vulnerabilities affecting PHP environments.

Due to a public leak of details prior to the embargo date, the disclosure timeline has been accelerated. System administrators are strongly advised to prepare patch pipelines immediately to deploy incoming fixes as soon as they drop.
If you run web infrastructure powering WordPress, Drupal, Magento, or custom web applications, drop what you're doing and check your patching pipelines.

The PHP core development team has issued an urgent advance notice announcing emergency security updates set to drop on Wednesday, October 21, at 14:00 UTC (10:00 AM EDT). The emergency release addresses two critical vulnerabilities, officially rated CVSS v4.0 9.2 following a public embargo leak that forced maintainers to accelerate their release timeline. Here is what went down behind the scenes, why the timeline moved up, and what your engineering team must do before the patches land. Under standard coordinated vulnerability disclosure, maintainers work privately with security firms and OS package maintainers to test fixes before releasing them publicly.

However, earlier today, details regarding the two vulnerabilities began leaking online: 

The Forum Leak: A post appeared on Y Combinator’s Hacker News forum from a user claiming that two critical PHP Remote Code Execution (RCE) flaws carrying a CVSS score of 10.0 were set to be disclosed on Thursday.

Confirmation from Researchers: Cybersecurity firm watchTowr confirmed via social media that the vulnerabilities, tracked as CVE-2026-109618 and CVE-2026-109619 are real core RCE bugs, noting that technical details had leaked ahead of the planned embargo window.

The Official PHP Team Response: Rather than holding out until Thursday, the PHP team advanced their release date to Wednesday morning. They explicitly warned:

"We reserve the right to release earlier should details of either vulnerability become public, or should evidence of active exploitation appear in the wild."

Why the Window for Action Is Extremely Short

Once an open-source project publishes a patch, threat actors immediately run git diff on the repository source code to identify what changed. With modern AI tools and automated exploit frameworks, researchers estimate that a functional weaponized exploit could be written within hours or even minutes of the source patch going live.

Immediate Action Items for IT & Security Teams

To ensure your web applications remain protected, take these steps immediately:

1. Inventory All Running Workloads: Identify every server, container, and shared host running PHP in your infrastructure. Determine whether you install PHP via distribution packages (apt, dnf), official Docker images, or custom builds.
2. Flag Legacy PHP Versions: Isolate any systems running PHP 5.x or 7.x. Plan an immediate migration strategy to a supported PHP 8 release, as legacy versions will not receive official patches.
3. Prepare Staging Environments: Ensure your automated test suites and deployment pipelines are ready to accept incoming package updates so you can deploy to production as soon as tests pass.
4. Subscribe to Updates: Monitor the official PHP ANNOUNCE Mailing List and distro-specific security advisories (Ubuntu, Debian, RHEL, Alpine) for backported package releases.

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.