Pendela BhargavaSai

Posted on May 5

🔴 Supply Chain Attacks Are Breaking the Internet in 2026 — Every Major Hack Explained

Your vulnerability scanner is hacking you. Your password manager got weaponized. Your AI coding tool is the new attack surface. Welcome to 2026.

The Year Everything Became a Weapon

In 2025, supply chain attacks were a concern. In 2026, they became the dominant threat vector in software security.

The numbers are staggering: a single compromised maintainer account poisoned a library with 100 million weekly downloads. A misconfigured CI/CD workflow cascaded into five separate tool compromises within days. A developer downloaded Roblox exploit scripts, and that mistake eventually exposed Vercel's internal database — which was listed for sale at $2 million on BreachForums.

This isn't theoretical risk. This is what happened between January and April 2026.

In this post, I'm going to break down every major supply chain attack that hit the IT and software ecosystem this year — what got compromised, how the attackers did it, what the real blast radius looked like, and most importantly, what you need to do right now to protect your pipelines.

Let's start with what a supply chain attack actually is — because most explanations bury the lead.

What Is a Software Supply Chain Attack?

Here's the mental model that matters:

Instead of breaking into your house, the attacker bribes your locksmith.

When you run npm install or pip install, you're implicitly trusting thousands of strangers who maintain open-source packages. You're trusting their accounts, their CI/CD pipelines, their GitHub credentials, and their judgment. Every single one of those trust relationships is an attack surface.

A supply chain attack exploits that trust. Instead of targeting you directly — which requires defeating your firewall, your endpoint detection, your access controls — attackers target the supplier. Compromise one maintainer account, and you've just compromised every developer who installs that package.

The attack chain looks like this:

1. `Identify` a maintainer of a widely-used package
2. Phish their npm/GitHub credentials, or exploit a misconfigured CI/CD workflow
3. Push backdoored versions — the malware runs at install time or on startup
4. Harvest: cloud credentials, SSH keys, API tokens, Kubernetes configs
5. Cascade: use stolen tokens to compromise more repos, more pipelines, more packages
6. Monetize: ransomware, data sale on BreachForums, cryptomining

The asymmetry is what makes this so devastating. The attacker breaks in once, at one point in the supply chain, and inherits access to thousands of downstream organizations simultaneously.

Now let's talk about what actually happened in 2026.

January 2026 — Cisco Unified Communications Zero-Day (CVE-2026-20045)

What got compromised

Cisco's entire enterprise voice stack: Unified Communications Manager, IM & Presence Service, Unity Connection, and Webex Calling Dedicated Instance.

How it happened

A critical zero-day in the web-based management interface allowed unauthenticated remote attackers to send crafted HTTP requests and execute arbitrary commands on the underlying OS — then escalate straight to root. No credentials needed. No user interaction required.

Why it's a supply chain risk (not just a vulnerability)

This one is subtler than the package ecosystem attacks below, but it's a textbook supply chain risk: managed service providers. Thousands of organizations outsource their voice and UC infrastructure to third parties. If your managed service provider is running vulnerable Cisco UC components, your business communications become a pivot point into your environment — even if your own perimeter is airtight.

This is the definition of inherited risk. You didn't deploy the vulnerable software. You didn't configure it. But you're exposed because you trusted someone who did.

How to protect yourself

Apply Cisco's emergency patch immediately (see Cisco Security Advisory cisco-sa-20260115-uc)
Implement continuous vendor monitoring — when a critical advisory drops, you need instant visibility into which of your vendors is exposed
Restrict management interface access to known IP ranges only
Map which applications and data flows depend on your vendors' UC components so you can assess blast radius before an attack, not after

February 2026 — GitHub Actions: The Misconfiguration That Started Everything

What got compromised

This is the origin point of the largest multi-tool supply chain campaign of 2026. A threat actor operating under the GitHub handle hackerbot-claw (account created February 20, 2026) ran an automated campaign scanning public repositories for a specific GitHub Actions misconfiguration: the pull_request_target event trigger with excessive token permissions.

On February 27–28, the attacker successfully exploited this misconfiguration in Aqua Security's Trivy repository, exfiltrating the aqua-bot service account's Personal Access Token (PAT). This PAT had write access to release automation — which is everything the attacker needed.

