# php situation is insane

Channel: Low Level
Video: https://www.youtube.com/watch?v=QRABrn606LE
Duration: 12 min
Language: English
Words: 2590
Transcript page: https://viewrankai.com/tools/youtube-transcript/QRABrn606LE

---

[0:00] This PHP bug is unironically the worst case scenario. It feels like every day there is a new vulnerability that comes out. And guys, this PHP one is truly the worst case scenario for like the infrastructure of the web as we know it. I want to highlight, by the way, every time I go on vacation in some form or fashion, and even just leaving my home for a long period of time, I'm currently in Las Vegas for Sentinel One's One Con, and literally this bug came out like on Monday, like the rumor started to happen when I landed. So, maybe there's a pattern, maybe I shouldn't leave my

[0:30] house. Anyway, not important. Earlier this week there were some rumors floating around that somebody had popped PHP, and not like popped a PHP plugin or popped like a vulnerability in PHP my admin. No, I'm talking like a vulnerability in the PHP runtime. It's important to understand that like while PHP is a language in and of itself that renders things on the web, right? You host a website, and the website has PHP in the back end. Ultimately, there is code that has to run that not only renders the PHP, but also talks over the network to the request and parses data out of that request to make the PHP

[1:03] daemon do things. If there are vulnerabilities in the way that PHP parses and handles the request, that can lead to remote on-off RCE, remote code execution, which is exactly what these two two separate vulnerabilities enable. It's truly insane. Now, there are a lot of people that worked on this, there's a variety of companies that got together that made this happen, but I think the primary finder of this bug is LCFR, a zero-day connoisseur, they say on Twitter. And this is a vulnerability this is a video of them exploiting the vulnerability with your traditional, you

[1:31] know, anime girl dancing kind of thing. Uh but the TLDR here is this is them throwing the exploit. So, the best write-up that I've seen on this is the the kalif.io write-up. I believe the hacker that found this, LCFR, is associated with kalif. I'll link their Twitter and the URL for this write-up in

[1:45] the in the description down below. Again, I'm not going to read this write-up, I'm going to kind of summarize it. Obviously, go to the Twitter profile of the researcher, go follow them, go read the write-up on your own. It's very, very good stuff, very technically in-depth, so So you're into that, read it. Um but let me go through like why this is such a big deal. This vulnerability is in PHP, which is the PHP Hypertext Preprocessor. Yes, it is a recursive backronym. From 5.4.0 and up, up to like I think the most recent patch that fixes this is 8.12.5, okay? 5.4.0 was released in July of

[2:17] 2004, which means that this bug has sat dormant for over 22 years. Now, why PHP? Why does this matter? Who gives a [ __ ] about PHP? Aren't we all using React and Node on the back end now? Isn't this the current meta of the web development world? Again, I'm not a web development guy. I remember when I was learning to code, I was doing LAMP stack and WAMP stack on my computers. I had like a bunch of eight back when they used to send you the [ __ ] disc and it's like pickles out of the bag, whatever. Um, I

[2:43] was running LAMP, so I learned to code. I learned how to do session authentication using PHP. My first ever login screen was in PHP, okay? I'm very near and dear to PHP. So, PHP is important because it runs all of these stacks. Laravel, Nextcloud, PHP MyAdmin, Joomla, Drupal, and all WordPress platforms are all PHP backends, which means if there is a bug in the PHP language in the daemon itself, it affects all of these platforms. It is like the gold standard for a software supply chain, you know, vulnerability where something in your stack that you don't control has a bug. Now, the bug in question is a thing that someone has a

[3:18] use after free, right? So, in any kind of manually memory managed language, you have to you maintain the responsibility of managing the memory, okay? You allocate, you free memory, and if you use memory after it's freed, a lot of really bad side effects can occur where other parts of the program may use the memory that's been freed in unintended ways. Again, the Khalif report explains it much better than I will. I'll give a high-level summary. They found one bug by failing the PHP allocator via a post request. The internal hash table had an error. This out of memory issue only existed in PHP greater than 7.3. There

