The Surge in GitHub‑Focused Attacks 

Truesec has observed a notable increase in attacks targeting organizational code repositories such as GitHub over recent months.

While many organizations have significantly improved their prevention, detection, and response capabilities by investing in XDR and SIEM solutions for endpoints, identities, network devices, and cloud workloads, platforms such as GitHub often fall outside these monitoring and protection scopes.

Observed attacks span from automated worm campaigns to targeted intrusions involving persistent access, large-scale data exfiltration, and ransom attempts. During the autumn of 2025, one such campaign – the self-replicating  NPM worm “Shai Hulud” and “Shai Hulud 2.0” – spread globally by compromising GitHub repositories and publishing malicious updates to NPM packages. During the spring, a supply-chain compromise targeting the Trivy security scanner affected multiple organizations through compromised GitHub actions, where malicious releases enabled credential exfiltration within CI/CD pipelines.

Initial Access: Small Mistakes, Big Impact 

In recent incidents that Truesec responded to, threat actors gained access by taking advantage of exposed identities – most commonly over-privileged Personal Access Tokens (PATs). With sufficient scope, a single leaked token can provide direct access to repositories, CI/CD workflows, and organizational settings, effectively granting control over the entire GitHub environment. PATs can easily leak through everyday developer workflows hard-coded into source code, accidentally committed to repositories, shared with third-party tools, or stored on private endpoints or collaboration platforms (e.g., Teams chats/channels) that later get compromised. Developers using personal accounts for accessing their company GitHub organization is common but creates another risk factor. A developer may leak an access token in a personal context which is then used by an attacker to access the developer’s company GitHub organization. 

Legacy or misconfigured repositories, unintentionally made public, may further expose internal tooling, keys, and secrets; such as that “before-my-time-repository” or the supposedly “temporary” test and proof-of-concept repository, that somehow became production-critical – without anyone revisiting its access and permission scopes.  

Traditional weaknesses of course still apply: vulnerable web applications, services that never needed to be exposed to Internet in the first place or overly permissive OAuth and GitHub integrations remain common entry points. Any system integrated with GitHub becomes part of its attack surface, and a compromise of one relationship can propagate to others. 

Living Off the Repo: The Cascading Effect of Secrets Sprawl 

Once a threat actor has gained access to your GitHub organization or enterprise, the impact strongly depends on your hygiene around secrets and data sanitization practices. Do you remember that one accidental commit of customer data and hard-coded secrets? Well, we reverted that one, didn’t we? Tough luck – even if a hard-coded secret is removed or replaced in a commit, it still lives on in the commit history or forks unless the history is explicitly rewritten. As a result, secrets can be harvested long after an exposure is believed to have been mitigated.

Each exposed secret creates a new opportunity to pivot. Consider these questions: What systems can be reached only by reading development artifacts? Can a threat actor successfully move to cloud environments? To databases? To SaaS platforms? To vendor systems? Are some tokens reused across multiple systems?

How a threat actor can move laterally is restricted by your organization’s defense-in-depth strategy. Truesec has seen customers who managed to significantly limit the impact of secret exposure by the virtue of having additional controls such as VPN access requirements or narrowly scoped permissions.

Besides worrying about secrets, access to repositories also enables longterm reconnaissance. By repeatedly cloning code and studying it over time, threat actors can map CI/CD workflows, abuse automation or GitHub-hosted runners, and uncover code vulnerabilities that support future reentry. Source code can be corrupted to introduce backdoors or distribute malicious software downstream. Especially in large organizations with many developers, these activities rarely stand out and blend into normal development workflows, delaying detection, and extending dwell time.

A git repository is seldom just a collection of source code – often it is a detailed map of your environment, trust relationships, infrastructure, etc. Treating it as such is key to preventing a single exposed secret from turning into a cascading compromise. Hardening your GitHub organizations and repositories is urgent to avoid situations where the developer end-user account becomes the weak link or the last line of defense.

Prevent and Detect: Reduce Impact 

Principle of Least privilege: Generally speaking, a GitHub organization should be configured to prevent a solitary user from taking high-impact actions. These include, but are not limited to, deploying applications, pushing software releases, and accessing sensitive assets. Making sure that administrative privileges are delegated to separate user accounts, not for daily use, is a critical step. An account for a developer should only have the privileges necessary for day-to-day work, in most circumstances implying no permissions to change repository or organization-wide security settings, install integrations or webhooks, invite new members, etc.

Account management: If you have a GitHub enterprise license, using your existing identity solution together with GitHub Enterprise Managed Users is the most secure way to manage accounts on GitHub. Users managed through your enterprise are not allowed to collaborate outside the enterprise or create public content. Policy is easier to control. However, using personal accounts together with organizational SSO is still much better than purely relying on personal accounts as this will force members to authorize SSH keys and tokens before they can be used with the organization.

Secrets management: Generally speaking, secrets should be managed through use of a secure secrets management solution, and only be exposed at the time of use. Avoid having secrets checked into code, and continuously monitor your repositories for secrets exposure by use of secrets scanners. If you have GitHub advanced security, you can enable push protection to prevent users from pushing commits containing suspected secrets.

CI/CD hardening: An attacker getting execution time in a workflow action can exfiltrate production secrets through several mechanisms. To reduce this risk, the ability to run pipelines in a context where secrets are exposed should be highly restricted, for example through a combination of environments, branch protections and pull request merge rules. Environments in GitHub allow administrators to configure rules specifying under what circumstances a job for a defined environment (such as ‘production’) is allowed to execute. By making sure that jobs for sensitive environments are not allowed to execute from any branch or commit, combined with rules preventing a user from single-handedly merging a pull request or push to a sensitive branch, the impact of a credential leak is reduced. In addition, the workflows themselves should limit access to secrets: If a job or a step does not require a secret, it should not have access to it.

Network access: Network-level mechanisms for achieving a higher degree of layered security can also contribute to reducing impact. By using IP address filtering on your GitHub enterprise so that only requests originating from approved sources are allowed, the risk that a leaked token can trivially be abused by an attacker acting from outside your trusted networks is minimized.

Supply chain management: As the recent Trivy supply-chain attack showed, third party GitHub actions can be a serious risk to an organization, and depending on the scope and effective privileges of a GitHub action, the impact of a compromise can be severe. To reduce the supply-chain risk when it comes to GitHub actions, you can for example pin actions to known good commit hashes. This mitigates against cases where malicious commits are pushed to branches, or where release tags are overwritten. It is possible to enforce this on an organizational level. Read more about Github Supply chain security in one of our previous blogposts. 

Threat monitoring and logging: Logging is crucial for observability, alerting, auditing, and digital forensics, in case of an attack against your organization. GitHub allows streaming logs to an external log management system, improving log retention and allowing alerting on anomalies. Web hooks can also be taken advantage of for auditing and alerting.

Move Forward With the Right Support

If your organization needs assistance securing and hardening GitHub, Truesec can help. Our application security consultants have solid experience helping customers secure source code repositories and CI/CD. If your GitHub organization has been compromised, contact our incident response team as soon as possible.