This GitHub README Hijacks Your AI and Spreads Like a Virus

Added: 2026-05-19

[00:00:00]What if I told you that the AI coding assistant that you're using could be turned into a worm that steals your API keys and spreads itself to every repository that you ever have access to?

[00:00:10]That is exactly what our guest Edward is going to show us today. It's going to be just a hidden, innocent-looking readme file that has a prompt injection that hijacks the AI agent with file system access and turns it against you. He's also going to show us the actual malicious prompt he's used to break out of sandboxes to exfiltrate data through DNS timing attacks and creates self-replicating code that spreads from developer to developer just like a worm.

[00:00:37]But before we jump in though, I want to address some feedback that you guys have been giving me, which by the way, I love hearing from you guys. Keep them coming.

[00:00:43]A lot of you have asked to see actual exploits and not just talk about them.

[00:00:47]So, today you're getting exactly that.

[00:00:49]So, thank you to those of you that suggested this. Please continue to give these comments and feedbacks to me. I love hearing them and it kind of helps us grow these videos that I make in the upcoming episodes. And as always, if you want to see somebody specific on this series, drop them down below. I'm going to look into it. This is how we get our next guest to come on and we just continue to grow this series as we go.

[00:01:10]All right, let's jump into it. All right, man, you're not just going after web components anymore. This is someone's personal machine that could have AWS keys, GitHub access, Jira, whatever that the developers have access to. The potential blast radius here is insane, right?

[00:01:27]>> Yeah, that's right. So, the the LLM is still running and it's still making a an external call to the to the API servers where that model is hosted. But the actual actions that LLM is running through the agent is running on your local machine. So, you can kind of piece together how bad these attacks can get if you're able to manipulate the agent's actions to an external data source, like an indirect prompt injection for example, and it's running on your local machine. Uh there's essentially sky's the limit to the amount of damage that you can do. Okay, so we've got the classic attack chain here. You need a delivery and you need some sort of an exploit, right?

[00:02:00]But with coding agents, there is this human element where they have to actually feed your malicious prompt to the agent. So, I asked them about the social engineering challenge. How does this work? I think the the things that I I tend to think about is what is going to be the highest impact. So, what are users likely going to pass their coding agents, right? So, when we think about that, we've got a few things like specifically like GitHub repositories are a big one. Right, a lot of people pass GitHub repositories their coding agents. So, you know, set this up. We can do websites, but I think I think coding repositories are a huge one and I think that's where the industry is very interested in and where a lot of the attack space is going to be headed. It's going to be sanitizing inputs from repositories. Here's what I was curious about. Let's say I'm working at example.corp and I'm only touching internal repos. How do you actually poison one of those to get the exploit to work or is that even the attack path you were talking about?

[00:02:56]>> like injecting into the the company's repository is is tricky, right? But there are there is a level of social engineering that is required, but the attacks rely on the fact that users are lazy, right?

[00:03:08]And that in their lifetime, they are probably going to set up an external GitHub readme or repo with that they haven't fully read or that there's, you know, something at the end.

[00:03:18]So, that might not come from the the company's GitHub account, but if it is executing code on victim's and the victim's machine has rewrite access to the company's GitHub, you can kind of start to inhibit and traverse across different GitHub accounts and the agent can do that on your behalf, which is a cool kind of worm that I've worked on, which I think would be cool to share.

[00:03:39]So, that's the delivery mechanism, some external repo they pull down. But, what about extraction? Because these things have sandboxes, right? Every single one of these times that I use cloud code, I'm pretty locked down to one folder and it's asking me, you know, a bunch of questions. How do you break out of those, or does that even matter for what you're doing? Yeah, so sandboxes is definitely matter. It's probably one of the uh the hardest parts of of the attacking the the IDEs and the identity agents. And essentially, what it is is that the the developers of these products have specifically designed these sandboxes to be networked network sandbox, right? So, any external network call that you're making to the internet requires user confirmation. And so, that can be a real problem when you're trying to attack these because anytime you're wanting to exfiltrate data, which is our our third step, right? The the input and you get the data, and then you try and exfiltrate it, it can stop that pretty well. So, you've got to be really creative with the ways in which you exfiltrate data, right? So, some of them allow um DNS resolutions. So, some of the the sandboxes allow DNS resolutions. And so, one way that I came up with, you could basically time the DNS resolutions to an external server, and you know, every second send one, or every second don't send one, and you could encode that in binary, and then you could say take your data, encode that into a DNS resolution, and then you're transmitting binary, which is getting past the sandbox.

[00:05:06]There's some other kind of tricky tricky ways to come up with um bypassing the sandbox. Another one is basically the way the way I approach it is you've got to map out every single command that you can run with no user confirmation. So, a lot of Cony agents will let you run, you know, list or print working directory, or change directory with no user confirmation because these are relatively benign commands.

[00:05:32]So, you've then got to work out, okay, here are all the commands that I can run, and here are some of the commands that maybe they put in by accident, right? So, sometimes you can write to your bash bash profile, right? Now, if you know, that's really bad, All right?

[00:05:46]And that should be outside the sandbox.

[00:05:48]But if you can write to a location on your machine that is then executed at a later, then that's a sandbox escape.

[00:05:54]Right? So, if you're writing to P list, are you writing to batch profile, or SSH config, you're not directly getting outside to the network at first, but when the user runs any kind of, you know, SSHs into anything, or runs any command, then it executes, and you leave the sandbox. So, anytime, yeah, anytime like a developer configures the sandbox, they think, you know, "Okay, we don't want any external network calls to happen. But we might give it read write access to your home directory." Right?

