On October 20, 2026, the PHP team gave advance notice of an emergency security release. The next day it shipped fixes for two critical vulnerabilities, and the UK’s NCSC urged organizations to update immediately.
Organizations that couldn’t update or apply temporary mitigations were told to consider taking affected systems offline.
That's a pretty serious recommendation for a language powering a substantial portion of the internet.
The PHP development team released emergency updates addressing both vulnerabilities.
The two issues, collectively nicknamed PHP2Shell, are identified as:
Both received a 9.2 critical severity rating under CVSS 4.0.
So, is PHP suddenly unsafe after decades? Are millions of WordPress websites about to get hacked? Should developers start migrating everything to another language?
Not quite.
These are legitimate, serious vulnerabilities with demonstrated exploits. But there's a big difference between understanding a security issue and assuming that every PHP server on the internet is about to catch fire.
Let's take a look at what actually happened.
First, This Isn't a WordPress Vulnerability
When we hear about critical PHP security issues, they're often associated with a particular application, framework, plugin, or some unfortunate developer who forgot to validate user input.
This time, the vulnerabilities exist inside the PHP interpreter itself.
That means applications built with WordPress, Drupal, Joomla, Laravel, or even a small custom PHP project could be affected if they're running a vulnerable PHP version.
Updating a WordPress plugin won't solve the problem. Neither will updating your Composer dependencies.
The vulnerability lives one layer below all of that.
In certain configurations, an attacker can exploit the interpreter while it's processing an incoming HTTP request, before your application code even begins executing.
Your carefully implemented authentication middleware, request validation, and authorization checks might never get a chance to do their jobs.
That's what makes this situation different from your typical PHP security advisory.
What's Actually Broken?
Both vulnerabilities involve how PHP manages memory and handles failures while processing requests.
They're related, but they work differently.
CVE-2026-109618: When Running Out of Memory Becomes Dangerous
PHP has a configurable memory limit that prevents individual requests from consuming excessive resources.
Normally, when a request exceeds that limit, PHP throws a fatal error and stops processing.
Pretty straightforward.
But PHP sometimes performs several internal operations while constructing data structures, such as the arrays used to store incoming form data.
Imagine PHP is building an internal array from a submitted form.
Partway through creating an entry, the interpreter runs out of memory. Execution stops, but some internal metadata has already been updated.
Now PHP believes an array entry exists even though it was never completely initialized.
During cleanup, the interpreter processes that incomplete entry as if it were valid.
That's where things get dangerous.
An attacker who can carefully manipulate the server's memory layout may be able to influence what PHP reads during that cleanup process.
Security researchers demonstrated that this can lead to arbitrary command execution.
The PHP team's advisory explains that the original out-of-memory handling relied on longjmp(), which could abruptly interrupt execution before internal operations had finished safely.
The patch changes this behavior so that recoverable memory failures are handled at safer execution points, while more severe failures terminate the worker instead of running unsafe cleanup.
The particularly concerning part?
Researchers demonstrated unauthenticated remote code execution against Apache running mod_php, using default PHP input and memory limits.
And the exploit can happen before the PHP script itself executes.
CVE-2026-109619: When One Request Leaves Something Behind
The second vulnerability is a little different.
PHP servers often use persistent worker processes to handle multiple HTTP requests.
A worker handles a request, releases the memory used by that request, and then moves on to another.
That's perfectly normal.
The problem arises when PHP releases memory but fails to clear an internal reference pointing to it.
A later request handled by that same worker might try to use the old reference.
This is known as a use-after-free vulnerability.
Certain fatal errors, session operations, and error-handling routines can create the conditions necessary for this to happen.
Researchers identified several exploitable paths involving session upload-progress processing, fatal-error backtraces, and other request-owned state.
Under the right conditions, an attacker can manipulate the memory that PHP mistakenly believes still belongs to a valid internal object.
Again, this can lead to remote code execution.
There's also a particularly interesting consequence: researchers at Wiz demonstrated ways to disclose portions of PHP worker memory.
Depending on what's stored there, that memory could contain sensitive information such as authentication tokens, credentials, or API keys.
So this isn't exclusively about executing malicious commands. Information disclosure is another possible impact.
Is This Really Exploitable, or Just a Theoretical Issue?
It's pretty exploitable.
Multiple research teams have independently demonstrated working attacks, including Datadog and Wiz.
Wiz tested vulnerable PHP installations running WordPress, Drupal, and Joomla, while Datadog demonstrated command execution against an Apache mod_php deployment.
However, successfully exploiting memory corruption is not always as straightforward as sending one generic request to every PHP server.
The exact behavior depends on several factors:
- The PHP version and how it was compiled.
- The server integration being used.
- Memory allocation behavior and enabled extensions.
- Application behavior and request-processing configuration.
- Whether the attacker can satisfy the necessary conditions for memory corruption.
The official CVSS 4.0 assessment lists high attack complexity and additional attack requirements.
That doesn't make the vulnerabilities harmless. It means exploit reliability can vary between environments.
Apache with mod_php is currently considered the highest-risk configuration, because researchers confirmed an application-independent attack path.
PHP-FPM isn't automatically safe, though.
The PHP advisories describe vulnerable PHP-FPM scenarios as well, including a validated session-related exploit that depends on suitable application behavior.
Other deployment methods, including php-cgi, FrankenPHP, and LiteSpeed, are also within the scope of the security advisory.
In other words, don't assume that using nginx with PHP-FPM makes the issue irrelevant.
At the same time, it would be inaccurate to suggest every vulnerable installation can be compromised with equal ease.
Are Attackers Already Exploiting It?
Unfortunately, yes. At least exploitation attempts are already happening.
AWS reported that its MadPot honeypot infrastructure detected a PHP2Shell exploitation attempt dating back to October 17, 2026, several days before public disclosure.
It subsequently observed additional attempts from multiple sources on October 21.
After patches and technical details became publicly available, AWS reported broader exploitation activity targeting its sensors.
Other security organizations also reported scanning and attempted exploitation.
There's an important distinction here, though.
An attacker attempting to exploit a server isn't necessarily evidence that the server was successfully compromised.
AWS specifically noted that it couldn't determine whether the early attempts would have succeeded against real-world systems.
Still, this isn't a vulnerability that should be casually placed on a maintenance backlog for next month.
Working exploits exist, and attackers are experimenting with them.
That's enough reason to prioritize an update.
Which PHP Versions Are Affected?
PHP released patched versions on October 21, 2026.
Here are the first fixed releases for each supported branch:
| PHP Branch |
First Fixed Version |
| PHP 8.5 |
8.5.12 |
| PHP 8.4 |
8.4.27 |
| PHP 8.3 |
8.3.36 |
| PHP 8.2 |
8.2.35 |
Earlier releases in each of these branches are vulnerable.
PHP 8.1 and older branches are also affected, but they no longer receive normal upstream security releases.
For this emergency, the PHP team did provide minimal source backports for PHP 7.4, 8.0, and 8.1.
Linux distributions and long-term-support vendors may also provide security patches for older versions.
This is worth remembering because a distribution-supplied PHP package can contain backported fixes without displaying the exact upstream version listed above.
Don't determine whether your server is patched from its version number alone if you're using vendor-maintained packages.
Also, PHP 8.2 reaches end of life on December 31, 2026. If you're planning a larger upgrade anyway, moving to a longer-supported branch makes sense.
What Should Developers Actually Do?
The immediate priority is pretty simple: determine which PHP runtime your application is using, then install the appropriate security update.
But there are a few details worth paying attention to.
1. Check the PHP Version You're Actually Running
On a Linux server, you can start with:
php -v
This tells you which version your command-line PHP executable is using.
However, the command-line version isn't necessarily the one serving your website.
Your web server might use PHP-FPM with a completely different executable, a different version, or even a separate PHP installation.
If you're running containers, check the PHP runtime inside the actual application container:
docker exec my-php-container php -v
Also inspect the container image, installed packages, and configured PHP service.
With managed hosting, check your hosting dashboard or contact your provider to confirm whether the security updates have been applied.
And remember that certain software products and administrative interfaces bundle PHP internally.
You might have PHP running somewhere without realizing it.
2. Install the Security Updates and Restart Your Workers
Once the updated PHP packages are available for your environment, install them using your normal deployment process.
If you're using containers, rebuild your affected images and redeploy them.
If you're using PHP-FPM or Apache, make sure the relevant worker processes are actually restarted or replaced.
Installing a new package doesn't help if old workers continue running vulnerable code.
Afterward, verify the runtime and perform basic smoke tests against the application.
You don't necessarily need to migrate an entire application to the newest major PHP branch today. Installing the patched release for your currently supported branch is a reasonable immediate response.
Just don't confuse updating PHP with updating your framework or Composer packages.
This is where things become more complicated.
The PHP security team has published temporary mitigations, but explicitly warns that none of them fully replaces the security update.
For CVE-2026-109619, administrators can disable session upload-progress handling:
session.upload_progress.enabled=0
On PHP 8.5, disabling fatal-error backtraces also reduces exposure to a demonstrated attack path:
fatal_error_backtraces=0
These changes need to be applied at the appropriate server or worker configuration level, followed by a worker restart.
But neither setting fixes every possible attack route.
For CVE-2026-109618, PHP also recommends a temporary administrative configuration that removes its per-request memory limit:
memory_limit=-1
This deserves some caution.
Removing PHP's memory limit can prevent the predictable out-of-memory condition used in confirmed exploits. But it also removes an important resource boundary.
An application can potentially consume far more memory than expected, affecting other processes or even the entire server.
The PHP team recommends pairing this approach with carefully configured request-size restrictions and container or cgroup memory limits.
Even then, underlying allocation failures remain possible.
So I wouldn't blindly paste these settings into production and assume the problem is solved.
They're emergency risk-reduction measures, not permanent fixes.
If a critical internet-facing service can't be patched or adequately protected, temporarily restricting its network access is a sensible option. In higher-risk situations, taking the affected service offline may be justified.
For the full list of conditions and precautions, follow the official PHP security advisory.
4. Check for Suspicious Activity
Patching addresses the vulnerability. It doesn't automatically undo an attack that may have already happened.
If your application was publicly accessible before being updated, reviewing recent activity is worthwhile.
Some things to investigate include unusual POST requests, unexpectedly large form submissions, repeated PHP memory-exhaustion errors, and unexplained worker crashes.
Datadog identified one particularly interesting log pattern: memory-exhaustion errors occurring in Unknown on line 0.
That can indicate a failure during PHP request initialization, before an application script starts executing.
It's not proof of exploitation, but it may deserve further investigation when combined with suspicious request traffic.
Unexpected shell processes spawned by PHP or Apache workers, unexplained outbound connections, and newly created files in web-accessible directories are more concerning.
And don't assume an HTTP 200 response means nothing happened. Researchers demonstrated successful command execution without necessarily crashing the worker or returning an obvious server error.
Of course, applications can produce memory errors and execute legitimate subprocesses for perfectly normal reasons.
The point is to investigate unusual combinations of events rather than treating every suspicious log entry as a confirmed breach.
If you find actual evidence of compromise, treat that as an incident. Updating PHP alone won't remove backdoors or invalidate stolen credentials.
Final Thoughts
PHP2Shell deserves attention.
Two critical vulnerabilities in the PHP interpreter can lead to unauthenticated remote code execution, researchers have demonstrated working exploits, and real-world exploitation attempts have already been observed.
That's serious enough without adding dramatic headlines about the entire internet being compromised.
If you maintain PHP applications, identify your actual runtime, apply the appropriate security update, restart affected workers, and review suspicious activity where warranted.
If you're on managed hosting, confirm that your provider has applied the patches.
And if you're still running an unsupported PHP version, this is a pretty good reminder that an upgrade plan should probably move higher on the priority list.
Sources and Further Reading