The problem is not particular to GitHub. It's not even particular to the issue of compromised credentials. Recently, we've had the xz backdoor, where a malicious entity slowly wormed themselves into a position of privilege in a project and inserted malicious code. We've had typosquatting and the use of names that sound very much like real, non-malicious modules used to publish malicious python code via standard repositories. We've had any number of thumping vulnerabilities introduced in major pieces of code by completely-authorised developers, without any malfeasance required at all.

The problem isn't limited to free software, either; the SolarWinds exploit used compromised credentials to insert malicious code into an entirely-proprietary software package. In the proprietary world also, fully-authorised developers are capable of doing it to themselves by accident; the CrowdStrike outage of 2024 involved no compromise, but still resulted in "the largest outage in the history of information technology".

So the problem is very real, but it's not specific to free software, it's not specific to compromised credentials, and it's definitely not specific to GitHub. It's not a simple problem, and it doesn't have a single, simple solution. It is, instead, an ongoing battle, in which many weapons may be deployed. These include, but are not limited to, constant vigilance, distribution of privilege, the increased use of schemes that allow one person to verify the correctness of another's work (checksums, digital signatures, reproducible builds), the slow decline of simple username/password authentication in favour of 2FA schemes, the massive increase in SSL deployment spearheaded by Let's Encrypt, and increased awareness of the importance of industrial support for fundamental free-software projects. All of these, and more, have their place in helping us all stay safe.

Edit: I also want to make the point that although the free-software development model may appear more vulnerable to malice (and I'm not sure I accept that that's anything more than an appearance, see above) I think it also really helps deal with things when they go wrong. The xz backdoor didn't make it onto any production systems, which I attribute to two principal characteristics of free software. Firstly, the distribution of labour between code authors, code packagers, and distributors; unlike with CrowdStrike, there's no one person or body whose approval can flush code from the dev systems to the desktops. The malicious code in xz took time to flow through the pipeline, which (fortunately for us all) enabled someone to catch it. Secondly, the availability of source enables anyone with clue to investigate. Andres Freund noticed anomalies in liblzma, and immediately had at his fingertips all the information he needed to dig down into the issue. He didn't have to ask some company's permission to access source under NDA, or worse, call some security hotline, tell them his concerns, and hope they'd be looked into sometime this century.

Hi @FuckGlen We really appreciate you flagging this. The best route to get this to the proper GitHub team is to use our abuse reporting tools. Here's all the info:

• Reporting abuse or spam
• Reporting a user
• Reporting an issue or pull request
• Reporting a comment

You can report behavior and content that violates community guidelines and terms. I am going to close this post, but for this and any future incidents, please refer to those links.

Thank you!

From the OP:

Ok looks like the source has been found.

https://en.internetwache.org/dont-publicly-expose-git-or-how-we-downloaded-your-websites-sourcecode-an-analysis-of-alexas-1m-28-07-2015/

Silly me! :)

PREVENTION -

<DirectoryMatch "^/.*/\.git/">
  Require all denied
</DirectoryMatch> 

in your apache config.

to restore your repo,

git push origin HEAD:master --force

To make it self-contained, though, this happens when you serve an entire Git repo for your website. So, for example, if your deploy process looks like

1. Push your changes
2. SSH into the webserver
3. Pull your changes

Then you should take note.

Git has a .git folder which contains all the meta-information about your repo, including your remote URLs. If you embed your credentials into the remote URL (if it looks like https://user@pass:github.com/user/repo.git, you've done this) then those credentials can be used to access your repository and do anything to it that you could do.

There are a few mitigations, depending on your situation:

1. As stated above, you can just configure your webserver to not serve the .git folder. This is the quickest, easiest solution, but also not a great one, because you're still exposing the contents of the repo to anyone who knows the paths. If you have any proprietary elements in there at all, use another mitigation.
2. Put your website's code in some subdirectory of the repository. You still get the ease of deployment, but now anything you want tracked but not published, you just... don't put in the public directory. This is a higher migration cost, but a cleaner approach, and easier to get right in the long run.
3. Pull with SSH, not with HTTPS. The keyfile, unless you're doing something horribly wrong, won't be published, so no one else can access the repo even if they do have access to the .git folder. Be aware that, with just this solution, they can still access the .git folder, but for some projects (e.g. most open-source ones) this is irrelevant, since everything in there is already public. As a nice side bonus, your server's connecting to GitHub will be more secure.