CyberWire Daily - A subtle flaw, a massive blast radius. [Research Saturday]

Episode Date: March 21, 2026

Yuval Avrahami from Wiz joins to share their work on "CodeBreach: Infiltrating the AWS Console Supply Chain and Hijacking AWS GitHub Repositories via CodeBuild." Wiz Research uncovered “CodeBreach,” a critical supply chain vulnerability caused by a subtle misconfiguration in AWS CodeBuild pipelines that allowed attackers to take over key GitHub repositories, including the widely used AWS JavaScript SDK that powers the AWS Console. By exploiting an unanchored regex filter, unauthenticated attackers could trigger privileged builds, steal credentials, and potentially inject malicious code into software used across a majority of cloud environments. AWS has since remediated the issue and introduced stronger safeguards, but the incident highlights a growing trend of attackers targeting CI/CD pipelines where small misconfigurations can lead to massive downstream impact. The research can be found here: CodeBreach: Infiltrating the AWS Console Supply Chain and Hijacking AWS GitHub Repositories via CodeBuild Learn more about your ad choices. Visit megaphone.fm/adchoices

You're listening to the Cyberwire Network, powered by N2K. Ever wished you could rebuild your network from scratch to make it more secure, scalable, and simple? Meet Meter, the company reimagining enterprise networking from the ground up. Meter builds full-stack, zero-trust networks, including hardware, firmware, and software, all designed to work seamlessly together. The result? Fast, reliable, and secure connectivity without the constant. and patching, vendor juggling, or hidden costs.

From wired and wireless to routing, switching, firewalls, DNS security, and VPN, every layer is integrated and continuously protected in one unified platform. And since it's delivered as one predictable monthly service, you skip the heavy capital costs and endless upgrade cycles. Meter even buys back your old infrastructure to make switching effortless. transform complexity into simplicity, and give your team time to focus on what really matters, helping your business and customers thrive. Learn more and book your demo at meter.com slash cyberwire.

That's M-E-T-E-R dot com slash cyberwire. Hello everyone and welcome to the Cyberwires Research Saturday. I'm Dave Bittner, and this is our weekly conversation with researchers and analysts tracking down the threats and vulnerabilities, solving some of the hard problems and protecting ourselves in our rapidly evolving cyberspace. Thanks for joining us. What actually brought it to our attention

was an actual threat actor that managed to take over an AWS GitHub repository using another COVID issue. We saw this and he thought it's pretty insane that it's possible to do something like that and that's what originally led us to look at this direction. direction. That's Yovol Avrahami, vulnerability researcher at WIS. The research we're discussing today is titled Code Breach, infiltrating the AWS console supply chain and hijacking AWS GitHub

repositories via CodeBuild. Well, before we dig into Codebreach itself, could you explain to us how is AWS CodeBuild normally used and what makes it an attractive target? CodeBuild is a CICD service. So it's normally used to trigger builds on source code. So what you normally do if you have a source repository, a code repository in GitHub, for example, you would connect codebilt to that. So whenever you do something like a push or a pool request

or you have a new feature and you want your automated test to run, those could run in codebit. And what makes an interesting target is that for code build to interact with GitHub with the source repository, for example, to tell it if you build, you know, failed or something like that, it actually needs some GitHub credentials. And often those are very powerful. And that means that if you are able to compromise a build that's running on a code build, you could end up hijacking the entire repository. So that's why it's an interesting, you know, target for us and for attackers. We saw attackers actually go after it as well. Well, take us through Code Breach. What exactly is going on here? Because the consequence of having a build being triggered for your pool request is that you now have code running in CodeBuild next to the GitHub credentials.

So this is something you wouldn't want anyone to be able to have. CodeBuild has this concept of Webbook filters, which basically mean, in simplicity, it's just a list of, of GitHub users that are allowed to trigger builds, right? So that actually is a valid way to do it. Like it's a bit annoying from, you know, just a user experience perspective to have to like fill in this list of every time someone joins your team,

you search its GitHub user ID, you need to add it to the list. When we saw this, we're like, like our organizations are actually implementing this. Like it sounds like a bit of a hustle, you know? So this is how we started to look into this. We thought we're going to look about, we're going to search for code build projects. And we, our hypothesis was that people are probably just lazy.

