Tag: npm

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

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

By | | 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.1 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.1 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.2 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.6 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.6

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.1 The March 31 compromise targeted this architectural criticality by poisoning the very mechanism of installation.2

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.3 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.1 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.2

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.6

The attack began when a developer or an automated CI/CD agent executed npm install.6 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.6 This script functioned as the primary dropper, utilising a sophisticated obfuscation scheme to hide its intent from static analysis tools.5

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.5 The second layer employed a character-wise XOR cipher with a key derived from the string “OrDeR_7077”.5 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. 5 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.5

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.6 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.5

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.5 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].5This 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.3 This shift in publishing methodology provided the first evidence of an account takeover.3 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.5

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.2

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.16 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.16

The attribution is supported by several “ironclad” pieces of evidence recovered during forensic analysis.18 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.18 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.15

The strategic objective of the Axios compromise was twofold: credential harvesting and infrastructure access.1 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.6 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.15

Attribution CharacteristicEvidence / Signature
Malware LineagemacWebT project name linked to BlueNoroff’s webT (RustBucket 2023).18
Campaign OverlapC2 message types and “FirstInfo” sequence mirror “Contagious Interview” TTPs.15
Target ProfileHigh-value developers, blockchain firms, and infrastructure maintainers.16
InfrastructureUse of anonymous ProtonMail accounts and bulletproof hosting for C2 nodes.10

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.10

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.5

Windows Implementation: The wt.exe Masquerade

On Windows systems, the setup.js dropper wrote a VBScript to the %TEMP% directory.6 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.6 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).5

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).6 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.6 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.6

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.4 It was downloaded to /tmp/ld.py and launched as an orphaned background process via the nohup command.4 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.4

PlatformPersistence MechanismKey Discovery Paths
WindowsRegistry Run Key + %PROGRAMDATA%\system.bat.6Check for %PROGRAMDATA%\wt.exe masquerade.6
macOSMasquerades as system daemon; survives user logout.4Check /Library/Caches/com.apple.act.mond.4
LinuxDetached background process (PID 1) via nohup.4Check /tmp/ld.py for Python script.6

Across all three platforms, the RAT engaged in immediate and aggressive system reconnaissance.6 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.6

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.1 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.6

Upon establishing a connection to the sfrclak[.]com C2 server, the RAT immediately began a deep scan for high-value secrets.6 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.2
  • Development and CI/CD: Harvesting npm tokens from .npmrc, GitHub personal access tokens, and repository deploy keys stored in ~/.ssh/.3
  • Local Environments: Dumping all environment variables, which in modern development often contain API keys for services like OpenAI, Anthropic, or database connection strings.2
  • System and Shell History: Searching shell history files (.bash_history, .zsh_history) for sensitive commands, passwords, or internal URLs that could reveal system topology.8

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.8 This ensures that even if the C2 traffic is intercepted, the underlying data remains unreadable without the attacker’s private key.8

Targeted Data TypeSpecific ArtifactsOperational Outcome
Auth Tokens.npmrc, ~/.git-credentials, .envAccess to modify upstream packages and hijack CI/CD pipelines.1
Network Access~/.ssh/id_rsa, shell historyLateral movement into production servers and internal repositories.6
Cloud Secrets~/.aws/credentials, IMDS metadataFull control over cloud-hosted infrastructure and data lakes.2
Crypto WalletsBrowser logs, wallet files (BTC, ETH, SOL)Direct financial theft for purported state revenue.8

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).6 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. 10

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.6 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.6

The Axios project had successfully implemented Trusted Publishing, yet the attackers were still able to publish malicious versions.6 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.6 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.6

FeatureLong-Lived API TokensTrusted Publishing (OIDC)
LifetimeStatic (often 30-90+ days).22Ephemeral (seconds to minutes).9
StorageEnvironmental variables, .npmrc.6Not stored; generated per-job.9
Security RiskHigh; primary vector for supply chain attacks.22Low; no static secret to leak.9
VerificationSimple possession-based.6Identity-based via cryptographic signature.9
Bypass PotentialCan override OIDC in current npm implementations.6Secure, if legacy tokens are revoked.6

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.6 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.6 For professionals, the lesson is clear: identity-based security is only effective when possession-based security is explicitly revoked.6

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

  1. 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.
  2. 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.
  3. 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.
  4. 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

  1. 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.
  2. 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.
  3. 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

  1. 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.
  2. Disable Lifecycle Scripts: Use the –ignore-scripts flag during installation in build environments to block the execution of postinstall droppers like setup.js.
  3. 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.23 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.23 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.23

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”.23 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.23 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.23

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.24 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.6

