1
00:00:03,800 --> 00:00:06,440
Welcome to Crying Out Cloud, the
podcast that will make you 

2
00:00:06,440 --> 00:00:10,720
laugh, cry, and reconsider all 
of your cloud security fears. 

3
00:00:11,000 --> 00:00:13,560
It's Eden and Nami Tai. 
We're back. 

4
00:00:14,480 --> 00:00:18,720
And today we have a guest, Sigit
Siddique. 

5
00:00:19,160 --> 00:00:21,560
Hey, Sigi. 
Hi everyone. 

6
00:00:22,800 --> 00:00:26,520
Segi is a security researcher 
from the Wiz research team, 

7
00:00:27,400 --> 00:00:30,960
finding radically cool things 
for the past five years at Wiz 

8
00:00:31,200 --> 00:00:34,520
and doing security research in 
the industry for over 10 years. 

9
00:00:34,520 --> 00:00:38,560
So stay tuned for a moment 
because we're going to tell you 

10
00:00:38,560 --> 00:00:43,240
the latest and greatest thing 
he's found, which is A1 liner 

11
00:00:43,280 --> 00:00:45,880
remote code execution 
vulnerability affecting both 

12
00:00:45,880 --> 00:00:51,720
github.com and GitHub Enterprise
Server, which is crazy. 

13
00:00:51,960 --> 00:00:54,280
And we're going to go into it 
Siggy. 

14
00:00:54,280 --> 00:00:56,400
Before we go into the 
vulnerability itself, which is 

15
00:00:56,440 --> 00:01:01,880
super interesting, let's talk a 
bit about the discovery process.

16
00:01:02,480 --> 00:01:07,080
You've been chasing this lead 
since 2024, which is a long 

17
00:01:07,080 --> 00:01:11,160
time, but back then it was too 
costly to really justify 

18
00:01:11,160 --> 00:01:14,920
continue working on it. 
What kept you on this trail for 

19
00:01:14,920 --> 00:01:17,880
almost 2 years before finally 
cracking it? 

20
00:01:18,520 --> 00:01:22,360
Yeah, So I really like GitHub as
a product. 

21
00:01:22,400 --> 00:01:25,560
I use it daily. 
So I thought that if I managed 

22
00:01:25,560 --> 00:01:28,640
to find a vulnerability in it, 
it would be really cool. 

23
00:01:28,640 --> 00:01:30,640
It was like a personal 
achievement. 

24
00:01:31,600 --> 00:01:37,960
So I had this lid standing on my
desk since 2024, but it really 

25
00:01:37,960 --> 00:01:41,880
required a lot of reverse 
engineering work, which is very 

26
00:01:41,880 --> 00:01:46,320
tedious and they couldn't really
justify doing it. 

27
00:01:46,960 --> 00:01:52,280
But it's 2026 now and we have AI
Advance that can do the heavy 

28
00:01:52,280 --> 00:01:54,120
lifting of reverse engineering 
for me. 

29
00:01:54,360 --> 00:01:57,720
And yeah, we managed to find a 
vulnerability at the end of the 

30
00:01:57,720 --> 00:02:00,200
day. 
Let's drill into the fact of the

31
00:02:00,200 --> 00:02:03,400
reverse engineering. 
So you used a combination of 

32
00:02:04,160 --> 00:02:06,520
reverse engineering with AI 
tooling. 

33
00:02:06,520 --> 00:02:09,520
Can you kind of give us a little
more detail into your setup and 

34
00:02:09,520 --> 00:02:13,680
how it how it works? 
Yeah, essentially GitHub is a 

35
00:02:13,680 --> 00:02:17,720
very complicated program. 
They have a lot of micro 

36
00:02:17,720 --> 00:02:21,240
services there and we don't have
the source code for these micro 

37
00:02:21,240 --> 00:02:22,880
services. 
We only have the compiled 

38
00:02:22,880 --> 00:02:26,160
binaries. 
Now for me as a researcher, I 

39
00:02:26,160 --> 00:02:28,800
much prefer reading source code 
instead of. 

40
00:02:31,000 --> 00:02:34,200
So there is like a process 
called reverse engineering when 

41
00:02:34,560 --> 00:02:37,920
you turn compiled binaries back 
to source code. 

42
00:02:38,760 --> 00:02:42,200
I personally do it with Ida, but
other researchers may use other 

43
00:02:42,200 --> 00:02:46,240
software. 
In any case, this is a very 

