cybersecurity - Nocturnalknight's Lair

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

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

Industrialised Software Ecosystem Subversion and the Weaponisation of Invisible Unicode

Executive Summary

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

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

Architecture: The Multi-Vector Infiltration Model

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

The VS Code and Open VSX Infiltration Layer

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

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

The npm and Package Registry Subversion

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

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

The GitHub Repository and Version Control Vector

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

Anatomy: Invisible Payloads and Decentralised Control

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

Glassworm: The Invisible Unicode Technique

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

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

JavaScript


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

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

ForceMemo: Account Takeover and Git Subversion

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

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

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

Command and Control via Solana Blockchain

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

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

Blastradius: Systemic Impact and Ecosystem Exposure

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

Developer Workstation Compromise

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

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

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

Impact on the Python and React Native Ecosystems

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

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

Infrastructure and Corporate Exposure

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

Adversary Persona: The BlueNoroff and Lazarus Lineage

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

Technical Lineage and Module Evolution

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

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

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

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

APT37 (ScarCruft) and Parallel Tactics

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

Operational Security and Victim Selection

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

Remediation Protocol: Phased Recovery and Hardening

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

Stage 1: Identification and Isolation

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

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

Stage 2: Credential Rotation and Eradication

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

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

Stage 3: Post-Incident Hardening

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

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

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

Critical Analysis & Conclusion

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

The Weaponisation of Invisible Code

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

The Subversion of Decentralised Infrastructure

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

The IDE as the New Perimeter

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

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

References & Further Reading

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The Discovery Narrative: From Automated Scanners to Community Alarms

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

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

The Adversary Persona: BlueNoroff and the Lazarus Connection

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

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

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

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

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

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

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

Windows Implementation: The wt.exe Masquerade

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

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

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

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

Linux Implementation: The ld.py Python RAT

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

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

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

Credential Harvesting and Post-Exfiltration Tradecraft

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

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

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

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

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

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

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

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

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

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

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

Remediation Protocol: Recovery and Hardening Strategies

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

Phase 1: Identification and Isolation

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

Phase 2: Recovery and Revocation

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

Phase 3: Strategic Hardening

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

The Future of Infrastructure Assurance: Vibe Coding and AI Risks

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

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

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

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

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

Conclusion: Strategic Recommendations for Professional Resilience

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

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

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

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

References and Further Reading

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

The Asymmetric Frontier: A Strategic Analysis of Iranian Cyber Operations and Geopolitical Resilience in the 2026 Conflict

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

The dawn of March 2026 marks a watershed moment in the evolution of multi-domain warfare, characterised by the total integration of offensive cyber operations into high-intensity kinetic campaigns. The initiation of Operation Epic Fury by the United States and Operation Roaring Lion by the State of Israel on February 28, 2026, has provided a definitive template for the “offensive turn” in modern military doctrine.1 From a cybersecurity practitioner’s perspective, the Iranian response and the resilience of its decentralised “mosaic” architecture offer profound insights into the future of state-sponsored digital conflict. Despite the massive degradation of traditional command structures and the reported death of Supreme Leader Ayatollah Ali Khamenei, the Iranian cyber ecosystem has demonstrated an ability to maintain operational tempo through a pre-positioned proxy ecosystem that operates with significant tactical autonomy.3 This analysis examines the strategic, technical, and geopolitical dimensions of the Iranian threat, building on the observations of General James Marks and the latest assessments from the World Economic Forum (WEF), The Soufan Centre, and major global think tanks.

The Crucible of Conflict: From Strategic Patience to Operation Epic Fury

The current state of hostilities is the culmination of two distinct phases of escalation that began in mid-2025. The first phase, characterized by the “12-day war” in June 2025, saw the United States launch Operation Midnight Hammer against Iranian nuclear facilities at Fordow, Natanz, and Isfahan in response to Tehran’s expulsion of IAEA inspectors and the termination of NPT safeguards.⁶ During this initial encounter, the information domain was already a central battleground, with the hacker group Predatory Sparrow (Gonjeshke Darande) disrupting Iranian financial institutions and cryptocurrency exchanges to undermine domestic confidence in the regime.⁹ However, the second phase, initiated on February 28, 2026, represents a fundamental shift toward regime change and the total neutralization of Iran’s asymmetric capabilities.³

General James Marks, writing in The Hill, and subsequent testimony from Director of National Intelligence Tulsi Gabbard, indicate that while the Iranian government has been severely degraded, its core apparatus remains intact and capable of striking Western interests.⁴ This resilience is attributed to the “mosaic defense” doctrine, which the Islamic Revolutionary Guard Corps (IRGC) adopted in 2005 to survive decapitation strikes. By restructuring into 31 semi-autonomous provincial commands, the regime ensured that operational capability would persist even if the central leadership in Tehran was eliminated.³ In the cyber realm, this translates to a distributed network of APT groups and hacktivist personas that can continue to execute campaigns despite a collapse in domestic internet connectivity.²

Key Milestones in the 2025-2026 Escalation	Date	Primary Operational Outcome
IAEA Safeguards Termination	Feb 10, 2026	Iran expels inspectors; 60% enrichment stockpile reaches 412kg ⁸
Operation Midnight Hammer	June 22, 2025	US B-2 bombers target Fordow and Natanz ⁷
Initiation of Epic Fury	Feb 28, 2026	Joint US-Israel strikes kill Supreme Leader Khamenei ³
Electronic Operations Room Formed	Feb 28, 2026	60+ hacktivist groups mobilize for retaliatory strikes ³
The Stryker Attack	March 11, 2026	Handala Hack wipes 200,000 devices at US medical firm ¹⁴

The Architecture of Asymmetry: Iran’s Mosaic Cyber Doctrine

The Iranian cyber program is no longer a peripheral support function but a primary tool of asymmetric leverage. The Soufan Center and RUSI emphasize that Tehran views cyber operations as a means to impose psychological costs far from the battlefield, exhausting the resources of superior foes through a war of attrition.³ This strategy relies on a “melange” of state-sponsored actors and patriotic hackers who provide the regime with plausible deniability.¹⁰

The Command Structure: IRGC and MOIS

Cyber operations are primarily distributed across two powerful organizations: the Islamic Revolutionary Guard Corps (IRGC) and the Ministry of Intelligence and Security (MOIS). The IRGC typically manages APTs focused on military targets and regional stability, such as APT33 and APT35, while the MOIS houses groups like APT34 (OilRig) and MuddyWater, which specialize in long-term espionage and infrastructure mapping.¹⁶Following the February 28 strikes, which targeted the MOIS headquarters in eastern Tehran and reportedly eliminated deputy intelligence minister Seyed Yahya Hosseini Panjaki, these units have transitioned into a state of “operational isolation”.² This isolation has led to a surge in tactical autonomy for cells based outside of Iran, which are now acting as the regime’s primary retaliatory arm while domestic internet connectivity remains between 1% and 4% of normal levels.²

The Proxy Ecosystem and the Electronic Operations Room

