To kick off this story, it seems fitting to provide a broader context on how I found myself in this predicament. As a security guy, my digital footprint has always irked me a bit. Yet, the inevitable clash arises when I need to self-promote to earn a living and secure job opportunities. However, I made a rather grave error; I left my résumé public with various contact details (I know, I can be an idiot sometimes). The link to the résumé was in a Markdown file on my GitHub. The plan was to hope it wasn’t an image I uploaded to the repository (as that would leave a commit history), and secondly, try to disable the link in the Markdown. As per usual, I glanced at the link, and the link stared back at me, prompting the question: where on earth is this hosted? I had no control over that link; it would linger there indefinitely, my information immortalized in who-knows-where. When you drag a file from your computer into GitHub’s Markdown, it runs a JavaScript to send that file to their server (even before you commit the altered Markdown). So, all I needed to do was drag it into the Markdown, wait for it to generate the link, and I’d have someone hosting whatever I pleased behind a GitHub link. Can you spot the problem here?

However, not everything is smooth sailing; we do have some restrictions:

Files up to 10 MB (which is quite substantial).
Not all file types were accepted, but most are, including:

PNG (.png)
GIF (.gif)
JPEG (.jpg, .jpeg)
SVG (.svg)
Log files (.log)
Markdown files (.md)
Microsoft Word (.docx), PowerPoint (.pptx), and Excel (.xlsx) documents
Text files (.txt)
PDFs (.pdf)
ZIP (.zip, .gz, .tgz)
Video (.mp4, .mov, .webm)

Yes, most of them are highly vulnerable. But you might be thinking, “They use a Web Application Firewall (WAF) to protect users from attackers who upload scripts or attempt XSS injections, right?” To your surprise, NO! They couldn’t care less about that. They employ a third-party technology called Camo, and whenever you formally report these vulnerabilities, they claim it’s by design. As if insecurity is meant to be by design—nothing leading users into error should be by design, and generating a URL to mimic their repository files seems far from secure. If, as a developer, you encountered a link containing github.com and the URL of a repository you trust, wouldn’t you click it? Well, if you did, sadly, that’s by design. But hold on, how does all this work? Give me steps for it, my friend! Hot-off-the-press steps, of course:

Since it’s by design, reproduce the steps in any repository! Whether it’s yours or not, after all, it’s by design.

Of course, you can upload any type of file, but here, we love JavaScript and, of course, a bit of XSS. After all, this is all by design.

Open any repository and go to the Issues section. Create a new issue (no need to submit it; you’ll see the POC video right after).

Drag and drop the file and wait for the magic to happen.

A URL will be generated, similar to this: https://github.com/github/hackathons/assets/{repoid}/{fileId...

Of course, I used their hackathons repository since it’s by design; I shouldn’t worry. Now, with this, we have a URL from a legitimate repository leading to an XSS, and of course, the link’s appearance is entirely harmless.

Protect Yourself
This kind of issue is entirely foreseeable and solvable on the part of the GitHub team. Every link we click with the GitHub domain now demands extra caution. It can lead you to an IP leak or even to some content you’d rather not see (NSFW), even if it’s from a legitimate repository, a legitimate URL, or a legitimate user. You must be careful because GitHub believes that this type of behavior is by design and should be maintained.

Video POC
https://youtu.be/xwfSHWV2opU