GitHub Security is constantly monitoring for abuse and security threats to GitHub, developers and communities that call GitHub home. In this blog, we are taking a moment to remind developers of some best practices and important defenses against common attack patterns against GitHub Actions.
One common observed attack pattern exploits situations where a user’s personal access token (PAT) has not been properly and securely stored. If a threat actor is able to obtain a GitHub user’s PAT, they then may add a malicious Actions workflow file to repositories accessible to the user. In some instances, we have observed threat actors taking additional steps to obfuscate their activities, such as setting the commit username to dependabot[bot] in an attempt to trick users into trusting the commit. Another attack pattern is adding immediately-invoked JavaScript to existing files in repositories accessible to the compromised user. The malicious files and code then collect repository secrets and send them to an endpoint where they are likely collected by the threat actor.
While stolen personal access tokens are one method of enabling the threats described above, compromised accounts or GitHub sessions similarly enable those threats. Stolen tokens, compromised accounts, and compromised sessions often occur due to the presence of malware on a user’s computer (for example, the RedLine Stealer).
What GitHub users and organizations can do
Owners of repositories, including private repositories, should review code changes and pay particular attention to added Actions workflow files and unexpected changes to JavaScript files. This includes any third-party files that may be included as part of the project.
If you believe your repository has been compromised, we recommend you consider any repository secrets as compromised and rotate them, both in your GitHub settings and any places they are used, such as SSH credentials.
To further secure your repository, you can explore:
Those who use JavaScript on their websites should consider using the integrity
attribute on any script tags so that manipulated content such as this doesn’t run, as outlined in https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity.
If you are concerned that your GitHub account has been compromised, you should employ the following measures to secure your account:
- Review your personal access tokens.
- Change your GitHub password.
- Reset your two-factor recovery codes.
- Take additional steps to review and secure your account.
The security and trustworthiness of GitHub and the broader developer ecosystem is our highest priority. In service of that, GitHub is always on the lookout for compromised account activity, and will disrupt this activity when and where we find it. You can do your part by keeping your account credentials safe, including personal access tokens, and paying particular attention to Actions workflows and JavaScript files when reviewing changes to your repositories. If you have any questions or concerns, please contact GitHub Support.
Tags:
Written by
Related posts
![](https://github.blog/wp-content/uploads/2024/01/Security-DarkMode-3-1.png?resize=400%2C212)
From object transition to RCE in the Chrome renderer
In this post, I’ll exploit CVE-2024-5830, a type confusion in Chrome that allows remote code execution (RCE) in the renderer sandbox of Chrome by a single visit to a malicious site.
![](https://github.blog/wp-content/uploads/2023/11/Security-LightMode-4.png?resize=400%2C212)
Configure GitHub Artifact Attestations for secure cloud-native delivery
Introducing the generally available capability of GitHub Artifact Attestations to secure your cloud-native supply chain packages and images.
![](https://github.blog/wp-content/uploads/2023/12/Security-DarkMode-1-2.png?resize=400%2C212)
3 ways to get Remote Code Execution in Kafka UI
In this blog post, we’ll explain how we discovered three critical vulnerabilities in Kafka UI and how they can be exploited.