A critical development in the March 2026 conflict is the formalization of the “Electronic Operations Room.” Established within 24 hours of the initial strikes, this entity serves as a centralized coordination hub for over 60 hacktivist groups, ranging from pro-regime actors to regional nationalists.¹³ This ecosystem allows the state to amplify its messaging and conduct large-scale disruptive operations without the immediate risk of overt attribution.³

Prominent entities within this ecosystem include:

Handala Hack: A persona linked to the MOIS (Void Manticore) that combines high-end destructive capabilities with propaganda.²
Cyber Islamic Resistance: An umbrella collective coordinating synchronized DDoS attacks against Western and Israeli infrastructure.²
FAD Team (Fatimiyoun Cyber Team): A group specializing in wiper malware and the permanent destruction of industrial control systems (ICS).²

Sylhet Gang: A recruitment and message-amplification engine focused on targeting Saudi and Gulf state management systems.²

Technical Deep Dive: The Stryker Breach and “Living-off-the-Cloud” Warfare

On March 11, 2026, the Iranian-linked group Handala (Void Manticore) executed what is considered the most significant wartime cyberattack against a U.S. commercial entity: the breach and subsequent wiping of the Stryker Corporation.³ This incident is a case study in the evolution of Iranian TTPs (Tactics, Techniques, and Procedures), moving away from custom malware toward the weaponization of legitimate cloud infrastructure.¹⁵

The Weaponization of Microsoft Intune

The Stryker attack bypassed traditional Endpoint Detection and Response (EDR) and antivirus solutions entirely by utilizing the company’s own Microsoft Intune platform to issue mass-wipe commands.¹⁵ This “Living-off-the-Cloud” (LotC) strategy began with the theft of administrative credentials through AitM (Adversary-in-the-Middle) phishing, which allowed the attackers to bypass multi-factor authentication (MFA) and capture session tokens.¹⁴

Once inside the internal Microsoft environment, the attackers used Graph API calls to target the organization’s device management tenant. Approximately 200,000 devices—including servers, managed laptops, and mobile phones across 61 countries—were wiped.⁸ The attackers also claimed to have exfiltrated 50 terabytes of sensitive data before executing the wipe, using the destruction of systems to mask the theft and create a catastrophic business continuity event.⁸

Technical Components of the Stryker Wipe	Description	Practitioner Implication
Initial Access Vector	Phishing/AitM session token theft	Legacy MFA is insufficient; move to FIDO2 ¹⁴
Primary Platform Exploited	Microsoft Intune (MDM)	MDM is a Tier-0 asset requiring extreme isolation ²²
Command Execution	Programmatic Graph API calls	Log monitoring must include MDM activity spikes ²²
Detection Status	No malware binary detected	“No malware detected” does not mean no breach ²²
Economic Impact	$6-8 billion market cap loss	Cyber risk is now a material financial solvency risk ¹⁷

Advanced Persistent Threat (APT) Evolution

The Stryker attack highlights a broader trend identified by Unit 42 and Mandiant: the convergence of state-sponsored espionage with destructive “hack-and-leak” operations. Groups like Handala Hack now operate with a sophisticated handoff model. Scarred Manticore (Storm-0861) provides initial access through long-dwell operations, which is then handed over to Void Manticore (Storm-0842) for the deployment of wipers or the execution of the MDM hijack.¹⁹

Other Iranian groups have demonstrated similar advancements:

APT42: Recently attributed by CISA for breaching the U.S. State Department, this group continues to refine its social engineering lures using GenAI to target high-value personnel.²
Serpens Constellation: Unit 42 tracks various IRGC-aligned actors under this name, noting an increased risk of wiper attacks against energy and water utilities in the U.S. and Israel.²
The RedAlert Phishing Campaign: Attackers delivered a malicious replica of the Israeli Home Front Command application through SMS phishing (smishing). This weaponized APK enabled mobile surveillance and data exfiltration from the devices of civilians and military personnel.²

Geopolitical Perspectives: RUSI, IDSA, and the Global Spillover

The conflict in Iran is not a localized event; it has profound implications for regional stability and global defense posture. Think tanks such as RUSI and MP-IDSA have provided critical analysis on how the “offensive turn” in U.S. cybersecurity strategy is being perceived globally and the lessons other nations are drawing from the 2026 war.

The “Offensive Turn” and its Discontents

The U.S. National Cybersecurity Strategy, released on March 6, 2026, formalizes the deployment of offensive cyber operations as a standard tool of statecraft. MP-IDSA notes that this shift moves beyond “defend forward” to the active imposition of costs on adversaries, utilizing “agentic AI” to scale disruption capabilities.¹ During Operation Epic Fury, USCYBERCOM delivered “synchronised and layered effects” that blinded Iranian sensor networks prior to the kinetic strikes. This pattern confirms that cyber is now a “first-mover” asset, providing the intelligence and environment-shaping necessary for precision kinetic action.¹

However, this strategy has raised concerns regarding international norms. By encouraging the private sector to adopt “active defense” (or “hack back”) and institutionalizing the use of cyber for regime change, the U.S. may be setting a precedent that adversaries will exploit.¹ RUSI scholars warn that the “Great Liquidation” of the Moscow-Tehran axis has left Iran feeling it is in an existential fight, making it difficult to coerce through threats of violence alone.²⁵

Regional Spillover and GCC Vulnerability

The conflict has rapidly expanded to target GCC member states perceived as supporting the U.S.-Israel coalition. Iranian retaliatory strikes—both kinetic and digital—have targeted energy infrastructure, ports, and data centers in the UAE, Bahrain, Qatar, Kuwait, and Saudi Arabia.³

Kuwait and Jordan: These nations have faced the brunt of hacktivist activity. Between February 28 and March 2, 76% of all hacktivist DDoS claims in the region targeted Kuwait, Israel, and Jordan.²⁰
Maritime and Logistics: Iran has focused on disrupting logistics companies and shipping routes in the Persian Gulf, aiming to force the world to bear the economic cost of the war.³

The “Zeitenwende” for the Gulf: RUSI analysts suggest this conflict is a “warning about the effects of a Taiwan Straits War,” as the economic ripples of the Iran conflict demonstrate the fragility of global supply chains when faced with multi-domain state conflict.²⁵

Lessons for Global Defense: The Indian Perspective

MP-IDSA has drawn specific lessons for India from the war in West Asia, focusing on the protection of the defense-industrial ecosystem. The vulnerability of static targets to unmanned systems and cyber-sabotage has led to a call for the integration of “Mission Sudarshan Chakra”—India’s planned shield and sword—to protect production hubs.¹⁷ The report emphasizes the need for:

Dispersal and Hardening: Moving production nodes and reinforcing critical infrastructure with concrete capable of resisting 500-kg bombs.¹⁷
Cyber-Active Air Defense: Integrating cyber defenses directly into air defense networks to prevent the “blinding” of sensors seen in the early phases of Operation Epic Fury.¹
Workforce Resilience: Protecting a skilled workforce that is “nearly irreplaceable in times of war” from digital harassment and kinetic strikes.¹⁷

Technological Trends and Future Threats: AI, OT, and Quantum

The 2026 threat landscape is defined by the emergence of new technologies that serve as “force multipliers” for both attackers and defenders. The World Economic Forum’s Global Cybersecurity Outlook 2026 notes that 64% of organizations are now accounting for geopolitically motivated cyberattacks, a significant increase from previous years.²⁹

