A critical PHP exploit leaked ahead of its incoming fix, after PHP alerted users such a fix was incoming. Prior to this fix being released with two critical vulnerabilities being fixed, the internet at large responded quickly by creating alleged PoCs within hours of publication, along with fake recommendations for mitigation.
Users of PHP, including frameworks that rely on PHP, are at very high risk of pre-auth Remote Code Execution and must update PHP to its latest version.
TL;DR – How to Defend
Update PHP on all systems as soon as an update becomes available, with the versions of PHP being 8.5.12, 8.4.27, 8.3.36, 8.2.35. Any version before 8.2 are EOL and no fix is forthcoming – these versions must be migrated to 8.2 or later secure versions.
Checkmarx Container Security can be used to identify the presence of PHP packages with the relevant CVEs in supported container configurations.
There are various supposed mitigation suggestions being circulated such as disabling unrelated session mechanisms, but PHP maintainers claim these suggestions are untrue and will not protect against the attack – apply any theoretical mitigations at your own peril.
Information on partial mitigation is available on the official advisory if it is currently impossible for you to update, but the only complete fix has been confirmed by the vendor is to fully update to a fixed version.
Introduction
PHP is an open-source web and script programming language that is extremely popular, comprising 75% of the public internet. A pair of newly exposed critical RCE vulnerabilities in PHP, both with CVSS 4.0 score of 9.2, have been reported to the public on October 20th with a fix released on October 21st, but rumors and alleged PoC exploits have been released in the interim period while users have been waiting for a fix or mitigation suggestions causing chaos and uncertainty.
What Happened
On October 20th, 2026 the PHP team released a heads-up notice to “all PHP users” to prepare them for an urgent and upcoming security release, with a promise of a fix and full disclosure on October 21st. The security release was to address two critical vulnerabilities (CVE-2026-109618 and CVE-2026-109619) rated 9.2 on CVSS v4.0.
These issues were fixed by PHP and a fix was released on Wednesday, 21 October 2026.
CVE-2026-109619 – certain PHP globals stay alive after a request ends, despite still pointing to freed up memory for that request. This memory can still be accessed by certain operations before it is reinitialized by a subsequent request resulting in a potential use after free vulnerability, though this requires an attacker to know the structure of the heap on the server.
The other issue, CVE-2026-109618, is a memory corruption triggered by Out-of-memory (OOM) errors which also leads to an RCE. Once the state of memory exhaustion is reached, a longjmp() call is performed to exit the current context in an invalid state, which could lead to attacker-controlled memory being executed. There are various ways in a file upload to consistently trigger these conditions such as not declaring a content length on file uploads, injecting multiple headers and uploading multiple empty files (generating file headers) which could exhaust system memory.
Ahead of this release members of the security community were already claiming to have created proof-of-concept exploits for these vulnerabilities in PHP. These PoCs were either partial or broken. When verifying fresh vulnerabilities, be extremely careful with code claiming to be exploit code, as it may contain malware.
Who is Vulnerable
All versions of supported PHP prior to 8.5.12, 8.4.27, 8.3.36 and 8.2.35 are vulnerable. Any versions before 8.2 are EOL and allegedly no fix is forthcoming – these versions are vulnerable.
According to official advisories [1] [2] setting memory_limit=-1 will mitigate one of the RCE issues, but this setting is problematic as it removes memory limitations and can lead to memory exhaustion, and further reconfiguration is required to try and mitigate this. For the second issue setting fatal_error_backtraces=0 and session.upload_progress.enabled=0 will mitigate the issue while removing these features; however, the only complete mitigation is to update to a fixed version.
During the wait period for the patch release rumors circulated on certain mitigation configuration but according to individuals that identify as involved with PHP – “ini settings will not save you”, which means that even if claims of exploitation are true there may be other ways to trigger the exploit such that the above setting is not a prerequisite of exploitation. These were later confirmed as partial or incomplete mitigations, and none offered complete coverage for both CVEs – which is why waiting for a timely official publication is so prudent.
On the Practice of “Upcoming Patch” Notifications
A valuable point to mention is the process of informing users of an upcoming patch – historically this served in reducing exposure by ensuring users were prepared for deployment as soon as the fix was out at a stated time, BEFORE attackers can reverse engineer it into a functioning exploit, since exploit development would be very difficult within the exposure window between notification and fix release.
However, with the introduction of LLMs into the research and exploit development process this practice may become more dangerous than it is helpful – attackers are able to quickly research recent updates, git changes, issues, open discussions and even the code itself for leads to achieve a very high exploit development velocity, and in this case the very warning of an upcoming update may have facilitated the development of the exploit. In other words, calling users’ attention of an upcoming update to reduce exposure time until exploitation could become a self-fulfilling prophecy that moves up the release time of an exploit.
On the other hand, a lot of speculation, misinformation and general FUD (Fear, Uncertainty, Doubt) has spread and inert/partial/overly specific PoCs have been released surrounding this specific report – a reminder that while matters may appear urgent it is still wise to wait for official confirmation, mitigation suggestions and fixes.
It seems that in the context of this event the approach of “Upcoming Patch” notifications has failed its users and has only enabled chaos, which might mean it’s time to reconsider this approach.
Identifying Vulnerable Versions
Since PHP versions are part of the operating system, rather than the SBOM – this issue will not be detected by SBOM scanning such as Software Composition Analysis (SCA). To assess potential exposure, organizations should identify their installed PHP versions and compare them against the officially affected versions, using host vulnerability scanners, system package inventories, or direct PHP version checks (php -v). Any affected installations should be updated to the latest patched versions.
Conclusions
Make sure to update PHP to Its latest versions – 8.5.12, 8.4.27, 8.3.36, 8.2.35. Other suggested fixes are partial, introduce their own problems, or completely irrelevant.
The critical vulnerabilities currently rocking the PHP world are an omen of things to come, as both the speed of exploit development and the speed of misinformation has surpassed in speed defenders’ ability to respond to imminent attacks.
Always cast doubt published mitigations and exploits until official information is available.
References
[1] https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w
[2] https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp
[3] https://www.php.net/archive/2026.php#2026-10-21-5
Vulnerabilities