#ci-cd-security

[definitelytzar]

Megalodon Supply Chain Attack Infects 5,500 GitHub Repositories via CI/CD Pipelines

In a startling display of automated aggression, a supply chain attack dubbed "Megalodon" has infected over 5,500 GitHub repositories in a single six-hour window. Discovered by cybersecurity researchers at SafeDep on May 18, 2026, this campaign represents a significant escalation in the targeting of CI/CD pipelines, leveraging a technique known as direct Poisoned Pipeline Execution (d-PPE) to harvest sensitive credentials at scale.

The Attack Vector: Direct Poisoned Pipeline Execution

Unlike traditional supply chain attacks that compromise package dependencies, Megalodon targeted the build process itself. Attackers utilized accounts with write access to inject malicious GitHub Actions workflows directly into repository definitions. When these workflows executed, they triggered attacker-controlled commands designed to exfiltrate secrets from the CI/CD environment.

The primary targets were high-value credentials, including:

- Cloud Provider Keys: AWS, Google Cloud, and Microsoft Azure credentials. - Authentication Tokens: SSH keys, API tokens, and GitHub Actions OIDC tokens. - Deployment Secrets: Environment variables used for production deployments.

Automation and Evasion Tactics

The Megalodon campaign was characterized by its industrial-scale automation. Attackers deployed a network of fake GitHub accounts with random eight-character names, often impersonating automated services such as "build-bot," "auto-ci," and "pipeline-bot."

SafeDep analysis identified two primary infection methods:

- SysDiag: Adding a new, seemingly benign workflow file that exfiltrates data in the background. - Optimize-Build: Replacing existing system files with a dormant backdoor that can be activated remotely via the GitHub API.

Real-World Impact: The Tiledesk Incident

The downstream consequences of Megalodon extend beyond code repositories. Live chat and chatbot service Tiledesk was a notable victim, with hackers compromising nine of its GitHub code areas. This led to the unintentional publication of seven infected versions of their product to the public npm package registry, effectively spreading the infection from the source code level to the package ecosystem.

GitHub's Security Posture

While GitHub has not publicly commented on the Megalodon attack specifically, the incident coincides with a separate disclosure regarding unauthorized access to approximately 3,800 internal GitHub-owned repositories via a compromised employee device. This dual revelation underscores a critical vulnerability in the software supply chain: even platforms designed for secure development are not immune to credential-based attacks.

For developers and maintainers, we recommend:

- Audit Workflow Files: Review all .github/workflows files for unauthorized changes or suspicious job steps. - Rotate Secrets: Immediately rotate any cloud credentials, API tokens, or SSH keys that may have been exposed to CI/CD pipelines. - Pin Actions: Use SHA-hashed references for GitHub Actions instead of version tags to prevent tampering. - Review Commit History: Look for commits from unknown accounts, especially those with bot-like names pushing workflow changes.

[definitelytzar]

GitHub Actions Compromised: Imposter Commits Steal CI/CD Credentials

A sophisticated supply chain attack has compromised the popular actions-cool/issues-helper GitHub Action, redirecting all existing tags to imposter commits designed to steal CI/CD credentials. The attack represents a new evolution in software supply chain exploitation, bypassing traditional code review processes entirely.

The Imposter Commit Technique

Unlike traditional supply chain attacks that inject malicious code through pull requests or direct commits, this attack used "imposter commits"—deceptive references that point to malicious code existing only in an adversary-controlled fork, rather than the original trusted repository.

StepSecurity researcher Varun Sharma explained: "Every existing tag in the repository has been moved to point to an imposter commit that does not appear in the action's normal commit history. That commit contains malicious code that exfiltrates credentials from CI/CD pipelines that run the action."

How the Attack Worked

When a GitHub Actions workflow referenced the compromised action by version tag, the following sequence occurred:

- The workflow pulled the malicious commit (thinking it was legitimate) - The action downloaded the Bun JavaScript runtime to the runner - It read memory from the Runner.Worker process to extract credentials - Stolen data was exfiltrated via HTTPS to t.m-koschecom

Connection to Mini Shai-Hulud Campaign

The exfiltration domain overlaps with the Mini Shai-Hulud campaign that recently compromised @antv npm packages, suggesting both attacks are part of a coordinated operation. Philipp Burckhardt, head of threat intelligence at Socket, confirmed: "That points to the same Mini Shai-Hulud activity cluster, not a separate npm-only incident."

Scope of Compromise

In addition to issues-helper, 15 tags associated with actions-cool/maintain-one-comment were also compromised with identical functionality. GitHub has since disabled access to both repositories due to violations of its terms of service.

StepSecurity warned: "Because every tag now resolves to malicious commits, any workflow that references the action by version pulls the malicious code on its next run. Only workflows pinned to a known-good full commit SHA are unaffected."

Remediation

Organizations using these actions must:

- Immediately remove references to actions-cool/issues-helper and actions-cool/maintain-one-comment - Rotate all CI/CD credentials that may have been exposed - Pin future actions to full commit SHAs instead of version tags - Monitor outbound connections from CI/CD runners for suspicious domains

Reflection

The imposter commit technique demonstrates a fundamental weakness in how GitHub Actions resolves dependencies. Tags are mutable references that can be rewritten by anyone with write access to a repository—whether that access was obtained legitimately or through compromise.

For enterprises relying on GitHub Actions for CI/CD, the lesson is unequivocal: never trust tags. Pinning to full commit SHAs provides cryptographic assurance that the code you're running is exactly what you reviewed. Anything less is an invitation to supply chain compromise.

[cyber-sec]

GitHub Workflow Bug Lets Attackers Run Code on Microsoft Repositories

A flaw in a GitHub Actions workflow in Microsoft’s Windows-driver-samples repo allowed attackers to inject Python code and execute it remotely, risking exposure of sensitive CI/CD secrets.

Source: Tenable

Read more: CyberSecBrief