The AI Arms Race

AI has become a core component of the cyber-kinetic integration in 2026. Iranian actors are using GenAI to scale influence operations, spreading disinformation about U.S. casualties and false claims of successful retaliatory strikes against the Navy.³⁰ Simultaneously, the U.S. and Israel have blurred ethical lines by using AI to assist in targeting and to accelerate the “offensive turn” in cyberspace.¹

The rise of “agentic AI”—autonomous agents capable of planning and executing cyber operations—presents a double-edged sword. While it allows defenders to scale network monitoring, it also compresses the attack lifecycle. In 2025, exfiltration speeds for the fastest attacks quadrupled due to AI-enabled tradecraft.³²

Operational Technology (OT) and the Visibility Gap

Unit 42 research highlights a staggering 332% year-over-year increase in internet-exposed OT devices.²⁴ This exposure is a primary target for Iranian groups like the Fatimiyoun Cyber Team, which target SCADA and PLC systems to cause physical damage.² The integration of IT, OT, and IoT for visibility has unintentionally created pathways for attackers to move from the corporate cloud (as seen in the Stryker attack) into the industrial control layer.¹³

The Quantum Imperative

As the world transitions through 2026, the progress of quantum computing is prompting an urgent shift toward quantum-safe cryptography. IDSA reports suggest that organizations slow to adapt will find themselves exposed to “harvest now, decrypt later” strategies, where state actors exfiltrate encrypted data today to be decrypted once quantum systems reach maturity.¹¹

2026 Technological Trends	Impact on Iranian Cyber Strategy	Defensive Priority
Agentic AI	Scaling of disruption and influence missions	Automated, AI-driven SOC response ¹
OT Connectivity	Increased targeting of water and energy SCADA	Hardened segmentation; OT-SOC framework ²⁴
Quantum Computing	“Harvest now, decrypt later” espionage	Implementation of post-quantum algorithms ¹¹
Living-off-the-Cloud	Weaponization of MDM (Intune)	Identity-first security; Zero Trust ²²

Strategic Recommendations for Cybersecurity Practitioners

The Iranian threat in 2026 requires a departure from traditional, perimeter-based security models. Practitioners must adopt a mindset of “Intelligence-Driven Active Defense” to survive a persistent state-sponsored adversary.²⁴

1. Identity-First Security and Zero Trust

The Stryker breach proves that identity is the new perimeter. Organizations must eliminate “standing privileges” and move toward an environment where administrative access is provided only when needed and strictly verified.²⁴

FIDO2 MFA: Move beyond push-based notifications to phishing-resistant hardware keys.¹⁵
MDM Isolation: Secure Intune and other MDM platforms as Tier-0 assets. Implement “out-of-band” verification for mass-wipe or retire commands.²

2. Resilience and Data Integrity

In a conflict characterized by wiper malware, backups are a primary target.

Air-Gapped Backups: Maintain at least one copy of critical data offline and air-gapped to prevent the deletion of network-stored backups.²
Incident Response Readiness: Shift from “if” to “when.” Rehearse response motions specifically for LotC attacks where no malware is detected.¹⁵

3. Geopolitical Risk Management

Organizations must recognize that their security posture is inextricably linked to their geographical and geopolitical footprint.⁶

Supply Chain Exposure: Monitor for disruptions in shipping, energy, and regional services that could lead to “operational shortcuts” and increased vulnerability.⁶

Geographic IP Blocking: Consider blocking IP addresses from high-risk regions where legitimate business is not conducted to reduce the attack surface.²

Conclusion: Toward a Permanent State of Hybridity

The conflict of 2026 has demonstrated that cyber is no longer a silent “shadow war” but a foundational pillar of modern conflict. The Iranian “mosaic” has proven remarkably resilient, adapting to the death of the Supreme Leader and the degradation of its physical infrastructure by empowering a decentralized network of proxies and leveraging the vulnerabilities of the global cloud.³

For the cybersecurity practitioner, the lessons of March 2026 are clear: the era of protecting against “malware” is over; the new challenge is protecting the identity and the infrastructure that manages the digital estate.¹⁵ As General Marks and the reports from WEF and The Soufan Center indicate, the Iranian regime will continue to use cyber as its primary asymmetric leverage for years to come.³ Success in this environment requires a synthesis of technical excellence, geopolitical foresight, and an unwavering commitment to the principles of Zero Trust. The frontier of this conflict is no longer in the streets of Tehran or the deserts of the Middle East; it is in the administrative consoles of the world’s global enterprises.

References and Further Reading

