PHP-sårbarheden: Det værste scenarie for nettets infrastruktur

Denne PHP-bug er uironisk set det værste tænkelige scenarie. Det føles, som om der hver dag kommer en ny sårbarhed. Og folkens, denne PHP-bug er sandelig det værste scenarie for selve infrastrukturen på nettet, som vi kender det.

Indledning og et mønster med ferier

Jeg vil forresten fremhæve, at hver gang jeg tager på ferie på den ene eller anden måde, ja selv bare når jeg forlader hjemmet i en længere periode ... jeg er lige nu i Las Vegas til SentinelOne's OneCon, og bogstaveligt talt kom denne bug ud om mandagen. Rygtet begyndte at spredes, lige da jeg landede. Så måske er der et mønster. Måske burde jeg ikke forlade mit hjem. Nå, ikke vigtigt.

Hvad der faktisk skete

Tidligere på ugen flød der nogle rygter om, at nogen havde "poppet" PHP. Og ikke som i at poppe et PHP-plugin eller en sårbarhed i phpMyAdmin. Nej, jeg taler om en sårbarhed i selve PHP-runtime-miljøet.

Det er vigtigt at forstå, at selvom PHP i sig selv er et sprog, der renderer ting på nettet ... du hoster en hjemmeside, og hjemmesiden har PHP i backenden ... så er der i sidste ende kode, der skal køre, som ikke bare renderer PHP'en, men som også taler over netværket med requesten og parser data ud af den request, så PHP-daemonen kan gøre ting. Hvis der er sårbarheder i den måde, PHP parser og håndterer requesten på, kan det føre til fjern-RCE, remote code execution, og det er præcis, hvad disse to separate sårbarheder muliggør. Det er virkelig vanvittigt.

Forskerne bag fundet

Der har været rigtig mange mennesker involveret i dette. En række virksomheder er gået sammen om at få det til at ske. Men jeg tror, at den primære finder af denne bug er LCFR, en "zeroday-connoisseur", som de selv skriver på Twitter. Og dette er en sårbarhed. Dette er en video af dem, der udnytter sårbarheden, med dit klassiske anime-pige-danse-agtige noget. Men TL;DR her er, at det er dem, der kaster exploiten af sted.

Den bedste write-up, jeg har set om dette, er write-uppen fra kf.io. Jeg mener, at hackeren, der fandt den, LCFR, er tilknyttet kf. Jeg linker til deres Twitter og URL'en til write-uppen i beskrivelsen herunder. Igen, jeg vil ikke læse write-uppen op. Jeg vil mere opsummere den. Selvfølgelig: Gå ind på forskerens Twitter-profil, følg dem, læs write-uppen selv. Det er rigtig, rigtig godt stof. Meget teknisk dybdegående. Så hvis du er til den slags, så læs den.

Hvorfor dette er så stort en sag

Men lad mig gennemgå, hvorfor dette er så stor en sag. Sårbarheden er i PHP, som står for "PHP: Hypertext Preprocessor". Ja, det er et rekursivt backronym. Den findes fra 5.4.0 og op til ... jeg tror, den seneste patch, der fikser dette, er 8.1.something. Okay, 5.4.0 blev udgivet i juli 2004, hvilket betyder, at denne bug har ligget dormant i over 22 år nu.

Hvorfor PHP? Hvorfor betyder det noget?

Hvem gider dog PHP? Bruger vi ikke alle React og Node i backenden nu? Er det ikke den aktuelle meta i webudviklingsverdenen? Igen, jeg er ikke webudvikler. Jeg husker, da jeg lærte at kode, kørte jeg LAMP-stack og WAMP-stack på mine computere. Jeg havde en Ubuntu 8.04 dengang, hvor de sendte dig cd'en, og den lugtede af pickles direkte ud af posen, eller hvad det nu var. Jeg kørte LAMP. Så det var sådan, jeg lærte at kode. Jeg lærte at lave session-autentifikation med PHP. Min første login-skærm nogensinde var i PHP. Okay. PHP ligger mig virkelig nært.

