GitHub vulnerability leaks sensitive security reports

A recently discovered GitHub vulnerability could expose a repository's security reports, giving attackers the opportunity to exploit any flaws in the code before users have time to patch.

Justin Cappos, a professor in the computer science and engineering department at New York University, discovered the vulnerability while applying a fix in another account's repository. He said he noticed his security reports were leaked to the account owner. Cappos discovered the vulnerability on March 13 and reported it to GitHub on March 20 through its bug bounty program with HackerOne, but no CVE was assigned.

Cappos told TechTarget Editorial the attack vector involves .github repositories that contain security.md files where users store instructions for how to report a vulnerability discovered in their repositories. Security.md files are intended to be public. The vulnerability is triggered when one user is trying to implement a fix for a problem they discovered on another repository.

Security.md file access could expose security weaknesses in another user's .github repository, Cappos said, but threat actors would still need to exploit the issues to launch attacks.

"What happens is that the security.md gives a link to where vulnerabilities are reported, so vulnerabilities that are reported for my software would go to the attacker," he said. "A good guy might realize that everyone running my software is at risk because of some bug in it. When they go tell me about it, that information goes to the attacker. The attacker can then compromise all of my users."

When GitHub users discover a mistake, they are instructed to fork the repository that contains the problem and the forked repository is then labeled .github. Next, they send a pull request to the newly named .github repository to notify the user of the correction. If the forked .github repository has security.md files, then all of the user's projects that don't have a .github repository will have their security vulnerability reports sent to the notifier.

The vulnerability can be triggered whether users merge the pull request or not, Cappos warned. He urged GitHub to make the attack harder to launch.

"When you fork someone else's .github, then whatever they said to do for security reports ends up getting applied automatically to all of your repositories. There's no warning for this. There's no notification," Cappos said. "Basically, you as a user who's just trying to do a good thing, like fix a typo or a bug, end up all of the sudden turning all your security reports to whoever the other party is."

Cappos raised many concerns related to this vulnerability. Security.md files in .github repositories can contain an array of sensitive information. When a user forks another user's repository to address changes, the security.md file is applied to all of their .github repositories. Subsequently, a GitHub user can't change the file after the fork; the fork contains any contents in the files at that time.

"If you put links, et cetera in there that point to things you control, you can, of course, change what is shown on those pages at any time," he wrote in an email to TechTarget Editorial.

Another one of Cappos main concerns is that the flaw can affect extremely secure repositories in ways users do not expect. Cappos emphasized attacks would only affect legitimate users looking to address mistakes made in code or projects shared on GitHub.

Cappos said he's seen no evidence of such attacks so far. But he conducted a scan of GitHub repositories and found thousands of users have accidentally leaked their security.md files. Cappos noticed that security information for some popular projects had been changed, though he said it's unclear if the changes were intentional, accidental or malicious. He added that most of the affected repositories aren't considered critical.

Cappos stressed that GitHub's security reporting process is meant to be anonymous or, at least, private to avoid tipping off attackers. While Cappos said the flaw is easy to exploit, targeting presents challenges. Threat actors could lure users in by intentionally including mistakes in their code, but there's no guarantee they'll respond.

During the vulnerability disclosure process with HackerOne on March 20, Cappos said they confirmed they had documentation of the issue, rated the vulnerability as critical and closed out the ticket. He spoke again with GitHub and noted they took the flaw seriously but seemed unsure if it constituted an actual vulnerability that required a fix.

"I would somewhat agree with GitHub's assessment that it isn't extremely severe. While their issue tracker rated it as critical (the highest category), mostly because you get access to very sensitive information and it impacts a wide array of repos, the fact that someone has to be a good Samaritan in the first place and fork your repo to send a pull request makes the attack harder to target at a specific party," Cappos wrote in an email. "However, for an attacker that just wants to compromise projects in general, this is a serious concern."

To date, the vulnerability has not been assigned a CVE or a fix. Cappos urged users to protect themselves by creating an empty .github repository.

"If you have created your own .github repository, then it won't affect you because you won't be able to overwrite your own when you fork someone else's. But if you have not created one, which most users have not because they aren't that popular, then you're vulnerable to this," he said.

David Vance, an analyst at TechTarget's Enterprise Strategy Group, said that while it would be dangerous for hyperlinks in security.md files to direct developers or researchers to report security vulnerabilities to a potential attacker, he was unsure how realistic that scenario is. Instead of a vulnerability, Vance said it could be a user awareness issue where GitHub users are unaware of all the proper configuration settings to mitigate this risk.

"Something similar to this has been a problem with cloud providers like AWS, Microsoft Azure and Google Cloud where users were unaware of all the cloud configuration settings and had led to plenty of security incidents in the past (e.g.: publicly exposed data in open S3 buckets)," Vance wrote in an email. "In light of this, the cloud providers and third-party security vendors have stepped up and added capabilities to enforce proper security configurations. I'm wondering if this is a gap GitHub has and is something that they should be enforcing as well?"

TechTarget Editorial contacted GitHub for comment. A GitHub spokesperson referred to instructions on how to create community health files and provided the following statement.

GitHub is committed to investigating reported security issues. We are aware of this report submitted through the GitHub bug bounty program and have validated it as a low security risk and likelihood of exploitation. We continue to invest in improving the security of GitHub and our products and are looking into opportunities to make this behavior clearer when editing security policy files.

Recent attacks against GitHub users have highlighted what a popular target the developer platform is for threat actors as well as the risks to the open-source supply chain. Earlier this month, Checkmarx discovered attackers manipulated GitHub Actions and the stargazing feature to trick developers into downloading malicious code. Checkmarx disclosed another attack campaign in March where attackers poisoned multiple popular GitHub code repositories, including Top.gg, which is used for search and discovery for the Discord platform.

Arielle Waldman is a news writer for TechTarget Editorial covering enterprise security.