Blog Security Advisory: Critical PHP RCE Vulnerabilities Under Investigation
Published October 21, 2026
Severity: Critical
Classification: Potential Remote Code Execution / Web Application Platform Vulnerability
Affected platform: PHP web applications and servers running potentially vulnerable PHP versions
TLP: CLEAR
Executive Summary
Ontinue Cyber Defense is aware of two critical PHP vulnerabilities publicly referenced as CVE-2026-109618 and CVE-2026-109619. The PHP project has officially announced two critical vulnerabilities rated CVSS v4.0 9.2, with a security release scheduled for 21 October 2026 at 14:00 UTC / 15:00 BST. At the time of publication, the PHP project has not publicly associated the announced vulnerabilities with these CVE identifiers.
Third-party reporting describes the vulnerabilities as potentially enabling unauthenticated remote code execution. However, official technical details, affected versions, fixed versions, exploitation prerequisites, and root-cause information have not yet been published.
At this time, Ontinue is actively investigating the vulnerabilities, reviewing available technical details, and conducting threat hunting across relevant customer telemetry. If evidence of exploitation is identified in a customer environment, Ontinue will follow our standard incident notification and escalation process through the ION portal.
Customers operating internet-facing PHP applications should treat this as a high-priority exposure and begin validating where PHP is deployed across their environment.
What We Know
Officially confirmed: The PHP project has announced a security release for 21 October 2026 at 14:00 UTC / 15:00 BST to address two critical vulnerabilities, both rated CVSS v4.0 9.2.
CVE identifiers: CVE-2026-109618 and CVE-2026-109619 have been publicly referenced, but appear to come from leaked or pre-release information and are not yet officially confirmed by PHP.
Details pending: PHP has not yet published affected versions, fixed versions, root-cause information, or official technical details.
Public reporting: Third-party sources describe a potential unauthenticated remote code execution risk, possibly involving multipart requests and PHP session upload-progress handling.
Observed PoC activity: Circulating code uses crafted multipart POST requests, oversized filename fields, a fixed PHPSESSID, and a two-request pattern.
Exposure may vary: Risk will depend on PHP version, runtime configuration, application exposure, and whether attackers can send crafted requests to affected PHP endpoints.
How It Works
Circulating proof-of-concept code purportedly associated with these vulnerabilities appears to exercise PHP’s handling of multipart form uploads in combination with session upload-progress tracking. PHP includes functionality that can track upload progress by writing upload metadata into the active session while a file upload is being processed.
The proof of concept uses a two-request pattern:
A first multipart POST request sends multiple file parts containing extremely large filename values while setting the PHP_SESSION_UPLOAD_PROGRESS field and a fixed PHPSESSID cookie.
A second multipart POST request reuses the same session identifier with a smaller upload, apparently intended to trigger processing of the previously written session upload progress data.
This behaviour appears designed to trigger abnormal processing of attacker-controlled upload and session data. However, Ontinue has not independently confirmed that the circulating code successfully triggers either reported vulnerability. The underlying vulnerability class and the mechanism by which code execution may be achieved have not yet been officially disclosed. The code reviewed by Ontinue does not include a complete weaponised payload, but it remains relevant for defensive review and threat hunting while official vendor guidance is pending.
Am I Affected?
Potentially exposed environments may include PHP-based content management systems, e-commerce platforms, custom web applications, and similar services. Inclusion in these categories does not indicate that exploitation against a specific product has been confirmed. Exposure will depend on the underlying PHP version, configuration, and deployment architecture.
Content management systems such as WordPress, Drupal, Joomla, Magento, or similar platforms.
Custom PHP applications that accept multipart form submissions or file uploads.
Public web servers running PHP-FPM, Apache with mod_php, NGINX with PHP-FPM, or containerised PHP workloads.
Applications where PHP sessions are enabled and upload progress functionality is available.
Customers should identify externally exposed PHP services and confirm the deployed PHP versions and runtime configuration. Particular attention should be given to systems where session.upload_progress.enabled is enabled and where attackers can send crafted multipart requests to PHP endpoints.
Ontinue Response
Our current response includes:
Reviewing publicly available technical details and proof-of-concept material.
Assessing potential exploitation paths and customer exposure scenarios.
Conducting threat hunting across relevant customer telemetry for suspicious web activity and exploitation indicators.
Monitoring for additional vendor guidance, confirmed affected versions, patches, and indicators of compromise.
Developing detection and triage logic as reliable technical details and indicators become available.
If Ontinue identifies suspicious or confirmed exploitation activity in a customer environment, we will raise and manage the incident through the ION portal in line with our standard process.
Recommended Customer Actions
Ontinue recommends customers take the following actions as a priority:
Inventory PHP exposure: Identify all internet-facing and internal systems running PHP, including cloud-hosted, containerised, and third-party managed applications.
Monitor vendor guidance: Track official PHP project advisories and distribution-specific updates for confirmed affected versions and patches.
Apply patches promptly: Once vendor patches are released and validated, prioritise updates for internet-facing PHP workloads.
Consider temporary precautionary controls: Subject to testing and official vendor guidance, review whether session.upload_progress.enabled can be disabled or restricted. Community guidance also recommends enabling strict session handling where feasible; these measures should be treated as risk-reduction steps and are not guaranteed to prevent exploitation.
Restrict exposed services where necessary: If timely patching is not possible, consider temporarily restricting public access to affected PHP services, applying allow-listing or network-level access controls, or isolating the service until official fixes can be deployed.