PHP er vigtigt, fordi det driver alle disse stacks: Laravel, Nextcloud, phpMyAdmin, Joomla, Drupal, og alle WordPress-platforme er PHP-backends. Hvilket betyder, at hvis der er en bug i selve PHP-sproget, i daemonen, så rammer det alle disse platforme. Det er som guldstandarden for en software supply chain-sårbarhed, hvor noget i din stack, som du ikke kontrollerer, har en bug.

Selve buggen: use-after-free

Buggen i question er noget, man kalder en use-after-free. I et manuelt memory-styret sprog har du selv ansvaret for at håndtere hukommelsen. Du allokerer, du frigør hukommelse, og hvis du bruger hukommelse efter, at den er frigivet, kan der opstå rigtig mange dårlige bivirkninger, hvor andre dele af programmet kan bruge den frigjorte hukommelse på utilsigtede måder. Igen, kf-rapporten forklarer det langt bedre, end jeg vil. Jeg giver en opsummering på højt niveau.

De fandt én bug ved at få PHP's memory-allokator til at fejle via en POST-request. Den interne hash-tabel fik en fejl. Dette out-of-memory-problem eksisterede kun i PHP 7.3 og opefter. De skrev en skill.md-fil, der prøver at opsummere mønsteret, de så i 7.3. Og ret hurtigt fandt LLM'en en anden version af samme mønster et andet sted i PHP. Så du har måske set denne "session upload progress" fløje rundt i INI-fil-sammenhænge. Det er den del af PHP, der håndterer uploads fra request-bodyen. Du kender det med PHP-session-ID-cookien, der forbinder dine data til data på serverens backend, ikke? Sådan bliver det hele håndteret.

I sidste ende gælder det samme mønster: Få PHP til at gøre noget, få det til at fejle midt i det, og fordi det fejlede midt i processen, sker der en fejlagtig oprydning, hvilket fører til en use-after-free. Samme proces var gældende i en anden del af PHP, i en ældre version helt tilbage til 5.3, i fil-upload-processen. Så igen, du har sikkert set Twitter-snak om denne session upload progress-funktion. Det er en funktion, der tillader dig at uploade filer tilknyttet en session. Og alt denne kode kører, før dit PHP-script overhovedet kører, før din kode overhovedet kører. Da jeg så denne exploit, tænkte jeg: "Åh, dette betyder sikkert kun noget, hvis du har en sessionsvariabel, der afhænger af en uploadet fil." Nej. Alt dette bliver kørt, før PHP'en overhovedet kører.

Sådan fungerer det

Der er to requests. Den første er, at du initialiserer en session, hvor du udfører et "file start", hvilket betyder, at du uploader en fil. Mens dette sker, er der globals i PHP, når du etablerer en session. Disse globals peger ind i requesten. Senere fejler multipart-parsingen på en måde, der er fatal, men som ikke crasher, hvilket betyder, at du enten har et parse-problem ... men jeg tror, at de i dette eksempel bruger out-of-memory-mønsteret fra før, hvor du kan få PHP's memory-allokator til at fejle og dermed få den til at bakke ud. Men den bakker ikke helt ud, fordi fil-uploaden ikke er færdig. Den lukker ikke sessionen helt ned. Hvad der faktisk sker, er, at sessionen frigives, men session-globalen stadig eksisterer. I en anden request fortsætter du fil-uploaden med endnu en multipart-formular. Du afslutter fil-uploaden, og det, der sker her, er, at den læser og derefter destruerer den frigjorte sessionsværdi. Ved at destruerer menes, at den skriver en værdi der. Så det her er use-after-free'en.

Kat-og-hund-eksemplet på use-after-free