Risk FactorImpact on Supply ChainDefensive Response
Automated UpdatesAI tools pull poisoned versions in seconds.23Pin dependencies; use npm ci.3
Shadow IdentityAI systems create untracked accounts and tokens.26Strict IAM governance and behavioral monitoring.26
Vulnerable GenerationAI propagates known-vulnerable code patterns.23Automated code review and logic-based security architecture.24
Speed over SafetyTight deadlines pressure developers to skip audits.15Mandate human-in-the-loop for dependency changes.24

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.7 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.24

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.10 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.6

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

  1. Immediate Remediation for Axios: Any system that resolved to [email protected] or 0.30.4 must be treated as fully compromised.3 This requires the immediate revocation and reissue of all environment secrets, SSH keys, and cloud tokens accessible from that system.2 The presence of the node_modules/plain-crypto-js directory is a sufficient indicator of compromise, regardless of the apparent “cleanliness” of its manifest.6
  2. Legacy Token Sunset: Organisations must perform a comprehensive audit of their npm and GitHub tokens.22 All static, long-lived API tokens must be revoked and replaced with OIDC-based Trusted Publishing.9 The Axios breach proves that the mere existence of a legacy token is a vulnerability that state-sponsored actors will proactively seek to exploit.6
  3. Enforced Dependency Isolation: Build environments and CI/CD pipelines should be configured with a “deny-by-default” egress policy.15 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.2
  4. 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.7

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.8

References and Further Reading

  1. 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
  2. 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
  3. 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
  4. 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/
  5. 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
  6. Supply-Chain Compromise of axios npm Package – Huntress, accessed on March 31, 2026, https://www.huntress.com/blog/supply-chain-compromise-axios-npm-package
  7. 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
  8. 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/
  9. 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/
  10. 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/
  11. 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
  12. 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/
  13. Axios Compromised With A Malicious Dependency – OX Security, accessed on March 31, 2026, https://www.ox.security/blog/axios-compromised-with-a-malicious-dependency/
  14. 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
  15. 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/
  16. 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/
  17. Technology – Axios, accessed on March 31, 2026, https://www.axios.com/technology
  18. Axios npm Supply Chain Compromise (2026-03-31) — Full RE + …, accessed on March 31, 2026, https://gist.github.com/N3mes1s/0c0fc7a0c23cdb5e1c8f66b208053ed6
  19. 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
  20. 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/
  21. 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
  22. 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/
  23. 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
  24. 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
  25. 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
  26. Sitemap – Cybersecurity Insiders, accessed on March 31, 2026, https://www.cybersecurity-insiders.com/sitemap/
  27. IAM – Nocturnalknight’s Lair, accessed on March 31, 2026, https://nocturnalknight.co/category/iam/
  28. 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 Npm Breach: What It Reveals About Software Supply Chain Security

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

By | | 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 ObservabilityWith Observability Tools
Compromise discovered too lateBehavioural anomalies flagged in real time
Malware executes silentlyPost-install scripts tracked and analysed
AI tool misuse invisibleDangerous flags or recursive harvesting detected
Manual triage takes daysAutomated 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)

Hidden Threats in PyPI and NPM: What You Need to Know

Hidden Threats in PyPI and NPM: What You Need to Know

By | | Comments 0 Comment

Introduction: Dependency Dangers in the Developer Ecosystem

Modern software development is fuelled by open-source packages, ranging from Python (PyPI) and JavaScript (npm) to PHP (phar) and pip modules. These packages have revolutionised development cycles by providing reusable components, thereby accelerating productivity and creating a rich ecosystem for innovation. However, this very reliance comes with a significant security risk: these widely used packages have become an attractive target for cybercriminals. As developers seek to expedite the development process, they may overlook the necessary due diligence on third-party packages, opening the door to potential security breaches.

Faster Development, Shorter Diligence: A Security Conundrum

Today, shorter development cycles and agile methodologies demand speed and flexibility. Continuous Integration/Continuous Deployment (CI/CD) pipelines encourage rapid iterations and frequent releases, leaving little time for the verification of every dependency. The result? Developers often choose dependencies without conducting rigorous checks on package integrity or legitimacy. This environment creates an opening for attackers to distribute malicious packages by leveraging popular repositories such as PyPI, npm, and others, making them vectors for harmful payloads and information theft.

Malicious Package Techniques: A Deeper Dive

While typosquatting is a common technique used by attackers, there are several other methods employed to distribute malicious packages:

  • Supply Chain Attacks: Attackers compromise legitimate packages by gaining access to the repository or the maintainer’s account. Once access is obtained, they inject malicious code into trusted packages, which then get distributed to unsuspecting users.
  • Dependency Confusion: This technique involves uploading packages with names identical to internal, private dependencies used by companies. When developers inadvertently pull from the public repository instead of their internal one, they introduce malicious code into their projects. This method exploits the default behaviour of package managers prioritising public over private packages.
  • Malicious Code Injection: Attackers often inject harmful scripts directly into a package’s source code. This can be done by compromising a developer’s environment or using compromised libraries as dependencies, allowing attackers to spread the malicious payload to all users of that package.

