Two critical PHP flaws, a leaked exploit, and a lot of very tired SOC teams. Here's what landed in Cribl Detect the next day, and how Detection Lab turned the CVEs into a working detection pack.
The week you just had
If you work in a SOC or write detections for a living, I don't need to tell you how this week went. You lived it.
Tuesday evening, details of two critical PHP vulnerabilities leaked onto a public developer forum, two days ahead of the planned coordinated disclosure. By Wednesday morning, scanners were already knocking. By Wednesday afternoon, the PHP project had pushed emergency patches a day early. Somewhere in there, a lot of you were deciding whether to pull public-facing sites offline, chasing down every PHP install your org forgot it had, and fielding the same Slack message from leadership every 45 minutes: "Are we exposed?"
That's the patching story, and the PHP maintainers deserve real credit for how fast they moved. But there's a second question that doesn't go away when the patch lands: did anyone get in before we closed the door? That's a detection question. This post is about how we answered it in Cribl Detect, and how fast.
PHP2Shell in 60 seconds
PHP2Shell is the nickname for CVE-2026-109618 and CVE-2026-109619, a pair of unauthenticated remote code execution flaws in the PHP engine itself. Both are rated CVSS v4.0 9.2. The name came from a leaked exploit tool, which tells you how the week was going to go.
The two bugs are cousins, not twins. CVE-2026-109618 is out-of-memory corruption: PHP uses longjmp() to bail out when an allocation fails, which can leave request memory half-initialized, and the cleanup routine then treats that garbage as valid. CVE-2026-109619 is stale global state: PHP keeps internal state that outlives the request memory it points to, so the next request a worker picks up can act on leftovers. ELLIO's write-up has a great detail here: early attack tooling named one CVE in its user agent while actually sending the payload for the other, because the leaked proof of concept had blended them together.
What made this one so ugly is where the bug lives. It's not a plugin or a framework. It's PHP, and Sansec reports the vulnerable code dates back to PHP 5.4 in 2012, affects both Apache mod_php and PHP-FPM, and hits apps like Magento, WordPress, Drupal, Joomla, Nextcloud and phpMyAdmin even when their own code is clean. PHP runs roughly 70% of websites. And because PHP processes the malicious request before any application code runs, application-level auth doesn't save you.
The short version of the timeline:
Patching is the only real fix, and PHP has said its workarounds only close some attack paths. If you're running PHP 8.1 or older, there's no official release, just source backports or your distro's package.
Patching closes the door. It doesn't tell you who's already inside.
Here's the uncomfortable math. Exploit details were public on Tuesday night. Patches shipped Wednesday afternoon. And a patch doesn't take effect until PHP-FPM or Apache actually restarts and loads the new binary. Add in the PHP 7.x box in the corner nobody owns, the vendor appliance with embedded PHP, and the change window that couldn't happen until Thursday, and you've got a real gap where attackers had a working shell and you didn't have a fix.
So the job this week was twofold: patch everything, and go look for evidence that someone beat you to it. The guidance from the research community was consistent on what to look for. Huntress said it plainly: alert on PHP worker processes launching shells, interpreters, or download tools. A PHP worker's whole job is to interpret a script and return a response. It has no business spawning bash, curl, or powershell.
That's simple to say. It's less simple to turn into tested, normalized, ATT&CK-mapped detection logic across every telemetry source you have, on a Wednesday night, while also patching. That's the part we wanted to take off your plate.
Detection Lab: paste a CVE, get a detection pack
The catalog rules templates are great once they become available (more details on those later, including the query logic), but teams need something actionable immediately. Not to mention that every environment is different, and the questions you actually have are specific: what would exploitation look like in my telemetry, and what do I need to be collecting to see it? That's what Detection Lab is for. It combines Cribl AI with public CVE metadata to build ATT&CK-aligned detections, and we ran it against both PHP2Shell CVEs. Here's what came back for CVE-2026-109618.
First, the context. Detection Lab pulled the vulnerability details (critical severity, CWE-416 use-after-free plus three related weaknesses) and wrote an analyst-grade explanation of the bug: how the OOM path gets triggered, why internet-facing PHP-FPM, CGI, and Apache deployments with big multipart, JSON, or compressed request bodies are most exposed, and why a low memory_limit on its own isn't a fix and can actually make the OOM condition easier to reach. It also laid out the likely attack chain end to end, mapped it to 8 ATT&CK techniques across 7 tactics, and listed the 16 data sources you'd need to see all of it.
Then it drafted the detections. Eight of them, and when you read them top to bottom, it's not a list of rules. It's the whole kill chain:
Each draft comes with its OCSF log source (HTTP Activity, Application Error, Process Activity, File System Activity, Network Activity), so you know exactly which telemetry feeds which rule. And nothing ships blind. Detection Lab hands you a draft pack and asks you to review the patterns, sanity-check the coverage, and decide which rules go live as-is, which need edits, and which stay out of the shared ruleset for now. You’re still the detection engineer. It just does the first three hours of typing for you.
Correlations: from eight alerts to one story
Let's be honest about draft 1. "Unusually large POST request" on its own is going to be noisy. Somebody's uploading a 40MB PDF to your CMS right now. If that rule pages your on-call at 3am every night, it's going to get muted by Friday.
That's why Detection Lab doesn't stop at single rules. It also planned four correlation searches that chain the drafts together into higher-confidence attack stories on the same host:
Notice draft 3 shows up in every chain. A PHP worker spawning a shell is the hinge of this whole attack, which is also why the Unusual PHP Child Process template is the one I'd turn on first. The large request is just a hint. The large request followed by an OOM fault followed by bash coming out of php-fpm on the same box? That's a page.
Each correlation also tells you which data sources it depends on, and the query generates automatically once you save the underlying event detections.
"OK, it fired. Now what?"
The last piece is the one I think practitioners will appreciate most, because it's the part that usually lives in someone's head or a half-finished runbook. Detection Lab closes out with recommended next steps: what to check, which telemetry needs to be in place, and where an analyst should pivot before wrapping an investigation or sharing findings. For CVE-2026-109618 it produced three tracks.
Validate exploitation and exposure. Find PHP-FPM and PHP error events showing memory exhaustion, allocation failures, crashes, or abnormal cleanup, then pull the request URI, client IP, status, and byte counts for the requests right before them. Confirm which internet-facing PHP endpoints and virtual hosts were involved, and check installed PHP version, SAPI, memory_limit, and patch status.
Scope affected hosts and follow-on activity. Pivot from PHP worker processes to their children and command lines, new or modified scripts and binaries in web-accessible paths, outbound connections and DNS from worker descendants, and any access to secret stores, cloud metadata, or application credentials.
Contain and improve control coverage. Check EDR containment status and process trees rooted in php-fpm and web-server workers, then sweep for persistence (cron, systemd units, startup scripts, SSH keys, scheduled tasks) and outbound flows from affected hosts after the suspicious activity. Detection Lab's own analysis also flags something easy to miss in a hurry: treat OOM crash activity from before you patched as potential compromise, and grab logs, binaries, and memory evidence before you recycle the workers.
Each track ships with a suggested KQL pivot you can run once the saved detections are deployed. For example, the scoping pivot:
dataset="sec_ocsf_detection_signals"
| where parent_process_name in~
("php-fpm","php-cgi","apache2","httpd")
| where process_name in~
("sh","bash","curl","wget","python","perl","nc")
| project _time, host, user, parent_process_name, process_name,
process_command_line
| sort by _time desc | limit 200
We ran the same workflow for CVE-2026-109619, and it produced its own detection pack, correlations, and next steps tuned to the stale-global-state path.
What landed in Cribl Detect on Thursday
By Thursday, less than 24 hours after PHP shipped its fixes, Cribl Detect customers had new PHP2Shell rule templates in the catalog, ready to enable. They're behavior-based, not signature-based, which matters a lot when the exploit tooling is changing by the hour. Here's what they look for.
Unusual PHP Child Process
It fires when a PHP FastCGI or embedded-server worker (php-fpm, php-cgi, LiteSpeed's lsphp, FrankenPHP) becomes the direct parent of a shell, a scripting interpreter, or a file transfer tool. The list is broad on purpose: sh, bash, busybox, python, perl, ruby, node, nc, socat, curl, wget, and on Windows cmd, powershell, mshta, certutil, and bitsadmin. The regex also handles versioned binaries like php8.3-fpm, because nobody's fleet runs one tidy PHP version.
Description
PHP FastCGI process managers such as php-fpm, php-cgi, LiteSpeed lsphp and FrankenPHP execute application code as pooled worker processes on behalf of a web server, running under a dedicated low-privilege service account. A worker's job is to interpret PHP and return a response, so it normally creates no child processes of its own.
Adversaries who obtain code execution inside a PHP application — through a web shell dropped into the document root, or by exploiting a vulnerable endpoint directly — issue operating system commands using PHP's command execution functions. Those functions fork from the worker, so the resulting shell, scripting interpreter or file transfer utility appears as an immediate child of the PHP worker process, an ancestry the application tier has no legitimate reason to produce.
This rule matches process execution telemetry on all platforms where the parent process is a PHP FastCGI or embedded-server worker and the child is a Unix or Windows shell, a scripting interpreter, or a file transfer utility, with environment-specific command-line exclusions applied.
Query Logic
device.os.type_id == 100 and class_uid == 1007 and activity_id == 1
and process.parent_process.file.name matches regex
"(?i)(^|\\\\)(php[0-9.]*-(fpm|cgi)|php-(fpm|cgi)[0-9.]*|lsphp[0-9.]
*|frankenphp)(\\.exe)?$"
and process.file.path matches regex "(?i)(^|\\\\)(sh|bash|dash|ash|zsh|ksh|csh|tcsh|busybox|python[0-9.]
*m?|pythonw|perl[0-9.]*|ruby[0-9.]*|lua[0-9.]*|node|nc|nc\\.openbsd
|ncat|netcat|socat[0-9]*|curl|wget|cmd|powershell|pwsh|mshta|cscript
|wscript|certutil|bitsadmin)(\\.exe)?$"Reverse Shell in a Process Started by a PHP Worker
Once an attacker has code execution, the next move is usually a callback to their own infrastructure. This rule looks at the command line of anything a PHP worker starts and flags classic reverse-shell tradecraft: /dev/tcp/ and /dev/udp/ redirection, mkfifo named pipes, PHP's fsockopen, nc -e and its cousins, socat EXEC:, Python's pty.spawn and socket.socket, and Perl's IO::Socket. These line up with the indicators Huntress published for PHP2Shell exploitation.
Description
PHP is a server-side scripting language that web servers run through worker processes such as PHP-FPM, php-cgi, Apache's mod_php, LiteSpeed and FrankenPHP. These workers execute the PHP code that builds a response for each web request.
Adversaries who gain code execution through a PHP worker may open a reverse shell, using shell features such as /dev/tcp/ redirection, named pipes created with mkfifo, or PHP's fsockopen function to connect back to their own infrastructure.
Alerts when a process started by a PHP-FPM, php-cgi, Apache, LiteSpeed or FrankenPHP worker has a command line containing /dev/tcp/, mkfifo or fsockopen. These reverse-shell patterns are among the indicators Huntress lists for exploitation of the PHP2Shell vulnerabilities, which Wiz showed allow unauthenticated remote code execution against WordPress, Drupal and Joomla.
Query Logic
device.os.type_id == 100 and class_uid == 1007 and activity_id == 1 and
process.parent_process.file.name matches regex "(?i)(^|\\\\)(php[0-9.]
*-(fpm|cgi)|php-(fpm|cgi)[0-9.]*|lsphp[0-9.]*|frankenphp|httpd|apache2)
(\\.exe)?$" and process.cmd_line matches regex "(?i)(/dev/(tcp|udp)/
|mkfifo|fsockopen|(^|[\\s;|&(\\x22'])(nc|ncat|netcat)(\\.exe)?\\s+.
*(-e\\b|--exec|--sh-exec)|socat\\s+.*(EXEC|SYSTEM):|pty\\.spawn|socket
\\.socket|IO::Socket)"PHP Worker Writes PHP in Temp Folder
This one is my favorite, because it's the sneaky one. Instead of dropping a webshell in the document root where it's easy to spot, an attacker writes a small PHP script into /tmp, /var/tmp, /dev/shm, or a Windows Temp folder, runs it, and deletes it. Huntress observed exactly this in the wild: a PHP FastCGI process repeatedly writing and executing temporary PHP files. The rule catches the write itself, for .php, .phtml, .phar, .phps, and .inc files. We shipped it in two flavors: one for CrowdStrike endpoint telemetry, and one built on native Windows object-access auditing (event 4663).
Description
PHP is a server-side scripting language that web servers run through worker processes such as PHP-FPM, php-cgi, Apache's mod_php, LiteSpeed and FrankenPHP. Temporary directories such as /tmp, /var/tmp, /dev/shm and the Windows Temp folders hold short-lived files that any process can write to.
Adversaries who gain code execution through a PHP worker may write a small PHP script into a writable temporary directory, run it, and delete it, so their code runs outside the web root and leaves few traces.
Alerts when a PHP-FPM, php-cgi, Apache, LiteSpeed or FrankenPHP worker process writes a file with a .php extension into /tmp, /var/tmp, /dev/shm, the Windows Temp folder or a user's AppData\Local\Temp folder.
This behavior was observed in recent incidents in which a PHP FastCGI process repeatedly wrote and executed temporary PHP files, in connection with the PHP2Shell vulnerabilities CVE-2026-109618 and CVE-2026-109619.
Query Logic
class_uid == 1001 and activity_id == 1 and metadata.event_code matches regex
"(?i)Written$" and actor.process.file.name matches regex "(?i)^(php[0-9.]
*-(fpm|cgi)|php-(fpm|cgi)[0-9.]*|lsphp[0-9.]*|frankenphp|httpd|apache2)
(\\.exe)?$" and file.path matches regex "(?i)\\.(php[0-9]?|phps|phtml
|phar|inc)$" and file.path matches regex "(?i)
(/tmp/|/var/tmp/|/dev/shm/|/run/shm/|\\\\Windows\\\\Temp\\\\|\\\\AppData
\\\\Local\\\\Temp\\\\)"These rules also run on data in motion, before it's stored. When the attack chain goes from exploit to shell to callback in minutes, waiting 20 to 30 minutes for data to be collected, ingested, stored, and enriched before a detection runs is a long time to be blind.
The real lesson of PHP2Shell week
The window between disclosure and exploitation used to be weeks. Then days. This week it was negative: attacks started before the patch existed. AI is helping researchers find bugs like this faster (the PHP Foundation says 15 new PHP CVEs have been published since July), and it's helping attackers weaponize them faster too. The old detection workflow, where you read the advisory, wait for vendor content, write the rule yourself at 2am, map it to ATT&CK by hand, and then discover you aren't collecting process telemetry from half your web tier, just doesn't fit inside that window anymore.
What we want Cribl Detect to give SOC and detection engineering teams on a week like this is pretty simple. A way to turn a brand-new CVE into a reviewed, ATT&CK-mapped detection pack and correlations in minutes, not a week. Curated, behavior-based rules in the catalog the next day. And an honest view of which telemetry you're missing, so "we have a rule for that" actually means something.
If you spent this week patching, hunting, and explaining PHP-FPM to your CFO: you earned the weekend. And if you want to see how Detection Lab handles the next one (there's always a next one), let's talk.
