The Supply Chain Lesson Behind Shai-Hulud and Megalodon

The Short Version

What: Shai-Hulud and Megalodon were 2026 software supply chain attacks that targeted the systems developers trust most: package registries, GitHub Actions workflows, CI/CD runners, provenance pipelines, and cloud identity federation.

Impact: Mini Shai-Hulud compromised npm and PyPI packages, including packages tied to TanStack, Mistral AI, Guardrails AI, UiPath, and OpenSearch, and was the first widely documented attack to ship malware carrying valid SLSA Build Level 3 provenance (CVE-2026-45321, CVSS 9.6). Megalodon later pushed 5,718 malicious commits to 5,561 GitHub repositories in roughly six hours, backdooring GitHub Actions workflows to steal cloud credentials, SSH keys, GitHub tokens, OIDC token data, and source-code secrets.

Status: These campaigns are no longer breaking news, but the lesson is still current. Any exposed credentials, dormant poisoned workflows, compromised package versions, or overly broad CI/CD trust policies that were not cleaned up may still create downstream risk.

Severity: High supply chain impact. This is not a single vulnerable package or one CVE you can patch and move on from. It is a repeatable attack pattern against the machinery that builds and publishes software.

Why it matters for package intake: Megalodon exploited the source-to-publication gap. The attacker did not need to compromise the npm account when a legitimate maintainer could unknowingly publish from poisoned source. This is the kind of gap SecureChain is designed to close, by analyzing new package versions at onboarding time, including source diffs, build-time hooks, obfuscated payloads, hidden execution paths, and exfiltration behavior, before a version is trusted downstream.

Do this now: Audit GitHub Actions workflows, check for Megalodon indicators, rotate any secrets exposed to suspicious CI runners, review affected package intake, and tighten OIDC trust policies.

Am I Affected?

You may be affected if your organization:

• Uses GitHub Actions for builds, tests, releases, package publishing, or deployment
• Allows workflows to request id-token: write
• Stores cloud, registry, SSH, Docker, Kubernetes, Terraform, or Vault credentials in CI/CD
• Consumes npm or PyPI packages from public registries without additional intake controls
• Installed affected Mini Shai-Hulud packages during the May 2026 exposure window
• Installed @tiledesk/tiledesk-server versions 2.18.6 through 2.18.12
• Allows direct pushes to default branches
• Does not require review for .github/workflows changes
• Treats provenance, signing, or a familiar package publisher as proof that a dependency is safe

A quick place to start is searching repositories for the known Megalodon workflow names and C2 address:

grep -R "SysDiag\|Optimize-Build\|216\.126\.225\.129" .github/workflows/ 2>/dev/null

Then look for encoded shell execution inside workflows:

grep -R "base64 -d.*bash\|base64.*| *bash" .github/workflows/ 2>/dev/null

If either search returns anything unexpected, review the repository history and CI logs before removing files or rotating credentials. Logs may be needed to understand what ran, when it ran, and which secrets were exposed.

What Shai-Hulud and Megalodon Are

Shai-Hulud is the name attached to a family of self-propagating supply chain attacks against developer ecosystems, especially npm and PyPI.

The original worm surfaced in September 2025, when Unit 42 documented a self-replicating npm worm that harvested credentials and used them to spread. A wider variant, Shai-Hulud 2.0, followed in November. By spring 2026, the threat actor tracked as TeamPCP had spent months backdooring high-trust developer and security tooling.

Mini Shai-Hulud, the May 2026 wave, raised the stakes. It did not just publish malicious packages through obviously suspicious accounts. It compromised legitimate build pipelines and used them to produce malicious packages that carried valid provenance attestations.

Megalodon hit a different layer. Instead of focusing on package publication, it mass-injected GitHub Actions workflows into thousands of repositories. Those workflows ran inside CI runners and stole the secrets CI/CD systems hold by design: cloud credentials, GitHub tokens, SSH keys, OIDC token request data, Docker credentials, Kubernetes configs, Terraform credentials, Vault tokens, and source-code secrets.