44
00:02:46,400 --> 00:02:50,960
hard, very tedious process. 
Especially for like doing it on 

45
00:02:50,960 --> 00:02:53,480
4 binaries in different 
programming language. 

46
00:02:54,320 --> 00:02:58,920
This is like really really easy.
Just kidding. 

47
00:02:58,960 --> 00:03:02,200
This would be really, really 
hard, so I couldn't really 

48
00:03:02,200 --> 00:03:07,640
justify it. 
But like in 2026, we have Claude

49
00:03:07,640 --> 00:03:12,600
and there is like the MCP hype, 
like modern context protocol. 

50
00:03:12,600 --> 00:03:16,640
You can hook Claude or any other
agent with your favorite 

51
00:03:16,640 --> 00:03:19,120
software. 
So this is exactly what we did. 

52
00:03:19,120 --> 00:03:22,640
We essentially gave Claude 
access to Ida, the reverse 

53
00:03:22,640 --> 00:03:26,840
engineering software, the 
reverse engineering myself. 

54
00:03:27,120 --> 00:03:31,400
I simply talked with Claude, 
asked it like free text 

55
00:03:31,400 --> 00:03:35,680
questions about the binaries and
it managed to to the entire 

56
00:03:35,680 --> 00:03:40,040
reversing process by itself. 
Like at this point I don't 

57
00:03:40,040 --> 00:03:42,920
really think I'm ever going to 
open Ida again. 

58
00:03:43,440 --> 00:03:48,480
I only going to interact with 
Ida by using either cloud or any

59
00:03:48,480 --> 00:03:53,320
other AI agent you. 
Should call it bye now, I'm 

60
00:03:53,320 --> 00:03:54,280
retired. 
That was for you. 

61
00:03:55,480 --> 00:03:58,480
Did Claude appreciate that you 
shared your license with with 

62
00:03:58,480 --> 00:03:59,880
him? 
Because I'm sure like, did he 

63
00:03:59,880 --> 00:04:02,120
know how expensive it is it? 
Is an issue. 

64
00:04:02,120 --> 00:04:04,040
I don't think it appreciates 
anything. 

65
00:04:05,760 --> 00:04:08,920
So from what we understand, this
basically allowed you to 

66
00:04:08,920 --> 00:04:11,840
condense what would have been 
otherwise probably months of 

67
00:04:12,280 --> 00:04:16,839
very tedious and difficult and 
work that you'd probably, as you

68
00:04:16,839 --> 00:04:20,000
mentioned, never do again. 
How do you think this changes 

69
00:04:20,000 --> 00:04:23,800
things for you personally, for 
your team, and for the industry 

70
00:04:23,800 --> 00:04:26,360
at large moving forward for this
sort of research? 

71
00:04:26,920 --> 00:04:30,560
Yeah, So reverse engineering has
always been part of my job. 

72
00:04:30,560 --> 00:04:35,320
Like I I can confidently say 
that I'm not a bad reversal and 

73
00:04:35,360 --> 00:04:39,240
it would still take me like 
weeks to months doing all of 

74
00:04:39,240 --> 00:04:43,560
this reverse engineering work. 
And like Claude with Aida, it 

75
00:04:43,560 --> 00:04:46,360
managed to do it within 48 
hours. 

76
00:04:47,480 --> 00:04:52,120
So I think this also has like a 
lot of meaning towards the rest 

77
00:04:52,120 --> 00:04:57,120
of the industry. 
Many companies up until now 

78
00:04:57,400 --> 00:05:00,240
enjoyed the benefits of security
by obscurity. 

79
00:05:00,560 --> 00:05:05,400
Since researchers cannot see the
source code, it's much harder to

80
00:05:05,400 --> 00:05:07,120
find security vulnerabilities in
it. 

81
00:05:07,920 --> 00:05:12,920
But now that the barrier has 
been somewhat lower, I think we 

82
00:05:12,920 --> 00:05:16,560
are going to see a lot of more 
vulnerabilities being found in 

83
00:05:16,600 --> 00:05:17,600
closed source software. 
Let. 

84
00:05:18,120 --> 00:05:20,320
Me tell you we have a lot of 
work still. 

85
00:05:21,120 --> 00:05:22,080
Thanks. 
Thanks again. 

86
00:05:22,240 --> 00:05:25,160
Thanks for that. 
Yeah, now it's still not an 

87
00:05:25,160 --> 00:05:28,320
out-of-the-box experience. 
Like you cannot take Claude, 

