Know Your Enemies: Live Exploit of a PHP Engine Security Breach - Alexandre Daubois

Please welcome Alex Dborah. >> Thanks. Um, does this work? Maybe. Oh, yeah. I need to w I think I'm going to talk very loud. So, all right. So, thank you very much uh for attending this talk. You made the right choice. Um so we are going to talk about security breaches and how those kind of things can be exploited and what they are actually really concretely what those security bres are in the PHP code. So uh first let me introduce myself. I'm Alexando. I'm the CTO of lett.com a French company creating many uh web applications and so on and also maintain a few oss project I'm going to talk about uh just after that I'm part of the symfony core team uh also part of the front end PHP core team and recently I joined the team of maintainer of PHP. So yeah pushing a few pull request here and there and having also so some RFC accepted. So pretty happy of this year. So as I told you I'm working at latial. And we maintain opensource projects uh such as Symfony API platform uh front end PHP the PHP interpreter. Uh so here who is using Symfony daily okay and API platform maybe. Okay a few. and funk and PHP. All right, you should use it. Uh I'm not going to ask about the PHP interpreter of course. Um but we have a few um people at Latiel that are maintaining this. So myself of course, but also Kev Nlas that you may know. Uh and we have yeah that is maintaining API platform and so on. So OSS projects are really our core um yeah business actually and PHP is our expertise. So of course we maintain also a few other projects but clearly our expertise is PHP and that's why I want to talk about PHP today. Uh so a little throwback about PHP. So it was first released in 1994 released for the first time and uh in the year 2000 the Zen gine 1.0 0 was released with some huge P improvements. Then four years later, Zenjen 2.0 was released and then uh that was the first time that we were able to do some object-oriented programming in PHP which wasn't the case before. You had to just do some functional programming and so on. But then in 20 uh in 2004, you can finally use classes, objects, methods and so on. In 2020, we have the just in time compiler that is introduced uh which allows to bring amazing performances to uh application that are CPU intensive, heavy math and so on. And in 2025, we have PHP 8.5 that is released and PHP 8.6 is scheduled to be released in November 2026. Why am I showing you this? it's that um PHP is 30 years old and counting and it's still being uh developed and it's still evolving in um thanks to the PHP foundation in a few for the few years uh past few year there are now core developer that are paid to fully work uh on the PHP interpreter which is a big uh relief for the PHP engine and yeah the the language is evolving super quickly. And that's uh really great news. So PHP is not dead, of course. Um so yeah, maybe you already saw this page. This is the source code of the PHP interpreter. And uh yeah, there are more than 145,000 commits for the last 30 years. So it's huge. of course uh since the beginning is that it's like uh 4,800 uh commits per year. So it's pretty huge. Um it's also 13 commits per day or an average time between two commits of two hours. So it's evolving quickly and uh yeah it's not definites, bring new features, uh fix bugs and so on. So, the project is more alive than ever. And this is thanks to more than 1,000 unique contributors and it also has like nearly 40,000 stars on GitHub. So, yeah, these are just numbers, but it shows you that this project still has a lot of interest. I'm sure that you are all agreeing with this of course in this room but for the times I show this uh this presentation to some conferences that were not PHP focused that's good to remind and of course PHP is pouring like between 75 to 80% of the web thanks to WordPress of course uh but yeah really this is huge and of course whenever someone wants to create a new um he shop or personal blog or things like that they are going to use WordPress. This is the solution by default and this is why PHP powers that much of the web and as you can imagine with a surface of attack of this large security is the main focus and this is the most important yet most complicated um topic in tech projects of course. So yeah this is really a big deal. So this is the page of the security advisories of the PHP source. So as you can see there are many uh security advisories that were published. So these are not the advisories of the 30 uh years uh of PHP, but we can see that we have some security advisories with some that are pretty recent like uh the very last one July 3rd of 2025. So people are still uh discovering security breaches in PHP and people are still fixing them. So this is great. And as you can see in the at the right of the screen uh we can we have like a score. So here we have moderate and low. And this is calculated thanks to the CVSS the common vulnerability scoring system. So this is a scoring system that gives you like how bad is the security breach that you are dealing with and there are a few factors that are determining the score that you are going to have uh for um for a breach. So we have eight of them. First one is attack vector. Does this um this bridge can be exploited uh through the network or do you have to to have access to some physical device or so on? Attack complexity. Is it complex to exploit this or is it super easy and nobody with no prior knowledge can use this security vulnerability. Third one is privilege required. Of course, if um bridge is uh requires you to be like logged as an admin, it would be uh a bit less worse than if uh anybody can use it when being anonymous or things like that. user interaction. Uh this means that um does your bridge needs someone to do something uh on your on their behalf and or the bridge can be just used uh without anyone doing anything on their computer for example. The scope does the bridge um affect everything in your project or just a little part. confidentiality. Does the bridge is already well known by everybody or is it um yeah not known at all for for now and yeah of course if nobody knows about it it's less worse integrity does this um break or compromise some of your data because remember that this scoring system is about all type of tools and projects it's not just about PHP so PHP is a language so for the integrity it's not really relevant But for any other tool or library or things like that that can be really relevant. And finally the availability. So if your security breach um is available available uh in every version of PHP for example this is really bad. But if it's only on the latest versions or an old version that is nearly not maintained etc this is as bad of course. And thanks to those factors you can determine a score. And uh so this is a unique ID that is generated when you have uh like answered every u factor that I just show you. Uh really okay it's a it looks like a bit complicated but really it just all the answers um compacted in just one string. So you the first one you have so CVS 3.1 this is so this is a version of the scoring system and then AVN. So AV is attack vector N network for example in this case and then you repeat the same thing for each factor and then you have a unique not a unique but a string that is uh compact and uh have all the information that you need for the scoring system and once once you have this you can determine the scale. So if it is zero there is no vulnerability of course zero to 3.9 slow then moderates then high then critical or exceptional the most of the time you are going to see moderate and low uh security advisories of course if it's critical or exceptional well it is exceptional so we never so see them literally uh sometimes it happened like the the time where we where there were some breach in the XZ uh library or tool that we saw like two or three years ago, something like that. This is critical and exceptional because it's widely available and um yeah, it can be a back door and super easy to to use. So yeah, that was critical or exceptional, but we saw in the security advisory page of the PHP interpreter that it's often low or moderate, but that doesn't mean that this is not bad and we are going to see this. So for this uh I want to yeah show you how do they really look like the security witnesses because we all hear about security witnesses and so on and vulnerabilities and back doors and so on but we don't always know uh what they look like really and how they can be exploited why the code is vulnerable what makes a code vulnerable so for the first example I'm going to talk about CVE 2035 uh uh 1220. So null bite termination host name. So this is a real um security advisory of the PHP interpreter that was uh disclosed um last year in July I think or June anyway it was last year so pretty recent and it was about opening a socket in PHP with built-in function focus vulnerability. So what you have to know is that uh in the PHP interpreter sometimes PHP is just a C wrapper. So for many low-level functions um yeah or system functions or things like that the BFP interpreter actually just wrap a C function just registering it as a PHP function telling okay this is available in the language but actually it nearly what it does is just yeah okay call the underlying C function and that's it. So you have the PHP function fog open in this case wrapper in the PHP interpreter that just register this function and then calls in C function and it makes of course a few uh verification about the arguments that you are going to to provide if it's a a string if it's an integer and things like that and in this precise case of CVE the problems lies in the underlying C function well not exactly it's not the C function that is vulnerable but we are going to see what's um what I'm talking about. So for that I just want to remind how strings are managed in C. So string management in C um you really deal with pointers. I mean that you are when you are dealing with strings in C you are telling the C language okay I have a pointer to this memory address. And when you want to store for example hello in C, it requires six memory blocks. So one for each letter and then one final memory block to tell uh to put the null by string. And this is what is going to tell the C language that this is the end of the string because you are not dealing with just an abstract string like in PHP for example. It's really you are dealing with memory blocks. And when you have just memory blocks, you you have to determine something that say that says okay this is the end of the string. And the convention is that we use the null bytes. So you have something something like that. You have the whole memory. So like one one GB of memory and then you have your string pointer at the first line at the first letter and if you want to read the second letter you are just going to increment the string pointer because memory addresses are just integers. So you have the string pointer plus one it's a e plus one lu uh and when to stop whenever we encounter this the null by termination we note that this is the end of string and this is a convention that all C developers and C++ and so on uh know and adapt and every functions uh in the C language are using this convention. The null bite is what uh yeah tells you this is the end of the string and you should not read after that because if you try to read some memory that you are not allowed to read them because it's after the null bite then um you are going to have like a sec fault or just your program is going to crash or this is an undefined behavior. So you don't want to do this. Of course, you don't want your program to crash. And in the case of this CVE, that was a huge problem because in PHP, you're like, okay, I'm currently manipulating a string, just a string. I don't have to care about memory blocks and so on. But in C, it's I'm currently manipulating a pointer. So there is a slight difference between those two that makes the vulnerability because actually you have the wrapper in the PHP interpreter that deals with strings and it called the underlying C function that relies on null bytes but in PHP you are allowed to have the null bite in the string that's completely allowed you can do whatever you want but in C you can't. And this is a slight difference that makes um this vulnerability exist. So this looks like this. We have fs sock open. We want to open a socket to an address and write something in uh in this and then close a socket. But you can see that we have a null bite just after local host and this is allowed in PHP. You are allowed to have null bytes in PHP strings but not in C. So what really happens here and this is what I want to show you uh live. So, I'm going to change just the setting. Okay. It doesn't crash. So, it's maybe a bit Uhhuh. bit um small like this. Is okay? Yeah. Fine. All right. So, um let's say you have a Docker file with a basic setup. So, I chose 8.3.22 22 because this is the latest version of PHP that is affected by this bridge of course. So we have this docker file that we are going to run right now. Uh yeah like this. Okay. Um so we have a docker with PHP that is running inside. And what I want to do as well in the setup is create a secret services secret service inside the docker like this. So we are going to have another service which is a PHP server that listen on this port with a few files but that's it. But it's just an internal service of the container. So you are not able to access it from the outside. Okay. Like this. Right. The setup is complete. We have PHP that is accessible from the outside and a secret service in the container which is not accessible from the outside. And then we are going to have a look at this. So I'm going to run the first query. So oh no just want of course to show you the PHP file first. So in the PHP file what we are going to do is okay we have a nost and a file in the query parameters for example and we want to ensure that the file and the host that we are going to fetch thanks with this script uh the host ends with secured partner.com. So we are sure that we are gathering the file from our secured partner and if we can't then unauthorize domain and we stop here. If the host in the query param hands with secured partner then we can continue and we we are going to try to read the file on the server. So here we are going to open the socket. So fs open with the hosts the ports uh yeah and some setup etc. If error management as usual and whenever the socket is open then we can craft our HTTP request to gather the file that we are we want to fetch. So we have the HTTP request. We want to get the file uh and we write it to the sockets and whenever we have a response here we are going to get the response from our secured partner. Close the socket and then return the response. Okay. So this is just a simple script that says I want um yeah my application I wanted to get some file from our secured partner and yeah just like man in the middle actually but yeah with some some checks like this. Okay. So, of course, if I'm going to execute this query like this unauthorized domain, of course, because we have the host here, which is just our local host and the file, but the domain doesn't end with secured partner.com. So, of course, it doesn't work. Now, let's try the seon query here. So, the difference here is that okay, the file is the same, but the host is the local host some null bytes uh null bytes um encoded in the URL because this is also allowed of course and then we end with secured.com and then we get a file and if we try to uh yeah just run this well we have something special here this is actually something that was inside the secret service that I created did earlier. This is the API keys.json file and it worked. But why? Because I have this it ends with secured partner. So what happens here exactly is okay we get the host. We check that it ends with secured partner.com. So it works of course because once again null bytes are allowed um in PHP strings. So yeah this check pass and then we try to read the file and then we have the culpit here which is focopen. As I told you focus just was just a wrapper around uh the C function which has the same name but because the C function relies on the null bytes. What happens here is that it receives this but the C function see the new bite here. So it says okay this is the end of the string because this is a convention. So the whole part is discarded and what focop is going to see is just that the local host and because uh this is inside the container uh of course I can access a secret service that I created earlier. Okay. So yeah, this is the whole security breach here that you can see. It is because the focop just discarded this because it's just a wrapper around the C function. And in C the convention is that the null bytes is the end of the string. All right. So let's um change this again. Nice. Okay. So what we just did here is server side request for joy. We created some query some requests on the server that wasn't supposed to be. Um as an example for this CVE the score was 5.9 out of 10. So it is it's a moderate security advisory but it's not actually that moderate because it's bad. It allows to create some request that you're not supposed to do and so on. So the first thing that I want to tell you is that maybe it's moderates but that's maybe the problem because uh it's maybe not the right word. It's not critical but it is impactful. So don't underestimate when you see a security advisory with some moderate or low uh severity. It may be impactful for you actually. So language boundaries are attack surfaces and PHP is memory safe but C is not. And the boundary is where the bug uh that the bug was born actually. And that was not necessarily old code that was not uh protected enough or something that it was just that it was a dangerous interface actually. Uh PHP strings are not C strings and implicit assumption uh makes vulnerabilities. Uh so yeah, as I said, bugs not um vulnerabilities not always come from complex code, but sometimes from obvious code because that was not that complex and that was pretty um easy to fix actually. Uh but yeah, because that was maybe too obvious then a vulnerability was born and yeah um security audit should sometime also includes runtime. So not just userland, not just frameworks, but also the engine itself. And auditing a PHP framework without understanding the the engine it runs on might might be incomplete in some cases. So yeah, it's important to understand how things work deeply and internally to really understand what you are looking at and what vulnerabilities can be uh discovered. All right. So that was the first vulnerability that I wanted to show you and that was an example of a concrete vulnerability how it looks and how you can protect a gam this against this. Well, you can maybe just uh do better uh input sanitization and things like that. Better input validation of course never trust something that the user is sending always. So harden your validation rules and everything is going to be fine. All right. So the second uh bridge I'm going to talk about is a pretty different and I'm going to talk about the zerod back door. So maybe some of you already know the story behind this but I know that a lot of people ignore what happened actually in PHP a few years ago when the back door nearly made it to a P PHP final release because it made it to the final to the release candidates of a PHP version. And yeah, I wanted to talk about this one because it's about back door and back doors are frightening and we always hear about uh it's super bad or we have a back door and so on but what actually is a back door, how it looks like and how you can how people can actually exploit them. So everything begins with a commit in March 2021 which is skip CI. So this is a special tag in the for the PHP interpreter to just keep the CI when you just want to fix the typo and so on and you don't want to run the the full CI of course. So this is the typo. >> Yeah. So this is not a typo of course. Uh and we are going to have a deeper look at this. Uh I just want you to notice the file where it is um added. So zib C. And that was pretty strategic because in every default installation of PHP you have um Z zedlib which is uh enabled by default. PHP relies on on a full extension mechanism and zlib is actually one of those extensions that is enabled by default in PHP because it allows to compress all the responses you are going to send back to the client and so on. So it is enabled in every installation by default but this can be disabled but distribution Linux distribution like DBN Ubuntu and so on uh distributes PHP with this enabled by default. So everybody is u yeah concerned by this and the thing that we showed that is obviously not a typo uh actually added some mechanism to um have a look at this HTTP user agent with 2T. So, PHP when it receives the requests automatically uh parses the HTTP request and all the headers and is going to store all the headers into uh um headers globals a global variable in the PHP interpreter that has uh everything all the HTTP headers and so on. So, this is actually how PHP normalizes uh HTTP headers http underscore and then the name of uh the header. So here user agent which is um HTTP to tell okay I'm sending your request from Safari, Firefox, Chrome and so on user agents as usual but there is a a typo and we are going to see why. So this is u actually the typo that was uh introduced in the commit earlier and we are going to have a look at it. So the first line is uh you can see that we have HTTP globals on the first line. So this is the global array where all HTTP errors are stored by the PHP interpreter when it receives request and then we have Z ash str which is okay in this hashmap find uh find the the element that that has this key. All right. So in the HTTP globals variable array, we are going to have a look at a precise key which is HTTP user agent with 2T. Which means that we are going to check if there is an HTTP header called user dash agent with double t. This is what the first line is doing. And then in the second line uh we have we are going to check that the zerodm string is actually in the http header and this is important and whenever we find this value in the header then we can call the zen evil string function. Basically this function is like okay I'm going to give you uh this PHP script just execute it whatever it is we evaluate the string just like the eval function in PHP of course. So if we can resume uh we have a look at HTTP globals we find some special header and if it contains a special value then we can execute any PHP script that is given after this value. So I'm talking about zerodm uh for a few minutes now but actually uh they are not related to this. It was just some troll or things like that uh from the aer uh just to make things a bit uh things a bit more complicated uh to understand from where it comes but zerodium which is a zero day vulnerability marketplace has nothing to do with this vulnerability and we don't really have any more exp explanations about this. So this comet how such commits can make it to the PHP source tree. This is the biggest question of course. Well the distant discovery is that the commit was created and pushed by which is no one than other than the creator of PHP. So the creator of PHP pushed this and it was reverted by Nikita Tapopov a few minutes or hours later. Nikapov which is a big contributor of PHP. Uh he for example he contributed the generators or this kind of uh features big features. So that was one of the biggest contributor of the PHP engine. So it was so the uh fixed typo was reverted by Nikita before being reverted again by Nikita Tapopov. So we have the creator of PHP introducing a back door. Then one of the biggest contributor reverting it before reverting the revert and then finally Ley Morrison reverted uh the revert that reverted. Yeah, you got it. Yeah. So you are like just what just happened and also that just um happened in a few hours. It was it was not like in a in days or months or that just it was just in a few hours and before I give you the answer of this mess. Um I want to show you the actual back door uh running. So let's change like this. All right. So in this second example, I have here an executable compromised. So if you ever receive some executable from me, okay, know that it's compromised. So don't push it to production, of course. So this is um the actually the the version that was affected by this commit uh wasn't computable anymore on my computer at least. So I took um the latest PHP 8.6 six uh Dave branch and I cherrypicked the commit and built um another compromised PHP executable. So this is compromised um and okay so we have a MC file. So yeah just let's run it like this. Okay so we have our compromised server that is running with the back door. So the index is just this okay hello from index.php and that's it. And now we have our uh request. So I'm just going to send a get request to our uh server. And I have a special HTTP header here, a user agent with 2T with zerodm just like we saw earlier and then some PHP scripts and it can be really whatever you want. So here, of course, a call to system to have a few insights on what's happening on my own computer. Super useful, but you get it. You can put everything you want here. And of course, because this is compromised, if I run this, okay, so that's nice. I have hello from alex.php, but also I have everything in my computer. So system I went to go on projects pwd prints this and then ls everything and I have everything. So I can literally yeah just execute anything and this is a real back door. Okay. So this is how it looks like and anybody can actually use this if the PHP execut executable is compromised and as you can see I don't need to be logged in. I don't need any user interaction. Attack vector is super simple. So as you can imagine such vulnerability would be critical exceptional of course uh but it's also yeah a bit hidden because you have to know that you have to put a second T to user agent which is uh yeah super hidden and you also have to put this prefix for it to work. So it's hidden in the PHP source code and nobody is going to discover it by accident by doing some request to the PHP interpreter. All right. So that was No, that's not it. Uh okay. So that was the demo of the back door. All right. So as you can see it was super easy to use. And I want to remind you that PHP is powering 80% of the web. So imagine if this made it to some release and nobody saw it. It wouldn't be just a catastrophic. So how did this happen? Why the creator of PHP and one of the biggest contributor would push something like this? Actually it was not them. It was that the VCS server of PHP was compromised as this time. And as you can as you know uh g doesn't do any verification about your identity. You can put everything you want in user email or user name configuration of gits and there is no verification that it is your real name or things like so likely the the made it to the g server of PHP and just use the name of Mustikita. So yeah, sorry, but it was not a huge story where the creator of PHP wanted to sabot sabotage his tool, but what you have to know is that it made it to the PHP 8.1 release candidate one. So it was not a dev branch or it was not yeah some alphabet or things like that. It was a release candidate. So it was nearly ready to be distributed to the to the world and be packaged in all the repositories of Linux distribution such as DBN, Ubuntu and so on. So you can imagine that it would it would have been uh pretty bad if it made it to the final release. Um because of this incident um PHP uh maintainers uh and people that uh yeah manage the whole PHP organization decided to switch to GitHub at the official repository host for PHP. Um before that it was just a mirror of g.php.net But they were like okay it's too much of a burden to maintain our own uh VCS server so let's just switch to GitHub and then it won't be compromised as it was for our own server. So a few things to understand from that is that trust is not a security mechanism. It was made by reputable authors even if it's were it was not them but reputable authors on reputable project and it was still compromised. It's not because okay it's a it's a big name that created a commit just to fix a typo that it's a trust mechan a security mechanism. All right. So now we have GPG key and so on. But yeah in this case nothing was signed and uh yeah someone could have say okay this is big contributor so I don't have to check anything but actually it's not a security mechanism. Your infrastructure is part of your threat model. So VCS CI release process these are things that you must absolutely take into account when you are doing some security audits. uh it's not just okay we have a VCS we have our CI that do yeah unit testing and so on and you have to yeah think about it also as uh of part of your treat model of course always open open source is not immune but it is resilient and it was detected reverted and publicly documented and it would have not been possible if it was some pre proprietary code so thanks to the open source some people went through the commits and saw this and and they alerted uh yeah the maintainers that something suspicious was uh being done. So we don't know exactly how they um managed to enter the VCS uh the version control system of PHP at the time or it's not publicly documented um for this part but yeah we know that uh thanks this is exclusively because of open source and this is why open source has such a huge reputation in security and why it is more resilient uh than proprietary code because of this kind of thing that can happen. So yeah, language bundaries are attack surfaces. Data structures are not the same everywhere. So think of it sometimes it can be really useful. Security audits should include the runtime. Trust is not a security mechanism. Infra is part of your threat model and open open source is not immune but it is resilient. Um well that's it. Um, I hope that you learned a few things about uh what are concretely um security vulnerabilities because we always hear about them and oh it's bad, they've been hacked and so on, but we don't know exactly what it looks like. So maybe those are not super complicated, but it allows you to really understand from where it can come and how to protect yourself against them. So more input valid, more input sanitation uh validations and things like that. And of course, open source is super uh super resilient and okay, not immune once again. But yeah, this is why open source is so known for being super um yeah, super secure because people from all over the world can just go through the commits and do some security audits on their own and yeah, that's what uh makes it reputation. Thank you very much. uh if you want to follow me um on I have a blog and also some socials or where I uh where I share a few things like that. Uh so if you want to follow this is where you can find all my links and I'm really glad that you were here and I hope that you learned things. Thank you. Thank you Alex. All right so complete failure on my part. forgot to mention that we have a Slack. We have a channel for each room where you can ask the speaker questions. Um, so if you do have any questions for Alex, you're right to laugh at me. Yeah. Um, if you do have any questions for Alex, please join the Slack channel now. Join the Woolbrook uh channel and then ask them away and I'll try and get to them as quickly as I can. In the meantime, Alex, I do have a couple of questions >> um for myself. >> How are these vulnerabilities typically discovered? Well, it really depends. Um, but most most of the all the open source projects have an email address where you can send security uh vulnerability reports. Of course, if you have discovered something, don't create an issue on GitHub to tell everyone that you discovered the back door, of course. But uh yeah uh there is an email where people from the security team so there are a few people in the foundation that are part of the security team of PHP uh that reads the the emails and yeah they acknowledge um the report and then do some investigation and create the fix and then warn everybody once the fix is uh is found. So yeah, it would deserve a whole talk about it, but typically that's people that are sending email to uh yeah specific email address. So Symfony also has such address. So security.com PHP it's like security php.net I guess everything is on the repo. So yeah, typically that's like this and fuzzing um also happens but fuzzing it's more for like it detects segmentation faults or edge cases and so on but fuzzing is not really the best way to discover security vulnerabilities. It can but it's pretty random. So yeah >> sense. Um Paul wants to know should the foundation have a bug bounty program considering the significance of PHP? >> Maybe. Uh I don't know >> your opinion. Yeah, >> saw the eyebrows go. >> I would love to say yes, but the foundation is already uh always looking for funding and sponsors just to pay people to work on the PHP interpreter full-time or part-time. So, yeah, it would be great, but I think that for now, this is not maybe the pri priority. uh we all know the financial situation of the whole world actually and um yeah the foundation is also part of this organization that leaves thanks to sponsors and uh yeah so vulkar and it um the foundation also allowed the German government to like spend 150 grand on the security audit. This is why we had so many vulnerabilities in 2025 because like money was given to people to report and find these and then paying maintainers to fix them. So like that is an alternative to a back bounty program is like taking money from organizations and like doing security research with them. >> Nice. Um I guess final question. Ollie wants to know what happened with the revert of the revert. Was it a mistake? It >> was not a mistake. It was actually the hacker that tried a second time to reintroduce the back door uh but under another name but it didn't work. But no, it was not a mistake. was actually a second tative to yeah sabotage the thing. >> It's pretty gnarly, isn't it? >> Yeah. >> Um >> so Nikita reverted found the vulnerability and reverted it and then they reversed it back. >> Yeah. So the hacker introduced it and the Nikita reverted it and then the hacker >> took the name of Nikita and pushed the reverse of the reverse. >> Attention please. And uh >> attention please. The fire alarm is about to be tested >> just in time. >> All right. Well, with that said, please give Alex another round of applause. Thank you very much.