PHP vulnerabilities

Critical PHP vulnerabilities: latest Control Risks updates

This page provides the latest information and guidance on the critical PHP vulnerabilities affecting websites and online services. As the situation develops, we will update this page with the latest relevant information and recommended actions to help understand the risk and what organisations should do.

For further information and technical guidance, you can also refer to the following sources. These provide additional detail on the vulnerabilities, available security updates and the latest advice:

See the latest update below 22 October 2026 – 1600 GMT

Summary

On 21 October 2026, the PHP¹security team disclosed two critical (CVSS 9.2) vulnerabilities that may allow an unauthenticated remote attacker to execute code on vulnerable PHP systems. PHP has released security updates addressing both vulnerabilities, and organizations are strongly encouraged to update affected systems immediately. These vulnerabilities were discovered using GPT-5.6 Sol and it is expected that public exploits will be developed rapidly.

The vulnerabilities apply to PHP installations serving web requests, including common deployment models such as Apache with mod_php, PHP-FPM, php-cgi, FrankenPHP and LiteSpeed environments.

CVE-2026-109618 involves corruption caused by out-of-memory handling during request processing. The advisory confirms unauthenticated remote code execution over HTTP against Apache mod_php and notes that the demonstrated attack can occur before application-specific code begins executing.
CVE-2026-109619involves request-owned internal state surviving after its backing memory has been freed and being reused by a later request handled by the same worker.

Organizations should treat this as an emergency remediation and threat-monitoring event. Patching is the only complete solution. Installing the update prevents future exploitation of these vulnerabilities, but it does not establish whether a system was compromised before remediation.

Recommended response

Patch affected PHP systems immediately.
Prioritize internet-facing services and Apache mod_php deployments.
Increase monitoring and review historical telemetry for suspicious activity.
Escalate suspected exploitation through established incident-response procedures

Threat assessment

Key updates

Multiple alleged PoCs have been released, including claims of exploits that bypass recent patches, but their functionality has not been independently confirmed.
Exploitation tooling is proliferating rapidly, likely fuelled by AI, including updated exploits and scanners designed to identify vulnerable systems.
Amazon Threat Intelligence observed exploitation of the vulnerabilities as early as 17 October.
Scanning and exploitation attempts are increased rapidly following the public disclosure, indicating significant threat-actor interest in identifying vulnerable systems.

Since our previous update, we have continued to see multiple threat actors and claimed security researchers releasing alleged proof-of-concept exploits for these vulnerabilities. We have seen actors claiming to have developed new exploits that are not mitigated by the recent patches; however, we have seen no evidence to officially confirm their functionality^2,3,4 . We have also observed multiple posts discussing various tools to aid the exploitation of these vulnerabilities including posting updated exploits⁵ and scanners to identify vulnerable systems ^6,7.

Multiple organisations have reported seeing the attempted exploitation of these vulnerabilities. Amazon Threat Intelligence on 21 October said that it had observed the vulnerabilities being exploited as early as 17 October⁸. In this instance the threat actor used what Amazon described as a “commercial anonymization network”. Amazon provided the IP addresses associated with this early activity as 103[.]216[.]220[.]92 which is a ProtonVPN server located in Brisbane, Australia. Many other organisations have also reported observing the vulnerabilities being targeted including Cloudflare, whose CEO Matthew Price on 22 October reported seeing thousands of attempts in the 10 hours before the public announcement, “That jumped to tens of thousands in the 45 minutes post announcement, hundreds of thousands within 2 hours, and millions now⁹.

Given the speed at which tools and exploits are being created, the vast majority of this work is almost certainly being done using AI. Alongside this we have also seen multiple posts highlighting that exploits do not function as claimed. It is highly likely that various actors are seeking to use this opportunity to gain notoriety by releasing tools, despite having limited capabilities to verify their functionality.

The first identified vulnerability reported on 21 October was a self-described security researcher claiming to have developed a proof-of-concept exploit for the vulnerabilities.

Evidence of this has been posted on social media¹⁰ and Github¹¹; however, there has been no official confirmation of the functionality of this proof-of-concept. This proof-of-concept was allegedly developed using multiple AI models.

As these vulnerabilities allow an unauthenticated threat actor remote code execution on effected systems, it would likely allow a threat actor to gain initial access to a system that could be used to maintain persistence on the webserver as well as deploy further malware. This could ultimately lead to the compromise of further connected systems. Systems already compromised and persistence gained are also likely to remain compromised despite patching these vulnerabilities as the threat actor can rely on the new persistence mechanism.

Given the severity of these vulnerabilities, it is almost certain that a wide range of threat actors are seeking to exploit them, including state-linked APT actors and advanced cybercriminal groups. State-linked groups will highly likely target government and defense systems as priorities. Cybercriminals will likely seek to target organisations that hold large volumes of data, such as the finance and retail sector, that can be further exploited or used for data extortion. We have continued to observe many threat actors discussing the vulnerabilities, seeking to develop and share exploitation methods including discussion relating to the above proof-of-concept. We have also seen multiple threat actors claiming to have gained remote-code-execution using these vulnerabilities.

