Critical PHP Security Advisory: Patch Urgently to Prevent Remote Memory Exploitation

The PHP security team has released emergency security updates following leaks and confirmed active exploitation in the wild. Threat intelligence providers (including Cloudflare) have detected active exploitation attempts against internet-facing servers.

Multiple memory-safety vulnerabilities allow unauthenticated attackers to corrupt internal request data and access or manipulate freed worker memory across HTTP requests—exposing sensitive credentials, API keys, and session tokens.

If you run PHP on internet-facing servers, treat this as a high-risk emergency and prioritize patching immediately.

1. How to Fix (Remediation Steps)

Update your PHP installation to one of the patched versions, restart all running PHP processes (FPM, Apache, CLI workers), and rebuild any associated container images:

PHP 8.5: Upgrade to 8.5.12 (or higher)
PHP 8.4: Upgrade to 8.4.27 (or higher)
PHP 8.3: Upgrade to 8.3.36 (or higher)
PHP 8.2: Upgrade to 8.2.35 (or higher)

Priority Target: Prioritize systems running mod_php, as the PHP security team rates this configuration at the highest risk.

Package & Environment Specifics

Official Docker Images: Ensure you pull images that are newer than php:8.2.34, php:8.4.26, or php:8.5.11 (e.g., php:8.2.35-fpm, php:8.4.27-apache, php:8.5.12-cli).
OS Packages (Debian, Ubuntu, RHEL, etc.): Check your distribution vendor for updated packages. OS vendors often backport security patches without changing the main version number—look for the relevant CVE IDs (CVE-2026-109618 and CVE-2026-109619) in your package manager changelogs.
Remi Repository: If you rely on rpms.remirepo.net, note that updates may be delayed. Switch to distribution packages or build from source if immediate patching is required.
PHP 8.1 and Older (End-of-Life): The core PHP project no longer maintains these versions. Upgrade to a supported branch immediately, check with your Linux vendor for backported packages, or apply the minimal source backports published by the PHP security team for versions 7.4, 8.0, and 8.1.

2. Temporary Mitigations (If You Cannot Patch Immediately)

These measures temporarily reduce exposure but do not make an installation completely safe. Apply all mitigations together in your central PHP configuration, then restart every PHP worker.

Set INI directives (Enforce system-wide so applications cannot override them):

session.upload_progress.enabled = 0
memory_limit = -1 (Each setting addresses a distinct vulnerability—applying only one leaves you exposed).

Filter Inbound Requests:

If multipart uploads are not required, block all multipart/form-data POST requests at your Web Application Firewall (WAF) or web server level before they reach PHP.
Set a restrictively low post_max_size setting.

3. Post-Patching: Indicators of Compromise (IoCs)

Because these vulnerabilities can expose worker memory to unauthorized reading or manipulation, inspect your systems for signs of exploitation:

HTTP Logs: Unusual multipart requests followed closely by memory-limit errors or repeated HTTP 500 status codes.
Cookies: Oversized or malformed PHPSESSID cookie values.
System Activity: Unexplained PHP worker crashes or unexpected restarts.
File Integrity: Web shells, unexpected new files, unauthorized modifications to existing .php files, or newly created admin accounts.
Network: Unexpected or unusual outbound connections originating from web worker processes.

Mandatory Post-Patch Action: Rotate all database passwords, API keys, encryption secrets, and session tokens stored or processed on internet-facing PHP systems, as worker memory contents may have been exfiltrated prior to patching.

4. Vulnerability Details & Timeline

What Happened

The PHP security team issued an advance notice on October 20 after details leaked prior to the scheduled disclosure date. Independent security researchers confirmed active exploitability, forcing the release schedule forward to October 21. Active exploitation attempts have already been observed in wild traffic by threat intelligence teams (including Cloudflare).

How the Flaws Work

Both issues stem from memory-safety flaws during out-of-memory (OOM) error handling:

CVE-2026-109618: Corrupts internal request structures, causing PHP to execute corrupted data as valid instructions or structures.
CVE-2026-109619: Allows stale request state to persist in memory after being freed, enabling subsequent HTTP requests processed by the same worker process to access or manipulate that lingering state.

For full technical advisories and GitHub Security Advisory (GHSA) details, refer to the official PHP advisory and Corelight research publications.

Update: 21 October 2026, 18:00 BST

This is no longer just a PHP patching exercise

Since the patches were released, it has become clear that the impact reaches well beyond organizations that knowingly "run PHP". The flaws sit in the PHP engine and are triggered before any application code runs, so every product, platform and service built on PHP inherits the risk. Application-level security controls, frameworks and plugins offer no protection.

Applications and platforms built on PHP

Security researchers at Wiz demonstrated unauthenticated remote code execution against the latest versions of WordPress, Drupal and Joomla. Any platform built on PHP is in scope, including Magento, WooCommerce, Shopware, and custom applications built on Laravel or Symfony. One industry estimate suggests around 18% of WordPress sites and 24% of Joomla sites run PHP 8.1 or older, which will not receive an official fix from the PHP project.

Hosting providers and control panels