Mange spørger mig, hvordan en use-after-free kan føre til kodeeksekvering. Okay, jeg har det eksempel, jeg bruger i mange videoer. Det er mit kat-hund-eksempel. Forestil dig, at du har to strukturer. Hvis du ikke er programmør, er en struct bogstaveligt talt bare en sammenkobling af to datatyper. I dette eksempel har du navnet på et dyr og en funktions-pointer til, hvordan det taler. Så det er en kat og en hund.

Bemærk, at det faktisk er de samme variabler i en anden struktur for "woof" og navnevariablen i dog-strukturen, men de ligger på en anden placering. Hvis du lagde disse to variabler oven på hinanden, ville speak-funktionen for hunden ligge oven på kattens navn, og kattens speak-funktion oven på hundens navn. I use-after-free-scenariet, hvad der sker, er, at du har en pointer, der peger på den samme hukommelsesblok. Den peger på samme sted, hvor de samme data findes, men den behandler dataene på to forskellige måder. Den behandler dem som en kat og en hund. Så en skrivning til navnevariablen i kat-scenariet kan bruges som speak-funktions-pointeren i hund-scenariet. Selvfølgelig er det en ekstremt forenklet version af det exploit-mønster, vi taler om. Dette er bogstaveligt talt funktions-pointere. At opnå RCE via en use-after-free ind i vilkårlig læsning/skrivning er langt mere kompliceret. Men det er den generelle idé om, hvordan en use-after-free gør sit.

Sponsorafsnittet

Og lige hurtigt, før vi fortsætter, vil jeg tale om dagens videosponsor. Folkens, det er mig. Jeg er sponsoren. Hvis du er interesseret i noget af det arbejde, jeg laver, hvis du kan lide mine videoer, så gør mig en tjeneste og tjek min podcast ud. Jeg har en podcast med Matt Johansson, nemlig Vulnerable U. Den er skide god. Vi har det fantastisk. Den hedder The Lowdown. Vi bogstaveligt talt bare snakker løs som her i en time ad gangen om sårbarheder. Vi hygger os. Der er også mange gode gæster på den podcast. Så hvis du er interesseret i mere langformat af mig og ham, der snakker løs, så tjek den ud. Og så har jeg et nyhedsbrev, der hedder The Most Significant Bit. Links til begge dele ligger i beskrivelsen herunder. Begge er gratis. Så kom nu, gratis stof fra din dreng. Slå til. Og sidst: Hvis du vil lære mere om hacking og kodning, så har Low Level Academy store ændringer på vej i 2027. Så giv det et kig også. Det var det. Se lige det. Det var ikke eens... det var 48 sekunders sponsorindslag. Wow.

Embargoen, patchen og ... er den overhovedet komplet?

Nu til det rigtig krydrede. Alt dette skete mere eller mindre i det skjulte. Der var angiveligt en lille gruppe mennesker, der kendte til buggen. Der blev arbejdet på at få en patch klar hos PHP, før det blev offentligt. Det var under embargo. Så de holdt fast i patchen, indtil det gik ud til offentligheden. PHP udgav patchen, og alt var godt.

I mellemtiden var det, der skete, at folk forsøgte at bruge LLM'er til at finde sårbarhederne. Det betyder, at folk i masser af oplag kastede formodentlig GLM 5.3, DeepSeek 4.1, et-eller-andet, jeg ved det ikke, måske en Gemini-model, altså alle frontier-modellerne, mod PHP-kodebasen. Patchen udkom, og igen, jeg prøver ikke at spreade FUD eller misinformation. Jeg læser bare bogstaveligt talt det, jeg ser på Twitter, hvilket nok ER misinformation. Jeg ved det ikke. Nå, men dette er nogen, der rapporterer, at exploiten eller i hvert fald den sårbarhed, der er blevet fremhævet ... det er dem, der kompilerer PHP med ASAN og derefter kører en PoC, der rammer den kodevej, hvor dette sker. Der er stadig en ASAN-violation. Der er en double free, hvilket antyder, at sårbarheden, der tales om i kfs write-up, stadig er til stede i 8.1.2-patchen. Desuden siger en anden højt respekteret forsker, Nicholas Cassus (eller hvad han nu hedder), at den nye 8.1.2-security patch er ufuldstændig og kræver yderligere validering. Det er åbenlyst en slags AI-genereret noget, men de fandt jo også buggen med AI, så jeg er ikke sikker på, hvor meget det betyder.

