There’s a strange irony playing out in the software supply chain. The tools we trust to protect systems are increasingly becoming the very things attackers go after. Not payment gateways. Not identity providers. But security tools—vulnerability scanners, CI/CD utilities, and even compression libraries tied deep into SSH authentication.
This isn’t coincidence. It’s deliberate targeting.
Over three consecutive years—March 2024, March 2025, and March 2026—we’ve seen multiple confirmed supply chain compromises. Two of those in 2026 happened within just 24 hours. Each case has been analyzed individually elsewhere, but when you line them up side by side, a clearer and more concerning picture emerges.
Case 1: XZ Utils (CVE-2024-3094) — The Long Game
In March 2024, a small delay in SSH login—about 500 milliseconds—caught the attention of an engineer. That tiny anomaly exposed one of the most dangerous backdoors in recent memory.
The attacker behind it, operating as “Jia Tan,” spent over two years building trust. They contributed legitimate code, fixed bugs, and engaged meaningfully with the project. Eventually, they gained commit access.
The real attack came later. Malicious code was hidden inside binary test files:
tests/files/bad-3-corrupt_lzma2.xztests/files/good-large_compressed.lzma
During the build process, these files were quietly unpacked using tr, a harmless-looking utility. That step injected a precompiled object into the build, ultimately hooking into RSA_public_decrypt inside SSH.
The result? A weakened authentication process—essentially turning SSH into an oracle.
What stands out here is not just the payload, but the patience. The attacker didn’t rush. They became part of the project.
Case 2: reviewdog → tj-actions (2025) — Trust as an Attack Vector
In March 2025, attackers didn’t go after thousands of repositories directly. Instead, they compromised one foundational GitHub Action: reviewdog/action-setup.
Through GitHub’s automated team invitation system, the attacker gained write access, pushed a malicious update, and repointed a version tag.
From there, the attack spread automatically:
action-setup→action-typos- →
eslint-changed-files - →
tj-actions/changed-files - → 23,000+ repositories
No one changed their code. Their pipelines just ran as usual—and executed malicious logic.
The payload scraped secrets directly from memory:
/proc/{PID}/mem- Extracted JSON structures like:
"name":{"value":"...","isSecret":true}
This bypassed GitHub’s masking entirely, because masking only applies to logs—not memory.
Case 3: Trivy / Aqua Security (March 2026) — Multi-Stage Attack with Blockchain C2
This attack unfolded in three stages.
First, a misconfigured pull_request_target workflow exposed secrets. Then, incomplete remediation left a bot token active. Finally, attackers used that token to overwrite release tags and inject malicious code.
The payload:
- Scraped credentials (SSH keys, cloud tokens, Kubernetes secrets)
- Encrypted them using AES-256-CBC + RSA-4096
- Exfiltrated data via multiple channels
Primary C2 endpoint:
hxxps://tdtqy-oyaaa-aaaae-af2dq-cai.raw.icp0.io
This is hosted on the Internet Computer (ICP) blockchain. No registrar. No takedown process.
Fallback exfiltration:
- GitHub repo:
tpcp-docs - Data uploaded via release assets
This design makes traditional incident response nearly useless.
Case 4: LiteLLM (March 24, 2026) — Automatic Execution via .pth
The LiteLLM compromise introduced a new level of danger.
Instead of relying on CI pipelines, it used a .pth file:
litellm_init.pth
Python automatically executes .pth files on startup. That means:
- No imports required
- No user interaction needed
- Every Python process becomes infected
The payload:
- Harvested credentials from local systems
- Targeted
.env, SSH keys, cloud configs, Kubernetes secrets - Exfiltrated to:
hxxps://models.litellm.cloud/
It also created persistence:
~/.config/sysmon/sysmon.py- Systemd service:
sysmon.service
A bug caused a fork bomb, which ironically revealed the attack. Otherwise, it might have gone unnoticed.
Patterns Across All Incidents
When you step back, a few trends become obvious:
1. March keeps showing up
Three years in a row. This likely ties to Q1 release pressure, conference schedules, and peak deployment cycles.
2. Security tools are prime targets
They operate with high privileges and broad access. Compromising one gives attackers visibility across entire environments.
3. Attackers are evolving infrastructure
We’ve seen a clear progression:
- No C2 → CI logs → HTTPS → GitHub CDN → Blockchain
4. Remediation gaps are common
Bot tokens are often missed during credential rotation, leaving backdoors open.
5. Metadata can’t be trusted
GitHub timestamps can be spoofed. Only commit SHAs and signed provenance are reliable.
MITRE Mapping
| Tactic | Technique ID | Technique Name | How It Applied |
|---|---|---|---|
| Initial Access | T1195.001 | Compromise Software Dependencies & Dev Tools | reviewdog/action-setup poisoned via automated GitHub team invitation exploit |
| Execution | T1059.006 | Command & Scripting: Python | Malicious Python script executed on CI runners to scrape process memory |
| Credential Access | T1552.001 | Unsecured Credentials: Credentials in Files | /proc/{PID}/mem scraped for in-memory GitHub Actions secret JSON structures |
| Credential Access | T1528 | Steal Application Access Token | GitHub Actions runner tokens and repository secrets extracted from process memory |
| Lateral Movement | T1199 | Trusted Relationship | Transitive dependency chain used to propagate payload from reviewdog → tj-actions → 23,000 repos |
| Exfiltration | T1048 | Exfiltration Over Alternative Protocol | Secrets printed to public CI workflow logs as exfiltration channel |
Detection Gaps That Still Exist
Several attack techniques here don’t fit cleanly into existing frameworks like MITRE ATT&CK:
- Abuse of
pull_request_target - Dependency chain propagation without direct compromise
- Blockchain-based C2 infrastructure
These are not edge cases anymore—they’re active threats.
Our Perspective on This Trend
Looking at these incidents together, it’s hard not to notice how far ahead attackers are thinking compared to defenders. These weren’t noisy, rushed intrusions. They were patient, calculated, and designed around how modern development actually works.
What stands out most is the shift in mindset. Attackers are no longer trying to break into systems directly. Instead, they are embedding themselves into the tools developers already trust. That changes the entire defensive model. Traditional controls assume a boundary between “trusted” and “untrusted” code, but these attacks blur that line completely.
Another concerning detail is how often detection came down to luck. A performance glitch, a crash, or an external researcher—these were the triggers. Not the security tools themselves. That should be a wake-up call. If the tools designed to detect threats are blind to attacks within their own ecosystem, then the problem is deeper than just patching vulnerabilities.
Finally, the move toward resilient infrastructure like blockchain-based C2 shows that attackers are planning for resistance. They are not just executing attacks—they are designing them to survive response efforts. That level of foresight suggests this trend is only going to accelerate.
If there’s one takeaway, it’s this: trust in the supply chain can no longer be assumed. It has to be continuously verified.