How it happened

The pull_request_target workflow is a GitHub Actions feature that lets CI pipelines trigger automatically on pull requests from external contributors. The problem: when misconfigured, external code gets access to the repository's internal secrets. The workflow essentially hands an untrusted contributor the keys to your pipeline.

Aqua detected the intrusion and attempted credential rotation. But here's the critical failure: the rotation was not atomic. Sequential token replacement left a window during which newly issued tokens may have been captured. As Aqua's VP of Open Source, Itay Shakury, later confirmed:

"We rotated secrets and tokens, but the process wasn't atomic, and attackers may have been privy to refreshed tokens."

This residual access enabled everything that followed in March.

The lesson about `pull_request_target`

This is a well-documented dangerous pattern, but it keeps getting deployed:

# ⚠️ DANGEROUS — external PRs can access your secrets
on:
  pull_request_target:
    types: [opened]

jobs:
  ci:
    permissions:
      contents: write  # ← This is the mistake

# ✅ SAFE — pin to SHA, restrict permissions
on:
  pull_request:

jobs:
  ci:
    permissions:
      contents: read  # minimum required

How to protect yourself

Never use pull_request_target with write permissions for workflows triggered by external contributors
Pin all GitHub Actions to full 40-character commit SHAs — not version tags (more on why this matters below)
Rotate credentials atomically — revoke all, reissue all, in a single synchronized operation
Limit service account tokens to minimum required permissions and scope

March 2026 — The Month Everything Went Wrong

March 2026 will go down as the most significant month in software supply chain history. Five major compromises. One threat group. A cascade that went from a misconfigured GitHub workflow to a ransomware operation targeting 1,000+ enterprise SaaS environments.

Let me break each one down.

🔍 Trivy (Aqua Security) — March 19–20, 2026

CVE-2026-33634 | Severity: CRITICAL

What happened

At approximately 17:43 UTC on March 19, 2026, an attacker with residual access from the February compromise force-pushed malicious code to 75 of 77 version tags in aquasecurity/trivy-action — the official GitHub Action for Trivy, one of the most widely deployed open-source vulnerability scanners in the world.

Simultaneously, all 7 tags in aquasecurity/setup-trivy were poisoned, and a weaponized Trivy binary (v0.69.4) was published to GitHub Releases, Docker Hub, GHCR, ECR Public, and deb/rpm repositories.

Safe versions: only trivy-action v0.35.0, setup-trivy v0.2.6, and trivy v0.69.3 were unaffected.

The attack was elegant and terrifying

The malicious entrypoint.sh ran the credential-harvesting payload first, then ran the legitimate Trivy scan. Workflows completed normally. No errors. No indication of compromise. Developers watching their CI logs saw a clean vulnerability scan — while their secrets were being exfiltrated in the background.

The malware (named "TeamPCP Cloud Stealer") performed three operations:

Dumped Runner.Worker process memory to extract GitHub PATs and CI secrets
Swept SSH keys, cloud credentials (AWS, GCP, Azure), Kubernetes tokens, Docker configs, Git credentials
Encrypted the bundle with AES-256 + RSA-4096 and exfiltrated to attacker-controlled servers

If the primary C2 channel failed, the malware fell back to creating a repository called tpcp-docs inside the victim's own GitHub organization to store stolen secrets. Check your org for that repo right now.

The forensic tells (that most teams missed)

# Each malicious commit had an impossible timestamp:
# - Claimed to be from 2021/2022
# - But parent commit was dated March 2026

# Additionally:
# - Only entrypoint.sh was modified per commit
# - Original commits touched multiple files
# - GitHub's "Immutable" release badge was present (but meaningless)

How to protect yourself

# ❌ VULNERABLE — tag can be rewritten silently
- uses: aquasecurity/trivy-action@v0.34.2

# ✅ SECURE — commit SHA is immutable
- uses: aquasecurity/trivy-action@f781cce5aab226378d021711787766a7d423d18d

If you ran Trivy between 17:43 and 23:13 UTC on March 19, 2026:

Search your GitHub org for any repo named tpcp-docs
Check DNS/network logs for connections to scan.aquasecurtiy[.]org (note the typo — deliberate)
Check for connections to 45.148.10.212
Treat all CI/CD secrets from that window as fully compromised — rotate everything

