Welcome to Crying Out Cloud, the podcast that will make you
laugh, cry, and reconsider all of your cloud security fears.
It's Eden and Nami Tai. We're back.
And today we have a guest, Sigit Siddique.
Hey, Sigi. Hi everyone.
Segi is a security researcher from the Wiz research team,
finding radically cool things for the past five years at Wiz
and doing security research in the industry for over 10 years.
So stay tuned for a moment because we're going to tell you
the latest and greatest thing he's found, which is A1 liner
remote code execution vulnerability affecting both
github.com and GitHub Enterprise Server, which is crazy.
And we're going to go into it Siggy.
Before we go into the vulnerability itself, which is
super interesting, let's talk a bit about the discovery process.
You've been chasing this lead since 2024, which is a long
time, but back then it was too costly to really justify
continue working on it. What kept you on this trail for
almost 2 years before finally cracking it?
Yeah, So I really like GitHub as a product.
I use it daily. So I thought that if I managed
to find a vulnerability in it, it would be really cool.
It was like a personal achievement.
So I had this lid standing on my desk since 2024, but it really
required a lot of reverse engineering work, which is very
tedious and they couldn't really justify doing it.
But it's 2026 now and we have AI Advance that can do the heavy
lifting of reverse engineering for me.
And yeah, we managed to find a vulnerability at the end of the
day. Let's drill into the fact of the
reverse engineering. So you used a combination of
reverse engineering with AI tooling.
Can you kind of give us a little more detail into your setup and
how it how it works? Yeah, essentially GitHub is a
very complicated program. They have a lot of micro
services there and we don't have the source code for these micro
services. We only have the compiled
binaries. Now for me as a researcher, I
much prefer reading source code instead of.
So there is like a process called reverse engineering when
you turn compiled binaries back to source code.
I personally do it with Ida, but other researchers may use other
software. In any case, this is a very
hard, very tedious process. Especially for like doing it on
4 binaries in different programming language.
This is like really really easy. Just kidding.
This would be really, really hard, so I couldn't really
justify it. But like in 2026, we have Claude
and there is like the MCP hype, like modern context protocol.
You can hook Claude or any other agent with your favorite
software. So this is exactly what we did.
We essentially gave Claude access to Ida, the reverse
engineering software, the reverse engineering myself.
I simply talked with Claude, asked it like free text
questions about the binaries and it managed to to the entire
reversing process by itself. Like at this point I don't
really think I'm ever going to open Ida again.
I only going to interact with Ida by using either cloud or any
other AI agent you. Should call it bye now, I'm
retired. That was for you.
Did Claude appreciate that you shared your license with with
him? Because I'm sure like, did he
know how expensive it is it? Is an issue.
I don't think it appreciates anything.
So from what we understand, this basically allowed you to
condense what would have been otherwise probably months of
very tedious and difficult and work that you'd probably, as you
mentioned, never do again. How do you think this changes
things for you personally, for your team, and for the industry
at large moving forward for this sort of research?
Yeah, So reverse engineering has always been part of my job.
Like I I can confidently say that I'm not a bad reversal and
it would still take me like weeks to months doing all of
this reverse engineering work. And like Claude with Aida, it
managed to do it within 48 hours.
So I think this also has like a lot of meaning towards the rest
of the industry. Many companies up until now
enjoyed the benefits of security by obscurity.
Since researchers cannot see the source code, it's much harder to
find security vulnerabilities in it.
But now that the barrier has been somewhat lower, I think we
are going to see a lot of more vulnerabilities being found in
closed source software. Let.
Me tell you we have a lot of work still.
Thanks. Thanks again.
Thanks for that. Yeah, now it's still not an
out-of-the-box experience. Like you cannot take Claude,
give it a binary and expect it like to be able to reverse and
generate. You still have to do some of the
heavy lifting like hook it up with the right tools and stuff
so. You're still going to have a job
too. There's still like a barrier,
like a barrier to entry, but it's a bit lower now.
Yeah, it's not just like you ask tragic BT you can do it and it
works out in the box like there's still enormous that you.
Need to sit around at this point yet your.
Grandma won't be finding vulnerabilities with her chat.
Help me. Help me plan my trip to Japan
and reverse engineer this binary.
Exactly. OK, so back to what you found.
So now I know how you how you did it, but can you walk us
through the vulnerability itself and how it can be exploited?
Yeah. So GitHub is made like at least
GitHub Enterprise, it's made from like 50 micro services
trying to communicate with each other.
Now specifically the vulnerability that we found is
in the micro services that handle the actual Git
operations. So not the UI, but like when you
do git pull or git push, there is code that need to handle
this. Now this is split to multiple
micro services that need to communicate with each other.
And this communication is actually really difficult
because first, git is very complicated.
Like I, I personally hate it. I never, I don't really know
git. So it's really difficult.
And during this communication, I suppose that it's possible that
different teams are responsible for each micro service.
So they really need to communicate between the teams to
understand what the protocol should actually look like.
And like in this specific case, one microservice treats a semi
colon in a certain way and another microservice treated in
a different way. This is like the the the source
of the bug. So essentially if you supply
there is a feature in git specifically called git push
options. And if if you supply a semi
colon in your git push options you're able to override like
very important security related variables.
And we managed to escalate it to a remote code execution.
But the source of the bug is like in the communication
between 2 micro services and how they handle the same input
differently. I think it's ironic, by the way,
that it's a semi colon because I think everyone culturally is
also confused by on you. It's a semi colon.
OK, so anyway, so you find that with the semi colon and then
what? What are you able to do with it?
OK, so first we like found the semi colon bug and we managed to
exploit it to a remote code execution on GitHub enterprise
server, which is like the self hosted version of github.com.
And then we were wondering whether this bug actually
effects github.com as well. So we tried at first it didn't.
Then we did some fiddling until it actually did manage to
exploit it on github.com, which is like which has a lot of
impact. Like people use github.com like
on a daily basis. This is where I'd say most of
the industry source code is actually being stored on
github.com. It's a critical infrastructure.
Yeah, yeah, for sure. So this has like a critical
meaning and obviously it got like critical score at GitHub.
So yeah, we reported it to github.com, both the effect on
GitHub Enterprise server, the self hosted solution, and
github.com the SAS product. No.
I was just going to ask like what the difference is in the
impactinggithub.com and GitHub enterprise?
So impacting github.com. You essentially impact all of
the github.com customers at the same time.
If you host your code on github.com, an attacker that
exploited this vulnerability could have accessed your code.
This is like really bad for GitHub Enterprise Server.
Like an attacker would need to know would need to be able to
access your GitHub Enterprise server if it's behind the VPN or
perhaps you have like strict ACL rules.
It's a bit more difficult trying to exploit either.
So like the impact is limited to basically your own organization
and perhaps a few small organisations that are sharing
the same server or yeah, working on the same projects.
Yeah, but on github.com you affect everyone instantly.
And this includes both public and private repositories.
Yeah, yeah. We like doing our proof of
concept. We demonstrated that we can
access a private repository of another of our accounts like.
Obviously we did not interfere with any other customers.
We wouldn't do that. We demonstrated the exploit only
on our. Account.
So what was it like working with GitHub on this?
What was it like during the disclosure process?
Yeah, so I've been doing responsible disclosure of
security vulnerabilities for a long, long time, and I can
confidently say that GitHub is their expert.
It took them less than two hours from the moment we submitted our
report until github.com is fully patched, fully mitigated.
They were very nice to communicate with.
They, they understand the value of this, of this research.
We really enjoyed working with them.
Yeah, I I can only say good things about them, really.
Did you help them like fix it? Did like, did you tell them what
to fix or did they have to figure it out themselves?
So we submitted like a very detailed security report from
our understanding, but our understanding is based on
reverse engineering. We don't have the source code.
They have the source code they like can do a better job of
understanding the real bug. But I want to believe that we
gave them like. I don't know good material to
work with the root cause of this bug.
I'm not wondering if they used AI to fix it, if it was so fast,
or if they're just that fast. I think they're good, like the
the people we talked with, they're they're good engineers.
Amazing. OK, so if you're listening to
this and you use GitHub, which is most people probably
listening to this, what should you do to make sure you're safe
whether you're a github.com customer or an enterprise user?
Oksogithub.com customers don't have to do anything.
GitHub did all of the heavy lifting for them.
As I said earlier, they patched the vulnerability within two
hours. Extremely depressive GitHub
enterprise server customers. They do need to apply the
patches on their own, so I really recommend applying these
patches. Like last week we did a query
trying to figure out how many Whiz customers have upgraded
their instances yet, and the numbers weren't really all that
good, so I. Listen to this episode and and
do it so our numbers will be higher.
Yeah, so I I really do recommend applying the patches.
Ziggy, thank you for sharing. Thank you for the awesome work
you're doing and we hope this helped everyone become more
informed and in the know on what's happening.
Thank you for asking me. If you enjoyed the show, be sure
to subscribe and share a link to the podcast, but not your cloud
keys. And as always, if your cloud
security strategy is making you cry, don't worry.
Just cry out Cloud.