Hvorfor kommer der nu så mange bugs, og hvorfor er så mange af dem use-after-free?

Men i sidste ende: Hvorfor kommer der så mange bugs nu, og hvorfor er så mange af dem use-after-free? Jeg har arbejdet hos mange virksomheder. Jeg har skrevet mange fuzzers. Fuzzers er de værktøjer, forskere bruger til at finde det, der kaldes spatiale, for det meste memory-corruption-sårbarheder. Der er en buffer overflow, der er en integer underflow, der fører til en buffer overflow, eller en out-of-bounds read eller write. Disse bugs har i lang tid været meget lette at finde med fuzzers, fordi fuzzers sprænger hele det træ, som programmet kan eksekvere, og finder alle edge cases i det. Problemet med en use-after-free er, at du skal have det, der kaldes en temporal bug: en bug, hvor flere tilstande opnås i programmets eksekvering. De opsummerer det i deres skill.md-fil, de giver LLM'en: Her er de to invarianter, der skal gælde for, at en use-after-free ikke eksisterer. Gå find, hvor denne invariant brydes. Vi har disse to forskellige tilstande, der kan opstå, og én af dem er en fatal fejl under fallibelt arbejde. Gå find den. Dette er ikke noget, fuzzers kan finde, fordi fuzzers tilfældigt bevæger sig gennem kodebasen og leder efter coverage. De prøver at få mere og mere coverage på grafen over kodebasen. De er ikke optimeret til at skabe to forskellige temporale tilstande i programmet, hvor den ene er et fejlcases, og den ene ikke er. LLM'en er rigtig god til netop det. Du kan specificere: Kan nogen af disse to tilstande eksistere? Og, afhængigt af hallucinationer, kan den finde dem meget hurtigt. Så vi vil begynde at se mange flere af disse bugs falde ned fra himlen. Og jeg vil fremhæve, at vi lige har haft hele verden kaste deres LLM'er mod PHP. Det er sandsynligt, at flere pre-auth RCE'er vil dukke op af ingenting. Så bare en advarsel til klassen. Dette er måske ikke enden på det.

Ville Rust fikse det?

Og ville Rust fikse dette? Faktisk, ja. Jeg mener, jeg advocater ikke for, at PHP-teamet skal omskrive hele PHP i Rust, for det giver i sig selv problemer set fra et code drift-standpunkt. Men dette er jo en use-after-free. Det er bogstaveligt talt et reference-counting-problem på en global pointer, der bruges på to forskellige måder, den ene efter at være blevet frigivet. Og det er netop det, Rust praler af: Vi gør borrow checkeren på compile-tid, så det kan ikke ske. Okay. Åh mand, skræmmende tider.

Ugen der i øvrigt var skrækkens uge

Dette sker samme uge, som jeg ankom hertil ... jeg kom for to dage siden, og dette droppede: En indisk certificate authority, e-Mudhra (undskyld, hvis jeg udtaler det forkert), havde otte certifikater, hvoraf den private nøgle til én af dem var lækket, så en masse certs blev invalideret. Og mens jeg optager dette nu, tror jeg bogstaveligt talt, at lige præcis nu er der droppet en GitLab-CVSS 10. Så det ER åbenbart vuln-sæson, folkens. Forbered jer, patch jeres bokse, tryk på like-knappen. Ses, farvel.

Transcriptet er organiseret i sektioner med overskrifter, og alle sætninger fra originalen er bevaret og oversat til dansk.