Together, the two campaigns show the same shift. Attackers are no longer only trying to poison the package you install. They are trying to poison the system that builds, signs, publishes, and deploys it.

Wave One: Mini Shai-Hulud and the SLSA Problem

Mini Shai-Hulud’s standout moment came on May 11, 2026 at 19:20 UTC, when 84 malicious artifacts were published across 42 packages in the @tanstack namespace inside a six-minute window. The packages appeared to come from TanStack’s real release pipeline, using its real OIDC identity.

That is because they did.

The mechanism, assigned CVE-2026-45321 (CVSS 9.6), chained three known GitHub Actions weaknesses into one path:

1. A pull_request_target trigger that runs with write access even when the triggering pull request comes from a fork, providing the foothold.
2. GitHub Actions cache poisoning, used to slip a modified dependency into the legitimate build.
3. Theft of a live OIDC token from runner process memory, used to obtain a valid Sigstore signing certificate.

With a real signing certificate from a real pipeline, the worm produced valid SLSA Build Level 3 provenance attestations for the malicious packages.

This is the part that should change how teams think about provenance.

It does not mean SLSA failed at what it was designed to do. It means many teams are asking provenance a question it does not answer. Provenance can show where an artifact came from and whether it was built by the expected process. In this case that guarantee was technically true, because the malicious packages really were built by the expected pipeline. The problem was that the pipeline itself had been compromised.

SLSA attests to build integrity. It does not prove the code entering the build was safe, that the workflow was not poisoned, or that the maintainer environment had not been compromised upstream. That distinction is not academic: the June 1 copycat wave against the @redhat-cloud-services namespace shipped malicious packages that each carried valid npm provenance, published through GitHub Actions OIDC from a compromised employee account. Provenance did exactly what it promises. It just does not promise what teams assume.

The worm spread to 172 npm packages plus a pair of PyPI packages across 404 malicious versions, reaching ecosystems tied to TanStack, Mistral AI, Guardrails AI, UiPath, and OpenSearch. The 2.3 MB obfuscated payload swept more than 100 file paths for secrets and installed reboot-surviving persistence hooks in developer tools, including Claude Code and Visual Studio Code. Public reporting put the affected packages at more than 518 million combined downloads [verify exact figure before publishing; sources differ on whether this is cumulative or weekly], which is why this was a downstream dependency problem for any organization pulling from public registries during the window, not just a maintainer-side incident.

One day later, on May 12, TeamPCP open-sourced the full Shai-Hulud framework on GitHub under an MIT license, reportedly alongside a contest offering $1,000 in Monero for the largest supply chain attack built with it. A capability refined over months became something any competent attacker could fork by the weekend.

A green provenance check is not a safety verdict. It is one signal in a larger trust decision.

Wave Two: Megalodon and the CI/CD Takeover

Six days after that open-source release, Megalodon arrived.

Between 11:36 and 17:48 UTC on May 18, 2026, the campaign pushed 5,718 malicious commits to 5,561 GitHub repositories. The attacker used throwaway accounts with randomized eight-character usernames (rkb8el9r, bhlru9nr, and similar) and forged bot-style author identities:

• build-bot
• auto-ci
• ci-bot
• pipeline-bot

The commit messages were built to look like routine maintenance:

• ci: add build optimization step
• chore: optimize pipeline runtime
• similar CI-themed changes that are easy to skim past

The attacker was not trying to make application code look malicious. The attacker was trying to make pipeline changes look boring.

Megalodon deployed two GitHub Actions workflow variants, both requesting id-token: write and actions: read, both executing a base64-decoded bash payload, and both reporting to the same C2 at 216.126.225.129:8443.

SysDiag was the noisy, broad variant. It added a workflow triggered on every push and pull request, maximizing how often it executed and harvested.

