Acknowledgments: Special thanks to Lindsey Welch and Ben Nahorney for their contributions to this investigation and writeup.
Update 10/21/26 @ 4:40pm ET
Since PHP released its security advisory this morning to address the two critical vulnerabilities, several researchers have come forward to release the technical details of the vulnerabilities:
Calif's write-up provides a detailed history of PHP memory-limit vulnerabilities, and then explains how Calif revisited those earlier findings through OpenAI's Patch the Planet initiative, uncovering multiple interruption point and reliable RCE paths.
Wiz has demonstrated how the unauthenticated RCE works against WordPress, Drupal, and Joomla, and showed that a separate memory disclosure path could expose passwords, tokens, API keys, and certificates.
As of October 21 at 4:30pm ET, Huntress has not observed in-the-wild exploitation on partner systems. We are continuing to monitor relevant developments linked to these vulnerabilities.
Update: 10/21/26 @ 10am ET
On October 21 around 9:30 am ET, the PHP team released PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 to address the two vulnerabilities.
According to PHP, all PHP installations serving web requests are at risk (including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed). An exploit exists for mod_php where an unauthenticated request can trigger an attack before any application code runs.
What to do:
Source downloads are on PHP's downloads site; organizations should update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 as soon as possible. For organizations that can't update immediately, PHP has also outlined measures to reduce exposure to specific attack paths in its advisory.
Other update guidance from PHP:
Linux distributions and LTS vendors received the patches ahead of publication. Check with your vendor for updated PHP packages.
PHP 8.1 and earlier are no longer supported by the PHP project and won't receive official updates. Some distributions and LTS vendors might backport fixes for these releases, so be sure to contact your vendor for further information or upgrade to a supported version.
Organizations using the volunteer-maintained rpms.remirepo.net repository should move to distribution-provided packages or build PHP from source to apply updates promptly. Updated packages from that repository won't be available today.
The PHP security team has also provided minimal source-backports for PHP 7.4, PHP 8.0, and PHP 8.1. These branches are intended for organizations that build PHP from source or don't have access to an LTS vendor.
For those running the older, outdated versions of PHP (prior to the 8.2.x version numbers), it's likely there will be no official patch to resolve the vulnerabilities. For environments running the deprecated, end-of-life versions of PHP, admins should immediately add the line session.upload_progress.enabled = Off to the php.ini configuration on your server. This may require you to restart your web services and/or the server itself in order to take effect, but will mitigate the known abuse cases.
While the software itself in these deprecated versions will receive no official patch from the PHP maintainers, security researchers have produced their own patches that will permit admins to rebuild the PHP modules from source code. Huntress cannot evaluate whether these patches are effective, and recommend that, wherever possible (and with adequate testing to ensure the upgrade doesn't break website functionality), admins should upgrade their version of PHP on the servers they maintain to the most current 8.5.x release.
The vulnerabilities:
PHP released further information about the two vulnerabilities.
CVE-2026-109618 is a remote code execution flaw in PHP's out-of-memory error handling. If PHP runs out of memory while setting up request data, it is interrupted and that data is only partially initialized. During request cleanup that partly initialized data is treated as valid, creating a path to code execution.
The impact here is unauthenticated remote code execution (RCE) as the web worker account: according to PHP, complete RCE was validated over HTTP against mod_php with default PHP input and memory limits, and normal prefork configurations with multiple workers.
CVE-2026-109619 is a remote code execution flaw caused by PHP retaining request-specific state after its backing memory has been freed. If the same worker processes a later request, PHP may access that stale state before the normal initialization resets it. This vulnerability can lead to unauthenticated heap use-after-free, memory disclosure, and remote code execution with the web worker's privileges.
Huntress has not yet seen in-the-wild exploitation of these vulnerabilities across our partner base as of October 21 at 10am ET; however, others are reporting that they are seeing attacks emerging. As such, updating promptly to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 and following the guidance above is critical.
Huntress is continuing to track developments related to CVE-2026-109618 and CVE-2026-109619. We will update this blog accordingly as new information emerges.
Background
On the morning of October 20, a post on Hacker News claimed that two critical PHP vulnerabilities were headed for public disclosure. The post was taken down, but not before screenshots made their way around social media. Within a few hours, our good friends over at watchTowr confirmed the leak, writing that the vulnerabilities were real and that "we were all supposed to wait until Thursday at 11am ET."
Shortly thereafter, the PHP security team posted an advance notice of an upcoming security release addressing two critical vulnerabilities, both with a CVSS v4.0 rating of 9.2. The team scheduled that release for Wednesday, October 21 at 14:00 UTC, a day earlier than the original embargo, and noted it reserves the right to release even sooner "should details of either vulnerability become public, or should evidence of active exploitation appear in the wild."
PHP is everywhere. It quietly powers WordPress, Drupal, Joomla, and Magento sites, shared hosting platforms, control panels, and an awful lot of software that doesn't even advertise that it runs PHP under the hood. When a critical bug lands in PHP itself, rather than in one app built on top of it, the number of places you have to go looking to identify vulnerable PHP versions gets very big, very fast.
Huntress is monitoring developments related to these vulnerabilities and will update this blog as new information becomes available.
What are CVE-2026-109618 and CVE-2026-109619?
The flaws exist in PHP, the popular programming language running behind a huge number of websites. PHP is designed primarily for web development and is widely supported by hosting providers.
Here's what we know about the PHP vulnerabilities so far (and what we don't):
What we know: Both vulnerabilities are rated critical by the PHP security team. Public reporting describes them as remote code execution in PHP's core, which would mean an attacker could get the server to run commands of their choosing.
What it affects: PHP has not published affected versions yet. Reports have pointed to versions 5, 6, 7, and 8 being impacted, and some researchers have said they expect fixes only for currently supported PHP 8 branches. In its official release, however, PHP said that impacted and fixed versions (along with full details of the flaws) will be published with the October 21 security release.
How it works: No technical root cause has been published. We currently don't yet know which part of PHP is involved, whether it's reachable over a plain web request, or whether it depends on a particular configuration. We'll update this post when the advisory and researcher writeups are public.
Why "php2shell"? That's the name circulating among researchers. If you've followed this space for any amount of time, you know a name like that usually means one thing: someone sends a request to your website, and gets a shell on your vulnerable server.
Technical Details
With no public technical details yet, we can't show you the exploit. What we can do is tell you what we're looking for and what our own telemetry says about where the risk lives.
What exploitation will probably look like
Florian Roth, who released a free tool called process-watcher (a Linux-based process monitoring tool aimed at detecting exploitation) put it well: exploitation of these bugs will most likely show up as suspicious child processes spawned by PHP. At Huntress, that lines up with what we see in nearly every PHP intrusion we work.
In practice, that means a PHP worker process like php-fpm, php-cgi, php-cgi.exe, httpd, or apache2 would launch something abnormal:
Shells like
sh,bash,cmd.exe, orpowershell.exeInterpreters like
pythonorperlDownload or networking tools like
curl,wget,nc, orcertutil.exe
It's worth taking a closer look at command lines that include reverse shell patterns:
/dev/tcp/fsockopenmkfifo
It's also worth looking at quick reconnaissance commands like whoami, id, uname -a, or ipconfig run straight from the web server.
Attacker PHP abuse: what we've seen recently
Even before this leak, Huntress regularly catches attackers abusing PHP applications.
One pattern from a recent Huntress incident that occurred last week is a good preview of what php2shell exploitation could look like. In this incident, a PHP FastCGI process repeatedly ran a one-liner that wrote a small PHP file with random marker strings into the first writable temp directory it could find, before executing and then deleting it. If none of the directories were writable, it would print !notwrtbl! to flag that.
While this pattern isn't related to php2shell, it's a good example of PHP spawning things it shouldn't.
On the Linux side, most internet-facing PHP lives on web servers and shared hosting, which are not closely monitored. An exposed Linux web server without endpoint detection is the type of system where PHP flaws can be exploited quietly and remain unnoticed.
Proof of Concept
We have not built or reproduced a proof of concept for these vulnerabilities, and we're not aware of public exploit code as of this writing. A short exploitation video was briefly posted online and then removed. Once fixes are shipped, we expect technical details and proof-of-concept code to follow quickly, and we'll update this post.
What should impacted organizations do?
The fixes aren't out yet, so the goal right now is to be ready to patch the minute they land. In the meantime, there are several things you can do to shrink your exposure.
Inventory every PHP install. Start with your web servers, and then go hunting for the less obvious locations: vendor appliances and Windows software that bundle
php.exeorphp-cgi.exe, control panels like cPanel and Plesk, and anything running WordPress, Drupal, Joomla, or Magento.Plan your patch window for Wednesday, October 21 at 10am ET. Patch internet-facing systems first. Watch the official PHP announcement for the fixed version numbers, and check your Linux distribution and hosting provider for backported packages.
Identify any end-of-life PHP environments. If you're running PHP 5, 7, or 8.0/8.1, you may not get a fix at all. Upgrade, take it off the internet, or put it behind a VPN or web application firewall (WAF) until you can.
Keep an eye on what PHP spawns. Alert on PHP worker processes launching shells, interpreters, or download tools. On Linux servers without endpoint detection, Florian Roth's process-watcher is a free, quick way to get this visibility today. Start it in observe mode.
If you find something, isolate the server, and preserve web server and PHP logs. Look for webshells and new files in your web root, along with new cron jobs, scheduled tasks, and accounts.
What is Huntress doing?
Hunting across our fleet. We captured a baseline of normal PHP behavior across our partner endpoints before the release. Once fixes and technical details drop, we'll compare against it to spot new activity quickly.
We already monitor for malicious activity on servers. Huntress already detects web server processes spawning shells and common webshell activity on Windows and Linux. Our SOC is on alert for PHP-related activity.
Watching the patch drop. Our Adversary Tactics team is tracking the release and researcher analysis in real time, and we'll update this post with indicators and detection guidance as they become available.
Auditing our internal PHP use. Huntress has reviewed relevant internal systems and taken appropriate steps to mitigate potential exposure to these vulnerabilities.
Sigma / YARA Rules
We'll publish detection rules to huntresslabs/threat-intel once technical details are available.
Indicators of Compromise (IOCs)
No indicators of compromise have been confirmed yet. This section will be updated as the situation develops.
Item | Description |
|---|---|
TBD | Pending vendor advisory and confirmed exploitation |
