SANS Stormcast Wednesday, April 29th, 2026: Odd Vercel Header Usage; GitHub Vuln Patches; MSFT RDP Notification Bug

If you are not able to play the podcast using the player below: Use this direct link to the audio file: https://traffic.libsyn.com/securitypodcast/9910.mp3

previous

Odd Vercel Header Usage; GitHub Vuln Patches; MSFT RDP Notification Bug

00:00

iTunes

MP3 Download

RSS Feed

Google

Podbean

Amazon Echo

YouTube

Spreaker

Spotify

Discussion

Login here to join the discussion.

Podcast Transcript

 Hello and welcome to the Wednesday, April 29th, 2026
 edition of the SANS Internet Storm Center's Stormcast. My
 name is Johannes Ullrich, recording today from
 Jacksonville, Florida. And this episode is brought to you
 by the SANS.edu Graduate Certificate Program in
 Incident Response. Well, Diaries Today is a quick write
 -up I did on some requests we're seeing in our honeypots
 that use a little bit of an unusual header, the X-Vercel-
 Set-Bypass-Cookie Header. Now, this header is related to the
 bypass value that you can define as a user of Vercel
 that will essentially bypass some of the protection
 mechanisms, like, for example, rate limiting. Now, this is
 not an unusual feature for any kind of application firewall
 or such, where in particular for developer purposes, you
 have the ability to essentially bypass at least
 some of the protection mechanisms. The value you
 would have to pass with the Vercel-Set-Bypass-Header,
 well, is random. And it's something that the user can
 define. And that does not appear to be really the use
 here, because they're using the X-Vercel-Set-Bypass-Cookie
 Header. So, with the additional cookie add-on. And
 that's where it gets a little bit interesting. So, this
 header is used so that the first time you send a request,
 you will set the bypass value. And then the server is
 responding with a Set-Cookie Header to essentially set a
 cookie. And that's in particular useful for browsers
 that are being used here for testing, because then the
 browser will automatically send the cookie. And with
 that, sort of retain the bypass feature here. The value
 they're sending here is sameside-none-secure, which is
 not documented. But there are similar parameters, in
 particular samesidenone, where you sort of specify that
 a cookie comes back with the none value for the same-side
 attribute. Not 100% sure what they're after here. Could be
 that they're hoping that some cookies may leak the value
 that is defined for this header. I don't have access to
 a Vercel setup here myself to sort of test this and see how
 this would be working. If anybody has any more insight,
 would be interested in hearing what the attacker may be
 accomplishing here. Also, these requests are being sent
 via open proxy servers. And Wiz Research published a blog
 post with details about a vulnerability in GitHub that
 they found. Now, if you're a user of GitHub and you're just
 using GitHub's cloud solution, you're perfectly fine. If you
 happen to use the on-prem option for GitHub, well, then,
 of course, you need to patch. The vulnerability is kind of
 interesting. And it's nice of Wiz to sort of dive a little
 bit into what exactly happened here. The fundamental problem
 that GitHub has is that it allows users to execute Git
 commands. And, well, Git commands are operating system
 commands. And they have a number of options that can be
 passed to the command. In this particular case, it was the
 Git pull command that actually caused the problem. Now, the
 way GitHub deals sort of with some of the problems arising
 from allowing users to run Git commands is that they run it
 through a proxy. They call it bobble-d. And this proxy is
 supposed to clean up some of the, well, bad characters,
 essentially, like semicolons and such. But it didn't do so
 correctly in this case, which then led essentially to an OS
 command injection vulnerability that could be
 used to execute code on GitHub's servers. Luckily,
 well, Wiz reported it. And GitHub did verify and then fix
 it almost within hours. So very quick response here from
 GitHub. And as far as they're saying, the vulnerability had
 not been exploited at the time. So no user data was
 lost. And one of the security improvements that I
 highlighted in this month's Microsoft patch Tuesday
 updates was the addition of more elaborate warnings if
 you're adding an RDP file. And if you're trying to then open
 the file. This has been off news for phishing. And that's
 sort of why Microsoft sort of improved the user interaction
 here. Well, they now published an update or an issue about
 this particular update that basically indicates these
 security warnings may sometimes show up a little bit
 garbled. This happens if you sort of have different
 displays with different display scaling. I guess it
 doesn't get the font size quite right. And as a result,
 some of the text may overlap, just making it more difficult
 to read. Well, and that's it for today. Thanks for liking.
 Thanks for subscribing. And thanks for recommending this
 podcast to others. And talk to you again tomorrow. Bye.