Optimize-Build was the quiet variant. It used workflow_dispatch, so the workflow could sit dormant until manually triggered through the GitHub API. That makes it more useful as a backdoor: no constant failed builds, no obvious breakage, and no immediate reason for a maintainer to notice.

The payload’s harvesting was broad. It collected CI environment variables and /proc/*/environ, AWS credentials across configured profiles, Google Cloud tokens, instance-role credentials pulled from AWS IMDSv2 and Azure IMDS endpoints, SSH private keys, Docker, .npmrc, .netrc, Kubernetes, Vault, and Terraform credentials, shell history, more than 30 regex patterns of API keys and connection strings, and, most consequentially, the GitHub Actions OIDC token request URL and token alongside GITHUB_TOKEN, GitLab, and Bitbucket tokens.

Why the OIDC Theft Matters

Many organizations have moved away from long-lived cloud keys in CI/CD and toward OIDC federation. That is a good direction. Instead of storing permanent AWS, Google Cloud, or Azure credentials in GitHub Actions, the workflow requests short-lived credentials when it needs them.

Megalodon shows where that model still needs guardrails.

If a malicious workflow can request id-token: write, it can obtain the OIDC token request data needed to impersonate a trusted workflow identity. If the corresponding cloud trust policy is scoped too broadly, that rogue workflow can mint short-lived cloud credentials on the attacker’s own machine.

The issue is not that OIDC is bad. The issue is that OIDC trust must be narrow. A secure setup should answer:

• Which exact repository can request this role?
• Which branch, tag, or environment is allowed?
• Which workflow is allowed?
• Does this workflow actually need id-token: write?
• Can a newly added workflow inherit the same trust?
• Can a workflow on a non-release branch request production credentials?

If the trust policy effectively says “this repository is trusted,” the blast radius is larger than it needs to be. OIDC reduces the risk of long-lived static secrets. It does not solve poisoned workflow execution.

The Tiledesk Case Shows the Downstream Risk

Megalodon was not only a repository-owner problem.

At least one downstream package, @tiledesk/tiledesk-server, was published in compromised form across versions 2.18.6 through 2.18.12. The important detail is that the npm account was not the initial point of compromise. The attacker poisoned the source repository by injecting malicious GitHub Actions workflow files, and the legitimate maintainer then unknowingly published releases from that poisoned source.

That is why 2FA and code signing were not enough. The publish event still looked legitimate, because the attacker never needed to take over the npm account. Both controls confirmed the release came from the real maintainer, which it did. The integrity gap was earlier, between source and publication.

That is also why source-diff analysis matters. A detector that reviews a new package version against its prior version at onboarding time would examine the change from 2.18.5 to 2.18.6 before trusting the new release. The injected workflow files and payload fall squarely into the categories that should raise alarms: build-time execution hooks, CI/CD-style execution paths, obfuscated payloads, hidden execution, credential harvesting, and suspicious network activity, the same backdoor shape as event-stream and ua-parser-js.

This is the specific gap SecureChain is built to address. Because it reasons over the source diff instead of trusting the publish event, SecureChain is designed to catch the maintainer-publishes-poisoned-source scenario that signing, provenance, and registry 2FA all miss, and to hand the security team a reasoning artifact, flagged diff hunks, rationale, and a verdict, before the release ships downstream.

 

The broader cascade looks like this:

1. A repository is modified through stolen or misused access.
2. A GitHub Actions workflow is injected or replaced.
3. The workflow runs inside a trusted CI environment.
4. Secrets are harvested from the runner.
5. A package may be built or published from poisoned source.
6. Downstream users install what appears to be a legitimate package.

From the consumer’s side, the package name is familiar, the publisher is legitimate, and the release comes from the expected account. But the source and workflow behind it were already compromised. “Trusted publisher” and “safe package” are not the same thing.

The Attribution Fight, and Why It Does Not Change Your Response

This is where the public coverage gets messy.

TeamPCP is strongly associated with the broader Shai-Hulud activity, including prior supply chain campaigns and the May 12 release of the worm framework. Some reporting attributes Megalodon directly to TeamPCP.

The more careful read is that Megalodon has strong tradecraft overlap with Shai-Hulud-style activity, but direct attribution is not settled. OX Security, which analyzed the Megalodon payload, assessed it as most likely a copycat, noting similar behavior and style but little shared code, no direct links, no shared identifying indicators, and no claim of responsibility. Megalodon also lacks the public encryption key TeamPCP required for entries in its own contest, so it is not even a contest submission. Mini Shai-Hulud carries strong TeamPCP attribution; Megalodon carries circumstantial overlap. Treat the direct attribution as low confidence.

For defenders, that distinction should not slow anything down. Whether Megalodon was TeamPCP, a copycat, or another actor using the open-sourced tooling, the response is identical: hunt for poisoned workflows, rotate exposed secrets, tighten OIDC, restrict workflow changes, and treat developer endpoints and CI/CD identities as part of the supply chain. Defend against the method, not the brand name.

The root cause is also less exotic than the campaign names suggest. Hudson Rock cross-referenced the GitHub usernames behind Megalodon’s commits against its infostealer database and found that 331 of 978 (over a third) matched machines already infected by infostealers, concluding the access was sourced from infostealer logs. The precondition for attacks like this is usually not a GitHub zero-day. It is a developer workstation or maintainer environment that was already compromised.

Why Traditional Scanners Miss This Class of Attack

Most vulnerability scanners are built to answer questions like:

• Does this package have a known CVE?
• Is this dependency outdated?
• Is this container using a vulnerable library?
• Is this artifact associated with known malware?

Those questions still matter. But Shai-Hulud and Megalodon operate in a different layer.

A poisoned GitHub Actions workflow is not necessarily a vulnerable dependency. A base64-encoded shell payload inside .github/workflows may not appear in an SBOM. A stolen OIDC token is not a CVE. A malicious package can carry valid provenance if the attacker compromised the pipeline that produced it. A legitimate maintainer can publish a malicious release if the source they publish from has already been poisoned.

Supply chain defense has to look beyond the final artifact. Teams need controls that inspect:

• package behavior before install
• source-level changes and version-to-version diffs
• workflow integrity and build-time execution hooks
• CI/CD permissions and runner behavior
• provenance and attestation context
• cloud identity scope
• maintainer and developer credential exposure
• post-publication vulnerability and compromise signals

The registry is only one layer. The build system is now a primary target.

Mitigation

Treat Shai-Hulud and Megalodon as a reason to audit and harden the software delivery path, especially if you have not reviewed your CI/CD exposure since May 2026.

1. Hunt your repositories

Search GitHub repositories and forks for:

• SysDiag and Optimize-Build workflow names
• the C2 address 216.126.225.129
• base64 -d | bash execution
• unexpected workflow_dispatch triggers
• unexplained id-token: write permissions
• workflow commits from unfamiliar bot-like identities
• direct pushes that changed .github/workflows

Pay particular attention to workflow changes around May 18, 2026, especially changes that bypassed pull-request review.

2. Block and review known egress

Block outbound traffic from CI runners to 216.126.225.129:8443, and review historical proxy, firewall, and netflow logs for connections from build systems or self-hosted runners. Blocking the IP is not a complete defense, since infrastructure rotates quickly, but it is useful for historical review and immediate cleanup.

3. Rotate exposed secrets

If a suspicious workflow ran, assume the runner environment was exposed. Prioritize rotation of GitHub PATs and fine-grained tokens, deploy keys, Actions secrets, GitHub App credentials, npm and PyPI publishing tokens, Docker registry credentials, SSH private keys, AWS, Google Cloud, and Azure credentials, Kubernetes configs, Terraform credentials, Vault tokens, and OIDC trust relationships tied to affected workflows.

One caution before you revoke: some Shai-Hulud-family payloads have included a destructive failsafe tied to token revocation. That behavior is not confirmed as a Megalodon payload feature, but on any host you suspect is infected, isolate and image it, and preserve CI logs, workflow-run history, and audit events, before revoking credentials.

4. Quarantine known compromised package versions

If you consume @tiledesk/tiledesk-server, check for versions 2.18.6 through 2.18.12. If any were installed, built, or deployed, review the affected environments and rotate secrets available during build or runtime. Pin to the last verified clean release, 2.18.5, and validate lockfiles.

5. Tighten OIDC trust

Do not allow broad repository-level trust for sensitive cloud roles. Where possible, restrict OIDC trust by repository, branch, tag, environment, workflow file, audience, and release path. A condition like sub restricted to repo:org/name:ref:refs/heads/main stops a rogue workflow on a side branch from minting production credentials.

Review every workflow requesting:

permissions:
id-token: write

Remove it unless the workflow has a documented need to request a token.

6. Require review for workflow changes

Treat .github/workflows as security-sensitive code. Use CODEOWNERS approval for workflow files, branch protection, required pull-request review, signed commits where appropriate, default read-only Actions permissions, third-party actions pinned to commit SHAs instead of mutable tags, restricted runner egress, and separate runners for sensitive release workflows. A workflow file can be as powerful as production deployment code. It should not be easier to change.

Detection

No single scanner result proves Shai-Hulud or Megalodon exposure. The relevant evidence lives across repository history, workflow files, CI runner logs, network logs, GitHub audit events, cloud identity logs, and package lockfiles. Behavioral signals also outlast atomic indicators, because the operator rotates infrastructure.

Useful signals include:

• unexpected changes to .github/workflows
• base64-decoded shell execution inside CI
• new or unexplained workflow_dispatch workflows
• workflows requesting id-token: write without a clear reason
• direct pushes to default branches
• unfamiliar bot-like author names and forged commit dates
• outbound CI runner traffic to 216.126.225.129
• new deploy keys, OAuth grants, or GitHub App installations
• unusual cloud role assumptions from GitHub Actions identities
• package publications shortly after suspicious workflow changes
• unexpected npm or PyPI versions in lockfiles from the exposure window

Example GitHub search terms:

"216.126.225.129"
"SysDiag"
"Optimize-Build"
"base64 -d | bash"
"id-token: write"

Example local workflow search:

grep -R "216\.126\.225\.129\|SysDiag\|Optimize-Build\|base64 -d" .github/workflows/ 2>/dev/null

These checks are a starting point, not a clean bill of health.

Prioritized Remediation Checklist

Audit repositories: Review GitHub Actions workflow changes, especially around May 18, 2026.

Search for IOCs: Look for SysDiag, Optimize-Build, suspicious base64 execution, and the reported C2 address.

Preserve logs: Keep workflow-run logs, GitHub audit logs, package lockfiles, and build artifacts before cleanup.

Rotate secrets: Rotate credentials exposed to any suspicious runner environment.

Tighten OIDC: Scope cloud trust policies to specific workflows, branches, tags, or environments.

Restrict workflow changes: Require pull-request review and CODEOWNERS approval for .github/workflows.

Review package intake: Check whether known-compromised package versions entered your environment.

Harden CI/CD: Pin third-party actions to commit SHAs, restrict runner egress, and minimize default workflow permissions.

Inspect developer endpoints: Treat developer workstations as part of the supply chain, especially where maintainers installed affected packages or had credentials present locally.

Why This Is Bigger Than One Campaign

The important thing about Shai-Hulud and Megalodon is not only the scale. It is the direction of travel. Attackers are moving upstream from vulnerable packages into the trust systems behind them:

• maintainer credentials
• developer endpoints
• CI/CD runners
• GitHub Actions workflows
• OIDC identities
• package publishing automation
• provenance and signing systems
• cloud deployment roles

That changes what open-source security has to mean. It is no longer enough to scan a package after it enters your environment. You need to know where it came from, how it was built, whether the build process was trustworthy, what changed from the last version, whether the package does anything suspicious during install or build, whether the publisher or repository was compromised, and whether the component will keep receivi in ng security fixes after deployment.

That is the problem SecureChain is built to address. SecureChain gives organizations a vetted source for open-source components, with malware screening, source-level inspection, provenance, and ongoing CVE remediation across the component lifecycle. For new package versions, it is designed to reason over the version-to-version diff and flag suspicious changes before they are trusted downstream, including build-time execution hooks, obfuscated payloads, hidden execution paths, and exfiltration behavior.

In a Megalodon-style scenario, that matters because the package may be published by the legitimate maintainer from the legitimate account. The malicious change is not at the registry boundary. It is in the poisoned source that reached the registry.

Shai-Hulud and Megalodon are reminders that the software supply chain is not just the code you install. It is the system that selected it, built it, signed it, published it, and continues to maintain it. That system now needs to be secured like production infrastructure.

Discover SecureChain →

FAQ

Is Megalodon the same thing as Shai-Hulud?

No. Shai-Hulud refers to a family of self-propagating supply chain attacks, especially across npm and PyPI. Megalodon was a mass GitHub Actions workflow-injection campaign on May 18, 2026. They are related by timing and tradecraft, but Megalodon is not confirmed to be the same operation or operator.

Was Megalodon definitely carried out by TeamPCP?

No. TeamPCP is strongly tied to the surrounding Shai-Hulud activity, and Megalodon overlaps with that style of attack, but direct attribution is not confirmed. The researchers who analyzed the Megalodon code assess it as most likely a copycat. Defenders should focus on the technique rather than the actor label.

Does SLSA provenance protect me from this?

Not by itself. Mini Shai-Hulud showed that malicious packages can carry valid SLSA Build Level 3 provenance if the attacker compromises the build pipeline. Provenance helps prove origin and build integrity. It does not prove the code was safe.

Does OIDC make CI/CD safe from credential theft?

OIDC is safer than storing long-lived cloud keys in CI, but it still needs tight scoping. If a malicious workflow can request id-token: write and the cloud trust policy is too broad, an attacker can mint short-lived credentials through the trusted pipeline identity.

Why did 2FA and signing not stop the Tiledesk compromise?

Because the attacker did not need to compromise the npm account. Megalodon poisoned the source repository, and the legitimate maintainer published from that poisoned source. 2FA and signing protect the publish event; they do not prove the source being published was clean.

I do not run many GitHub repositories. Am I still exposed?

Possibly. Even if you were not directly hit, your upstream dependencies may have been built or published from compromised repositories. Any organization that consumes open-source packages inherits some risk from the build pipelines behind those packages.

What is the most important long-term fix?

Treat CI/CD as production infrastructure. Restrict workflow changes, scope OIDC tightly, monitor runner behavior, reduce secrets in CI, inspect packages before install, and stop treating provenance or a familiar publisher as a complete safety signal.

Sources

• Cloud Security Alliance – “Shai-Hulud/Megalodon: A Two-Wave AI Developer Supply Chain Attack”
• Protos Labs – “TeamPCP’s Shai-Hulud Campaign and the Copycat Wave”
• SafeDep – Megalodon campaign analysis (commit dataset, Tiledesk cascade)
• OX Security – Megalodon and Shai-Hulud copycat attribution analysis
• StepSecurity – Megalodon GitHub Actions secret-exfiltration analysis; Mini Shai-Hulud / TanStack analysis
• Tenable – Mini Shai-Hulud CVE-2026-45321 FAQ
• Hudson Rock – Megalodon infostealer root-cause analysis
• Unit 42 (Palo Alto Networks) – original Shai-Hulud worm reporting, September 2025
• The Hacker News – Megalodon and Mini Shai-Hulud campaign coverage
• Socket – npm token invalidation and Shai-Hulud campaign analysis