Critical PHP Vulnerabilities (CVE-2026-109618 & CVE-2026-109619)

October 21, 2026 4 min read

Table of Contents

What is the risk?
What are we doing?
How to mitigate the threat
References & official advisories

On October 20, 2026, the PHP security team issued an advance security advisory regarding two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, affecting core PHP source code. Both vulnerabilities carry a critical-severity CVSS v4.0 score of 9.2 and could potentially allow unauthenticated remote code execution (RCE) on affected servers.

The official patched PHP releases are now available. Given the potential impact across web applications, content management systems (CMS), and microservices running PHP, Detectify recommends immediate asset discovery and patching.

What is the risk?

While specific technical implementation details remain under embargo, early advisories indicate:

Unauthenticated Remote Code Execution (RCE): Both vulnerabilities allow remote attackers to execute arbitrary code on the underlying host operating system without prior authentication.
Broad impact: Security advisories highlight that these flaws potentially affect all supported release branches and legacy environments (including PHP 5.x through 8.x).
High attractiveness to attackers: Because PHP powers a vast majority of the public web, including platforms like WordPress, Drupal, Magento, and custom Laravel/Symfony applications, public exploit payloads are expected to follow shortly after official technical details are disclosed.

What are we doing?

The Detectify Security Research team is actively monitoring the situation:

Assessment rollout: We are actively investigating the development of in-house automated detection assessments for our scanning engines to identify exposed, vulnerable PHP runtimes across customers’ attack surfaces without impacting service availability.
Asset discovery: Detectify’s Surface Monitoring continuously maps internet-facing assets running PHP web applications, helping security teams locate shadow or legacy PHP workloads.

How to mitigate the threat

IMPORTANT NOTICE: The temporary measures and configuration adjustments listed below only reduce exposure surface vectors. Only applying the official PHP patch or upgrading to a secure version will mitigate these vulnerabilities.

To ensure your organization remains protected, we recommend taking the following steps immediately:

1. Upgrade your PHP installation: Upgrade your environment to the latest patched version for your respective branch:

PHP 8.2: Upgrade to 8.2.35
PHP 8.3: Upgrade to 8.3.36
PHP 8.4: Upgrade to 8.4.27
PHP 8.5: Upgrade to 8.5.12

Note on legacy/EOL releases: Given the severity of these vulnerabilities, the PHP security team has provided minimal source-backports for PHP 7.4, PHP 8.0, and PHP 8.1 to assist teams building directly from source or operating without access to an LTS vendor. Otherwise, organizations running End-of-Life (EOL) versions should look for distribution backports (e.g., from OS vendors like Ubuntu or RHEL) or migrate immediately to supported 8.x branches.

2. Temporary Exposure Minimization Measures: If immediate upgrading is delayed, apply the following hardening steps to reduce risk vectors across vulnerable runtimes:

A. Mitigating RCE via OOM Corruption (CVE-2026-109618)

Set unlimited memory limits: Set memory_limit=-1 via administrative configuration (e.g., php_admin_value in FPM pools or Apache config) so applications cannot override it. Confirm that no downstream pool, directory, or application settings re-impose a finite limit. Note: This prevents user-controllable PHP memory limit failures, though system-level allocation failures can still hit the vulnerable path.
Restrict request payloads: Lower post_max_size (e.g., 8M for non-upload applications, 32M if uploads are required). Ensure upload_max_filesize remains strictly below post_max_size. Enforce limits at the web server or proxy layer for decoded request sizes, input field counts, multipart part counts, header counts, and nesting depth—including requests lacking a usable Content-Length.
Enforce availability boundaries: Use container or cgroup limits with policies designed to kill only the affected worker. Avoid relying on RLIMIT_AS or RLIMIT_DATA, as these can directly trigger the vulnerable allocation failure.

B. Mitigating RCE via Stale Global State (CVE-2026-109619)

Disable Session Upload Progress: Set session.upload_progress.enabled=0 via global php.ini, FPM pool, or server configurations applied prior to request parsing (do not rely on ini_set() or .user.ini). Restart all workers afterwards.
Disable backtraces (PHP 8.5): If running PHP 8.5, set fatal_error_backtraces=0 and restart workers to disable the confirmed fatal backtrace path.
Clean up diagnostics & configuration: Remove invalid or deprecated per-request settings that generate diagnostic output before initialization completes. (Hiding outputs using error_reporting, display_errors, or @ does not prevent the vulnerability).
Address fatal triggers: Resolve reachable fatal errors and execution timeouts, including failure points in callbacks, file uploads, import processing, or cleanup logic.

3. Inventory internet-facing assets: Use Detectify to run an asset discovery scan to identify all exposed HTTP service endpoints and web applications running on PHP.

4. Deploy patches across pipelines: Ensure application owners and infrastructure operators pull updated PHP packages from upstream package managers (Debian, Ubuntu, RHEL, Docker Hub, etc.).

5. Isolate high-risk services: If immediate patching is not possible, temporarily isolate vulnerable application servers behind access-controlled gateways or Web Application Firewalls (WAFs) with strict filtering enabled.