You know, they probably are not implementing this. So we went out to search for like code build projects that were configured as public. So you have this setting which makes a code build project public, meaning anyone can see its settings. And that allowed us to actually search for, you know, code build projects. and see their configurations and see if people are actually set in this list or are they being lazy. And we found a couple of AWS GitHub repository, like pretty major one. And we'll talk about one of them later on, which were connected to code build.

And they actually had this list of users. So we were like, okay, good for AWS. You know, they weren't being lazy. They actually narrowed down who could trigger builds in their GitHub repositories. So at first it looked like a dead end, but when we looked at these, you know, lists again, something stood out. The separator between the numbers and the list,

it wasn't like a comma or a space. It was a pipe character, which is, you know, quite odd for a normalist. And then it was actually the clue that this is actually not a normalist. This is a reg X expression, which basically meant that it will not only authorize the user ideas in the list, but because of how Reg X work, it will authorize any user ID that contains an approved user ID.

Okay. Wow. So how does this differ from a more traditional cloud misconfiguration? So I think, first of all, it's not that clear that it's in a misconfiguration. Like the people who configured it in AWS assumed it was secure. And also us, when we saw this list of numbers at the beginning, we were sure like, okay, this is like they specified which accounts can actually trigger a build. So it looks like it's very subtle.

I'd say it's what makes this interesting and why it went unnoticed for a lot of time. And the impact here is really crazy because because of this subtle misconfiguration, you are able to actually take over key AWS GitHub repositories. And we're talking like some of the data. the most crucial gate of propositors that are used all across, you know, AWS environments. We'll be right back. When it comes to mobile application security, good enough is a risk. A recent survey shows that 72% of organizations reported at least one mobile application security incident last year,

and 92% of responders reported threat levels have increased in the past two years. Guard Square delivers the highest level of security. for your mobile apps without compromising performance, time to market, or user experience. Discover how Guard Square provides industry-leading security for your Android and iOS apps at www.gardesquare.com. AI is changing how enterprises operate and how they stay protected. It's time to eliminate risk and protect innovation. From March 23rd through the 26th, join Trend AI for actionable AI

security insights. Catch impactful sessions at RSAC, then unwind and grab a bite at their lounge in Trapasueño. Experience industry-leading AI security in person, engage with the experts, and get your chance to win $500,000. San Francisco lets AI fearlessly. Learn more at trendmicro.com slash RSA. Well, can you walk us through an attack scenario here from the attacker's perspective? How do they go about doing what they want to do? So the way to go about it from, like, if you're an attacker, who want to actually exploit this,

you need to open a GitHub account, which has an ID that contains one of the approved maintenance ideas. And this is actually not that simple. an ID like that is available for registration, something like once every five days, because you need the ID to have an exact match of an approved maintainer ID inside it. So every five days, something occurs

that we internally called it an eclipse. You know, when an ID is exactly a super string of an approved ID. And when that moments come out, you just need to flood GitHub with a lot of user, creation requests, right? Because users in GitHub are created all the time.

If you don't create a lot of users at the precise moment where the idea is up for registration, like someone else is going to take the, you know, this special idea. And so we figure out a couple of ways to actually bypass. It's not really bypassing GitHub rate limits. It's just a couple of avenues which GitHub doesn't rate limit at the time. And we find a way actually to create a lot of GitHub users at the, a precise moment to actually capture the attacker user ID. And once you have this user ID, the attack scenario is really simple.

You just open a pool request to the GitHub repository you want to compromise. Once you open it, because codebills sees your GitHub user ID, and because of how the filter is implemented, a build will be triggered from your pool request. And now you have code execution in a build, which has GitHub credentials. So you have those credentials and at that time you can just do whatever you want. You basically add an admin of the repository. You can push code, open poor requests, exfilitate secrets. And we actually saw someone do something like that about a month before our research.

So we know that people are actually, you know, abusing this mechanism. It was a different code with the issue, but, you know, the overall attack pattern is the same. You open a PR, you abuse some is configuration. to trigger a building code build. And once your build is running, you can take the GitHub credentials, right? And just if you have complete control over the GitHub repository, you can release your own code,

