Your Build Pipeline Is the Attack Surface — Four Active Exploits This Week
The Convergence
This is not a trend piece. Four distinct supply chain attacks are live against CI/CD pipelines this week. They share one assumption: inputs to the build are trusted because the channel was trusted. The channel is not the artifact.
The build pipeline is running untrusted input as code and calling it a dependency fetch.
Attack 1: GitHub .patch URL Injection
GitHub exposes a .patch view for any commit. The commit message renders inline in that output. GNU patch -p1 cannot distinguish between the real diff and a diff-shaped payload pasted into the commit message. Demo target is .git/hooks/post-applypatch. Silent code execution on the next git am. Reviewers never see it. The payload lives in the commit message, and the diff tab doesn't render that. git cherry-pick is immune. git apply blocks .git/ traversal, then happily applies the injected hunks to working-tree files.
Attack 2: Checkmarx KICS (Lapsus$)
Lapsus$ took Checkmarx's GitHub account and published malicious payloads twice, in March and again last week. KICS runs in CI with source, build artifacts, and cloud credentials in scope. If your pipeline runs KICS, it has been executing attacker code with the runner's full permissions. The downstream is compounding. The Vect ransomware group is now working with TeamPCP to ransom KICS-compromised companies. Vect's encryptor has a flawed algorithm that permanently destroys files larger than 128KB. Paying does not recover the data. The spec destroys it.
Attack 3: ShinyHunters via Anodot
ShinyHunters compromised Anodot, a cloud-cost monitoring SaaS, and pivoted into customer Snowflake data stores. Vimeo, Rockstar Games, Zara, and Payoneer are confirmed. A cost-monitoring tool has no reason to hold data-plane credentials. In practice it accumulates broad read access because nobody scopes the IAM role down. Every SaaS in the stack holding cloud credentials is a potential Anodot.
Attack 4: elementary-data PyPI Trojan
elementary-data, 1.1M monthly downloads, was trojaned for 12 hours through a GitHub Actions script-injection flaw. Malicious version 0.23.3 exfiltrated warehouse credentials, cloud keys, API tokens, and SSH keys from every CI runner and developer machine that pulled it. The vector is the ${{ github.event.*.body }} injection pattern.
The Pattern
Same root cause in all four. The build system treats a mutable pointer as a stable artifact: a .patch URL, a tag reference, a package version, a SaaS API token. GitHub Actions has no lockfiles, no integrity hashes, and no transitive dependency visibility. GitHub acknowledged the gaps and said changing defaults would break existing workflows. That is a permanent condition of the platform now. Plan around it.
What to do
Grep all CI configs for `patch -p1`, `curl.*\.patch`, and any GitHub-sourced .patch URL processing by end of day Monday. Replace with `git cherry-pick` or `git apply --reject`.
Verify Checkmarx KICS binary hashes against known-good versions from before March 2026. Check CI runner logs for unexpected outbound connections during KICS scan steps.
If elementary-data ever installed (check lockfiles for version 0.23.3), rotate ALL credentials accessible to those environments — cloud keys, API tokens, SSH keys, database creds.
Audit all SaaS tools with credentials or API access to your data infrastructure (Snowflake, BigQuery, S3). Apply least-privilege — cost monitoring tools should not have data-plane access.
Pin every GitHub Action to a full commit SHA. Implement an automated CI check that blocks any tag-based action references in workflow files.