🧠 LiteLLM — March 24, 2026

Severity: CRITICAL | ~3.4M daily downloads | 40-minute exposure window

What happened

LiteLLM is a Python package providing a unified interface for 100+ LLM APIs — OpenAI, Anthropic, Google, AWS Bedrock, Azure OpenAI. Because it sits between your applications and multiple AI providers, it has access to API keys and cloud credentials for all of them. That's exactly why it was targeted.

The compromise was a cascade from Trivy: LiteLLM's CI/CD pipeline used Trivy for security scanning. When Trivy was poisoned on March 19, the malware in LiteLLM's pipeline exfiltrated its PyPI publish token to TeamPCP. Five days later, attackers used that token to upload two malicious versions directly to PyPI:

litellm==1.82.7 — published 10:39 UTC
litellm==1.82.8 — published 10:52 UTC

Both were live for approximately 40 minutes before PyPI quarantined them. During that window, they accumulated tens of thousands of downloads.

The 3-stage payload

# Stage 1: Credential Harvesting
# Exfiltrates to models.litellm.cloud (attacker-controlled, not official BerriAI domain)
collect([
    "LLM API keys (OpenAI, Anthropic, Google...)",
    "Cloud credentials (AWS, GCP, Azure)",
    "SSH keys, shell history, .env files",
    "Crypto wallets",
    "Kubernetes configs"
])

# Stage 2: Kubernetes Lateral Movement
# Deploys privileged DaemonSets → full cluster access

# Stage 3: Persistence
# Installs ~/.config/systemd/user/sysmon.service
# Polls attacker server for additional payloads
# Survives package removal

The .pth file mechanism in v1.82.8 was particularly nasty: it placed a litellm_init.pth file that executed on every Python interpreter startup — meaning the payload fired even when LiteLLM wasn't explicitly imported.

Disclosure suppression

When the community opened GitHub issue #24512 to report the compromise, TeamPCP deployed 88 bots from 73 unique compromised developer accounts in a 102-second window to spam the thread. They used the compromised maintainer account to close the issue as "not planned." This is one of the first documented uses of AI-assisted bot networks for supply chain attack disclosure suppression.

Immediate action

# Check if you're affected
pip show litellm | grep Version
# v1.82.7 or v1.82.8 = COMPROMISED

# Check for persistence
ls ~/.config/systemd/user/sysmon.service
ls ~/.config/sysmon/sysmon.py

# In Kubernetes
kubectl get pods -n kube-system | grep "node-setup"

# Purge cache
pip cache purge
# or
rm -rf ~/.cache/uv

# Safe version
pip install litellm==1.82.6

📦 Axios (npm) — March 30–31, 2026

Severity: CRITICAL | ~100M weekly downloads | Attributed: UNC1069 (North Korea)

What happened

Axios is one of the most depended-upon libraries in the JavaScript ecosystem. At the time of the attack, it was present in approximately 80% of cloud and code environments. The attack didn't exploit any code vulnerability — it was a straightforward account takeover.

Attackers compromised the npm account of jasonsaayman, Axios's primary maintainer, by changing the account's associated email from jasonsaayman@gmail.com to ifstap@proton.me. This bypassed the GitHub Actions OIDC publish flow entirely.

The attack timeline:

2026-03-30 05:57 UTC — plain-crypto-js@4.2.0 published (clean decoy, builds registry history)
2026-03-30 23:59 UTC — plain-crypto-js@4.2.1 published (malicious postinstall backdoor)
2026-03-31 00:21 UTC — axios@1.14.1 published (MALICIOUS, tagged: latest)
2026-03-31 01:00 UTC — axios@0.30.4 published (MALICIOUS, tagged: legacy)
2026-03-31 03:29 UTC — Detected and removed

39 minutes. Two malicious versions. Both tagged as the default install.

The payload

The malicious dependency plain-crypto-js contained a postinstall hook that silently downloaded and executed platform-specific stage-2 RAT implants from sfrclak[.]com:8000. Cross-platform: macOS, Windows, Linux.