88
00:05:28,360 --> 00:05:31,880
give it a binary and expect it 
like to be able to reverse and 

89
00:05:31,880 --> 00:05:34,560
generate. 
You still have to do some of the

90
00:05:34,560 --> 00:05:37,600
heavy lifting like hook it up 
with the right tools and stuff 

91
00:05:37,600 --> 00:05:39,760
so. 
You're still going to have a job

92
00:05:39,800 --> 00:05:43,720
too. 
There's still like a barrier, 

93
00:05:43,720 --> 00:05:47,040
like a barrier to entry, but 
it's a bit lower now. 

94
00:05:47,560 --> 00:05:50,920
Yeah, it's not just like you ask
tragic BT you can do it and it 

95
00:05:50,920 --> 00:05:52,760
works out in the box like 
there's still enormous that you.

96
00:05:52,800 --> 00:05:54,840
Need to sit around at this point
yet your. 

97
00:05:54,880 --> 00:05:58,240
Grandma won't be finding 
vulnerabilities with her chat. 

98
00:05:58,840 --> 00:06:00,960
Help me. 
Help me plan my trip to Japan 

99
00:06:00,960 --> 00:06:02,360
and reverse engineer this 
binary. 

100
00:06:02,920 --> 00:06:05,800
Exactly. 
OK, so back to what you found. 

101
00:06:05,960 --> 00:06:09,880
So now I know how you how you 
did it, but can you walk us 

102
00:06:09,880 --> 00:06:13,400
through the vulnerability itself
and how it can be exploited? 

103
00:06:13,960 --> 00:06:17,920
Yeah. 
So GitHub is made like at least 

104
00:06:17,920 --> 00:06:22,760
GitHub Enterprise, it's made 
from like 50 micro services 

105
00:06:22,760 --> 00:06:24,600
trying to communicate with each 
other. 

106
00:06:25,560 --> 00:06:29,200
Now specifically the 
vulnerability that we found is 

107
00:06:29,200 --> 00:06:33,280
in the micro services that 
handle the actual Git 

108
00:06:33,280 --> 00:06:36,280
operations. 
So not the UI, but like when you

109
00:06:36,280 --> 00:06:40,600
do git pull or git push, there 
is code that need to handle 

110
00:06:40,600 --> 00:06:43,280
this. 
Now this is split to multiple 

111
00:06:43,280 --> 00:06:46,200
micro services that need to 
communicate with each other. 

112
00:06:46,920 --> 00:06:49,600
And this communication is 
actually really difficult 

113
00:06:49,600 --> 00:06:52,760
because first, git is very 
complicated. 

114
00:06:52,760 --> 00:06:56,160
Like I, I personally hate it. 
I never, I don't really know 

115
00:06:56,160 --> 00:06:58,440
git. 
So it's really difficult. 

116
00:06:58,800 --> 00:07:04,960
And during this communication, I
suppose that it's possible that 

117
00:07:04,960 --> 00:07:08,720
different teams are responsible 
for each micro service. 

118
00:07:08,920 --> 00:07:12,840
So they really need to 
communicate between the teams to

119
00:07:12,840 --> 00:07:15,880
understand what the protocol 
should actually look like. 

120
00:07:16,120 --> 00:07:21,520
And like in this specific case, 
one microservice treats a semi 

121
00:07:21,520 --> 00:07:25,600
colon in a certain way and 
another microservice treated in 

122
00:07:25,600 --> 00:07:28,320
a different way. 
This is like the the the source 

123
00:07:28,320 --> 00:07:34,520
of the bug. 
So essentially if you supply 

124
00:07:35,200 --> 00:07:39,800
there is a feature in git 
specifically called git push 

125
00:07:39,800 --> 00:07:42,480
options. 
And if if you supply a semi 

126
00:07:42,480 --> 00:07:47,640
colon in your git push options 
you're able to override like 

127
00:07:48,960 --> 00:07:51,880
very important security related 
variables. 

128
00:07:52,200 --> 00:07:56,040
And we managed to escalate it to
a remote code execution. 

129
00:07:56,480 --> 00:07:59,720
But the source of the bug is 
like in the communication 

130
00:07:59,720 --> 00:08:04,160
between 2 micro services and how
they handle the same input 

131
00:08:04,160 --> 00:08:06,200
differently. 
I think it's ironic, by the way,

132
00:08:06,200 --> 00:08:09,280
that it's a semi colon because I
think everyone culturally is 

133
00:08:09,280 --> 00:08:12,080
also confused by on you. 
It's a semi colon. 