Affected and Patched Versions

PHP branch	Affected versions	Patched release
8.5	Earlier than 8.5.12	8.5.12
8.4	Earlier than 8.4.27	8.4.27
8.3	Earlier than 8.3.36	8.3.36
8.2	Earlier than 8.2.35	8.2.35

PHP 8.1 and older are no longer supported by the PHP project. Some operating-system distributions and long-term-support vendors may provide backported fixes. Where a supported backport is unavailable, migrate to a supported PHP branch.

Required Actions

Given the critical nature of these vulnerabilities and the potential for unauthenticated remote code execution, organizations should take immediate action to identify affected PHP systems, apply the appropriate security updates, and validate successful remediation. Priority should be given to internet-facing or otherwise externally accessible systems.

Identify exposure. Inventory internet-facing and internally accessible applications and services running PHP. Record each PHP version, hosting platform, container image, web server and SAPI/deployment model.
Prioritize high-risk systems. Address externally accessible systems first, with particular priority for Apache mod_php deployments because unauthenticated RCE has been demonstrated against this configuration.
Apply the security update. Upgrade to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, as applicable. For vendor-managed operating systems, use the vendor-provided security package or confirmed backport.
Restart relevant services. Ensure updated packages are loaded by restarting the affected PHP workers, web services, containers or workloads in accordance with normal change procedures.
Validate remediation. Confirm the effective runtime version on every affected host, pool, container and application tier. Do not rely only on package inventory where multiple PHP installations may exist.
Address unsupported versions. Migrate end-of-life PHP installations to a supported branch or obtain and verify a supported vendor backport as an urgent interim measure.

Alongside patching, increase monitoring around services that use PHP and review available historical telemetry for evidence of attempted or successful exploitation. This is especially important for systems that were vulnerable and reachable from the internet or another untrusted network.

Unusual, malformed or high-volume HTTP requests, particularly multipart requests or requests associated with abnormal body sizes, field counts, headers or nesting.
Unexpected PHP, Apache or web-server worker crashes, memory exhaustion events, fatal errors, timeouts, restarts or repeated replacement of workers.
Unexpected child processes, command shells, scripting interpreters or system utilities launched by PHP, Apache, PHP-FPM or another web-service account.
Unexpected outbound network connections from web servers or PHP workloads, including connections to unfamiliar external addresses
New or modified files in web roots, temporary directories, upload locations, application directories or other paths writable by the web-service account.
Changes to scheduled tasks, services, startup mechanisms, user accounts, SSH keys, application configuration or other persistence-relevant locations.
EDR, SIEM, WAF, IDS/IPS, cloud-security or network alerts associated with affected systems, including signs of web-shell activity, credential access or lateral movement.

IMPORTANT: Absence of a single indicator does not establish that exploitation did not occur. Correlate web, endpoint, identity, application and network telemetry when assessing potentially exposed systems.

Response to Suspected Exploitation

If suspicious activity or credible indicators of compromise are identified, treat the matter as a potential security incident rather than solely as a patch-management issue. Follow the organization’s established incident-response and evidence-preservation procedures.

Consider isolating the affected host, container or workload from untrusted and internal networks while maintaining appropriate investigative access.
Preserve relevant web-server, PHP, operating-system, EDR, WAF, authentication, application and network telemetry before destructive remediation where practicable.
Investigate process execution, persistence, file changes, outbound connections, authentication activity and use of credentials accessible to the application or web-service account.
Assess potential access to application secrets, database credentials, API keys, tokens, certificates and cloud or service-account credentials.
Examine adjacent systems for lateral movement or follow-on activity originating from the potentially affected host.
Rebuild or restore the system from a known-good source where integrity cannot be established
Rotate credentials and secrets that were confirmed or reasonably suspected to have been exposed.

Isolation trigger

Consider isolation when telemetry indicates likely code execution, persistence, web-shell activity, suspicious outbound communications, credential access or other activity that cannot be explained by authorized operations. Balance isolation against operational impact and evidence-preservation requirements.

Temporary Risk Reduction

If patching cannot be completed immediately, apply applicable temporary controls from the PHP advisory. These measures reduce exposure to specific attack paths but do not make a vulnerable installation safe and must not replace the security update.

For CVE-2026-109618, administratively enforce memory_limit=-1 where appropriate and confirm that no pool, directory or application setting restores a finite PHP memory limit.

Maintain conservative post_max_size and upload_max_filesize values and enforce decoded request-size and input limits at the web server or reverse proxy, including requests without a usable Content-Length.
Where multipart form data is not required, block it before requests reach PHP.
Use container or cgroup controls as an availability boundary where appropriate. Do not use RLIMIT_AS or RLIMIT_DATA as substitutes, because the PHP advisory warns these may trigger the vulnerable allocation-failure path.

For CVE-2026-109619, disable session upload progress using session.upload_progress.enabled=0 and restart all workers. On PHP 8.5, set fatal_error_backtraces=0 and restart workers.

Remove invalid or deprecated per-request settings that emit diagnostics before initialization, and remediate attacker-reachable fatal errors and execution timeouts.