Transcript

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 PHP1 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 1's uh OneCon 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 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 MyAdmin. 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 Damon do things. If there are vulnerabilities in the way that PHP parses and handles the request, that can lead to remote unauthor 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 zeroday connoisseur, they say on Twitter, and this is a vulnerability. This is a video of them exploiting the vulnerability with your traditional, you know, anime girl dancing kind of thing. Uh, but the TLDDR here is this is them throwing the exploit. So, the best write up that I've seen on this is the the Khif.io write up. I believe the hacker that found this LCFR is associated with Khif. I'll link their Twitter and the URL for this write up in in the description down below. Again, I'm not going to read this right 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, if 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 prep-processor. Yes, it is a recursive backronym from 5.4.0 and up to like I think the most recent patch that fixes this is 8125. Okay. 540 was released in July of 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 wampstack on my computers. I had like a buntu eight back when they'd send you the [ __ ] disc and it smelt like pickles out of the bag, whatever. Um, I 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, NexCloud, 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 Damon 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 say 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 khif report explains it much better than I will I'll give a highle 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 73. They wrote a skill.md file that tries to like basically summarize what is the pattern that we saw in 73. And pretty quickly the LLM found another version of that same pattern in another area of PHP. So you may have seen this um 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 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 53 in the um file upload process. Right? So again, you've probably seen on Twitter talks of this um session upload progress feature. This is a feature that allows you to upload files associated with a session. And again, all this code runs before your PHP script even runs or 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 of 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 that are you establishing a session. Those globals point into the request. Uh later the multi-art 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 an 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 exists. So in a second request, you continue the file upload with another multi-art form. You end the file upload. And what happens here is it reads and then destroys the 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 example that I use in a lot of videos. It's like my cat dog example. But like imagine you have two strrus, right? And if you're not a programmer, a strct is literally just like a a a conjunction of two data types, right? So in this example, you have the name of an animal and the function pointer to it 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 woof 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 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 function pointer in the dog scenario. Obviously an extremely simplified like version of the uh the the exploit pattern we're talking about. This is literally function pointers. Achieving rce via a use after free into arbitrary readwrite 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 Johansson over at Vulnerable You. It's [ __ ] awesome. We have a great time. It's called The Lowdown. We literally just yapp like this for like an hour at a time about vulnerabilities. Have a good time. 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 hacking ultimately and coding, Lowle Academy has some big changes coming in 2027. Um, so go give that a look as well. That's it. Look at that. That's what That wasn't even That was 48 seconds a sponsor poll. 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 in embargo. And so, they held on to the patch until it went kind of public. PHP released the patch and everything was good. Now in the meantime what was happening was people were trying to use LLM to find the vulnerabilities. So this means like in mass people were throwing like probably GLM53 DeepSeek 41 something something I don't know like a Gemini model and then like all the frontiers at the PHP codebase. 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 is 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 PC 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 Khif's writeup is still present in the 8512 um, patch. Also another highly regarded researcher uh Nicholas Cassus says leaving the sphere 8512 security patch is incomplete 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 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 use after freeze? I worked at 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. 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 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 skill. 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 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 codebase and looking for coverage. They're trying to get more and more coverage on the graph of the codebase. They're not optimized for creating two disperate 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 want to highlight that like we just had an like the whole world throw their LLM at PHP. It is likely that more pre-off rce 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 fix this? Actually, yeah. I mean, again, I'm not I'm not advocating the PHP team rewrite all of PHP and Rust because, you know, there's issues with doing that in and of itself from a u a code drift standpoint, but like this is used after free, right? This is literally a uh a reference counting issue on a global pointer that gets used two different ways. One after being freed. Um 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 the same week I got here on I got here two days ago. This dropped. uh an Indian certificate authority e- mudra sorry if I pronounced that wrong had eight certificates where one of them the private key was four so a lot of search got invalidated 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 doo be vone season guys prepare yourself patch your boxes hit the like button see later bye