134
00:08:13,160 --> 00:08:16,160
OK, so anyway, so you find that 
with the semi colon and then 

135
00:08:16,160 --> 00:08:17,840
what? 
What are you able to do with it?

136
00:08:18,400 --> 00:08:24,280
OK, so first we like found the 
semi colon bug and we managed to

137
00:08:24,280 --> 00:08:28,400
exploit it to a remote code 
execution on GitHub enterprise 

138
00:08:28,400 --> 00:08:32,039
server, which is like the self 
hosted version of github.com. 

139
00:08:33,240 --> 00:08:35,960
And then we were wondering 
whether this bug actually 

140
00:08:35,960 --> 00:08:41,159
effects github.com as well. 
So we tried at first it didn't. 

141
00:08:41,159 --> 00:08:45,840
Then we did some fiddling until 
it actually did manage to 

142
00:08:46,280 --> 00:08:51,240
exploit it on github.com, which 
is like which has a lot of 

143
00:08:51,240 --> 00:08:54,360
impact. 
Like people use github.com like 

144
00:08:54,360 --> 00:08:58,160
on a daily basis. 
This is where I'd say most of 

145
00:08:58,160 --> 00:09:01,400
the industry source code is 
actually being stored on 

146
00:09:01,400 --> 00:09:04,560
github.com. 
It's a critical infrastructure. 

147
00:09:04,960 --> 00:09:08,160
Yeah, yeah, for sure. 
So this has like a critical 

148
00:09:08,160 --> 00:09:12,840
meaning and obviously it got 
like critical score at GitHub. 

149
00:09:13,680 --> 00:09:17,520
So yeah, we reported it to 
github.com, both the effect on 

150
00:09:17,520 --> 00:09:20,760
GitHub Enterprise server, the 
self hosted solution, and 

151
00:09:21,040 --> 00:09:22,520
github.com the SAS product. 
No. 

152
00:09:22,520 --> 00:09:24,120
I was just going to ask like 
what the difference is in the 

153
00:09:24,120 --> 00:09:26,400
impactinggithub.com and GitHub 
enterprise? 

154
00:09:27,760 --> 00:09:31,720
So impacting github.com. 
You essentially impact all of 

155
00:09:31,720 --> 00:09:34,320
the github.com customers at the 
same time. 

156
00:09:34,520 --> 00:09:39,520
If you host your code on 
github.com, an attacker that 

157
00:09:39,520 --> 00:09:42,600
exploited this vulnerability 
could have accessed your code. 

158
00:09:42,640 --> 00:09:46,520
This is like really bad for 
GitHub Enterprise Server. 

159
00:09:47,680 --> 00:09:51,160
Like an attacker would need to 
know would need to be able to 

160
00:09:51,160 --> 00:09:54,760
access your GitHub Enterprise 
server if it's behind the VPN or

161
00:09:54,760 --> 00:09:58,120
perhaps you have like strict ACL
rules. 

162
00:09:59,000 --> 00:10:02,560
It's a bit more difficult trying
to exploit either. 

163
00:10:04,080 --> 00:10:07,440
So like the impact is limited to
basically your own organization 

164
00:10:07,440 --> 00:10:10,720
and perhaps a few small 
organisations that are sharing 

165
00:10:10,720 --> 00:10:13,600
the same server or yeah, working
on the same projects. 

166
00:10:13,840 --> 00:10:17,440
Yeah, but on github.com you 
affect everyone instantly. 

167
00:10:18,200 --> 00:10:21,240
And this includes both public 
and private repositories. 

168
00:10:21,600 --> 00:10:24,280
Yeah, yeah. 
We like doing our proof of 

169
00:10:24,280 --> 00:10:26,680
concept. 
We demonstrated that we can 

170
00:10:26,680 --> 00:10:31,440
access a private repository of 
another of our accounts like. 

171
00:10:31,520 --> 00:10:34,680
Obviously we did not interfere 
with any other customers. 

172
00:10:34,680 --> 00:10:37,680
We wouldn't do that. 
We demonstrated the exploit only

173
00:10:37,680 --> 00:10:38,320
on our. 
Account. 

174
00:10:38,320 --> 00:10:40,040
So what was it like working with
GitHub on this? 

175
00:10:40,560 --> 00:10:42,440
What was it like during the 
disclosure process? 

176
00:10:42,960 --> 00:10:46,560
Yeah, so I've been doing 
responsible disclosure of 