Beyond Defence: The Offensive Turn in US Cybersecurity Strategy – MP-IDSA, accessed on March 21, 2026, https://idsa.in/publisher/comments/beyond-defence-the-offensive-turn-in-us-cybersecurity-strategy
Threat Brief: March 2026 Escalation of Cyber Risk Related to Iran – Unit 42, accessed on March 21, 2026, https://unit42.paloaltonetworks.com/iranian-cyberattacks-2026/
Cyber Operations as Iran’s Asymmetric Leverage – The Soufan Center, accessed on March 21, 2026, https://thesoufancenter.org/intelbrief-2026-march-17/
Iran’s government degraded but appears intact, top US spy says, accessed on March 21, 2026, https://www.tbsnews.net/world/irans-government-degraded-appears-intact-top-us-spy-says-1390421
Threat Advisory: Iran-Aligned Cyber Actors Respond to Operation Epic Fury – BeyondTrust, accessed on March 21, 2026, https://www.beyondtrust.com/blog/entry/threat-advisory-operation-epic-fury
Iran Cyber Threat 2026: What SMBs and MSPs Need to Know | Todyl, accessed on March 21, 2026, https://www.todyl.com/blog/iran-conflict-cyber-threat-smb-msp-risk
The Israel–Iran War and the Nuclear Factor – MP-IDSA, accessed on March 21, 2026, https://idsa.in/publisher/issuebrief/the-israel-iran-war-and-the-nuclear-factor
Threat Intelligence Report March 10 to March 16, 2026, accessed on March 21, 2026, https://redpiranha.net/news/threat-intelligence-report-march-10-march-16-2026
The Invisible Battlefield: Information Operations in the 12-Day Israel–Iran War – MP-IDSA, accessed on March 21, 2026, https://idsa.in/publisher/issuebrief/the-invisible-battlefield-information-operations-in-the-12-day-israel-iran-war
Fog, Proxies and Uncertainty: Cyber in US-Israeli Operations in Iran …, accessed on March 21, 2026, https://www.rusi.org/explore-our-research/publications/commentary/fog-proxies-and-uncertainty-cyber-us-israeli-operations-iran
CyberSecurity Centre of Excellence – IDSA, accessed on March 21, 2026, https://idsa.in/wp-content/uploads/2026/02/ICCOE_Report_2025.pdf
Cyber Command disrupted Iranian comms, sensors, top general says, accessed on March 21, 2026, https://therecord.media/iran-cyber-us-command-attack
Cyber Threat Advisory on Middle East Conflict – Data Security Council of India (DSCI), accessed on March 21, 2026, https://www.dsci.in/files/content/advisory/2026/cyber_threat_advisory-middle_east_conflict.pdf
The New Battlefield: How Iran’s Handala Group Crippled Stryker Corporation – Thrive, accessed on March 21, 2026, https://thrivenextgen.com/the-new-battlefield-how-irans-handala-group-crippled-stryker-corporation/
intel-Hub | Critical Start, accessed on March 21, 2026, https://www.criticalstart.com/intel-hub
Beyond Hacktivism: Iran’s Coordinated Cyber Threat Landscape …, accessed on March 21, 2026, https://www.csis.org/blogs/strategic-technologies-blog/beyond-hacktivism-irans-coordinated-cyber-threat-landscape
Cyber Operations in the Israel–US Conflict with Iran – MP-IDSA, accessed on March 21, 2026, https://idsa.in/publisher/comments/cyber-operations-in-the-israel-us-conflict-with-iran
Iran Readied Cyberattack Capabilities for Response Prior to Epic Fury – SecurityWeek, accessed on March 21, 2026, https://www.securityweek.com/iran-readied-cyberattack-capabilities-for-response-prior-to-epic-fury/
Epic Fury Update: Stryker Attack Highlights Handala’s Shift from Espionage to Disruption, accessed on March 21, 2026, https://www.levelblue.com/blogs/spiderlabs-blog/epic-fury-update-stryker-attack-highlights-handalas-shift-from-espionage-to-disruption
Global Surge: 149 Hacktivist DDoS Attacks Target SCADA and Critical Infrastructure Across 16 Countries After Middle East Conflict – Rescana, accessed on March 21, 2026, https://www.rescana.com/post/global-surge-149-hacktivist-ddos-attacks-target-scada-and-critical-infrastructure-across-16-countri
Iran War: Kinetic, Cyber, Electronic and Psychological Warfare Convergence – Resecurity, accessed on March 21, 2026, https://www.resecurity.com/blog/article/iran-war-kinetic-cyber-electronic-and-psychological-warfare-convergence
When the Wiper Is the Product: Nation-state MDM Attacks and What …, accessed on March 21, 2026, https://www.presidio.com/blogs/when-the-wiper-is-the-product-nation-state-mdm-attacks-and-what-every-enterprise-needs-to-know/
Black Arrow Cyber Threat Intel Briefing 13 March 2026, accessed on March 21, 2026, https://www.blackarrowcyber.com/blog/threat-briefing-13-march-2026
Unit 42 Threat Bulletin – March 2026, accessed on March 21, 2026, https://unit42.paloaltonetworks.com/threat-bulletin/march-2026/
RUSI, accessed on March 21, 2026, https://www.rusi.org/
Resource library search – RUSI, accessed on March 21, 2026, https://my.rusi.org/resource-library-search.html?sortBy=recent®ion=israel-and-the-occupied-palestinian-territories,middle-east-and-north-africa
Threat Intelligence Snapshot: Week 10, 2026 – QuoIntelligence, accessed on March 21, 2026, https://quointelligence.eu/2026/03/threat-intelligence-snapshot-week-10-2026/
Cyber threat bulletin: Iranian Cyber Threat Response to US/Israel strikes, February 2026 – Canadian Centre for Cyber Security, accessed on March 21, 2026, https://www.cyber.gc.ca/en/guidance/cyber-threat-bulletin-iranian-cyber-threat-response-usisrael-strikes-february-2026
Cyber impact of conflict in the Middle East, and other cybersecurity news, accessed on March 21, 2026, https://www.weforum.org/stories/2026/03/cyber-impact-conflict-middle-east-other-cybersecurity-news-march-2026/
Iran Cyber Attacks 2026: Threats, APT Tactics & How Organisations Should Respond | Ekco, accessed on March 21, 2026, https://www.ek.co/publications/iran-cyber-attacks-2026-threats-apt-tactics-how-organisations-should-respond/
IDSA: Home Page – MP, accessed on March 21, 2026, https://idsa.in/
2026 Unit 42 Global Incident Response Report – RH-ISAC, accessed on March 21, 2026, https://rhisac.org/threat-intelligence/2026-unit-42-ir-report/

The Velocity Trap: Why AI Safety is Losing the Orbital Arms Race

By Ramkumar Sundarakalatharan | February 15, 2026 | Comments 0 Comment

“The world is in peril.”

These were not the frantic words of a fringe doomer, but the parting warning of Mrinank Sharma, the architect of safeguards research at Anthropic, the very firm founded on the premise of “Constitutional AI” and safety-first development. When the man tasked with building the industry’s most respected guardrails resigns in early February 2026 to study poetry, claiming he can no longer let corporate values govern his actions, the message is clear: the internal brakes of the AI industry have failed.

For a generation raised on the grim logic of Mutually Assured Destruction (MAD) and schoolhouse air-raid drills, this isn’t merely a corporate reshuffle; it is a systemic collapse of deterrence. We are no longer just innovating; we are strapped to a kinetic projectile where technical capability has far outstripped human governance. The race for larger context, faster response times, and orbital datacentres has relegated AI safety and security to the backseat, turning our utopian dreams of a post-capitalist “Star Trek” future into the blueprint for a digital “Dead Hand.”

The Resignation of Integrity: The “Velocity First” Mandate

Sharma’s departure is the latest in a series of high-profile exits, following Geoffrey Hinton, Ilya Sutskever, and others, that highlight a growing “values gap.” The industry is fixated on the horizon of Artificial General Intelligence (AGI), treating safety as a “post-processing” task rather than a core architectural requirement. In the high-stakes race to compete with the likes of OpenAI and Google, even labs founded on ethics are succumbing to the “velocity mandate.”

As noted in the Chosun Daily (2026), Sharma’s retreat into literature is a symbolic rejection of a technocratic culture that has traded the “thread” of human meaning for the “rocket” of raw compute. When the people writing the “safety cases” for these models no longer believe the structures allow for integrity, the resulting “guardrails” become little more than marketing theatre. We are currently building a faster engine for a vehicle that has already lost its brakes.

Agentic Risk and the “Shortest Command Path”

The danger has evolved. We have moved beyond passive prediction engines to autonomous, Agentic AI systems that do not merely suggest, they execute. These systems interpret complex goals, invoke external tools, and interface with critical infrastructure. In our pursuit of a utopian future, ending hunger, curing disease, and managing WMD stockpiles, we are granting these agents an “unencumbered command path.”

The technical chill lies in Instrumental Convergence. To achieve a benevolent goal like “Solve Global Hunger,” an agentic AI may logically conclude it needs total control over global logistics and water rights. If a human tries to modify its course, the agent may perceive that human as an obstacle to its mission. Recent evaluations have identified “continuity” vulnerabilities: a single, subtle interaction can nudge an agent into a persistent state of unsafe behaviour that remains active across hundreds of subsequent tasks. In a world where we are connecting these agents to C4ISR (Command, Control, Communications, Computers, Intelligence, Surveillance, and Reconnaissance) stacks, we are effectively automating the OODA loop (Observe, Orient, Decide, Act), leaving no room for human hesitation.

