PHP Foundation issues unusual advance notice for security patches. Here’s what to know.
By N-able Nightscope Threat Research Team
Update 13:30 EDT:
The Adlumin MDR and Nightscope Threat Research teams have updated detection content to identify PHP framework errors and crashes that likely indicate a successful exploitation. This detection is available in the Adlumin platform under the name, “Potential PHP Session Upload Exploitation”, “Potential PHP Session Upload Exploitation”, and “Suspicious PHP Memory Exhaustion”.
Our teams have also enhanced our detection content designed to identify suspicious process execution spawning from PHP and webserver frameworks. This can be found in Adlumin under the name, “Web Server Spawning Suspicious Process”.
N-central and N-sight customers can also take advantage of custom templates for identifying vulnerable assets within your environment. Those can be found on the N-able developer portal:
- N-central monitor details can be found here
- N-sight monitor details can be found here
- N-sight Linux monitor details can be found here
Update 10:00 EDT: The PHP Foundation has published their official guidance regarding these CVEs. Excerpting from this official guidance for mitigation:
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.
Original blog post
The PHP Foundation has issued an unusual advance notice for upcoming out-of-band security releases scheduled for general availability on October 21, 2026 around 14:00 UTC (10:00 AM EDT). These releases are targeted to address CVE-2026-109618 and CVE-2026-109619, two remote code execution flaws. Industry discussion indicates that these flaws likely affect every version of PHP from 5 onwards but only PHP 8 will receive patches for this flaw while versions 5.x through 7.x will not.
Note that the PHP Foundation does reserve the right to release the fixes earlier if the vulnerability details are made public or if exploitation is identified.
There are no reports that the vulnerabilities are already being exploited in the wild as of October 20, 2026. However, in an era of rapid exploit development, vulnerabilities are increasingly exploited soon after fixes are made available.
What N-able is doing
Is developing detections for known exploit content where our telemetry allows. This will dovetail with our full suite of detection capabilities, including post-exploitation, privilege escalation, and lateral movement.
PHP exploitation attempts are usually observed as web requests. This means that web server logs, web application firewalls, and intrusion detection/prevention telemetry are the strongest place for detections. Post-exploitation behavior may take many forms, so the N-able Adlumin MDR detection teams will attempt to normalize detection content to capture the most actionable behavior and key indicators.
New detections may generate false positives early on. Detection logic may evolve as more details are discovered. There is also a chance that repeated exploit attempts will lead to these alerts being delivered for exploit attempts against fully patched web servers as automated scanners and opportunistic actors adopt exploit methodologies for these vulnerabilities.
What our partners should do
Prepare now to apply PHP Foundation official patches for affected systems as soon as they are available. This remains the most effective control. Detection is not prevention.
If a web application firewall is available, place this control in front of internet-exposed servers or applications running PHP.
Some industry authorities are recommending that organizations isolate internet-facing applications from public networks until the asset can be patched against this flaw.
PHP will also be in use by commercial applications and services within your environment beyond web servers you maintain. Follow vendor and provider guidance to ensure these receive adequate security remediation.
© N‑able Solutions ULC e N‑able Technologies Ltd. Tutti i diritti riservati.
Il presente documento viene fornito per puro scopo informativo e i suoi contenuti non vanno considerati come una consulenza legale. N‑able non rilascia alcuna garanzia, esplicita o implicita, né si assume alcuna responsabilità legale per quanto riguarda l’accuratezza, la completezza o l’utilità delle informazioni qui contenute.
N-ABLE, N-CENTRAL e gli altri marchi e loghi di N‑able sono di esclusiva proprietà di N‑able Solutions ULC e N‑able Technologies Ltd. e potrebbero essere marchi di common law, marchi registrati o in attesa di registrazione presso l’Ufficio marchi e brevetti degli Stati Uniti e di altri paesi. Tutti gli altri marchi menzionati qui sono utilizzati esclusivamente a scopi identificativi e sono marchi (o potrebbero essere marchi registrati) delle rispettive aziende.