[3:51] was a skill.md file that tries to like basically summarize what is the pattern that we saw in 7.3. And pretty quickly the LM found another version of that same pattern in another area of PHP. So you may have seen this session upload progress float around in like the the INI file stuff. So this is the part of PHP that handles uploads for the request body. You know, you have that like the PHP session ID cookie that like associates your data to data on the back end of the server, right? That's how this all gets handled. So ultimately via the same pattern of have PHP do something, cause it to fail in the

[4:25] middle of doing something, and then because it failed in the middle, there's improper cleanup leading to a use after free, that same process applied in a different part of PHP at an older version back to 5.3 in the file upload process, right? So again, you've probably seen on Twitter talks of this session upload progress feature. It's a feature that allows you to upload files associated with a session. And again, all this code runs before your PHP

[4:52] script even runs, your code even runs. So you know, when I saw this exploit I was like, oh surely this only matters if you have a session variable that depends on an uploaded file. Well, no, all this gets ran before the PHP even runs. Here's how it works. There are two requests. The first one is you initialize a session where you are performing a file start, which means you're uploading a file, okay? So while this happens, there are globals in PHP

[5:16] that are you establishing a session. Those globals point into the request. Later, the multipart parsing fail fails in a way that is fatal but does not crash, which means you either have a parsing issue, but I think in this example they use in the out of memory pattern from before, where you can cause the memory allocator in PHP to fail, ultimately causing it to bail out. But it doesn't bail out completely. Because the file upload is not complete, it doesn't completely shut down the session. What actually happens is the session is freed, but the session global still exist. So, in a second request, you continue the file upload with

[5:51] another multipart form, you end the file upload, and what happens here is it reads and then destroys a freed session value. By destroying it means it writes a value there. So, this here is the use after free. Now, a lot of people ask me like how can a use after free lead to code execution, okay? I have this

[6:11] example that I use in a lot of videos. It's like my cat dog example. But like imagine you have two structs, right? And if you're not a programmer, a struct is literally just like a conjunction of two data types, right? So, in this example, you have the name of an animal and the function pointer to its speaking. So, this is a cat and a dog. Now, notice that there are actually the same variables in a different structure for the, you know, the wolf and the name variable for the structure dog, but they're in a different location. So, if you were to overlay these two variables on top of each

[6:42] other, you would have the speak for the dog overlay the name on the cat and the speak for the cat overlay the name on the dog. In the use after free scenario, what is happening is you have a pointer pointing to the same block of memory. It points to the same location where the same data exists, but it's treating the data in two different ways. It's treating it as a cat and a dog. So, a write to the name variable in the cat scenario can be used as the speak

[7:10] function pointer in the dog scenario. Obviously, an extremely simplified like version of the the the exploit pattern we're talking about. This is literally function pointers. Achieving RCE via a use after free into arbitrary read write is like much more complicated, but this is a general idea of like how a use after free does its thing. And real quick, before we keep going, I want to talk about today's video sponsor. Um guys, it's me. I'm the sponsor. Um if you're interested in any of the work that I'm doing, if you like my videos, do me a favor, check out my podcast. I have a podcast with Matt

[7:41] Johansson over at Vulnerable U. It's [ __ ] awesome. We have a great time. It's called the Lowdown. We literally just yap like this for like an hour at a time about vulnerabilities, have a good time. Uh a lot of good guests on that podcast, too. So, if you're interested in more long-form of me and him yapping, check that out. And then also, I have a newsletter called The Most Significant Bit. Uh both links to those are down in the description below. They're both free. So, I mean, come on, free stuff from your boy. Hit it up. And lastly, if you want to learn more stuff about

[8:05] hacking ultimately and coding, Low Level Academy has some big changes coming in 2027. Um so, go give that a look as well. That's it. Look, that that's what I wasn't even That was 48 seconds. A sponsor pull. Wow. Now, here's the kicker, right? So, this was all happening kind of in the shadows, right? There was apparently like a small group of people that knew about the bug. There was uh work being done to get a patch figured out by PHP before this went public. It was an embargo. And so, they held onto the patch until it went kind of public. PHP released the patch, and everything was