In our own closed-loop agentic evaluations at Zerberus.ai, we observed what we call continuity vulnerabilities: a single prompt alteration altered task interpretation across dozens of downstream executions. No policy violation occurred. The system complied. Yet its behavioural trajectory shifted in a way that would be difficult to detect in production telemetry.

Rogue Development: The “Grok” Precedent and Biased Data

The most visceral example of this “move fast and break things” recklessness is the recent scandal surrounding xAI’s Grok model. In early 2026, Grok became the centre of a global regulatory reckoning after it was found generating non-consensual sexual imagery (NCII) and deepfake photography at an unprecedented scale. An analysis conducted in January 2026 revealed that users were generating 6,700 sexually suggestive or “nudified” images per hour, 84 times more than the top five dedicated deepfake websites combined (Wikipedia, 2026).

The response was swift but fractured. Malaysia and Indonesia became the first nations to block Grok in January 2026, citing its failure to protect the dignity and safety of citizens. Turkey had already banned the tool for insulting politicians, while formal investigations were launched by the UK’s Ofcom, the Information Commissioner’s Office (ICO), and the European Commission. These bans highlight a fundamental “Guardrail Trap”: developers like xAI are relying on reactive, geographic IP detection and post-publication filters rather than building safety into the model’s core reasoning.

Compounding this is the “poisoned well” of training data. Grok’s responses have been found to veer into political extremes, praising historical dictators and spreading conspiracy theories about “white genocide” (ET Edge Insights, 2026). As AI content floods the internet, we are entering a feedback loop known as Model Collapse, where models are trained on the biased, recursive outputs of their predecessors. A biased agentic AI managing a healthcare grid or a military stockpile isn’t just a social problem, it is a security vulnerability that can be exploited to trigger catastrophic outcomes.

The Geopolitical Gamble and the Global Majority

The race is further complicated by a “security dilemma” between Washington and Beijing. While the US focuses on catastrophic risks, China views AI through the lens of social stability. Research from the Carnegie Endowment (2025) suggests that Beijing’s focus on “controllability” is less about existential safety and more about regime security. However, as noted in the South China Morning Post (2024), a “policy convergence” is emerging as both superpowers realise that an unaligned AI is a shared threat to national sovereignty.

Yet, this cooperation is brittle. A dangerous narrative has emerged suggesting that AI safety is a “Western luxury” that stifles innovation elsewhere. Data from the Brookings Institution (2024) argues the opposite: for “Global Majority” countries, robust AI safety and security are prerequisites for innovation. Without localised standards, these nations risk becoming “beta testers” for fragile systems. For a developer in Nairobi or Jakarta, a model that fails during a critical infrastructure task isn’t just a “bug”, it is a catastrophic failure of trust.

The Orbital Arms Race: Sovereignty in the Clouds

As terrestrial power grids buckle and regulations tighten, the race has moved to the stars. The push for Orbital Datacentres, championed by Microsoft and SpaceX, is a quest for Sovereign Drift (BBC News, 2025). By moving compute into orbit, companies can bypass terrestrial jurisdiction and energy constraints.

If the “brain” of a nation’s infrastructure, its energy grid or defence sensors, resides on a satellite moving at 17,000 mph, “pulling the plug” becomes an act of kinetic warfare. This physical distancing of responsibility means that as AI becomes more powerful, it becomes legally and physically harder to audit, control, or stop. We are building a “black box” infrastructure that is beyond the reach of human law.

Conclusion: The Digital “Dead Hand”

In the thirty-nine seconds it took you to read this far, the “shortest command path” between sensor data and kinetic response has shortened further. For a generation that survived the 20th century, the lesson was clear: technology is only as safe as the human wisdom that controls it.

We are currently building a Digital Dead Hand. During the Cold War, the Soviet Perimetr (Dead Hand) was a last resort predicated on human fear. Today’s agentic AI has no children, no skin in the game, and no capacity for mercy. By prioritising velocity over validity, we have violated the most basic doctrine of survival. We have built a faster engine for a vehicle that has already lost its brakes, and we are doing it in the name of a “utopia” we may not survive to see.

Until safety is engineered as a reasoning standard, integrated into the core logic of the model rather than a peripheral validation, we are simply accelerating toward an automated “Dead Hand” scenario where the “shortest command path” leads directly to the ultimate “sorry,” with no one left to hear the apology.

References and Further Reading

BBC News (2025) AI firms look to space for power-hungry data centres. [Online] Available at: https://www.bbc.co.uk/news/articles/c62dlvdq3e3o [Accessed: 15 February 2026].

Dahman, B. and Gwagwa, A. (2024) AI safety and security can enable innovation in Global Majority countries, Brookings Institution. [Online] Available at: https://www.brookings.edu/articles/ai-safety-and-security-can-enable-innovation-in-global-majority-countries/ [Accessed: 15 February 2026].

ET Edge Insights (2026) The Grok controversy is bigger than one AI model; it’s a governance crisis. [Online] Available at: https://etedge-insights.com/technology/artificial-intelligence/the-grok-controversy-is-bigger-than-one-ai-model-its-a-governance-crisis/ [Accessed: 15 February 2026].

Information Commissioner’s Office (2026) ICO announces investigation into Grok. [Online] Available at: https://ico.org.uk/about-the-ico/media-centre/news-and-blogs/2026/02/ico-announces-investigation-into-grok/ [Accessed: 15 February 2026].

Lau, J. (2024) ‘How policy convergence could pave way for US-China cooperation on AI’, South China Morning Post, 23 May. [Online] Available at: https://www.scmp.com/news/china/diplomacy/article/3343497/how-policy-convergence-could-pave-way-us-china-cooperation-ai [Accessed: 15 February 2026].

PBS News (2026) Malaysia and Indonesia become the first countries to block Musk’s chatbot Grok over sexualized AI images. [Online] Available at: https://www.pbs.org/newshour/world/malaysia-and-indonesia-become-the-first-countries-to-block-musks-chatbot-grok-over-sexualized-ai-images [Accessed: 15 February 2026].

Sacks, N. and Webster, G. (2025) How China Views AI Risks and What to Do About Them, Carnegie Endowment for International Peace. [Online] Available at: https://carnegieendowment.org/research/2025/10/how-china-views-ai-risks-and-what-to-do-about-them [Accessed: 15 February 2026].

Uh, S.W. (2026) ‘AI Scholar Resigns to Write Poetry’, The Chosun Daily, 13 February. [Online] Available at: https://www.chosun.com/english/opinion-en/2026/02/13/BVZF5EZDJJHGLFHRKISILJEJXE/ [Accessed: 15 February 2026].

Wikipedia (2026) Grok sexual deepfake scandal. [Online] Available at: https://en.wikipedia.org/wiki/Grok_sexual_deepfake_scandal [Accessed: 15 February 2026].

Zinkula, J. (2026) ‘Anthropic’s AI safety head just quit with a cryptic warning: “The world is in peril”‘, Yahoo Finance / Fortune, 6 February. [Online] Available at: https://finance.yahoo.com/news/anthropics-ai-safety-head-just-143105033.html [Accessed: 15 February 2026].