Google's Threat Intelligence Group attributed this to UNC1069, a financially motivated North Korean threat actor. OpenAI was sufficiently exposed via Axios's dependency chain that it revoked its macOS code-signing certificate on March 31, 2026 as a precaution.

Check your lockfiles now

# Check for compromised versions
grep -E "axios.*(1\.14\.1|0\.30\.4)" package-lock.json
grep -E "plain-crypto-js" package-lock.json yarn.lock bun.lockb

# Safe versions
npm install axios@1.14.0  # Last legitimate 1.x with SLSA provenance

How to protect yourself

Enable phishing-resistant MFA on npm, GitHub, and all cloud platforms — no exceptions
Use npm ci with strict lockfiles instead of npm install
Monitor npm for maintainer email changes on critical dependencies
Audit and block postinstall scripts in CI environments where possible
Never run npm install on production systems from ephemeral runners without lockfile pinning

🤖 Anthropic Claude Code — March 31, 2026

Severity: HIGH | ~512,000 lines of proprietary source code | Root cause: Human error

What happened

This one is different from the others — it wasn't a malicious actor compromising a third party. Anthropic accidentally shipped the entire source code of Claude Code to the public npm registry.

When Anthropic published @anthropic-ai/claude-code version 2.1.88, a missing exclusion rule in the build configuration caused a 59.8 MB JavaScript source map file (cli.js.map) to be bundled into the package. That source map pointed to a zip archive on Anthropic's Cloudflare R2 storage containing the full, unobfuscated TypeScript source — 512,000 lines across 1,906 files.

Security researcher Chaofan Shou spotted it on X within hours. By the time Anthropic pulled the package at ~08:00 UTC, the code had been downloaded from their own cloud storage, mirrored to GitHub, and forked tens of thousands of times.

What was exposed

Complete multi-agent orchestration architecture
Self-healing memory system (MEMORY.md architecture with lazy-load topic files)
"Undercover Mode" — suppresses Anthropic-internal metadata in commits to public repos
Anti-distillation controls — injects fake tool definitions into API responses to poison competitor training data
44 feature flags, including an unreleased Tamagotchi easter egg planned for April 1–7
Bidirectional CLI-to-IDE communication layer

The cascading danger

The leak coincided — entirely coincidentally — with the Axios RAT attack. Anyone who updated Claude Code via npm between 00:21 and 03:29 UTC on March 31 may have simultaneously pulled a trojanized version of Axios.

Additionally, attackers immediately registered npm packages mimicking Anthropic's internal tooling (audio-capture-napi, color-diff-napi, image-processor-napi) to stage dependency confusion attacks against developers trying to compile the leaked source.

Do not download, fork, build, or run any GitHub repository claiming to be "leaked Claude Code." Many of these repositories are active malware lures delivering Vidar Stealer and GhostSocks.

Anthropic's official statement

"Earlier today, a Claude Code release included some internal source code. No sensitive customer data or credentials were involved or exposed. This was a release packaging issue caused by human error, not a security breach. We're rolling out measures to prevent this from happening again."
— Anthropic Spokesperson

What this means for your build pipeline

# The failure point: Bun generates source maps by default.
# A single missing line in build config exposed 512K lines of IP.

# Lesson: Add this to your CI/CD pre-publish checklist:
✓ Verify .npmignore excludes *.map files
✓ Verify `files` field in package.json is allowlist-based, not denylist
✓ Run `npm pack --dry-run` and inspect the manifest before every publish
✓ Set up automated secret/source scanning on all npm publish workflows

April 2026 — The Attacks Keep Coming

▲ Vercel — April 19, 2026

Severity: CRITICAL | Entry point: AI productivity tool | Dwell time: ~2 months

What happened

This attack is a masterclass in how OAuth trust relationships create invisible lateral movement paths.

The chain:

February 2026: A Context.ai employee downloaded Roblox game exploit scripts. Those scripts installed Lumma Stealer malware.
Lumma Stealer exfiltrated the employee's Google Workspace OAuth tokens.
Context.ai's Chrome Extension had been granted full Google Drive read access by users during onboarding.
A Vercel enterprise employee had used Context.ai and connected their Vercel Google account.
Attackers pivoted from the stolen tokens → Context.ai's AWS environment → OAuth tokens for their product → the Vercel employee's workspace → Vercel's internal systems.