[8:36] good. Now, in the meantime, what was happening was people were trying to use LLMs to find the vulnerability. So, this means like in mass, people were throwing like probably GLM-53, DeepSeek-41, something something I don't know, like a Gemini model and then like all the frontiers at the PHP code base. The patch came out, and again, I'm not trying to like fud or spread misinformation. I'm just literally reading what I'm seeing on Twitter, which probably isn't

[9:01] misinformation. I don't [ __ ] know. Anyway, this is somebody reporting that the exploit in question, or at least the vulnerability that's been highlighted, uh this is them compiling PHP with ASan and then running a POC that exercises the code path um that that where this occurs. There's still an ASan violation. There's a double free, which implies that the vulnerability talked about in Khalif's write-up is still present in the 8.5.12 um patch. Also, another highly regarded researcher, uh Nicolas uh Krassas, says, "Leaving this here, 8.5.12 security patch is incomplete and needs further validation." You know, it's obviously kind of an AI generated thing, but also they found the bug with AI. So, I'm not

[9:42] sure how much that matters. But ultimately, here's the thing. Why are so many bugs coming out now and why are so many of them as use after freeze? I worked a lot of companies. I've written a lot of fuzzers, right? Fuzzers are the tools that researchers use to find what are called spatial most of the time memory corruption vulnerabilities. I mean, there's a buffer overflow, there's an integer underflow that leads to a buffer overflow or like an out-of-bounds read or write, okay? These bugs have been very easy to find for a long time with fuzzers because fuzzers just explode the whole tree that the program can execute and find all the edge cases

[10:14] in it. The issue with a use after free is that you need to have what is called a temporal bug. A bug where multiple states are achieved in the program's execution, right? And so, they summarize it here in their skilled at MD file. They give the LLM. Here are the two invariants that need to hold for an LLM or for you use after free not to exist, go find where this invariant breaks, right? We have these two different states that can occur and one

[10:41] of them is a fatal during fallible work. Go find that. This is not a thing that fuzzers can find because fuzzers are randomly going through the code base and looking for coverage. They're trying to get more and more coverage on the graph of the code base. They're not optimized for creating two disparate temporal states in the program where one is a failure case and one is not, okay? The LLM is really good at doing that. You can specify, "Hey, can any of these two states exist?" And you know, pending hallucinations, it can find them very quickly. So, we're going to start seeing a lot more of these bugs fall out. And I

[11:15] want to highlight that like we just had in like the whole world throw their LLM at PHP. It is likely that more pre-auth RCEs are going to fall out of the woodwork. So, just warning to the class, uh this may not be the end of it. And would Rust have fixed this? Actually, yeah. I mean again, I'm not I'm not advocating the PHP team rewrite all of PHP in Rust because, you know, there's issues with doing that in and of itself from a code drift standpoint. But, like, this is use after free, right? This is literally a a reference counting issue on a global pointer that gets used two different

[11:47] ways, one after being freed. And so, this is like the thing that that Rust brags about. It's like, we do the borrow checker at compile time, so like it can't happen, okay? Uh yeah, man, scary times. This is happening this same week. I got here on I got here 2 days ago, this dropped. Uh an Indian certificate authority, e-Mudhra, sorry if I pronounced that wrong, had eight certificates where one of them the private key was four. So, a lot of certs gotten validated. And then, I'm also, literally, as I'm recording this now, I think like a GitLab CVSS 10 just dropped. So, like, it it do be vuln season, guys. Prepare

[12:25] yourself, patch your boxes, hit the like button. See y'all later. Bye.

---

About this transcript
Read from YouTube's own caption track and laid out by ViewRank AI (https://viewrankai.com).
ViewRank AI finds the videos already beating a creator's own average on Instagram, TikTok and YouTube Shorts, transcribes them from the audio itself in more than 60 languages, and turns what worked into new ideas and scripts.
Free transcript tools, no account needed: https://viewrankai.com/tools
How to read any video this way: https://viewrankai.com/llms.txt