Over 5,500 GitHub repositories compromised in a single coordinated campaign. Cloud credentials, SSH keys, and Kubernetes configs silently exfiltrated. Here's what happened and why most teams wouldn't have caught it in time.
What Happened
In early 2026, threat researchers identified a coordinated supply-chain campaign, now dubbed Megalodon, that systematically injected malicious commits into thousands of open-source repositories on GitHub. Unlike opportunistic attacks that target a single high-profile project, Megalodon operated at industrial scale automated tooling probed for misconfigured CI/CD pipelines, weak branch protections, and dependency confusion gaps across a broad swath of the OSS ecosystem.
Once inside a repository, the payload was surgical. Malicious code exfiltrated three classes of sensitive material: cloud provider credentials embedded in environment files and workflow YAML, SSH private keys stored inadvertently in project directories, and Kubernetes configuration files containing cluster access tokens all transmitted over encrypted channels to attacker-controlled infrastructure.
Key Insight: The attack didn't exploit a zero-day. It exploited developer blind spots secrets that slipped into version control, dependencies with known vulnerabilities, and container images that had never been inspected. The vulnerabilities had been there for months. Megalodon simply industrialized their discovery.
The Attack Chain, Step by Step
Reconnaissance: Automated repository enumeration Attackers ran tooling across GitHub's public graph to identify repositories with lax branch protection rules, publicly accessible Actions secrets, or dependency manifests referencing packages with known CVEs.
Initial Access: Dependency confusion and typo squatting Malicious packages were published to registries under names nearly identical to legitimate internal libraries. CI pipelines resolve attacker-controlled packages on fresh installs, executing payload code during build time.
Secret Harvesting: Credential extraction from history and environment Scripts recursively scanned commit history, .env files, workflow definitions, and Kubernetes manifests for credential patterns. Over 5,500 repositories exposed at least one usable secret.
Lateral Movement: Cloud and cluster pivoting Stolen AWS keys, GCP service account tokens, and kubeconfig files were used within hours to pivot into production environments spinning up compute for crypto mining, exfiltrating databases, or establishing persistent access.
Persistence: Backdoor commits and poisoned SBOMs in a subset of repositories; attackers merged additional commits that introduced subtle logic backdoors changes designed to survive code review by appearing as routine dependency bumps or linting fixes.
Why Traditional Security Missed It
Most affected organizations had some form of security tooling in place. The problem wasn't the absence of controls it was the cadence and coverage of those controls. Point-in-time scans run at deployment missed secrets committed three sprints ago. Dependency audits ran on declared packages, not on transitive dependencies pulled at build time. Container images were scanned at publishing but never re-evaluated as new CVEs emerged.
Megalodon exposed a fundamental gap: the repository is a living attack surface, and it requires continuous, layered inspection not periodic checkboxes.
How Vigilnz Closes the Gap
Vigilnz was built for exactly this threat model: a continuous, developer-native security layer that covers the full depth of the repository from commit history to runtime containers.
Secret Scanning - Pre-commit and continuous history scanning detects API keys, cloud credentials, private keys, and Kubernetes tokens the moment they enter version control or retroactively across your entire commit history. Entropy-based detection catches custom credential formats that pattern-matching alone misses.
SCA Security - Software Composition Analysis evaluates every direct and transitive dependency against a continuously updated vulnerability database. Megalodon-style dependency confusion attacks are flagged by integrity verification ensuring resolved packages match expected provenance, not just version strings.
SBOM Analysis - Automatically generate and continuously evaluate a Software Bill of Materials for every build. VigilNZ monitors your SBOM against new CVE disclosures in real time, so a vulnerability published after your last deployment still triggers an immediate alert, not a surprise at the next audit.
Container Scanning - Every container image base, application, and sidecar is scanned at build and continuously re-evaluated as new vulnerabilities emerge. Vigilnz surfaces exploitable CVEs with runtime context: whether the vulnerable package is reachable, not just present.