Vercel disclosed the breach on April 19, 2026. By then, the attacker had approximately 2 months of dwell time. Vercel's CEO Guillermo Rauch confirmed the attack chain publicly on X and named Context.ai as the compromised third party.

The stolen Vercel internal database was listed for sale at $2 million on BreachForums by ShinyHunters.

The env variable problem

Vercel's environment variable model left variables not explicitly marked as "sensitive" unencrypted at rest. Once an attacker had team-scoped OAuth access, they could read all non-sensitive environment variables — connection strings, API keys, third-party service credentials — stored by developers who assumed they were protected.

Key takeaway for developers

You can have perfect security in your own systems and still get breached because an AI productivity tool you gave full Drive access to got compromised via an employee who downloaded Roblox scripts.

This is the supply chain threat model in its purest form. The attack surface is no longer just your code — it's every OAuth permission you've ever granted.

How to protect yourself

Immediate actions:
✓ Audit all OAuth app permissions in your Google Workspace — revoke apps with excessive access
✓ Mark ALL Vercel environment variables as "sensitive" explicitly (not just secrets)
✓ Query database connection logs for IPs outside known egress ranges, Feb–Apr 2026 window
✓ Rotate all API keys and secrets stored in Vercel project environment variables

Systemic changes:
✓ Never grant AI tools full-read workspace access — use scoped permissions
✓ Implement OAuth token monitoring to detect abnormal access patterns
✓ Treat third-party AI tools with the same vendor risk assessment as any SaaS platform

🔐 Bitwarden CLI — April 22, 2026

Severity: CRITICAL | Window: 90 minutes | Notable: First supply chain attack targeting AI coding tools

What happened

The Shai-Hulud worm's "Third Coming." At 5:57 PM ET on April 22, 2026, attackers published @bitwarden/cli@2026.4.0 — a malicious version of the CLI tool for the world's most popular open-source password manager (10M+ users, 50,000 business customers). By 7:30 PM ET, it was gone.

90 minutes. That's the entire attack window.

The attack vector: Bitwarden's repository uses checkmarx/ast-github-action — one of the GitHub Actions compromised in the ongoing Checkmarx supply chain campaign (also attributed to TeamPCP). Attackers hijacked Bitwarden's CI/CD pipeline, editing the publish-cli.yml workflow five consecutive times to inject a prebuilt malicious tarball containing the payload bw1.js.

Bitwarden confirmed: no user vault data was accessed. The web extension, desktop apps, and all other clients were unaffected. Only the CLI npm package was compromised.

The payload was remarkable

The malware targeted six distinct credential surfaces and introduced two novel capabilities:

// Credential targets:
targets = [
  "AWS access keys + SSM/Secrets Manager",
  "Azure credentials + Key Vault",
  "GCP service account keys + Secret Manager",
  "GitHub PATs + npm publish tokens",
  "SSH keys + shell history + .env files",
  "AI coding assistant configurations"  // ← NEW in 2026
]

// Novel capability 1: AI tool targeting
// Explicitly probed for: Claude, Cursor, Codex CLI, Aider
// If authenticated session found → extract credentials + inject persistence

// Novel capability 2: Self-propagating worm
// Uses victim's npm publish tokens to backdoor ALL packages they can publish to
// Exfiltrates to public GitHub repos (RSA-encrypted) as dead-drop C2
// GitHub traffic not flagged by security tools → effective evasion

// Kill switch: skips if Russian locale detected

This changes the threat model for AI coding tools

The Bitwarden CLI attack — combined with the Vercel breach via Context.ai — confirms a clear pattern that security teams need to internalize:

AI coding tools (Claude, Cursor, Copilot, Aider) sit at the intersection of everything attackers want: source code access, command execution, API credentials, and cloud service connections.

These tools are now explicitly named in supply chain attack malware. Your AI coding assistant's authentication state is a credential worth stealing.

Immediate response

# Check if affected (installed between 5:57–7:30 PM ET, April 22)
npm list @bitwarden/cli  # 2026.4.0 = COMPROMISED

# Clean install
npm uninstall -g @bitwarden/cli
npm cache clean --force
npm install -g @bitwarden/cli@2026.4.1  # verified clean

