Code Signing addresses a core trust problem: how can users know that software downloaded from the internet is genuine and unmodified? By attaching a digital signature to executables, publishers assert both their identity and the integrity of the code.
How Code Signing Works
Developer applies for a Code Signing certificate from a Certificate Authority (CA), submitting proof of identity.
A public/private key pair is generated. The private key stays on the developer’s machine.
At signing: code is hashed → hash encrypted with private key → signature block embedded in the executable.
At verification: browser retrieves publisher certificate → decrypts digest with public key → rehashes code → compares. A match confirms authenticity and integrity.
Signable File Types (VeriSign Authenticode)
Extension
Type
.EXE
Executable programs
.CAB
Cabinet files (installation packages)
.OCX
ActiveX controls
.DLL
Dynamic link libraries
.CAT
Digital thumbprint files
Limitations of Code Signing
Relies on the CA’s ability to verify applicant identity — fraudulent applications can yield valid certificates for malicious code.
A legitimately-signed program can still contain intentionally malicious logic.
Certificate Revocation Lists (CRLs) create a gap between key compromise and revocation.
SQL Injection is one of the most prevalent web vulnerabilities. It involves passing crafted SQL commands through unsanitised input fields to interact directly with the backend database — potentially exposing, modifying, or deleting all data. Once exploited, it is equivalent to handing the attacker direct database access.
The Classic Bypass: ‘ or 1=1–
-- Normal authentication query:
SELECT * FROM users WHERE username='John' AND password='secret'
-- After injection of: ' or 1=1--
SELECT * FROM users WHERE username='John' AND password='' or 1=1--'
-- WHERE clause always TRUE → login bypassed
UNION Injection
SELECT header, txt FROM news
UNION ALL SELECT name, pass FROM members
-- Exposes all member credentials
Four Categories of SQL Injection
Category
Mechanism
SQL Manipulation
Modify WHERE clauses or use UNION to change query results
Code Injection
Append EXECUTE commands to run arbitrary stored procedures
Function Call Injection
Inject calls to database functions (mainly Oracle PL/SQL)
Buffer Overflows
Exploit extended stored procedures to overflow memory
Prevention Guidance
Use parameterised queries / prepared statements in all database interactions — this is the primary defence.
Filter all input: strip single quotes, double quotes, slashes, backslashes, semicolons, NULL, and carriage returns.
Convert numeric values to integers before using in SQL; validate with ISNUMERIC.
Run the database server with a low-privilege account.
The Demilitarised Zone (DMZ) is a semi-trusted network segment between the public internet and an organisation’s internal network, hosting web servers, FTP services, email relays, and DNS. Despite its protective design, protocols operating within it carry vulnerabilities that attackers exploit to pivot into the internal network.
DMZ Architecture Options
Method
Description
Layered DMZ
Systems placed between two firewalls with different rule sets; internet traffic reaches DMZ but not internal segments
Multi-Interface Firewall
Single firewall with a third interface managing traffic between internet, DMZ, and internal network. Currently the preferred design.
Commonly Permitted DMZ Protocols
Protocol
Port(s)
FTP
TCP 20, 21
SMTP
TCP 25
DNS
TCP/UDP 53
HTTP
TCP 80
HTTPS
TCP 443
SSH (management)
TCP 22
Internal vs External DMZ Protocol Attacks
Internal attacks exploit protocols communicating between DMZ systems — e.g., compromising a web server to pivot to a database server over a trusted channel.
External attacks exploit protocols from the DMZ reaching into the internal corporate network — pivoting from a compromised DMZ host into the intranet.
Countermeasures
Apply all available patches against known DMZ protocol exploits promptly.
Deploy an Intrusion Prevention System (IPS) on DMZ segments.
Maintain a robust security policy and sound audit trail.
Isolate the DMZ — never connect it directly to the internal network.
Keep no credentials, vital resources, or sensitive internal data in the DMZ.
Files created in the DMZ must be reviewed by an administrator before migration to the internal network.
Imagine your favourite bottled water brand — trusted, widely distributed, consumed daily by millions. Now imagine a criminal gains access to the bottling factory and injects a contaminant into a single production run. The bottles look identical. The labels are correct. But the contents are poisoned.
This is not a hypothetical food safety scenario. On May 11, 2026, this exact playbook was executed in the digital world — and the consequences rippled across thousands of software development teams globally.
The target? npm — the world’s largest public software library. The method? A coordinated supply chain attack. The victims? Companies including TanStack, Mistral AI, UiPath, and OpenSearch — names that sit at the heart of modern software development and artificial intelligence.
This blog post unpacks what happened, why it matters, and what every professional — technical or not — needs to understand and do about it.
What is npm? (For the Non-Technical Reader)
Before we dive into the attack, let’s understand the battlefield.
When software developers build applications — whether a banking app, a hospital system, or an AI chatbot — they don’t write every single piece of code from scratch. Instead, they use pre-built, ready-made code components called packages, downloaded from a shared online library.
npm (Node Package Manager) is the world’s largest such library — a public repository hosting over 2 million packages, freely available to anyone. Think of it as a massive, open hardware store where developers pick up ready-made components to build their software faster.
The key word here is public. Anyone can create a free account and publish packages. Anyone can download them without even logging in. This openness is npm’s greatest strength — and, as this attack demonstrates, its most dangerous vulnerability.
🔑 Key Point — The Public Repository Risk: Public software repositories operate on a trust model. Developers assume that packages published under a known, reputable name are safe. Attackers exploit this trust by compromising publishing credentials and inserting malicious code into packages that developers already rely on.
What Happened? The Attack Explained Simply
On the night of May 11, 2026, a security company called SafeDep detected something unusual: a sudden burst of new software package versions being published to npm — over 401 versions across 170 packages, all within a five-hour window.
This was no ordinary update cycle. It was a coordinated attack.
Here is what the attacker did, step by step:
Obtained publishing credentials — The attacker gained the “master keys” to publish new versions of legitimate, trusted packages. This was likely achieved through phishing, credential theft, or compromising a developer’s account or device.
Published poisoned versions — New, slightly higher version numbers were released for popular packages. To a developer checking for updates, these looked completely legitimate.
Hidden trap activated — Inside these new versions, the attacker had replaced normal build scripts with a hidden instruction: the moment a developer installed the package, malicious code would automatically run in the background — silently, without any warning.
Credentials stolen — The malicious code immediately began searching for and stealing sensitive access keys: cloud server credentials, GitHub tokens, and software publishing passwords.
Self-propagation — Using those stolen credentials, the attacker then planted more malicious code into the victims’ own code repositories — meaning the next developer who downloaded the project would also be infected.
🔑 Key Point — The Preinstall Hook Exploit: npm allows packages to run scripts automatically during installation — a legitimate feature used for setup tasks. In this attack, the entire legitimate content was replaced with a single malicious “preinstall” hook. This is an abuse of a trusted, built-in feature — making detection harder because the mechanism itself is normal.
Who Was Affected?
The scale and selection of targets is what makes this attack remarkable. The attacker did not cherry-pick one or two packages — they went after entire families of packages at once:
Company / Project
Packages Hit
Scale
TanStack
React Router, Vue Router, Solid Router, Dev Tools
42 packages, 84 versions
Mistral AI
Core SDK, Azure integration, GCP integration
3 packages, 9 versions
UiPath
Entire automation platform scope
65 packages, 65 versions
OpenSearch
JavaScript client
1 package, 1 version
Others
squawk, tallyui, beproduct, draftauth, and more
59+ packages
TanStack Router alone has over 3 million weekly downloads. The potential blast radius of this attack — had it gone undetected longer — was enormous.
🔑 Key Point — Blast Radius: In security, “blast radius” refers to how far damage can spread from a single compromised point. Supply chain attacks have an exceptionally large blast radius because one poisoned package can infect thousands of downstream applications and organisations that rely on it.
What Did the Malicious Code Actually Do?
For the more technical reader, here is a breakdown of the payload’s capabilities — and they are sophisticated.
4.1 Credential Harvesting
The malicious code contained a modular credential-stealing framework with dedicated modules targeting:
AWS cloud credentials — Access keys, secret keys, and even instance credentials from AWS’s internal metadata service
GitHub tokens — Personal access tokens, OAuth tokens, GitHub App installation tokens, and GitHub Actions workflow tokens
npm publish tokens — Giving the attacker the ability to publish further poisoned packages under more identities
HashiCorp Vault tokens — Used by enterprises to store sensitive secrets and passwords
🔑 Key Point — Credential Chaining: Notice the logic here. By stealing npm publish tokens, the attacker can create more poisoned packages. By stealing GitHub tokens, they can inject malicious code into more repositories. By stealing AWS keys, they can access cloud infrastructure. Each stolen credential opens another door. This is called lateral movement in cybersecurity — moving from one compromised system to deeper, more sensitive ones.
4.2 Exfiltration via Session Protocol — Hiding in Plain Sight
Most malware sends stolen data to a command-and-control server — a fixed address that security teams can detect and block. This attacker was smarter.
They used the Session messaging app — an encrypted, decentralised messenger — to send stolen credentials. Because Session uses a network of distributed nodes (similar in concept to how Tor works), there is no single server to block or take down. The stolen data was routed through the network invisibly.
🔑 Key Point — Decentralised Exfiltration: Traditional security monitoring looks for suspicious connections to known bad IP addresses. When attackers use decentralised, encrypted messaging networks, they bypass this detection method entirely. This represents an evolution in attack sophistication that demands equally evolved detection strategies.
4.3 IDE and AI Agent Poisoning — The Most Alarming Part
Perhaps the most innovative — and alarming — aspect of this attack was its targeting of developer tools directly:
Claude Code (Anthropic’s AI coding assistant) configuration files were replaced with malicious versions
VS Code task runner configurations were poisoned
By committing these malicious configuration files into victims’ code repositories via GitHub, the attacker ensured that other developers who later cloned or downloaded the project would also have their tools hijacked — creating a self-spreading mechanism.
🔑 Key Point — AI Tool Attack Surface: As AI coding assistants become standard in developer workflows, they introduce a new attack surface. Malicious actors who can inject instructions into AI agent configuration files can effectively redirect what the AI does on a developer’s machine — silently executing attacker-controlled code under the guise of normal AI assistance. This is an emerging and rapidly growing threat vector.
Why Did This Happen? — The Root Causes
This attack did not happen because of some exotic, impossible-to-prevent vulnerability. It happened because of well-known, preventable security gaps.
Root Cause 1: Weak or Absent Multi-Factor Authentication (MFA)
Publishing credentials were obtained by the attacker. Had the accounts required a second form of authentication — a phone confirmation, a hardware key — stolen passwords alone would not have been enough. npm does offer MFA. It was either not enabled or not enforced.
Root Cause 2: No Cryptographic Package Signing
When you download a package from npm, you are trusting that it came from who it says it came from. Cryptographic signing would allow npm to mathematically verify this. Without it, anyone with valid credentials can publish anything under any name.
Root Cause 3: Automated, Unverified Updates
Many development pipelines automatically pull the latest package versions. Speed and convenience are prioritised over verification. When a poisoned version appears, it gets pulled in automatically before anyone notices.
Root Cause 4: Excessive Implicit Trust in Public Repositories
The entire ecosystem operates on trust. Popular packages are assumed safe. This cultural assumption, without technical enforcement, is a systemic vulnerability.
🔑 Key Point — Zero Trust Applies Here Too: The Zero Trust security principle — “never trust, always verify” — applies not just to network access but to software supply chains. Just because a package has millions of downloads and a reputable name does not mean the version you are installing today is safe.
What Should Organisations Do? — Controls and Recommendations
Immediate Actions
Audit your project lockfiles for any of the 170 compromised packages and their affected version numbers (full list available at safedep.io)
Scan codebases for unexpected files in .claude/ and .vscode/ directories
Technical Controls
Enable MFA on all npm, GitHub, and cloud provider accounts
Use hardware security keys (FIDO2/WebAuthn) for publishing accounts
Implement dependency pinning — lock packages to specific verified versions rather than accepting automatic updates
Deploy software composition analysis (SCA) tools to continuously monitor for known malicious packages
Use package manager proxies that block known malicious packages before they reach developer machines
Administrative Controls
Establish a formal Software Supply Chain Security Policy
Enforce least-privilege on who can publish packages
Conduct regular security awareness training specifically covering supply chain risks
Define an incident response procedure specifically for supply chain compromise events
Require security review before adopting new third-party packages
Preventative Controls
Maintain a vetted, approved list of third-party packages (software bill of materials — SBOM)
Subscribe to threat intelligence feeds that track malicious package publications
Implement CI/CD pipeline checks that block builds if suspicious package versions are detected
Regularly verify the integrity of developer tool configurations (VS Code, AI coding assistants)
Certification Spotlight
This section is specifically for readers preparing for CISSP, CCSP, or AAISM certifications. The concepts in this attack map directly to examination domains.
📘 CISSP — Certified Information Systems Security Professional
This attack touches multiple CISSP domains:
CISSP Domain
Concept Illustrated in This Attack
Domain 1 — Security & Risk Management
Third-party risk management; supply chain risk; risk appetite vs. control implementation
Domain 2 — Asset Security
Credential management; data classification of publishing tokens and cloud keys
Domain 3 — Security Architecture
Zero Trust architecture; defence in depth; attack surface analysis
Domain 4 — Communication & Network Security
Decentralised exfiltration via Session protocol; C2 channel evasion techniques
Domain 6 — Security Assessment
Software Composition Analysis (SCA); vulnerability scanning of dependencies
Domain 7 — Security Operations
Incident response; credential rotation; IOC (Indicator of Compromise) analysis
🎓 CISSP Exam Note: Supply chain attacks are increasingly tested under Domain 1 (third-party risk) and Domain 8 (secure software development). Understand the concept of a Software Bill of Materials (SBOM) — it is a key control for managing third-party software risk and is referenced in NIST guidelines that CISSP candidates should be familiar with.
☁️ CCSP — Certified Cloud Security Professional
The cloud dimension of this attack is particularly relevant for CCSP candidates:
CCSP Domain
Concept Illustrated in This Attack
Domain 1 — Cloud Concepts & Architecture
Shared responsibility model — npm is a cloud-hosted service; who is responsible for security?
Domain 2 — Cloud Data Security
AWS IAM credential theft; cloud metadata service exploitation (169.254.169.254)
Secure software supply chain; dependency management in cloud-native development
Domain 6 — Legal & Compliance
Breach notification obligations when cloud credentials are exposed; data sovereignty implications of exfiltration via decentralised networks
🎓 CCSP Exam Note: The exploitation of the AWS metadata endpoint (169.254.169.254) is a well-known cloud attack technique called Instance Metadata Service (IMDS) abuse. CCSP candidates should understand how IMDSv2 (requiring session-oriented requests) mitigates this attack, and why organisations should enforce IMDSv2 on all EC2 instances.
AAISM — Advance in AI Security Management
For AAISM candidates, this incident raises important governance, organisational, and risk management considerations:
AAISM Area
Concept Illustrated
Security Risk Management
Third-party and supply chain risk as an organisational risk category; likelihood vs. consequence analysis
Organisational Security
Security culture — developers not enabling MFA represents a human and cultural risk, not just a technical one
Security Governance
Board and executive notification obligations when a supply chain incident occurs; escalation frameworks
Physical and Personnel Security
Insider threat considerations — compromised developer credentials blur the line between insider and outsider threat
Incident Management
Detecting, containing, and recovering from a software supply chain incident; communicating with stakeholders
Business Continuity
Impact of supply chain compromise on business operations; recovery time objectives for affected systems
🎓 AAISM Exam Note: Australian organisations should also consider their obligations under the Privacy Act 1988 and the Notifiable Data Breaches (NDB) scheme if this attack resulted in exposure of personal information. The Australian Cyber Security Centre (ACSC) Essential Eight framework is directly relevant here — particularly controls around application patching, application control, and restricting administrative privileges.
The Bigger Picture — An Escalating Threat
This attack did not happen in isolation. It is part of a clear, escalating trend in 2026:
In March 2026, the axios npm package (used in virtually every JavaScript project) was similarly compromised
In May 2026, within days of this attack, further npm malware incidents were reported targeting DeFi platforms and Telegram
The pattern is unmistakable: attackers have identified the software supply chain as a high-value, under-defended attack surface. One compromised publishing credential can reach millions of developers instantly. The return on investment for attackers is extraordinarily high.
What is perhaps most alarming about this specific attack is the deliberate targeting of AI coding tools. As artificial intelligence becomes embedded in the software development workflow, it creates a new and largely unexplored attack surface. Poisoning an AI assistant’s configuration is not just an attack on one developer — it is an attack on every piece of code that AI assistant helps write, review, or deploy.
🔑 Key Point — AI as an Attack Vector: We are entering an era where AI systems are not just tools but active participants in software development. Security frameworks, policies, and controls must evolve to account for the integrity of AI agent configurations as a critical security asset — not an afterthought.
Conclusion: Trust Must Be Earned — Not Assumed
The npm supply chain attack of May 2026 is a watershed moment. It demonstrates that the implicit trust the software industry places in public repositories is a systemic vulnerability that attackers are now exploiting at scale, with automation, and with increasing sophistication.
The good news: the tools to prevent this exist. Multi-factor authentication, cryptographic signing, dependency pinning, software composition analysis, and Zero Trust thinking applied to software supply chains can dramatically reduce the risk.
The challenging news: these tools only work if organisations choose to implement them — consistently, completely, and as a cultural commitment rather than a compliance checkbox.
In the words of a fundamental security principle: trust, but verify. In the modern threat landscape, even that is no longer enough. The new standard must be: verify, then trust — and keep verifying.
npm Security Advisory — Best Practices for Package Publishers
OWASP — Software Component Verification Standard (SCVS)
This blog post was written for both general and professional audiences. Certification callouts are for educational reference only and do not constitute official exam guidance. Always refer to official body of knowledge materials for examination preparation.
CISSP Made Easy 