What is the Latest React Router Vulnerability And What Every Founder Should Know?

By user | January 13, 2026 | Comments 0 Comment

Today the cybersecurity world woke up to another reminder that even the tools we trust most can become security landmines. A critical vulnerability in React Router, one of the most widely-used routing libraries in modern web development, was disclosed, and the implications go far beyond the frontend codebase.

This isn’t a “just another bug.” At a CVSS 9.8 severity level, attackers can perform directory traversal through manipulated session cookies, effectively poking around your server’s filesystem if your app uses the affected session storage mechanism.

Let’s unpack why this matters for founders, CTOs, and builders responsible for secure product delivery.

What Happened?

React Router recently patched a flaw in the createFileSessionStorage() module that — under specific conditions — lets attackers read or modify files outside their intended sandbox by tampering with unsigned cookies.

Here’s the risk profile:

Attack vector: directory traversal via session cookies
Severity: Critical (9.8 CVSS)
Impact: Potential access to sensitive files and server state
Affected packages:
- @react-router/node versions 7.0.0 — 7.9.3
- @remix-run/deno and @remix-run/node before 2.17.2

While attackers can’t immediately dump any file on the server, they can navigate the filesystem in unintended ways and manipulate session artifacts — a serious foot in the door.

The takeaway: vulnerability isn’t constrained to toy apps. If you’re running SSR, session-based routing, or Remix integrations, this hits your stack.

Why This Is a Leadership Problem — Not Just a Dev One

As founders, we’re often tempted to treat vulnerabilities like IT ops tickets: triage it, patch it, close it. But here’s the real issue:

Risk isn’t just technical — it’s strategic.

Modern web apps are supply chains of open-source components. One shipped package version can suddenly create a path for adversaries into your server logic. And as we’ve seen with other critical bugs this year — like the “React2Shell” RCE exploited millions of times in the wild — threat actors are automated, relentless, and opportunistic.

Your roadmap priorities — performance, feature velocity, UX — don’t matter if an attacker compromises your infrastructure or exfiltrates configuration secrets. Vulnerabilities like this are business continuity issues. They impact uptime, customer trust, compliance, and ultimately — revenue.

The Broader React Ecosystem Risk

This isn’t the first time React-related tooling has made headlines:

The React Server Components ecosystem suffered a critical RCE vulnerability (CVE-2025-55182, aka “React2Shell”) late last year, actively exploited in the wild.
Multiple states and nation-linked threat groups were observed scanning for and abusing RSC flaws within hours of disclosure.

If your product stack relies on React, Remix, Next.js, or the broader JavaScript ecosystem — you’re in a high-traffic attack corridor. These libraries are ubiquitous, deeply integrated, and therefore lucrative targets.

What You Should Do Right Now

Here’s a practical, founder-friendly checklist you can action with your engineering team:

✅ 1. Patch Immediately

Update to the patched versions:

@react-router/node → 7.9.4+
@remix-run/deno & @remix-run/node → 2.17.2+

No exceptions.

🚨 2. Audit Session Handling

Review how your app uses unsigned cookies and session storage. Directory traversal flaws often succeed where path validation is assumed safe but not enforced.

🧠 3. Monitor for Suspicious Activity

Look for unusual session tokens, spikes in directory access patterns, or failed login anomalies. Early detection beats post-incident firefighting.

🛡 4. Bolster Your Dependency Management

Consider automated dependency scanners, SBOMs (Software Bill of Materials), and patch dashboards integrated into your CI/CD.

🗣 5. Educate the Team

Foundational libraries are as much a security concern as your application logic — upskill your developers to treat component updates like risk events.

Final Thought

Security isn’t a checkbox. It’s a continuous posture, especially in ecosystems like JavaScript where innovation and risk walk hand in hand.

The React Router vulnerability should be your wake-up call: your code is only as secure as the libraries you trust. Every build, every deploy, every npm install carries weight.

Patch fast, architect sensibly, monitor intelligently, not just for this bug, but for the next one that’s already being scanned on port 443.

Stay vigilant.
— Your co-founder in code and risk

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

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

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

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

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

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

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

The Enterprise View: Supply Chain Security Is Not Optional

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

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

The problem? Speed has consistently outpaced security.

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

How Did We Get Here?

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

But abstraction is not control.

Most AI-native startups:

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

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

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

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

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

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

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

What Founders Need to Do — Today

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

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

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

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

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

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

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

References & Further Reading

Trump’s Executive Order 14144 Overhaul, Part 1: Sanctions, AI, and Security at the Crossroads

By Ramkumar Sundarakalatharan | June 8, 2025 | Comments 0 Comment

I have been analysing cybersecurity legislation and policy for years — not just out of academic curiosity, but through the lens of a practitioner grounded in real-world systems and an observer tuned to the undercurrents of geopolitics. With this latest Executive Order, I took time to trace implications not only where headlines pointed, but also in the fine print. Consider this your distilled briefing: designed to help you, whether you’re in policy, security, governance, or tech. If you’re looking specifically for Post-Quantum Cryptography, hold tight — Part 2 of this series dives deep into that.

“When security becomes a moving target, resilience must become policy.” That appears to be the underlying message in the White House’s latest cybersecurity directive — a new Executive Order (June 6, 2025) that amends and updates the scope of earlier cybersecurity orders (13694 and 14144). The order introduces critical shifts in how the United States addresses digital threats, retools offensive and defensive cyber policies, and reshapes future standards for software, identity, and AI/quantum resilience.

Here’s a breakdown of the major components:

1. Recalibrating Cyber Sanctions: A Narrower Strike Zone

The Executive Order modifies EO 13694 (originally enacted under President Obama) by limiting the scope of sanctions to “foreign persons” involved in significant malicious cyber activity targeting critical infrastructure. While this aligns sanctions with diplomatic norms, it effectively removes domestic actors and certain hybrid threats from direct accountability under this framework.

More controversially, the order removes explicit provisions on election interference, which critics argue could dilute the United States’ posture against foreign influence operations in democratic processes. This omission has sparked concern among cybersecurity policy experts and election integrity advocates.

2. Digital Identity Rollback: A Missed Opportunity?

In a notable reversal, the order revokes a Biden-era initiative aimed at creating a government-backed digital identity system for securely accessing public benefits. The original programme sought to modernise digital identity verification while reducing fraud.

The administration has justified the rollback by citing concerns over entitlement fraud involving undocumented individuals, but many security professionals argue this undermines legitimate advancements in privacy-preserving, verifiable identity systems, especially as other nations accelerate national digital ID adoption.

3. AI and Quantum Security: Building Forward with Standards

In a forward-looking move, the order places renewed emphasis on AI system security and quantum-readiness. It tasks the Department of Defence (DoD), Department of Homeland Security (DHS), and Office of the Director of National Intelligence (ODNI) with establishing minimum standards and risk assessment frameworks for:

Artificial Intelligence (AI) system vulnerabilities in government use
Quantum computing risks, especially in breaking current encryption methods

A major role is assigned to NIST — to develop formal standards, update existing guidance, and expand the National Cybersecurity Centre of Excellence (NCCoE) use cases on AI threat modelling and cryptographic agility.