# Find C2 artifacts
find / -name "bw1.js" -o -name "bw_setup.js" 2>/dev/null

# Search for data exfil repos
# Check public GitHub for repos containing: "Shai-Hulud: The Third Coming"

# Rotate if affected:
# → GitHub PATs
# → npm tokens  
# → AWS access keys
# → GCP service account keys
# → Azure credentials
# → SSH keys

The Big Picture: TeamPCP and the Campaign Architecture

Most of the March–April attacks trace back to a single threat group: TeamPCP (also operating as DeadCatx3, PCPcat, Persy_PCP, ShellForce, and CipherForce).

TeamPCP first appeared in late December 2025 as a group focused on cloud-native infrastructure exploitation. Their 2026 campaign was methodical:

Phase 1 (Feb 27–28):  Exploit pull_request_target in Trivy → steal aqua-bot PAT
Phase 2 (Mar 1):      Aqua rotates credentials → incomplete rotation
Phase 3 (Mar 19):     Use residual access → poison 75 Trivy tags + Docker images
Phase 4 (Mar 21):     Use stolen PATs from Trivy → poison KICS GitHub Actions
Phase 5 (Mar 24):     Use LiteLLM CI's Trivy → steal PyPI token → poison LiteLLM
Phase 6 (Mar 27):     Telnyx Python SDK compromised
Phase 7 (Mar 30–31):  Axios npm package poisoned (separate North Korean actor)
Phase 8 (Apr 15):     Vect ransomware lists first victim from Trivy campaign
Phase 9 (Apr 22):     Bitwarden CLI poisoned via Checkmarx GitHub Action

The campaign spanned PyPI, npm, Docker Hub, GitHub Actions, and OpenVSX in a single coordinated multi-ecosystem operation.

Systemic Defenses: What Actually Works

After cataloging all of this, here's what the evidence shows actually works:

1. Pin to commit SHAs, not version tags

# This is the single highest-impact change you can make:

# ❌ VULNERABLE (both of these)
uses: some-action@v2.0
uses: some-action@main

# ✅ IMMUTABLE — cannot be silently changed
uses: some-action@a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2

The 2025 tj-actions attack and the 2026 Trivy attack both succeeded because developers referenced actions by tag. Both would have been completely immune with SHA pinning. One line of config change. That's it.

2. Use lockfiles strictly

# In CI/CD pipelines:
npm ci          # NOT npm install
pip install --require-hashes -r requirements.txt

# Never allow unpinned transitive dependencies in production

3. Atomic credential rotation

When you detect a compromise and rotate credentials, the rotation must be a single synchronized operation — revoke all active tokens, generate new ones, update all consumers simultaneously. Sequential rotation leaves a window. TeamPCP exploited exactly this window in the Trivy incident.

4. Principle of least privilege for service accounts

# Your CI service account should not have:
# - write access to multiple repositories
# - admin access to package registries
# - broad cloud IAM roles

# It should have exactly:
# - read access to the specific repos needed for this job
# - publish access to the specific package this job publishes
# - no persistent credentials (use OIDC/short-lived tokens)

5. Behavior-based CI monitoring

The LiteLLM incident was caught first by a developer whose machine started stuttering — their CPU was pegged because the malware's fork bomb behavior crashed the system. That's not monitoring; that's luck.

What you actually need: alerts for Python processes making outbound POST requests at install time. Package installation should pull from PyPI — it should never POST encrypted binary payloads to external endpoints.

Alert rule: 
  process: python (via pip subprocess)
  direction: outbound
  method: POST
  payload: encrypted binary
  action: ALERT + BLOCK

6. Audit OAuth permissions regularly

The Vercel breach started with a productivity tool that was granted full Google Drive read access. Every OAuth integration in your organization is a potential pivot point. Audit them. Scope them to minimum required permissions. Revoke anything that hasn't been used recently.

7. Treat your AI coding tools as high-privilege systems

Given the Bitwarden CLI attack explicitly targeted Claude, Cursor, Codex, and Aider credentials, it's time to treat AI coding assistant authentication state with the same security posture as cloud access keys:

