Acknowledgments: Special thanks to Lindsey Welch and Ben Nahorney for their contributions to this investigation and writeup.
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.
Detections are already in place. 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.
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 |