These methods are increasingly sophisticated, leveraging the natural behaviours of developers and package management systems to spread malicious code, steal sensitive information, or compromise entire systems.

Timeline of Incidents: Malicious Packages in the Spotlight

A series of high-profile incidents have demonstrated the vulnerabilities inherent in unchecked package installations:

  • June 2022: Malicious Python packages such as loglib-modules, pyg-modules, pygrata, pygrata-utils, and hkg-sol-utils were caught exfiltrating AWS credentials and sensitive developer information to unsecured endpoints. These packages were disguised to look like legitimate tools and fooled many unsuspecting developers. (BleepingComputer)
  • December 2022: A malicious package masquerading as a SentinelOne SDK was uploaded to PyPI, with malware designed to exfiltrate sensitive data from infected systems. (The Register)
  • January 2023: The popular ctx package was compromised to steal environment variables, including AWS keys, and send them to a remote server. This instance affected many developers and highlighted the scale of potential data leakage through dependencies. (BleepingComputer)
  • September 2023: An extended campaign involving malicious npm and PyPI packages targeted developers to steal SSH keys, AWS credentials, and other sensitive information, affecting numerous projects globally. (BleepingComputer)
  • October 2023: The recent incident involving the fabrice package is a stark reminder of how easy it is for attackers to deceive developers. The fabrice package, designed to mimic the legitimate fabric library, employed a typosquatting strategy, exploiting typographical errors to infiltrate systems. Since its release, the package was downloaded over 37,000 times and covertly collected AWS credentials using the boto3 library, transmitting the stolen data to a remote server via VPN, thereby obscuring the true origin of the attack. The package contained different payloads for Linux and Windows systems, utilising scheduled tasks and hidden directories to establish persistence. (Developer-Tech)

The Impact: Scope of Compromise

The estimated number of affected companies and products is difficult to pin down precisely due to the widespread usage of open-source packages in both small-scale and enterprise-level applications. Given that some of these malicious packages garnered tens of thousands of downloads, the potential damage stretches across countless software projects. With popular packages like ctx and others reaching a substantial audience, the economic and reputational impact could be significant, potentially costing affected businesses millions in breach recovery and remediation costs.

Real-world Impact: Consequences of Malicious Packages

The real-world impact of malicious packages is profound, with consequences ranging from data breaches to financial loss and severe reputational damage. The following are some of the key impacts:

  • British Airways and Ticketmaster Data Breach: In 2018, the Magecart group exploited vulnerabilities in third-party scripts used by British Airways and Ticketmaster. The attackers injected malicious code to skim payment details of customers, leading to significant data breaches and financial loss. British Airways was fined £20 million for the breach, which affected over 400,000 customers. (BBC)
  • Codecov Bash Uploader Incident: In April 2021, Codecov, a popular code coverage tool, was compromised. Attackers modified the Bash Uploader script, which is used to send coverage reports, to collect sensitive information from Codecov’s users, including credentials, tokens, and keys. This supply chain attack impacted hundreds of customers, including notable companies like HashiCorp. (GitGuardian)
  • Event-Stream NPM Package Attack: In 2018, a popular JavaScript library event-stream was hijacked by a malicious actor who added code to steal cryptocurrency from applications using the library. The compromised version was downloaded millions of times before the attack was detected, affecting numerous developers and projects globally. (Synk)

These incidents highlight the potential repercussions of malicious packages, including severe financial penalties, reputational damage, and the theft of sensitive customer information.

Fabrice: A Case Study in Typosquatting

The recent incident involving the fabrice package is a stark reminder of how easy it is for attackers to deceive developers. The fabrice package, designed to mimic the legitimate fabric library, employed a typosquatting strategy, exploiting typographical errors to infiltrate systems. Since its release, the package was downloaded over 37,000 times and covertly collected AWS credentials using the boto3 library, transmitting the stolen data to a remote server via VPN, thereby obscuring the true origin of the attack. The package contained different payloads for Linux and Windows systems, utilising scheduled tasks and hidden directories to establish persistence. (Developer-Tech)

Lessons Learned: Importance of Proactive Security Measures

The cases highlighted in this article offer important lessons for developers and organisations:

  1. Dependency Verification is Crucial: Typosquatting and dependency confusion can be avoided by carefully verifying package authenticity. Implementing strict naming conventions and utilising internal package repositories can help prevent these attacks.
  2. Security Throughout the SDLC: Integrating security checks into every phase of the SDLC, including automated code reviews and security testing of modules, is essential. This ensures that vulnerabilities are identified early and mitigated before reaching production.
  3. Use of Vulnerability Scanning Tools: Tools like Snyk and OWASP Dependency-Check are invaluable in proactively identifying vulnerabilities. Organisations should make these tools a mandatory part of the development process to mitigate risks from third-party dependencies.
  4. Security Training and Awareness: Developers must be educated about the risks associated with third-party packages and taught how to identify potentially malicious code. Regular training can significantly reduce the likelihood of falling victim to these attacks.