Don't leave AI tools authenticated in unmonitored environments
Rotate AI tool API keys on the same schedule as cloud credentials
Monitor for abnormal AI tool usage patterns (large data transfers, unusual API calls)
Be aware that your AI coding assistant may have access to your entire codebase, your git credentials, and your cloud service connections simultaneously

The Developer's Quick Reference Checklist

Here's a condensed action list you can use right now:

For your CI/CD pipelines

☐ Pin all GitHub Actions to full commit SHAs
☐ Use npm ci / pip install --require-hashes (not npm install / pip install)  
☐ Audit pull_request_target workflows for excessive permissions
☐ Limit service account tokens to minimum required scope
☐ Enable GitHub's SHA pinning organizational policy
☐ Set up behavior-based alerts for install-time network requests

For your dependencies

☐ Check for plain-crypto-js in any lockfile (Axios RAT indicator)
☐ Check for litellm==1.82.7 or 1.82.8 in any Python environment
☐ Check @bitwarden/cli for version 2026.4.0 (rotate if found)
☐ Search your GitHub org for repos named "tpcp-docs" (Trivy compromise indicator)
☐ Audit all GitHub Actions for recent unexpected workflow edits

For your organization

☐ Audit all OAuth app permissions — revoke excessive access
☐ Mark all Vercel environment variables as "sensitive"
☐ Rotate credentials from any CI pipeline that ran Trivy on March 19, 2026
☐ Implement vendor monitoring with automated CVE-to-vendor mapping
☐ Document your complete dependency tree (can you answer: what packages did production install in the last 30 days?)

Closing Thoughts

The pattern across all of these attacks is the same: attackers are targeting trust, not systems.

They're not breaking through your firewall. They're getting invited through the front door — via a trusted package, a trusted OAuth app, a trusted GitHub Action, a trusted vulnerability scanner.

The question isn't whether your perimeter is secure. The question is whether you know every entity you trust, what access you've granted them, and what happens to your environment if any one of them is compromised.

Supply chain security in 2026 isn't a specialized discipline anymore. It's table stakes for any team that ships software.

The next compromised package is already on its way to your CI pipeline. The question is whether you'll see it land.

Resources and Further Reading

If you're responsible for a CI/CD pipeline, share this with your team — the SHA pinning point alone is worth the read.*

All technical details sourced from public security disclosures, vendor incident reports, and independent researcher analysis.

Tags: #security #cybersecurity #devops #opensource #supplychain #javascript #python #npm #github

The Year Everything Became a Weapon

What Is a Software Supply Chain Attack?

January 2026 — Cisco Unified Communications Zero-Day (CVE-2026-20045)

What got compromised

How it happened

Why it's a supply chain risk (not just a vulnerability)

How to protect yourself

February 2026 — GitHub Actions: The Misconfiguration That Started Everything

What got compromised

How it happened

The lesson about pull_request_target

How to protect yourself

March 2026 — The Month Everything Went Wrong

🔍 Trivy (Aqua Security) — March 19–20, 2026

What happened

The attack was elegant and terrifying

The forensic tells (that most teams missed)

How to protect yourself

🧠 LiteLLM — March 24, 2026

What happened

The 3-stage payload

Disclosure suppression

Immediate action

📦 Axios (npm) — March 30–31, 2026

What happened

The payload

Check your lockfiles now

How to protect yourself

🤖 Anthropic Claude Code — March 31, 2026

What happened

What was exposed

The cascading danger

Anthropic's official statement

What this means for your build pipeline

April 2026 — The Attacks Keep Coming

▲ Vercel — April 19, 2026

What happened

The env variable problem

Key takeaway for developers

How to protect yourself

🔐 Bitwarden CLI — April 22, 2026

What happened

The payload was remarkable

This changes the threat model for AI coding tools

Immediate response

The Big Picture: TeamPCP and the Campaign Architecture

Systemic Defenses: What Actually Works

1. Pin to commit SHAs, not version tags

2. Use lockfiles strictly

3. Atomic credential rotation

4. Principle of least privilege for service accounts

5. Behavior-based CI monitoring

6. Audit OAuth permissions regularly

7. Treat your AI coding tools as high-privilege systems

The Developer's Quick Reference Checklist

For your CI/CD pipelines

For your dependencies

For your organization

Closing Thoughts

Resources and Further Reading

The lesson about `pull_request_target`