Git Ransomware Attack Prompts Secure Best Practices Recommendations

Atlassian Bitbucket, GitHub, and GitLab this week issued a joint blog post to help educate and inform users of the three platforms on secure best practices in the wake of a Git ransomware incident two weeks ago.

“Though there is no evidence Atlassian Bitbucket, GitHub, or GitLab products were compromised in any way, we believe it’s important to help the software development community better understand and collectively take steps to protect against this threat,” the blog reads.

Quick background: On Thursday, May 2, the security teams of Atlassian Bitbucket, GitHub, and GitLab learned of user account compromises across all three platforms, ultimately resulting in hundreds of public and private repositories held for ransom by an unknown cyber kidnapper (see details below). The compromises largely came from “leakage” of user credentials, perhaps from third-parties. Weak passwords are the likely cause. At this time, the security teams of all three companies are collaborating to investigate the incidents, the blog said.

The incident: The ransomware hacker hit roughly 400 Git repositories and demanded roughly $600 in Bitcoin paid within 10 days (May 13) not to make the victims’ code public, multiple reports said. The hacker claimed the victims’ data was being held on their servers. The attacks occurred across Git hosting services GitHub, Bitbucket, and GitLab. Users affected by the ransomware reported that their code disappeared and replaced by this demand:

“To recover your lost code and avoid leaking it: Send us 0.1 Bitcoin (BTC) to our Bitcoin address ES14c7qLb5CYhLMUekctxLgc1FV2Ti9DA and contact us by Email at with your Git login and a Proof of Payment. If you are unsure if we have your data, contact us and we will send you a proof. Your code is downloaded and backed up on our servers. If we don’t receive your payment in the next 10 Days, we will make your code public or use them otherwise.”

As of Monday, May 6, there had been 36 abuse reports for the Bitcoin address, according to the Bitcoin Abuse Database blog, and the hacker threatened to delete code. In keeping with the cyber extortionists’ collective strategy that less is more, the demand was 0.1 bitcoin, which at the time of the incident was about $590 but has risen to roughly $780.

Key Learnings

In the hijack’s immediate wake, it wasn’t clear how the hackers conducted the attacks but the the platforms’ security teams now are “confident that we understand how the account compromises and subsequent ransom events were conducted,” the blog said. The hacker appears to have scanned the web for Git config files and used stolen credentials to carry out the heist at Git hosting services. Some users suspect that it wasn’t a targeted attack but a random, bulk attack carried out by a script. Apparently, some of the victims used weak passwords for their GitHub, GitLab and Bitbucket accounts. They also didn’t remove access tokens for apps left unused for months. Both mistakes left accounts vulnerable to hacking.

“My password was a weak one that could’ve been relatively easily cracked via brute-force (it’s not a common one but starts with “a” and has only a-z characters in it) and it could be that they just automatically checked if they can access the account and then ran some git commands,” wrote one user on the StackExchange forum. “It is also possible that my email address and that particular password are on a list of leaked accounts.”


Here’s how users can protect their repositories from such attacks:

  • Enable multi-factor authentication on your software development platform of choice — Bitbucket, GitHub or GitLab.
  • Use strong and unique passwords for every service to prevent credential reuse if a third-party experiences a breach and leaks credentials.
  • Understand the risks associated with the use of personal access tokens, which, used via Git or the API, circumvent multi-factor authentication. Tokens may have read/write access to repositories depending on scope and should be treated like passwords. If you enter your token into the clone URL when cloning or adding a remote, Git writes it to your .git/config file in plain text, which may carry a security risk if the .git/config file is publicly exposed.
  • When working with the API, use tokens as environment variables instead of hard coding them into your programs.
  • Do not expose .git directories and .git/config files containing credentials or tokens in public repositories or on web servers.

The blog post also offers steps for users to recover their affected repositories. Users requiring additional assistance to recover their repository contents are referred to support sites for each platform.

Related Content

Return Home




    Why this can even happen against a remote git server shows how incredibly naive the architecture is at its core. There is no reason at all to allow instantly erasing history in a version control system. Having the password stolen or not should not be an issue for an action that should not exist to begin with. If Git servers had the protocol implemented as dedicated hardware to only accept adding new data with daily quota throttling, it would and should not matter if someone stole SSH tokens from the administrator’s work laptop. Data should never be erased remotely from a server!

    The whole network stack needs to be rewritten from scratch without all the obvious NSA backdoors (like allowing the operating system and motherboard to use internet directly without having packets signed between the user and hardware firewall for each application being granted access).

      Joe Panettieri:

      Hi David: Thanks for your note and readership. Can you share any details about your background to provide more context for your comment?


    I studied computer science at a Swedish University and used to develop firmware for mobile phones.

    If I would redesign Git for dedicated cloud hardware, I would physically prevent force push by letting the main repository be an overwrite protected custom memory of approved pull requests as symmetrically encrypted commits accepted by the product owner. The cloud server will have no idea of what’s inside the Git repository, so the customers only need to take care of their own passwords and keys to prevent leaks. If an attacker tries to push something bad, they just move the active head back to the previous commit. Public repositories will not be able to see the ignored commits outside of active history, so spam will not be visible. Needs a 16GB large key from a quantum random source for encrypting/decrypting blocks of commits. If the key is changed after leaking, the product owner creates a new repository with clean history and waits for the server to remove things that have been marked for removal during a whole year. A repository marked for deletion cannot be read again without a phone call about ransomware to the cloud administrator, so that leaked keys cannot access old code.

Leave a Reply

Your email address will not be published. Required fields are marked *