The Visual Studio Marketplace is administered by Microsoft that also owns GitHub, but submissions to the marketplace comes from independent developers and this is not the first time a malicious VS code extension has been discovered.

This attack is the latest in a series of attacks targeting software developers and software supply-chains. Earlier, the same threat actor had breached Aqua, a software developer that produces Trivy, an open-source tool for code verification. That breach enabled the threat actors to push a malicious version of Trivy that infected several large enterprises.[2] TeamPCP has also claimed responsibility for the latest version of Shai Hulud, an information-stealing worm that spreads via npm and pypi code repositories. [3]

On May 18, an automated campaign codenamed megalodon pushed 5,718 malicious commits to 5,561 GitHub repositories in a six-hour window. Using throwaway accounts and forged author identities (build-bot, auto-ci, ci-bot, pipeline-bot), the attacker injected GitHub Actions workflows containing base64-encoded bash payloads that exfiltrate CI secrets, cloud credentials, SSH keys, OIDC tokens, and source code secrets to a C2 server. The campaign deployed two payload variants. The mass variant (SysDiag) adds a new workflow triggered on every push and pull request, maximizing automated execution. A targeted variant (Optimize-Build) replaced existing workflows with workflow_dispatch triggers, creating dormant backdoors that the attacker can fire on demand via the GitHub API. [4]

Even a GitHub repository maintained by a contractor for the US Cybersecurity and Infrastructure Security Agency, CISA, was compromised after it was mistakenly exposed to the internet. According to reporting, the exposed material included cloud keys, tokens, plaintext usernames and passwords, internal logs, backups, and files related to CISA’s internal software build, test, and deployment processes. Some of the exposed credentials reportedly provided high-privilege access to AWS GovCloud environments. [5]

Assessment

Software development, and the open-source ecosystem supporting it, is now increasingly being targeted in attacks. It is clear that threat actors have discovered that current practice for many software development teams is not secure against dedicated attacks against this environment. These attacks are now rapidly reaching the point where they will pose a systemic risk. Campaigns such as Shai-Hulud and Megalodon have shown how compromised packages, malicious code, and automated propagation can move through developer ecosystems at scale. When repositories contain valid credentials or poorly protected build logic, attackers may be able to move from simple exposure to operational access, package tampering, or further credential theft.

GitHub, GitLab, Azure DevOps, package registries, and artifact repositories are not just collaboration platforms. They are business-critical development environments that often contain source code, deployment logic, infrastructure-as-code, internal documentation, and access paths into cloud and production systems.

Threat actors also actively monitor public and misconfigured repositories for exposed credentials. Hardcoded secrets, cloud keys, access tokens, and CI/CD credentials are often discovered within minutes of being committed. Even a short exposure window can be enough for an attacker to extract value, establish access, or attempt lateral movement into connected systems.

The risk is not limited to direct compromises or developer mistakes. Modern software delivery depends on a connected chain of services, including repositories, CI/CD platforms, artifact repositories, identity providers, cloud environments, and package registries. A breach in one part of that chain can create access into others. The whole system for trust-based verification of code can now be subverted. Even the tools used to verify code has been weaponized in attacks.

For European organizations, the implication is practical. Development platforms should be governed, monitored, and protected as critical infrastructure. They can provide attackers with access to credentials, deployment processes, and trusted software paths into the organization.

TeamPCP is part of the English-language cybercriminal ecosystem. It is likely that one or more members of this ecosystem has intimate knowledge of modern software development and software pipelines, possibly being a software developer themselves. So-far Russian cybercriminals have not picked up on this trend, likely because Russia and the Russian IT industry is often not part of the modern cloud-based software development ecosystem, so Russian cybercriminals likely have limited experience from it.

However, as the attacks have been highly successful, these techniques may spread in the future. TeamPCP primarily conduct data leak extortion attacks, but they have also announced some form of collaboration with a Russian ransomware-as-a-service group, called Vect. So far not much appears to have come of this collaboration, but success usually leads to other copying it.

Recommendations

Organizations should treat repository and CI/CD security as a priority control area, not as a developer tooling issue. The following actions are recommended:

• Avoid long-lived secrets in CI/CD environments: Prefer temporary trust mechanisms such as OIDC-based federation where possible. Persistent secrets should not be stored as GitHub secrets unless there is a clear operational need and compensating controls are in place.
• Use a dedicated secrets management solution: Production secrets and credentials that are not required for build or deployment should be stored in an approved secrets management platform, not in repositories, build variables, or developer-managed configuration files.
• Limit where secrets can be used: Scope secrets to the minimum number of repositories, workflows, and jobs required. Protect sensitive workflows with GitHub Environments, approval requirements, and branch protection rules.
• Continuously scan repositories for secrets: Implement automated scanning across source code, commit history, pull requests, and configuration files. If a secret is found, removing it from the repository is not sufficient. The credential must be revoked or rotated immediately.
• Reduce reliance on personal access tokens: Limit the use of PATs and enforce restrictions on how they can be created, scoped, and used. Where possible, replace them with short-lived or centrally governed authentication methods.
• Enforce SSO and central identity governance: Require SSO for all users, preferably through enterprise-managed identities. Avoid using personal developer accounts for enterprise access where possible. If personal accounts are used, they can introduce unmanaged device and identity risk, including the possibility that a compromise of a personal workstation becomes an enterprise breach.
• Apply security requirements at organization or enterprise level: Controls should not depend only on individual repository administrators. Enforce baseline requirements centrally, including branch protections, required reviews, security checks, and restrictions on repository settings.
• Separate privileged administration from daily use: GitHub administration should not be performed from the same account used for routine development. Consider separate privileged admin accounts for infrequent high-risk actions.
• Control third-party GitHub Actions: Restrict which actions and providers can be used at organization or enterprise level. Where third-party actions are required, pin them to hashes or use immutable versions to reduce the risk of supply chain compromise.
• Review GitHub Actions cache usage: Ensure caches cannot leak data between security contexts, such as between pull requests and production deployment workflows.
• Integrate GitHub audit logs with monitoring: Forward GitHub audit logs to a SIEM or central logging platform and define alerts for suspicious activity, including secret access changes, new tokens, privilege changes, new runners, workflow modifications, and unusual repository access.
• Harden self-hosted runners: Self-hosted runners should be isolated, rebuilt regularly, and protected against leakage between jobs. Avoid reusing runners across workloads with different trust levels unless strong isolation is in place.

The key objective is to reduce the chance that a single exposed credential or repository misconfiguration can become broader operational access. This requires a combination of secret hygiene, identity control, CI/CD hardening, and continuous monitoring across the software delivery environment. [6]

If you or your organization have concerns about the topic above or need support, please reach out to your Truesec contact for further assistance.
References

[1] https://github.blog/security/investigating-unauthorized-access-to-githubs-internal-repositories/
[2] https://www.aquasec.com/blog/trivy-supply-chain-attack-what-you-need-to-know/
[3] https://research.jfrog.com/post/shai-hulud-here-we-go-again/
[4] https://safedep.io/megalodon-mass-github-repo-backdooring-ci-workflows/
[5] https://krebsonsecurity.com/2026/05/cisa-admin-leaked-aws-govcloud-keys-on-github/
[6] https://www.truesec.com/hub/blog/tips-for-supply-chain-security-in-ci-cd-mitigating-risks-from-third-party-github-actions