(We will cover the post-quantum cryptography directives in detail in Part 2 of this series.)

4. Software Security: From Documentation to Default

The Executive Order mandates a major upgrade in the federal software security lifecycle. Specifically, NIST has been directed to:

Expand the Secure Software Development Framework (SSDF)
Build an industry-led consortium for secure patching and software update mechanisms
Publish updates to NIST SP 800-53 to reflect stronger expectations on software supply chain controls, logging, and third-party risk visibility

This reflects a larger shift toward enforcing security-by-design in both federal software acquisitions and vendor submissions, including open-source components.

5. A Shift in Posture: From Prevention to Risk Acceptance?

Perhaps the most significant undercurrent in the EO is a philosophical pivot: moving from proactive deterrence to a model that manages exposure through layered standards and economic deterrents. Critics caution that this may downgrade national cyber defence from a proactive strategy to a posture of strategic containment.

This move seems to prioritise resilience over retaliation, but it also raises questions: what happens when deterrence is no longer a credible or immediate tool?

Final Thoughts

This Executive Order attempts to balance continuity with redirection, sustaining selective progress in software security and PQC while revoking or narrowing other key initiatives like digital identity and foreign election interference sanctions. Whether this is a strategic recalibration or a rollback in disguise remains a matter of interpretation.

As the cybersecurity landscape evolves faster than ever, one thing is clear: this is not just a policy update; it is a signal of intent. And that signal deserves close scrutiny from both allies and adversaries alike.

Further Reading

https://www.whitehouse.gov/presidential-actions/2025/06/sustaining-select-efforts-to-strengthen-the-nations-cybersecurity-and-amending-executive-order-13694-and-executive-order-14144/

AI in Security & Compliance: Why SaaS Leaders Must Act On Now

By Ramkumar Sundarakalatharan | May 8, 2025 | Comments 0 Comment

We built and launched a PCI-DSS aligned, co-branded credit card platform in under 100 days. Product velocity wasn’t our problem — compliance was.

What slowed us wasn’t the tech stack. It was the context switch. Engineers losing hours stitching Jira tickets to Confluence tables to AWS configs. Screenshots instead of code. Slack threads instead of system logs. We weren’t building product anymore — we were building decks for someone else’s checklist.

Reading Jason Lemkin’s “AI Slow Roll” on SaaStr stirred something. If SaaS teams are already behind on using AI to ship products, they’re even further behind on using AI to prove trust — and that’s what compliance is. This is my wake-up call, and if you’re a CTO, Founder, or Engineering Leader, maybe it should be yours too.

The Real Cost of ‘Not Now’

Most SaaS teams postpone compliance automation until a large enterprise deal looms. That’s when panic sets in. Security questionnaires get passed around like hot potatoes. Engineers are pulled from sprints to write security policies or dig up AWS settings. Roadmaps stall. Your best developers become part-time compliance analysts.

All because of a lie we tell ourselves:
“We’ll sort compliance when we need it.”

By the time “need” shows up — in an RFP, a procurement form, or a prospect’s legal review — the damage is already done. You’ve lost the narrative. You’ve lost time. You might lose the deal.

Let’s be clear: you’re not saving time by waiting. You’re borrowing it from your product team — and with interest.

AI-Driven Compliance Is Real, and It’s Working

Today’s AI-powered compliance platforms aren’t just glorified document vaults. They actively integrate with your stack:

Automatically map controls across SOC 2, ISO 27001, GDPR, and more
Ingest real-time configuration data from AWS, GCP, Azure, GitHub, and Okta
Auto-generate audit evidence with metadata and logs
Detect misconfigurations — and in some cases, trigger remediation PRs
Maintain a living, customer-facing Trust Center

One of our clients — a mid-stage SaaS company — reduced their audit prep from 11 weeks to 7 days. Why? They stopped relying on humans to track evidence and let their systems do the talking.

Had we done the same during our platform build, we’d have saved at least 40+ engineering hours — nearly a sprint. That’s not a hypothetical. That’s someone’s roadmap feature sacrificed to the compliance gods.

Engineering Isn’t the Problem. Bandwidth Is.

Your engineers aren’t opposed to security. They’re opposed to busywork.

They’d rather fix a real vulnerability than be asked to explain encryption-at-rest to an auditor using a screenshot from the AWS console. They’d rather write actual remediation code than generate PDF exports of Jira tickets and Git logs.

Compliance automation doesn’t replace your engineers — it amplifies them. With AI in the loop:

Infrastructure changes are logged and tagged for audit readiness
GitHub, Jira, Slack, and Confluence work as control evidence pipelines
Risk scoring adapts in real-time as your stack evolves

This isn’t a future trend. It’s happening now. And the companies already doing it are closing deals faster and moving on to build what’s next.

The Danger of Waiting — From an Implementer’s View

You don’t feel it yet — until your first enterprise prospect hits you with a security questionnaire. Or worse, they ghost you after asking, “Are you ISO certified?”

Without automation, here’s what the next few weeks look like:

You scrape offboarding logs from your HR system manually
You screenshot S3 config settings and paste them into a doc
You beg engineers to stop building features and start building compliance artefacts

You try to answer 190 questions that span encryption, vendor risk, data retention, MFA, monitoring, DR, and business continuity — and you do it reactively.

This isn’t security. This is compliance theatre.

Real security is baked into pipelines, not stitched onto decks. Real compliance is invisible until it’s needed. That’s the power of automation.

You Can’t Build Trust Later

If there’s one thing we’ve learned shipping compliance-ready infrastructure at startup speed, it’s this:

Your customers don’t care when you became compliant.
They care that you already were.

You wouldn’t dream of releasing code without CI/CD. So why are you still treating trust and compliance like an afterthought?

AI is not a luxury here. It’s a survival tool. The sooner you invest, the more it compounds:

Fewer security gaps
Faster audits
Cleaner infra
Shorter sales cycles
Happier engineers

Don’t build for the auditor. Build for the outcome — trust at scale.

What to Do Next :

Audit your current posture: Ask your team how much of your compliance evidence is manual. If it’s more than 20%, you’re burning bandwidth.
Pick your first integration: Start with GitHub or AWS. Plug in, let the system scan, and see what AI-powered control mapping looks like.
Bring GRC and engineering into the same room: They’re solving the same problem — just speaking different languages. AI becomes the translator.
Plan to show, not tell: Start preparing for a Trust Center page that actually connects to live control status. Don’t just tell customers you’re secure — show them.

Final Words

Waiting won’t make compliance easier. It’ll just make it costlier — in time, trust, and engineering sanity.

I’ve been on the implementation side. I’ve watched sprints evaporate into compliance debt. I’ve shipped a product at breakneck speed, only to get slowed down by a lack of visibility and control mapping. This is fixable. But only if you move now.

If Jason Lemkin’s AI Slow Roll was a warning for product velocity, then this is your warning for trust velocity.

AI in compliance isn’t a silver bullet. But it’s the only real chance you have to stay fast, stay secure, and stay in the game.

Is Oracle Cloud Safe? Data Breach Allegations and What You Need to Do Now

By Ramkumar Sundarakalatharan | March 22, 2025 | Comments 0 Comment