you could push malicious code. The main thing is just doing this without being noticed, right? Are there any particular kinds of organizations that would be most at risk from this issue? First of all, anyone that's using, a CICD service can have this issue. The main thing is whether your repositories are public or private, right? Because if you are private repositories only, for example,

the only one who sees the repositories and can attack them are internal users, right? Your own company users. So the risk is much lower than if your code repository is public. And that exactly is what happened to AWS. They, you know, they open source their code. And unfortunately, the side effect of doing that is that anyone can see your code and sometimes the CICD configurations. So if you're an organization that runs CICD builds on public repositories, you should really take notes about it, you know, regarding issues like this. Because what makes them crazy is that the attacker has no prior access to your organization at all.

Right? And he just submits one pool request. he gets his build running and suddenly he's an admin of one of your key components right? It's such a supply chain a nightmare it's a really, really

interesting risk. Now, how did AWS respond once you disclosed this issue? Oh, they were great. They were really fast within I think 48 hours. They already mitigated all of the problematic filters

and they actually released a new feature which automatically instead of having like this list of user ideas that you need to maintain and keep track of AWS now automatically has a feature that checks

what is the actual permissions of the person who opened the pool request over the GitHub repositories right so it automatically detects if you're an owner of the GitHub repository and only if so it will allow a build to trigger.

And this is such a good improvement, but the thing is that this is the default for new code build projects, right? So if you have a code build projects from before this issue, you need to change your settings. And this is the main, like, action item from this issue. Go to your code build settings

and enable this feature. It's called pull request comment approval. And it's, it's, it really is, an easy click and you're much more secure. So the fix is available, but you have to know to do it and then actually go ahead and do it. Yeah. Like AWS fixed the repositories that they have,

that we found are vulnerable, right? But it's problematic for them to just go inside, you know, existing projects and change their settings without the customers knowing about it, right? So they automatically enable this for new projects, but if you have an existing project, you should really look into whether this setting is enabled. From a high level, are there lessons that security teams can take away from this

in terms of trusting managed cloud services? Yeah, it's a tough one, right? Because you don't know that if you implement this yourself, you're going to do necessarily a much better job, right? But I think this falls into the configuration of the cloud service. And in these areas, when you have like a lot of recent attacks, and the industry is a bit behind like CICD security, I think you really need to like double-check your configuration.

And if there are any way for you to reduce the privileges, you need to do it, right? CICD is such a problematic very. right now, we see countless attacks. So the main point is you want to close the biggest, you know, the biggest attack surface right now, which is public repositories. So you really need to look at the CI CD services of your public repositories and try to secure them first because they are open to the world.

And this is what makes them good targets for attackers. Our thanks to Yovall Avrahami from Wiz for joining us. The research is titled Code Breach, Infiltrating the Aal. WS console supply chain and hijacking AWS GitHub repositories via code build. We'll have a link in the show notes. And that's Research Saturday, brought to you by N2K CyberWire. We'd love to know what you think of this podcast. Your feedback ensures we deliver the insights that keep you a step ahead

in the rapidly changing world of cybersecurity. If you like our show, please share a rating and review in your favorite podcast app. Please also fill out the survey in the show notes or send an email to CyberWire wire at n2k.com. This episode was produced by Liz Stokes. We're mixed by Elliot Peltzman and Trey Hester. Our executive producer is Jennifer Ibin. Peter Kilpe is our publisher, and I'm Dave Bittner.

Thanks for listening. We'll see you back here next time. If you only attend one cybersecurity conference this year, make it R-SAC 2026. It's happening March 23rd through the 26th in San Francisco, bringing together the global security community for four days of expert insights, hands-on learning, and real innovation. I'll say this plainly, I never miss this conference. The ideas and conversations stay with me all year.

Join thousands of practitioners and leaders tackling today's toughest challenges and shaping what comes next. Register today at rsacconference.com slash cyberwire 26. I'll see you in San Francisco. Getting ready for a game means being ready for anything. Like packing a spare stick. I like to be prepared. That's why I remember, 988, Canada's suicide crisis helpline.

It's good to know, just in case. Anyone can call or text for free confidential support from a train responder anytime. 988 suicide crisis helpline is funded by the government in Canada.