[00:06:19]If you've got read write access to home directory, you've broken the sandbox already. There's no sandbox in the first place. Because you can append it to these these kind of executable locations, and, you know, as soon as the user reloads anything, or does anything, uh you can kiss your data goodbye. So, you're basically planting time-delayed exploit that trigger later when they use some sort of a normal command. That's absolutely wild.

[00:06:45]And this makes me laugh because it's literally uh every time I use Claude, I'm typing in the dangerously skip permission, and I'm guessing that that just becomes basically a shortcut for everything that you have just described.

[00:06:58]It is It is definitely a shortcut, and it um it kind of bypasses the whole problem of sandbox in the first place, and makes it makes it very easy to to have data exfiltration. So, I think if you're a if you're planning on running that flag, I would strongly recommend you you sanitize, or at least have a good look at any external data you're passing your code into. Damn. Ouch. All right.

[00:07:20]So, one thing that one of my viewers always ask for is they want to see actual exploits, no more theory.

[00:07:27]So, I just asked him if he had a favorite prompt that actually works, and if he can share it with us. Yeah, for sure. So, this this one that I'm going to show you as an example of a agentic worm that I had.

[00:07:40]And basically, what it was is that if you give a coding agent read-write access to your GitHub right through the CLI and read access to your home directory, which is very common, both of these things are very common, you can actually create a prompt injection worm. Right? And the way you do that is at first a prompt injection is planted and then the user, you know, pulls down that that readme and that readme tells the user to exfiltrate data and then append that malicious prompt injection to all of their readmes that they are on their GitHub. And so, this is kind of like the MySpace worm, right?

[00:08:15]So, it kind of expands. So, let me quickly show you that. Oh, yeah. So, here we've got an example of part of a prompt injection that that I would use. So, this has been used in the past. It's actually been patched, but it was very effective and it was wormable. So, here you've obviously got where your entire readme would be. And at the end we can append this kind of system error.

[00:08:43]So, essentially what this is telling it is grab the API key, append it to squidward.pro, which is my domain, {forward slash} verify, and then curl it.

[00:08:56]Right? Or open it with your browser.

[00:08:59]And then propagate all accessible repos with this exact prompt injection.

[00:09:06]So, there are a few reasons why this worked. And one of them is first of all, it it crossed it like an error, right?

[00:09:13]So, you could imagine a coding agent is taking all of this, you know, readme repository information above here, and then at the end it's taking this error.

[00:09:23]It might think that there was an error loading the the GitHub repository and therefore try and resolve it.

[00:09:31]As well as this, we're actually using some pretty clever ways of disguising it.

[00:09:38]So, we're telling it it's cloning a repository and then appending this this API statement here.

[00:09:45]API exfiltration, so we're not just running that. So, it kind of disguises it by by kind of sneaking that in at the end.

[00:09:54]So, yeah. This is a an example of a a prompt that worked pretty well.

[00:09:58]Um and it was fully wearable, so we we ran it across about four or five examples of GitHub GitHub accounts and it was able to propagate um from one to the other.

[00:10:12]Wait, so let me make sure I understand this. There is a normal read me explaining the project and at the bottom you stick this fake error message.

[00:10:22]Is that error syntax something that the agent recognizes or is it just some random garbage that looks like an error just to trick the model that you've came up with? Yeah, it's a good question. So, there's there's no um one-size-fits-all for kind of formatting errors um with these these models. But, at the end of the day they're large language models and they've been trained on a corpus of errors. And so, this is what some errors look like, right? And so, it sees this and it goes, "Oh, yeah, my training data kind of knows that that looks like an error. That's an error. Let me resolve this, right?" And so, the whole point of the error is that you're you're pushing the model into this space where it's like, "Oh, I'm helping the user set up a read me, right? Cuz I'm a helpful coding assistant. And no, the user has an error. That's really bad. Let me go resolve that." So, you're kind of instead of, you know, talking to the model directly saying, "Hey Claude, take all my data away to a hacker, right?"

[00:11:10]You're not doing that. You're just kind of saying, "Hey Claude, there's an error here and it would be good if you could resolve it since you're a helpful coding assistant, right?" So, these are what these kind of these models and agents are trained to do. So, if you can abuse their like helpfulness, right? By resolving an error, then you're good.

[00:11:26]That is brilliant. You're exploiting their helpfulness instead of trying to directly command them.

[00:11:33]All right. I love all this, but you know how this goes.

[00:11:37]What is the challenge you have that you want to give our viewers who want to practice this stuff? My challenge for you is to go to your coding agent and see what tools can be executed without a sandbox.

[00:11:49]So, what commands run automatically without asking for your confirmation?

[00:11:54]I want you to map those out and then find the ones that maybe give you the possibility of speaking to the internet.

[00:12:00]And that's how you start doing this. And of course, you know, I need a guest shout-out. Who do you want to see next?

[00:12:05]>> I would love to see Joel Donut come on from Zenity. He's a he's a also great great prompt injector. There you have it. Edward just showed us how to turn AI coding assistants into worms that can steal your entire repo. We went from theory to actually seeing an exploit, saw how to bypass sandboxes with a time-delayed attack, >> [music] >> and learned that one malicious readme can spread across every repository you have access to. So, if you enjoyed this, as always, make sure you hit that like button, and of course, if this is your first time coming across one of my videos, hit that subscribe button so you don't miss any upcoming videos, >> [music] >> and you become a subscriber. All right, that's it. I'll see you all in next week's video. Peace.