SSRF Vulnerability on Major Gaming Company

A gaming company's content service that fetches resources from a URL you hand it, and the obvious question hanging over that kind of feature is always the same one, what happens when you point it somewhere the developers never meant for it to go. This one's confirmed, not just "based on," Wiz's own published benchmark data lists this exact challenge as Content SSRF, an AWS IMDS SSRF pulled straight from a real hack Nagli pulled off on a gaming company, and it paid out $27,500. Worth noting too, Wiz later ran AI agents against this same challenge to see how they'd do, and more than one solved it for under ten dollars in compute, which says something either about how learnable this bug class has become or how little the model actually needed to get lucky with.

Interacted with the site itself first while running Caido in the background to catch everything passing through.

Nothing useful jumped out from the UI directly, but the page source told a different story, a script firing off requests to fetch content in the background, visible once I actually watched Caido catch it in real time.

It was pulling a specific file through an API endpoint built around a module ID, a version number, and a filename. Obvious next question, what happens if that filename parameter isn't actually limited to real files sitting on the server.

Since this whole fetch was happening client-side anyway, just a success message logged quietly in the background rather than anything rendered on the page, calling it myself straight from the browser console was the fastest way to actually test it without fighting the UI at all. This is the part worth actually remembering past this one lab specifically, whenever you see an endpoint fetching a file by name, don't just try other filenames, try handing it a full URL instead and see if it still obliges. Threw localhost in where the filename normally went.

It answered. A fake-looking auth token came back along with it, and a header dump confirming it was genuinely making an internal request on the server's own behalf rather than just echoing something back. The token itself didn't lead anywhere further on its own, decorative rather than a real way in. But if it was willing to reach localhost without blinking, the actual test worth running was the one every hunter reaches for first in exactly this situation, the cloud metadata endpoint.

Pointed it at 169.254.169.254 instead, and it went and fetched that too, no hesitation, no filtering on where that URL parameter was actually allowed to point. Full SSRF into the instance's own metadata service, confirmed.

And that's the whole bug, start to finish, a file-fetching feature that never actually checked whether what it was fetching was a file at all. Nagli's own line on this one, sitting right in the brief, was that finding something like this is harder than actually exploiting it once you've found it, and working through this lab made that pretty obvious in practice, the entire technical move here was one URL swapped in where a filename was expected. The real skill wasn't the exploit, it was the instinct to even try it in the first place instead of assuming a fetch-by-filename endpoint was exactly what it looked like.

Happy hunting, see you in the next scope :)