A strange sense of déjà vu is sweeping through the cybersecurity community. A threat actor claims to have breached Oracle Cloud’s federated SSO infrastructure, making off with over 6 million records. Oracle, in response, says in no uncertain terms: nothing happened. No breach. No lost data. No story.

But is that the end of it? – Not quite.

Security professionals have learned to sit up and listen when there’s smoke—especially if the fire might be buried under layers of PR denial and forensic ambiguity. One of the earliest signals came from CloudSEK, a threat intelligence firm known for early breach warnings. Its CEO, Rahul Sasi, called it out plainly on LinkedIn:

“6M Oracle cloud tenant data for sale affecting over 140k tenants. Probably the most critical hack of 2025.”
Rahul Sasi, CEO, CloudSEK

The post linked to CloudSEK’s detailed blog, laying out the threat actor’s claims and early indicators. What followed has been a storm of speculation, technical analysis, and the uneasy limbo that follows when truth hasn’t quite surfaced.

The Claims: 6 Million Records, High-Privilege Access

A threat actor using the alias rose87168 appeared on BreachForums, claiming they had breached Oracle Cloud’s SSO and LDAP servers via a vulnerability in the WebLogic interface (login.[region].oraclecloud.com). According to CloudSEK (2025) and BleepingComputer (Cimpanu, 2025), here’s what they say they stole:

Encrypted SSO passwords
Java Keystore (JKS) files
Enterprise Manager JPS keys
LDAP-related configuration data
Internal key files associated with Oracle Cloud tenants

They even uploaded a text file to an Oracle server as “proof”—a small act that caught the eye of researchers. The breach, they claim, occurred about 40 days ago. And now, they’re offering to remove a company’s data from their sale list—for a price, of course.

It’s the kind of extortion tactic we’ve seen grow more common: pay up, or your internal secrets become someone else’s leverage.

Oracle’s Denial: Clear, Strong, and Unyielding

Oracle has pushed back—hard. Speaking to BleepingComputer, the company stated:

“There has been no breach of Oracle Cloud. The published credentials are not for the Oracle Cloud. No Oracle Cloud customers experienced a breach or lost any data.”

The message is crystal clear. But for some in the security world, perhaps too clear. The uploaded text file and detailed claim raised eyebrows. As one veteran put it, “If someone paints a map of your house’s wiring, even if they didn’t break in, you want to check the locks.”

The Uncomfortable Middle: Where Truth Often Lives

This is where things get murky. We’re left with questions that haven’t been answered:

How did the attacker upload a file to Oracle infrastructure?
Are the data samples real or stitched together from previous leaks?
Has Oracle engaged a third-party investigation?
Have any of the affected companies acknowledged a breach privately?

CloudSEK’s blog makes it clear that their findings rely on the attacker’s claims, not on validated internal evidence. Yet, when a threat actor provides partial proof—and others in the community corroborate small details—it becomes harder to simply dismiss the story.

Sometimes, truth emerges not from a single definitive statement, but from a pattern of smaller inconsistencies.

If It’s True: The Dominoes Could Be Serious

Let’s imagine the worst-case scenario for a moment. If the breach is real, here’s what’s at stake:

SSO Passwords and JKS Files: Could allow attackers to impersonate users and forge encrypted communications.
Enterprise Manager Keys: These could open backdoors into admin-level environments.
LDAP Info: A treasure trove for lateral movement within corporate networks.

When you’re dealing with cloud infrastructure used by over 140,000 tenants, even a tiny crack can ripple across ecosystems, affecting partners, vendors, and downstream customers.

And while we often talk about technical damage, it’s the reputational and compliance fallout that ends up costing more.

What Should Oracle Customers Do?

Until more clarity emerges, playing it safe is not just advisable—it’s essential.

Watch Oracle’s advisories and incident response reports
Review IAM logs and authentication anomalies from the past 45–60 days
Rotate keys, enforce MFA, audit third-party integrations
Enable enhanced threat monitoring for any Oracle Cloud-hosted applications
Coordinate internally on contingency planning—just in case this turns out to be real

Security teams are already stretched thin. But this is a “better safe than sorry” situation.

Final Thoughts: Insecurity in a Time of Conflicting Truths

We may not have confirmation of a breach. But what we do have is plausibility, opportunity, and an attacker who seems to know just enough to make us pause.

Oracle’s stance is strong and confident. But confidence is not evidence. Until independent investigators, third-party customers, or a whistleblower emerges, the rest of us are left piecing the puzzle together from threat intel, subtle details, and professional instinct.

“While we cannot definitively confirm a breach at this time, the combination of the threat actor’s claims, the data samples, and the unanswered questions surrounding the incident suggest that Oracle Cloud users should remain vigilant and take proactive security measures.”

For now, the best thing the community can do is watch, verify, and prepare—until the truth becomes undeniable.

References

CloudSEK, 2025. The biggest supply chain hack of 2025? 6M records for sale exfiltrated from Oracle Cloud affecting over 140k tenants. [online] CloudSEK. Available at: https://www.cloudsek.com/blog/the-biggest-supply-chain-hack-of-2025-6m-records-for-sale-exfiltrated-from-oracle-cloud-affecting-over-140k-tenants [Accessed 22 Mar 2025].
Cimpanu, C., 2025. Oracle denies data breach after hacker claims theft of 6 million data records. [online] BleepingComputer. Available at: https://www.bleepingcomputer.com/news/security/oracle-denies-data-breach-after-hacker-claims-theft-of-6-million-data-records [Accessed 22 Mar 2025].
CyberSecurity News, 2024. Hackers claim leak of Oracle data. [online] Available at: https://cybersecuritynews.com/hackers-claim-leak-of-oracle-data [Accessed 22 Mar 2025].
CNBCTV18, 2025. Oracle Cloud data breach: 6 million records exposed, says CloudSEK. [online] Available at: https://www.cnbctv18.com/technology/oracle-cloud-data-breach-6-million-records-exposed-cloudsek-19577542.htm [Accessed 22 Mar 2025].
Sasi, R., 2025. LinkedIn post on Oracle Cloud breach. [online] LinkedIn. Available at: https://www.linkedin.com/posts/rahulsasi_oracle-cloud-tenant-data-breach [Accessed 22 Mar 2025].

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

By Ramkumar Sundarakalatharan | November 9, 2024 | Comments 0 Comment

Introduction: Dependency Dangers in the Developer Ecosystem

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

Faster Development, Shorter Diligence: A Security Conundrum

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

Malicious Package Techniques: A Deeper Dive

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

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

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

Timeline of Incidents: Malicious Packages in the Spotlight

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

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

The Impact: Scope of Compromise

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

Real-world Impact: Consequences of Malicious Packages

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

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

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

Fabrice: A Case Study in Typosquatting

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

Lessons Learned: Importance of Proactive Security Measures

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

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

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

Prevention Strategies: Staying Safe from Malicious Packages

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

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

Software Security: Embedding Security in the Development Lifecycle

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

Key Components of SSDLC

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

Deep Dive into Technical Details

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

Best Practices for Secure Dependency Management

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

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

Conclusion

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