21 October 2026 | Post-patch update to our earlier PHP2Shell investigation.
Yesterday, the internet was trying to work out what was wrong with PHP. Today, we have the patches, the technical details, and a rather revealing account of how the disclosure went wrong.
And it turns out the most widely shared fix was never going to solve the problem.
On 21 October, PHP released emergency updates for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, both rated 9.2 under CVSS v4.0.
The vulnerabilities can allow unauthenticated remote code execution (RCE), meaning an attacker could potentially run code on a vulnerable server without first logging in.
Before the release, much of the discussion centred on PHP’s session upload-progress feature. Researchers shared screenshots of an exploit called PHP2Shell, forum users exchanged configuration changes, and administrators tried to work out whether their websites were exposed.
Now we know something important.
The vulnerabilities are rooted in PHP’s internal memory management and error handling. The upload-progress feature provides one possible route into the problem, but disabling it cannot protect against both flaws.
The PHP security team has made its recommendation clear: temporary mitigations are incomplete, and updating PHP is the only reliable solution.
But the technical details are only half the story. According to a new account from the PHP Foundation, one underlying weakness was first noticed in 2024, researchers demonstrated its full impact in August 2026, and several disclosure problems disrupted the final days before release.
Here’s what the patches reveal, where yesterday’s reporting needs correcting, and what defenders should do next.
PHP2Shell: What Was Patched on 21 October?
PHP has released fixes for both vulnerabilities across its four supported release branches.
PHP 8.2 also reaches end of life on 31 December 2026, so anyone upgrading from an older installation should consider a longer-supported branch where compatibility allows.
There is some relief for organisations maintaining legacy installations. PHP published minimal source backports for versions 7.4, 8.0 and 8.1. These are intended to help maintainers who build PHP from source or lack access to a commercial long-term support provider.
Linux distributions and other support vendors received the fixes in advance, so administrators should check their own provider’s security packages rather than assume that every patched installation must display one of the upstream version numbers.
The affected deployment types extend beyond one web server configuration.
PHP’s advisory includes PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed among the environments at risk.
It identifies Apache with mod_php as particularly concerning because researchers demonstrated remote code execution through an unauthenticated request before the application's own PHP code begins running.
That’s quite important. A website’s login screen, application permissions or input validation may never get an opportunity to stop an attack occurring earlier in PHP's request processing.
What Are the Two PHP2Shell Vulnerabilities?
Both flaws involve how PHP handles memory when something goes wrong. To understand them, it helps to know what happens when a web server processes a request.
PHP allocates memory to store the information it needs while running the request. When that work finishes, PHP cleans up the temporary information and releases memory that is no longer needed.
If this process goes wrong, the program may try to use information that was never properly prepared or memory that has already been released.
These problems are known as memory-safety vulnerabilities.
CVE-2026-109618: Memory Corruption When PHP Runs Out of Memory
The first vulnerability involves an out-of-memory (OOM) condition.
An out-of-memory condition occurs when a program cannot allocate the memory it needs to continue an operation.
According to PHP’s technical advisory, the problem occurs when PHP interrupts a request while some internal information is only partially initialised.
During cleanup, PHP may then treat that incomplete information as valid. This can corrupt memory and, under exploitable conditions, allow an attacker to execute code.
Researchers demonstrated remote code execution against Apache with mod_php using default settings. The flaw can be reached before application-specific code runs.
The PHP Foundation also identifies PHP-FPM as exposed through application-level paths, although the detailed advisory distinguishes between demonstrated exploit chains and paths supported by source analysis.
The key point for defenders is that this vulnerability exists within PHP's request-handling machinery. Updating a WordPress plugin, changing an application password or disabling one PHP feature will not repair that underlying flaw.
CVE-2026-109619: When One Request Leaves Dangerous Data Behind
The second vulnerability concerns stale internal state.
A PHP worker is a running process that handles web requests. Some workers process several requests over their lifetime. Ordinarily, information belonging to a completed request should be cleared before the worker processes another. But a fatal error can interrupt that cleanup.
The advisory for CVE-2026-109619 explains that PHP can retain an internal reference to memory belonging to an earlier request, even after that memory has been released. A later request handled by the same worker may then access that invalid reference.
This is called a use-after-free vulnerability.
An attacker who can influence the conditions surrounding those requests may be able to exploit the resulting memory corruption.
The PHP Foundation says researchers demonstrated remote code execution against a real application running Apache with mod_php. Its detailed advisory also describes a validated session-related path involving PHP-FPM.
Unlike the first vulnerability, this problem can involve information surviving improperly between requests.
Both CVEs have the same official CVSS severity score of 9.2. Their actual exploitability depends on the PHP configuration, request handling and other conditions, so treating either as harmless would be a mistake.
The One-Line Fix Was Only Part of the Answer
If you followed yesterday's discussion, you probably saw this setting:
session.upload_progress.enabled=0
It appeared in security forums and social media posts as a potential way to protect PHP installations before the emergency update.
The setting disables PHP's session upload-progress functionality, which allows applications to track file-upload progress.
The advice wasn't entirely invented. The official advisory now establishes that session upload progress is involved in a demonstrated path for CVE-2026-109619. But the setting only addresses that particular route and does not cover other variants.
More importantly, it does nothing to fix CVE-2026-109618. That flaw involves PHP's out-of-memory handling and can be exploited through a separate path.
Why the Method of Applying the Setting Matters
The disclosure also settles a detail that was debated in the early forum discussions.
PHP says the upload-progress setting must be applied through configuration that takes effect before request parsing, such as php.ini, an FPM pool or appropriate server configuration.
It explicitly warns against relying on ini_set() or FPM .user.ini files for this temporary measure.
That matters because some configuration mechanisms are applied too late in the request lifecycle to prevent the relevant behaviour. Administrators also need to restart PHP workers after making the change.
So even for the one attack path that the setting may restrict, simply changing a configuration file is not enough to assume protection.
The Other Mitigation Is Surprisingly Counterintuitive
The advisory recommends a different temporary approach for CVE-2026-109618 when immediate updating is impossible.
It involves administratively setting memory_limit=-1, removing the predictable PHP memory limit that can trigger the demonstrated out-of-memory exploit path.
That may sound surprising. Limiting application memory is normally an important part of protecting server availability.
But in this particular vulnerability, reaching PHP's configured memory limit can trigger the unsafe behaviour.
Removing that specific limit reduces exposure to one controllable failure condition, although underlying memory allocation failures can still occur.
PHP therefore recommends combining any temporary changes with appropriate request-size restrictions and container or control-group memory safeguards.
The precise configuration matters, and these changes can affect service availability. Administrators should follow the official mitigation guidance and assess their environment rather than apply them blindly.
For PHP 8.5, the advisory also describes disabling fatal-error backtraces as another partial mitigation for CVE-2026-109619.
None of these controls provides complete protection. The lesson from the overnight workaround is straightforward: a setting may block one known attack route while leaving the underlying vulnerability intact.
TryHackMe's SOC Level 1 learning path helps you practice investigating security alerts and examining the evidence behind suspicious activity.
PHP Knew About One Underlying Problem in 2024
The most revealing part of the PHP Foundation's new account has little to do with the viral exploit screenshots. The roots of CVE-2026-109618 go back to 2024.
That year, PHP underwent an external security audit funded by Germany's Sovereign Tech Agency, organised through OSTIF and conducted by Quarkslab.
While addressing one of the audit findings, a PHP core developer noticed the out-of-memory issue that would eventually become CVE-2026-109618.
The team considered whether it might be exploitable, but no concrete attack path had been established.
Fixing it also presented a difficult engineering problem.
Some proposed solutions risked breaking compatibility with existing PHP applications. Others introduced performance concerns, denial-of-service risks or complications for third-party extensions.
According to the Foundation, its small security team struggled to agree on the right approach, and work on a solution repeatedly stalled.
The Foundation has described the delay as a failure involving its decision-making process and limited engineering resources.
What Changed in August 2026?
Security firm Calif began auditing PHP on 30 July through the Patch the Planet programme.
On 11 August, a Calif researcher reported an unconditional remote code execution vulnerability with the same underlying cause identified in 2024.
OpenAI independently reported the same root cause that day.
Wiz supplied additional findings later in August, and OpenAI reported further attack vectors in September.
These reports demonstrated the severity of a problem PHP had already been investigating.
From 11 August, the Foundation says fixing the vulnerability became the top priority for its security-funded developers.
The bug was not necessarily undiscovered until 2026. The decisive change was that researchers had demonstrated how the underlying weakness could lead to serious security consequences.
That turned a difficult, unresolved engineering problem into an urgent vulnerability requiring a coordinated fix.
AI Security Research Played a Role, but People Still Had to Fix the Bug
The Foundation's retrospective also offers a look at how AI is changing vulnerability research.
It describes using AI-assisted tools through a collaboration with Alpha-Omega and later adding further tools for validating vulnerability reports and potential exploits.
Those tools worked alongside traditional testing methods, including instrumented builds and controlled environments designed to reproduce failures.
The Foundation says its security team has published 15 CVEs since 1 July 2026, while also examining more than 100 reports that were invalid, duplicated or could not be reproduced.
Those numbers help explain the pressure on maintainers.
Automated tools can increase the number of potential vulnerabilities researchers identify. But maintainers still need to determine which reports are valid, understand their impact and create patches that won't break existing software.
In PHP's case, resolving the out-of-memory flaw required changes to core runtime behaviour.
The Foundation says people made the decisions and developed the fixes, even as automated tools helped researchers investigate and validate findings.
For security learners, that's a useful reminder that discovering a suspicious condition, proving it is exploitable and safely fixing it are three different technical challenges.
How the Coordinated Disclosure Unravelled
The PHP Foundation has now published its own timeline of the events leading up to the emergency release.
The Exploit Video Came From a Reporting Researcher
Remember the PHP2Shell tool screenshot and video circulating overnight?
The Foundation now identifies the video as an accidental publication by Calif, one of the firms involved in researching and reporting the vulnerabilities. The video showed a proof of concept operating against several targets.
A proof of concept (PoC) is a demonstration designed to show that a particular technique or vulnerability can work.
Although Calif removed the video, copies had already begun spreading. According to the Foundation, the publication contributed to other proof-of-concept development during 21 October. The video was real research material. But its early circulation still disrupted the planned disclosure process.
TryHackMe's SOC Level 1 learning path helps you practice investigating security alerts and examining the evidence behind suspicious activity.
What Should PHP Administrators Do Now?
The immediate response has changed from preparing for a patch to making sure the patch has actually been applied.
1. Update the PHP Runtime
Install the corrected PHP release for the branch you're running, or an appropriate vendor-provided fixed package.
If you rely on managed hosting, check whether your provider has applied the security update.
PHP specifically warns that the volunteer-maintained rpms.remirepo.net repository did not have updates available at release time and urges affected users to use distribution packages or build from source.
2. Restart the Relevant PHP Processes
A package update may not immediately replace every running worker process.
Where appropriate, restart PHP-FPM, Apache or the relevant PHP service, then verify the active runtime.
Check the actual web-serving environment rather than relying solely on the version reported by a command-line PHP installation.
3. Review Older PHP Installations
PHP 8.1 and earlier do not receive standard upstream releases for these vulnerabilities.
Check whether your distribution or long-term support vendor has provided fixes. Otherwise, plan migration to a supported version or an appropriately maintained environment.
If immediate remediation is impossible, consider temporarily isolating affected internet-facing services in line with your organisation's risk and availability requirements.
4. Review Temporary Configuration Changes
If you applied emergency configuration changes overnight, record what was changed and why.
Do not assume a setting applied through .user.ini provided the protection you expected.
After updating and verifying the patched runtime, review temporary changes through normal change management.
Some hardening settings may still be appropriate, but emergency adjustments to memory and request handling should be assessed for compatibility and operational impact.
5. Investigate Suspicious Activity
Review relevant web server, PHP, endpoint and security monitoring logs.
Potential leads include unusual request patterns, unexpected PHP worker behaviour, suspicious child processes, and memory-related errors.
These are investigative clues, not proof of exploitation by themselves.
Preserve relevant evidence if you suspect compromise and follow your incident response process.
6. WordPress Users: Check PHP
If you run WordPress, this issue affects the underlying PHP runtime rather than WordPress application code.
WordPress has published its own advisory encouraging site owners to update PHP.
You can find the runtime version in the WordPress dashboard under Tools → Site Health → Info → Server, or through your hosting control panel.
Updating WordPress plugins alone will not fix these PHP vulnerabilities.
Curious about detecting the next threat?
What PHP2Shell Teaches Us Now That the Patch Is Out
Few hours ago, the central question was whether the claims about PHP2Shell could be trusted.
Now, the official disclosure gives us enough information to assess them.
The vulnerabilities were real. The leaked CVE identifiers and expected patch versions were accurate. The suggested upload-progress mitigation addressed one legitimate attack route, but it was never a complete answer.
A vulnerability can remain unresolved even after its technical symptoms are known, especially when fixing it requires changes to complex, widely used software.
Researchers need to demonstrate impact. Maintainers need to weigh engineering trade-offs. Distributors need time to prepare updates. Defenders need reliable information quickly enough to act.
AI-assisted security research is adding speed to that process, but it also increases the amount of evidence maintainers must evaluate.
For anyone learning cyber security, PHP2Shell is a useful case study in vulnerability research, patch management and incident response.
The skills go beyond identifying a CVE. You need to understand what the evidence proves, how a vulnerability affects real systems and why a proposed mitigation may only address part of the risk.
You can develop your understanding of how cyber attacks unfold and how defenders respond through Windows Incident Response & Forensics.
TryHackMe's SOC Level 1 learning path helps you practice investigating security alerts and examining the evidence behind suspicious activity.
Ayomide Joseph A.
