TENEX Signal • Episode 2
Host: Tyler Moffitt
Co-host: Tom
Analyst commentary: Anna Pham
A patch closes a vulnerability, but what happened before it was applied? This episode explores PHP2Shell, the signs worth investigating, and what security teams should check beyond the patch, with commentary from TENEX analyst Anna Pham.
Cold open
TOM:
Your team patches a critical vulnerability. Everybody moves on. What could still be wrong?
TYLER:
Somebody could already have the credentials they need. You fixed the bug, but those credentials might still work.
TOM:
Welcome to 10x Signal. I'm Tom, here with Tyler Moffitt.
TYLER:
I'm a cybersecurity strategist at TENEX, with more than fifteen years in malware and threat research. We take the security news and talk about what it actually means for your team.
Today: PHP2Shell. We're building on the reporting in the 10x Signal newsletter, and I've got commentary from Anna, one of our senior analysts. I asked her what she'd want to know when a customer says, “We patched.”
1. The story: the clock started before the patch
TOM:
Give me the quick version. What's PHP2Shell?
TYLER:
Two critical vulnerabilities in PHP, the software behind a lot of websites and applications. They're CVE-2026-109618 and CVE-2026-109619, both with a reported severity score of 9.2.
The concern is that an attacker can potentially run commands on an affected server or get information out of its memory.
PHP released emergency fixes on October twenty-first. But Amazon Threat Intelligence reported an exploitation attempt on October seventeenth. Four days earlier.
TOM:
Do we know whether those early attempts worked?
TYLER:
Amazon documented an attempt. It couldn't establish whether those early attempts would have worked against real-world systems.
But on October twenty-fourth, Perplexity’s research documented successful command execution on honeypots, systems set up to observe attacks. The report connected incoming requests to shells actually starting on the servers.
Those were research environments. They show that execution was possible in that setup; they don't tell us how many businesses were compromised.
TOM:
What stood out to you in that research?
TYLER:
What the server did after the request arrived. Anna explains why the usual application logs might not settle that question:
ANNA PHAM | Read by Tyler:
“The hard part is how little the logs show. The request may get a normal response, or the worker may crash, and the only trace may be a few memory errors mentioning ‘Unknown on line 0’. Sometimes there's nothing at all, so a clean error log proves very little.”
TYLER:
Perplexity’s research correlated the requests with process activity: the web process started a shell, commands ran, and outbound connections were attempted. That connection between the request and the result is what makes the finding useful.
A request tells you what somebody tried. Process evidence helps show what the server actually did.
TOM:
Would every shell launched by a web server mean an attack?
TYLER:
No. Some applications legitimately start other processes. The analyst needs the context: what command ran, which account ran it, and what happened immediately before and after. In this research, the packet and process evidence connected the request to execution. That's why the sequence matters more than a single alert.
TOM:
How far back should a team investigate?
TYLER:
It changes where you start looking. If your review begins on the day you patched, you're leaving out the period you're most interested in.
Amazon recommends looking back to at least October seventeenth. Use that as a reference point, and go further if your own evidence warrants it.
2. The fix: installed doesn't always mean running
TOM:
What's the easiest thing to miss when applying the fix?
TYLER:
Anna points to two things here: running processes and hidden installations. She mentions Plesk, a web-hosting control panel. Here's her wording:
ANNA PHAM | Read by Tyler:
“I'd also confirm the fix is actually in place. PHP has to be restarted after the update, because running workers keep the old code until they restart. PHP also hides in places people don't think of. Plesk's own control panel needed a separate update. […] Containers carry their own PHP and need to be rebuilt. Finally, check the build date or package changelog rather than the version number, since Plesk's fixed builds for older PHP versions show the same version number as the vulnerable ones.”
TOM:
So PHP can be in the environment even if nobody on your team develops in it?
TYLER:
Exactly. You can patch the application you know about and miss a separate component. The vendor's advisory helps your team identify the right update.
TOM:
What would you want the person managing this to report back?
TYLER:
Which systems were affected, which fixes are running, and what remains exposed. The technical team can work through the vendor-specific checks. The person coordinating the response needs to know where help or a decision is still needed.
“Most of them are patched” needs a follow-up.
3. The consequence: the server might only be the starting point
TOM:
Okay. The team confirms the fix. Now explain the credentials problem.
TYLER:
The vulnerability can expose information from memory. Depending on what was there, that could include passwords, tokens, or API keys.
An API key could let that application access another service. If somebody steals it, patching the PHP server doesn't automatically revoke that access.
TOM:
Would they need to run a command first to get those secrets?
TYLER:
Not necessarily. Information exposure and attacker code execution are different outcomes. That's why an investigation focused only on finding a malicious file or a shell could miss the credentials question. The response team needs to establish what sensitive information the affected process could have held.
TOM:
Give me an example.
TYLER:
Imagine a web application that uses a service account to access cloud storage. This is a hypothetical.
You've patched the web server. But now that account is being used from somewhere unexpected.
You check whether a deployment or scheduled job explains it. If it doesn't, bring the account's activity into the investigation. Anna describes why:
ANNA PHAM | Read by Tyler:
“The one that changes the scope is the server's own credentials being used from somewhere new. At that point the investigation is no longer about the web server. It's about everything those credentials can reach.”
TOM:
Who needs to be in that investigation?
TYLER:
The responders, the application owner, and whoever manages those identities. The application owner can explain what the account is supposed to do. The identity team can help establish where it was used. That gives responders a way to distinguish an expected connection from something that needs containment.
If exposure is suspected, they need to decide what to revoke or rotate and what else to investigate.
TOM:
What if they look and don't find anything?
TYLER:
Then ask what they could actually see. Anna has a useful line on that:
ANNA PHAM | Read by Tyler:
“The most useful evidence is process activity on the web servers, then WAF, proxy, and outbound traffic logs, then cloud and identity logs to catch stolen credentials being used. Retention decides what you can conclude. If your logs don't reach back to October 17, you can only say ‘no evidence in what we have’.”
TYLER:
Turning on logging today won't show you what happened last week. Make the gap visible so the team can decide what action it justifies.
TOM:
Is there anything we could accidentally erase while we're fixing this?
TYLER:
Yes. Restarting PHP workers can destroy evidence in memory. If there's reason to suspect compromise, involve the response team early so they can preserve relevant evidence where feasible.
That isn't a reason to leave an exposed service vulnerable while everybody waits for perfect forensics. You need containment and evidence collection coordinated with the fix. The useful decision is who can isolate the system, what can be collected safely, and when the restart happens.
4. The fallback: what controls can buy you
TOM:
What about a system the team can't patch immediately?
TYLER:
Give it an owner and a plan. Depending on the exposure, that may mean restricting access or isolating it while the team works through the fix.
Anna's guidance on monitoring is worth hearing directly:
ANNA PHAM | Read by Tyler:
“Monitoring can catch what happens after a break-in and, with the right tools, respond automatically. It can't stop the bug, reliably see memory being read, or prove nothing happened. The PHP project says its configuration workarounds reduce exposure but don't make a server safe, and WAF providers describe their rules as a stopgap.”
TOM:
Can an attacker get in and still fail to finish what they came to do?
TYLER:
Yes. In the Perplexity research report, a shell ran, but attempts to write to web directories hit a read-only filesystem, and the download tool the command tried to use wasn't installed. Those obstacles limited later actions. They didn't undo the execution.
That's a useful question to ask about an alert: what did we stop, and what happened before we stopped it?
TOM:
What does that tell us about how an application should be set up?
TYLER:
The access the application has. Does it need unrestricted outbound internet access? Can its account reach more data than the application uses? Does it need permission to write to those directories?
Those choices affect what an attacker could do with a foothold. They have to fit the application, because blindly blocking everything can break legitimate work. But permissions and connections that serve no business purpose are worth removing.
Three questions and close
TOM:
All right. Somebody finishes this episode and walks into their next meeting. What are the three questions?
TYLER:
First: did the fix reach every affected system, and is the fixed code actually running?
Second: what have we checked from the period before the patch?
Third: could exposed credentials give somebody access somewhere else, and who's following up?
You don't need a thirty-page report to start that conversation. You need an answer, an owner, and visibility into the gaps.
The patch fixes the vulnerability. It doesn't erase the exposure window.
Thanks to Anna for her commentary and to the SOC team for the reporting behind 10x Signal.
The stories we didn't cover are in the 10x Signal newsletter. You'll find the newsletter and the technical source links in the episode notes. Follow 10x Signal wherever you listen.
I'm Tyler Moffitt. Thanks for joining us.
TOM:
And I'm Tom. See you next time.
Sources