Shared hosting and managed platforms are a major exposure point. cPanel is rolling out updates across its PHP 7.4 to 8.5 builds, and CloudLinux is expected to backport fixes to older versions. If a provider hosts your website or application, the patch is in their hands, not yours.

Appliances and vendor products

Many network appliances, management consoles and commercial software packages bundle their own copy of PHP. The UK NCSC has urged organizations to check appliances and third-party services that bundle PHP. Few vendors have published advisories so far, and more are expected over the coming days.

Third parties and your supply chain

Your suppliers, agencies and managed service providers may run exposed PHP systems that connect to your environment or handle your data. A compromised supplier system can become a route into your organization.

Containers and build pipelines

Container base images and CI/CD images that include PHP must be rebuilt and redeployed. Updating a running container does not update the image it was built from.

The threat landscape is moving quickly

Exploitation attempts against hosting providers were reported from early on 21 October, before patches were released.
More than 100 public repositories claiming to contain exploits appeared within hours. Some are unreliable and some may be malicious. Do not run unverified exploit or "patch" scripts.
Attackers are already changing their payloads to evade early WAF rules, and Cloudflare has expanded its protections in response.
Government bodies and major online platforms in Finland, the Netherlands and Japan took services offline as a precaution.

What we recommend now

Ask your hosting providers and managed service providers to confirm in writing that they have patched, and when.
Contact vendors of appliances and commercial software in your environment and ask whether their products bundle PHP and when fixes will ship.
Review your key suppliers, prioritizing those that host customer-facing services for you or connect to your network.
Rebuild container images that include PHP and redeploy them.
Treat end-of-life PHP (8.1 and older) as a priority. Where no fix is available, follow NCSC guidance and take the system offline or restrict access.

How ACDS Observatory can help

Observatory continuously discovers your internet-facing assets and identifies those running PHP or PHP-based platforms, including the PHP version where it is visible. For customers using third-party monitoring, the same check can be applied across your suppliers. Contact your ACDS account manager to request a report of PHP assets across your attack surface.

References

Update: 22 October 2026, 08:00 BST

Exploitation began before public disclosure

Amazon Threat Intelligence has reported that its honeypot network recorded a PHP2Shell exploitation attempt on 17 October 2026, four days before the vulnerabilities were publicly disclosed. The attempt came from a commercial anonymization network, and it is not yet known how the attacker obtained details of the flaws while they were under embargo.

Further attempts followed from 02:00 UTC on 21 October, when the first public proof-of-concept exploits appeared, and increased sharply after the patches were released. AWS now describes PHP2Shell as being broadly exploited in the wild, and Cloudflare reports that attackers are actively modifying their payloads to evade WAF rules.

At the time of writing, no successful compromises have been publicly confirmed, and neither CVE has been added to CISA's Known Exploited Vulnerabilities catalog.

What this means for you

Extend your investigation window back to 17 October. If you are reviewing internet-facing PHP systems for signs of compromise, start from 17 October rather than the disclosure date. Systems patched on 21 October may still have been targeted before the fix was applied.

Treat patching as a matter of hours, not days. Working exploits appeared within hours of the patch release. Any internet-facing PHP system that has not yet been updated should be patched, isolated or taken offline immediately.

New indicators of compromise

Search your web server logs for:

POST requests containing the string PHP_SESSION_UPLOAD_PROGRESS in multipart form uploads, particularly on endpoints that do not normally accept file uploads
Repeated HTTP 500 or 502 responses from PHP workers following multipart requests

IP addresses observed by AWS:

IP addressFirst observed103.216.220.9217 October 202631.223.184.16621 October 202637.19.200.521 October 2026134.209.159.6421 October 2026103.114.163.18821 October 202695.217.98.3721 October 2026

These addresses belong to shared anonymization infrastructure. AWS recommends using them to investigate past activity rather than blocking them outright, as legitimate traffic may share them.

Patch availability

PlatformStatusPHP 8.2 to 8.5 (php.net, Windows builds, official Docker images)Fixed: 8.5.12, 8.4.27, 8.3.36, 8.2.35Debian 12 and 13FixedUbuntu 22.04, 24.04, 26.04, 26.10Fixed (Ubuntu 20.04 via Ubuntu Pro only)Red Hat Enterprise Linux 8 (php:7.4)Fixed (RHSA-2026:87080)Red Hat Enterprise Linux 9 and 10PendingAlmaLinuxFixes rolling out ahead of RHEL; some end-of-life streams excludedAmazon Linux 2023Pending for PHP 8.2 to 8.5; no fix planned for PHP 8.1SUSE, AlpinePendingcPanel EasyApache 4Fixed in build 25.91Plesk for LinuxFixedPlesk for WindowsPendingRemi repositoryNot yet updated; use distribution packages or build from source

Patch status is changing quickly. Always confirm against your vendor's own security advisory before treating a system as fixed.

Products that depend on PHP

The Dutch National Cyber Security Centre (NCSC-NL) is maintaining an inventory of more than 600 products that depend on PHP, including hosting control panels, firewalls, NAS devices, PBX systems, webmail, CMS and e-commerce platforms. Most entries are still under vendor investigation. If you run any of these products, contact the vendor to confirm whether a fix is available.

References

‍