177
00:10:46,560 --> 00:10:49,880
security vulnerabilities for a 
long, long time, and I can 

178
00:10:49,880 --> 00:10:53,480
confidently say that GitHub is 
their expert. 

179
00:10:53,840 --> 00:10:58,840
It took them less than two hours
from the moment we submitted our

180
00:10:58,840 --> 00:11:03,440
report until github.com is fully
patched, fully mitigated. 

181
00:11:03,800 --> 00:11:06,120
They were very nice to 
communicate with. 

182
00:11:06,440 --> 00:11:10,640
They, they understand the value 
of this, of this research. 

183
00:11:11,240 --> 00:11:12,840
We really enjoyed working with 
them. 

184
00:11:13,800 --> 00:11:16,760
Yeah, I I can only say good 
things about them, really. 

185
00:11:17,960 --> 00:11:20,480
Did you help them like fix it? 
Did like, did you tell them what

186
00:11:20,480 --> 00:11:23,120
to fix or did they have to 
figure it out themselves? 

187
00:11:23,400 --> 00:11:27,960
So we submitted like a very 
detailed security report from 

188
00:11:27,960 --> 00:11:30,920
our understanding, but our 
understanding is based on 

189
00:11:30,920 --> 00:11:32,800
reverse engineering. 
We don't have the source code. 

190
00:11:33,080 --> 00:11:37,000
They have the source code they 
like can do a better job of 

191
00:11:37,000 --> 00:11:41,440
understanding the real bug. 
But I want to believe that we 

192
00:11:41,440 --> 00:11:44,120
gave them like. 
I don't know good material to 

193
00:11:44,120 --> 00:11:46,800
work with the root cause of this
bug. 

194
00:11:47,840 --> 00:11:50,640
I'm not wondering if they used 
AI to fix it, if it was so fast,

195
00:11:50,960 --> 00:11:54,000
or if they're just that fast. 
I think they're good, like the 

196
00:11:54,080 --> 00:11:56,400
the people we talked with, 
they're they're good engineers. 

197
00:11:57,280 --> 00:11:59,720
Amazing. 
OK, so if you're listening to 

198
00:11:59,720 --> 00:12:02,000
this and you use GitHub, which 
is most people probably 

199
00:12:02,000 --> 00:12:06,280
listening to this, what should 
you do to make sure you're safe 

200
00:12:06,280 --> 00:12:10,200
whether you're a github.com 
customer or an enterprise user? 

201
00:12:10,760 --> 00:12:14,280
Oksogithub.com customers don't 
have to do anything. 

202
00:12:14,440 --> 00:12:16,640
GitHub did all of the heavy 
lifting for them. 

203
00:12:17,280 --> 00:12:20,960
As I said earlier, they patched 
the vulnerability within two 

204
00:12:20,960 --> 00:12:24,280
hours. 
Extremely depressive GitHub 

205
00:12:24,320 --> 00:12:27,840
enterprise server customers. 
They do need to apply the 

206
00:12:27,840 --> 00:12:32,480
patches on their own, so I 
really recommend applying these 

207
00:12:32,480 --> 00:12:36,320
patches. 
Like last week we did a query 

208
00:12:36,800 --> 00:12:40,560
trying to figure out how many 
Whiz customers have upgraded 

209
00:12:40,560 --> 00:12:45,560
their instances yet, and the 
numbers weren't really all that 

210
00:12:45,560 --> 00:12:48,800
good, so I. 
Listen to this episode and and 

211
00:12:48,800 --> 00:12:50,800
do it so our numbers will be 
higher. 

212
00:12:51,160 --> 00:12:54,720
Yeah, so I I really do recommend
applying the patches. 

213
00:12:55,560 --> 00:12:58,880
Ziggy, thank you for sharing. 
Thank you for the awesome work 

214
00:12:58,880 --> 00:13:02,960
you're doing and we hope this 
helped everyone become more 

215
00:13:02,960 --> 00:13:05,240
informed and in the know on 
what's happening. 

216
00:13:06,440 --> 00:13:09,720
Thank you for asking me. 
If you enjoyed the show, be sure

217
00:13:09,720 --> 00:13:13,680
to subscribe and share a link to
the podcast, but not your cloud 

218
00:13:13,680 --> 00:13:16,360
keys. 
And as always, if your cloud 

219
00:13:16,360 --> 00:13:19,160
security strategy is making you 
cry, don't worry. 

220
00:13:19,440 --> 00:13:20,720
Just cry out Cloud.