By recognising these lessons, developers and organisations can better safeguard their software supply chains and mitigate the risks associated with third-party dependencies.

Prevention Strategies: Staying Safe from Malicious Packages

To mitigate the risks associated with malicious packages, developers and startups must adopt a multi-layered defence approach:

  1. Verify Package Authenticity: Always verify package names, descriptions, and maintainers. Opt for well-reviewed and frequently updated packages over relatively unknown ones.
  2. Review Source Code: Whenever possible, review the source code of the package, especially for dependencies with recent uploads or unknown maintainers.
  3. Use Package Scanners: Employ tools like Sonatype Nexus, npm audit, or PyUp to identify vulnerabilities and malicious code within packages.
  4. Leverage Lockfiles: Tools like package-lock.json (npm) or Pipfile.lock (pip) can help prevent unintended updates by locking dependencies to a specific version.
  5. Implement Least Privilege: Limit the permissions assigned to development environments to reduce the impact of compromised keys or credentials.
  6. Regular Audits: Conduct regular security audits of dependencies as part of the CI/CD pipeline to minimise risk.

Software Security: Embedding Security in the Development Lifecycle

To mitigate the risks associated with malicious packages and other vulnerabilities, it is essential to integrate security into every phase of the Software Development Lifecycle (SDLC). This practice, known as the Secure Software Development Lifecycle (SSDLC), emphasises incorporating security best practices throughout the development process.

Key Components of SSDLC

  • Automated Code Reviews: Leveraging tools that automatically scan code for vulnerabilities and flag potential issues early in the development cycle can significantly reduce the risk of security flaws making it into production. Tools like SonarQube, Checkmarx, and Veracode help in ensuring that security is built into the code from the beginning.
  • Security Testing of Modules: Security testing should be conducted on third-party modules before integrating them into the project. Tools like Snyk and OWASP Dependency-Check can identify vulnerabilities in dependencies and provide remediation advice.

Deep Dive into Technical Details

  • Malicious Package Techniques: As discussed earlier, typosquatting is just one of the many attack techniques. Supply chain attacks, dependency confusion, and malicious code injection are also common methods attackers use to compromise software projects. It is essential to understand these techniques and incorporate checks that can prevent such attacks during the development process.
  • Vulnerability Analysis Tools:
    • Snyk: Snyk helps developers identify vulnerabilities in open-source libraries and container images. It scans the project dependencies and cross-references them with a constantly updated vulnerability database. Once vulnerabilities are identified, Snyk provides detailed remediation advice, including fixing the version or applying patches.
    • OWASP Dependency-Check: OWASP Dependency-Check is an open-source tool that scans project dependencies for known vulnerabilities. It works by identifying the libraries used in the project, then checking them against the National Vulnerability Database (NVD) to highlight potential risks. The tool also provides reports and actionable insights to help developers remediate the issues.
    • Sonatype Nexus: Sonatype Nexus offers a repository management system that integrates directly with CI/CD pipelines to scan for vulnerabilities. It uses machine learning and other advanced techniques to continuously monitor and evaluate open-source libraries, providing alerts and remediation options.

Best Practices for Secure Dependency Management

  • Dependency Pinning: Pinning dependencies to specific versions helps in preventing unexpected updates that may contain vulnerabilities. By using tools like package-lock.json (npm) or Pipfile.lock (pip), developers can ensure that they are not inadvertently upgrading to a compromised version of a dependency.
  • Use of Private Registries: Hosting private package registries allows organisations to maintain tighter control over the dependencies used in their projects. By using tools like Nexus Repository or Artifactory, companies can create a trusted repository of dependencies and mitigate risks associated with public registries.
  • Robust Security Policies: Organisations should implement strict policies around the use of open-source components. This includes performing security audits, using automated tools to scan for vulnerabilities, and enforcing review processes for any new dependencies being added to the codebase.

By integrating these practices into the development process, organisations can build more resilient software, reduce vulnerabilities, and prevent incidents involving malicious dependencies.

Conclusion

As the developer community continues to embrace rapid innovation, understanding the security risks inherent in third-party dependencies is crucial. Adopting preventive measures and enforcing better dependency management practices are vital to mitigate the risks of malicious packages compromising projects, data, and systems. By recognising these threats, developers and startups can secure their software supply chains and build more resilient products.

References & Further Reading

Bitnami