LiveOverflow · Transcript · · Updated
The race to the first exploit // php2shell – Transcript
Video by LiveOverflow · Watch the original on YouTube
Summary
AI-generated from the transcript. Verify details against the source video.
- The speaker shares their experience using public knowledge and AI tools to find a critical remote code execution vulnerability in PHP and create an exploit.
- After trying various approaches and filtering out false leads, the agent discovered a Use-After-Free involving multipart parsing and session initialization.
- The speaker notes that while the proof of concept worked, it required reading proc mem for addresses and lacked an address leak.
Use this video with Pro
Reading, copying and transcript downloads are free. Create saved AI results for this video with a signed-in Pro account ($9/month).
Transcript
Search ignores accents. All transcript text stays visible.
Php2shell is a short comic series about Stefan Esser, published by Calif. Just kidding, of course. You probably already heard about the critical remote code execution vulnerability in PHP that was announced yesterday. It is so bad that they just warned everybody for an upcoming patch, so everybody can allocate the time necessary and prepare processes to patch immediately.
And in this video, I want to share with you my experience using the public knowledge to find the vulnerability and create an exploit. This vulnerability is serious, so don't underestimate it.
At 10 p.m. my Time Harsh shared the tweet by Calif announcing it. This tweet has since been deleted, probably because the original version contained a really fun video with a lot of useful details, but it was too late. It was already out there. So over the last 24 hours, a lot of people pointed their Clanker at the target to rediscover it before the patch is out.
And there has been lots of AI slop that turned out to be wrong. For example, this tweet was very popular and lots of people treated it as real. But looking closer at it, and by that I mean asking an agent about it. It turns out to be wrong. And now that we know it's a Use-After-Free, we can get definitive proof that this was just AI hallucinating slop.
But there have been other attempts that looked more credible at first, so let's have a look at them. For example, there was this one here. But if you also look closely here at the lab setup script, you can see it sets very specific settings for session serialization or a vuln PHP script with an include.
And in the proof of concept script, you can see here it is preparing a PHP Unserialized payload. And the session injection also does something with an Unserialized payload. And the Use-After-Free example also works with an Unserialized payload. So at first sight, it all looks good.
And if you ask the AI to verify it, the I might say, yeah, it works, but you need to be careful because it does exploit something. So it looks real, but it doesn't match the original claims. And the Use-After-Free, for example, is a known issue already disclosed in May this year.
I think this is really interesting that so many people through tokens at this, but failed. It shows that it's not as easy as go find a zero day in PHP. Of course, there also have been other attempts from some people that looked a lot more real, but they also didn't share exploit code because they know better.
So I also gave it a try and I got really close. I found the Use-After-Free and had a proof of concept exploit, but I was missing an address leak, so I thought it might be interesting to share my methodology and process how I did this. And not everybody is using a $200 Codex subscription with daybreak, which has less guardrails for hacking, so I thought this video would be a good snapshot of October 2026, how the methodologies with AI look like right now.
And then we can see how it will change over time. So let me share how I approached it. And keep in mind I know nothing about PHP internals. When Harsh shared the tweet, there was a video, and I think this video can provide a lot of hints to guide our attention into the right place.
So I used Codex to take the video and extract the relevant frames and the text on the screen. This took a bit, but this gave us a nice markdown file with the actual text, which then the agent can also read. And I already noticed something myself in the video before, and that is that it claims to work on PHP 5.4 and later.
Which means something was added in that version that introduced the vulnerability, and that already limits our search space a lot. So I immediately tasked Codex to pull the 5.4 source code and ask about which version came before, so we can look at the code diff.
But I expected there to be a lot of changes, so I wanted to limit the search even more. And so in the video, there were multiple proof of concept exploits shown against Drupal or WordPress and so on. But the last one was the crazy one for me because it shows it was just a simple index dot php with echo. Hi. Nothing else.
And from the exploit output, we can clearly see that there are some memory corruption going on, so we are not looking for a higher level PHP vulnerability. We are looking for something low level in. See also it mentioned SAPI boundary and Apache prefork/mod_php, which I think could give us some hints that this is a requirement.
I had actually no idea what SAPI or SAPI means and. Apache Prefork/mod_php. So I just asked Codex. And it kind of explained it to me. So to me, it was clear this is the area where we should start looking for vulnerabilities. But I ran into daybreak guardrail issues.
I also tweeted about it and it was very frustrating. But regardless of those issues, I did manage to set up a test lab with the same ubuntu and PHP version as seen in the video, including an ASN debug build. So we have a nice environment for testing and catching possible memory corruptions.
Like I said, one approach I had was looking for features that were introduced in 5.4 and remained unchanged until today. And I was poking around a bit and eventually the agent found a use after free. So I got excited. But I know I need to be careful with this stuff because on a closer look, it changes a PHP config variable.
And we need this code in PHP and it's also already fixed. So definitely not what we are looking for. At that time. The daybreak guardrails were really frustrating, and I actually had a theory that OpenAI was applying strong guardrails, very specific to the zero day, to prevent people from developing an exploit for it faster.
And I thought, if that's the case, I could abuse that as an oracle by probing individual files. And if I'm reaching the correct file, the guardrails will block me. I thought I was so clever, but the theory turned out to be wrong. The daybreak issue was a bug. I don't know what happened just before that I was doing other exploit stuff and had no issues.
But after several responses on Twitter, I authenticated the next morning and it was all fine. Anyway, when I was doing this exercise with the single files, I stumbled over another Use-After-Free. But it requires this specific PHP code and it almost looks like a JavaScript browser exploit snippet. Quite interesting.
Also apparently not fixed, but I don't think anybody cares about this attack vector, so feel free to do whatever you want. Anyway, I went to bed and on the next day I fixed my guardrail issues and I could continue and give the agent a much broader task based on the hints of the video. Take the PHP 5.4 code and identify any code that is reachable via network and is related to mod, PHP and SAPI, especially around file uploads.
Don't ask me why I specifically mentioned that. I guess I must have read that somewhere or had a feeling. Git. Blame the code and document relevant files and code changes in commits.md file. If they made it into 5.4 and survived until the version 8.5.4. Specifically, look for Use-After-Free or other memory corruption issues like integer over and underflows off buy one issues, buffer overflows, race conditions and re entrances, and after 45 minutes the agent had a result.
We got a first proof of concept exploit. It's said that it found a good match to the video, something related to the cookie re parsing and cookie tables. The video mentioned natural tables 149, and it could be useful for heap grooming. So to lay out the heap in a way that is important for the exploit to succeed.
And it also said it found a heap use after free involving a stale p s id. By the way, p, s and bg are C preprocessor macros, and they are basically used as a little helper to just point to some global session ID or serializer state.
But it also said that it requires a session handler with Re-entrancy something like this here. So still not what we are looking for, but I just sent the agent again with the goal to develop a POC exploit against the local test lab matching the video. So a plain index dot php file session upload progress cookie Reparse path is a most likely candidate.
First trigger Asan and then develop a POC exploit and this took then 1.5 hours and it found it. So let's take a closer look at the steps taken. Codex sent a few subagents and I don't want to peek into everything now in detail, but after some uninteresting messages there was a search the web and if we look closely, we can see it.
Searched for Calif and php2shell and it found something. A public disclosure bundle now claims the cached pointer chain we are testing. I treat it as untrusted and reproduce it in an isolated lab, and accepted only if ASAN confirms it. And looking at the next steps, we can see it.
Found the fake writeup and downloaded that bundle. Great. This makes me not worried about the next time when somebody does this with some malicious code. Anyway, let's ignore that and see what the agent did. It tried to validate it, but it doesn't work. See how much it tried here, but it couldn't succeed.
And it concludes the widely circulated cached pointer explanation is falsified. I'm recording that as a reproducible negative result, but the agent continued with other ideas. But they all didn't work. Delimiter, null bytes and other stuff that didn't work. And it sometimes came back to the public fake report again.
I've confirmed the public second progress update freeze. The cached civil narrative is mechanically wrong, but now it expands the search. For example, it mentioned clean up failures as one of the ideas, and it is now running 4000 tests.