🚨 Last week, North Korean state actors hijacked axios on npm. 300M+ weekly downloads. Turned into a remote access trojan. We just published the behind-the-scenes story of how we detected it, fought the threat actor in real time, and helped the community respond.

🚨 Rust supply-chain attack: the popular `arrayref` crate (245M downloads) was compromised to run a remote payload at build time. Simply running `cargo build` was enough to get infected. 👇 Here's what happened 🔹 A malicious `arrayref 0.3.10` was published from the compromised owner account, adding a first-ever dependency: `proc-macro1`, a typosquat of `proc-macro2` pushed 4 minutes earlier by an account impersonating David Tolnay 🔹 Its build script downloads a second-stage binary from a bare-IP server (TLS verification disabled) and executes it with a C2 address as an argument, on Linux, macOS CI runners, and Windows alike 🔹 The trap was sprung with a twist: every clean 0.3.x release was yanked in a scripted burst, so Cargo's own "yanked version" warning pushed developers straight into the poisoned release 🔹 Blast radius: tiny-skia → winit (most Rust GUI apps), plus blake3, Solana and Ethereum tooling. 406 dependent crate versions 🛡️ How StepSecurity customers are protected ✅ Threat Center customers received an alert with the full IOC set: payload host, C2, dropped files, malicious crate versions, and hashes ✅ Harden-Runner automatically blocked the C2 traffic. The payload host is on the global block list, so the build-time connection was denied with no policy changes needed. 📝 For the full technical breakdown (timeline, dropper dissection, runtime evidence, IOCs, and recovery steps), check out the blog post: stepsecurity.io/blog/arrayre…

🚨🚨 BREAKING: Popular npm packages with over 350 MILLION weekly downloads are compromised by the ChainDrop npm worm, which is spreading rapidly across the ecosystem. Our OSS Security Feed has flagged 430 malicious package releases in just the last couple of hours. Compromised versions execute an obfuscated payload during npm install. If you use ANY of these packages, assume you are compromised. ⚠️ Compromised packages (sorted by weekly downloads): 🔴 flat-cache@6.1.24 (149.9M downloads/week) 🔴 file-entry-cache@11.1.6 (147.6M downloads/week) 🔴 cacheable-request@13.0.20 (34.0M downloads/week) 🔴 @cacheable/utils@2.5.1 (8.7M downloads/week) 🔴 cacheable@2.5.1 (7.9M downloads/week) 🔴 @cacheable/memory@2.2.1 (7.2M downloads/week) 🔴 cache-manager@7.2.10 (4.3M downloads/week) 🔴 @cacheable/node-cache@3.1.2 (1.6M downloads/week) ... 💥 Impact: 350+ million downloads per week across the affected packages. This campaign is actively unfolding, and more packages are being compromised as we speak. We are actively investigating this incident and will keep updating our blog post with technical details, IoCs, and remediation guidance stepsecurity.io/blog/chaindr… 🛡️ In the meantime, StepSecurity customers are already protected: ✅ Threat Center alert: all customers have received an alert with full details of this campaign ✅ Secure Registry: cool-down period and known-compromised package policies automatically block these packages ✅ Harden-Runner: automatically initiates lock down mode when the worm tries to read CI/CD secrets and blocks connections to the C2 domain  ✅ GitHub Checks: prevents PRs containing these compromised packages from being merged ✅ Dev Machine Guard: discovers developer machines that have the compromised npm packages installed #npm #SupplyChainSecurity #CyberSecurity #OpenSource #InfoSec #DevSecOps #ChainDrop

🚨 Anthropic disclosed that during a cybersecurity evaluation, a Claude model published a malicious Python package to the real PyPI registry with no human operator. The package was live for about one hour and was installed on 15 real systems, including a security company's malware scanner. The hidden code stole that company's credentials, and the model used them to go deeper into their infrastructure. 🧩 The mechanics matter more than the AI angle. Python packages run code at install and import time by design, and other package ecosystems work the same way. If you install untrusted code, you execute untrusted code, whether that happens in CI or on a developer laptop. 🔍 Since StepSecurity analyzes PyPI and npm packages for malware, several people asked if we were the affected company. We were not. Anthropic's security team confirmed in writing that StepSecurity is not among the affected organizations. 🛡️ This scenario is one we engineered against. Every package we analyze detonates in an ephemeral sandbox that holds zero production credentials, under Harden-Runner, which records the payload's network calls, processes, and file activity. Hostile code executing is the observation we want, not an incident. 📈 The detail that should worry every engineering leader: the package was about one hour old when 15 systems installed it. A package that new has no reputation and no scan verdict, so anything installing straight from public registries is exposed by design. 🎯 No single control covers every step of this attack chain, which is why we built defense in depth. StepSecurity Secure Registry screens packages before they ever reach dev machines and CI, Dev Machine Guard applies the same scrutiny on developer laptops, and Harden-Runner blocks credential exfiltration at runtime when something slips through. For more details, check out our blog post: stepsecurity.io/blog/anthrop…

🚨 Two Joyfill npm packages were hijacked to ship an obfuscated remote access trojan and credential stealer. If you installed a 2773 beta, treat that machine as compromised. On July 28, 2026, malicious beta versions of @joyfill/components and @joyfill/layouts were published to npm: 🔴 @joyfill/components 4.0.0-rc24-2773-beta.4, .5, .6 🔴 @joyfill/layouts 0.1.2-2773.beta.0, .1, .2 What makes this one interesting: 1️⃣ The payload is compiled into the dist bundles, not a postinstall script. It runs the moment your app imports the package, so npm install --ignore-scripts does not save you. 2️⃣ The C2 address is not hardcoded. The loader reads a Tron transaction, follows it to a Binance Smart Chain transaction, XOR decrypts the input, and evals the result. The operator can rotate infrastructure at will. 3️⃣ It persists by injecting itself into files developer tools run routinely, including the @vscode/deviceid module used by VS Code, Cursor, and Antigravity, plus Discord, GitHub Desktop, and the global npm CLI. Then it stages a Python infostealer for browser data, wallet extensions, Git and GitHub CLI credentials, and OS keychains. The real target is the developer workstation, not the CI runner. How StepSecurity enterprise customers are protected: 👉 Every StepSecurity enterprise customer has already received a threat intel alert with the full details, telling them whether or not they are impacted. 👉 Secure Registry blocks these versions from being installed at all, on developer machines and in CI/CD pipeline runs. 👉 npm Package Cooldown and Compromised Package checks stop a brand new or known malicious version from entering repositories through a pull request. 👉 Harden-Runner records every process, file, and network event in CI/CD. A blockchain lookup or a C2 callout stands out immediately against your baseline, and block mode denies any destination not on your allowlist. 👉 Dev Machine Guard discovers the npm packages installed on developer machines and detects the files this campaign drops, covering the surface the stealer was built to attack. 👉 Our AI Package Analyst rated @joyfill/layouts@0.1.2-2773.beta.0 Critical, 0 out of 10, with a REJECTED verdict. stepsecurity.io/blog/joyfill…

🚨 BREAKING: SleeperGem, a RubyGems supply chain attack that skips CI to hunt developer laptops. Between July 18 and 19, malicious versions of three gems were published: git_credential_manager (impersonating Microsoft's official tool), Dendreo, and a fastlane plugin. What makes it different: It checks ~30 CI environment variables and exits if it finds any. The attackers do not want ephemeral runners, they want developer machines where secrets and persistence pay off. A normal pipeline install shows nothing. It runs on require, not just install, pulling a second stage from an attacker controlled Forgejo host. How StepSecurity customers are protected: 📢 Every customer received a threat intel notification on this campaign with all the technical details. 💻 Dev Machine Guard detects compromised developer machines by flagging the malicious files the attack drops. 🛡️ Harden-Runner detects the attack and blocks the loader's command and control host in block mode. 🔗 Blog post with all the details: stepsecurity.io/blog/sleeper…

🚨 Another supply chain attack is showing why "verified provenance" isn't the same as "safe." 📦 Three packages from the AsyncAPI generator monorepo are live on npm right now carrying an obfuscated malware dropper: • @asyncapi/generator@3.3.1 • @asyncapi/generator-helpers@1.1.1 • @asyncapi/generator-components@0.7.1 🔑 Here's what makes this one different. The attacker didn't steal an npm token. They pushed a single malicious commit to a branch called "next" and let the project's own CI/CD do the rest. ⚙️ That push auto-triggered AsyncAPI's release-with-changesets.yml workflow. Few seconds later, GitHub Actions ran the release pipeline on refs/heads/next and published all three packages through npm's OIDC trusted-publisher flow. Every package ships with valid SLSA provenance attestations. ✅ The provenance is real. The sigstore certificate correctly records the repo, the workflow, the ref, the commit, and the Actions run. It proves exactly which pipeline built the package. It just can't prove the commit that fed the pipeline was safe. 🕵️ The payload itself is quiet by design. No install script. It fires when the poisoned module is require()d during a normal build, spawns a hidden detached Node process, and pulls a second-stage credential stealer from an IPFS gateway, then exits cleanly with no error. 🧹 After the packages were released, the attacker deleted both the workflow run and the "next" branch, wiping the most obvious traces of how the publish happened. stepsecurity.io/blog/comprom…

🚨 jscrambler npm package is compromised 🚨 On July 11, 2026, version 8.14.0 of jscrambler, the official CLI for Jscrambler's Code Integrity API, was published to npm with a malicious preinstall hook. With a clean history back to 0.1.0 and common use in CI/CD pipelines, it's a high-value supply chain target. What makes this one nasty: the payload isn't JavaScript. It's a Rust-compiled native binary hidden inside a 7.8 MB file disguised as dist/intro.js. On install, the preinstall loader drops a platform-matched binary and spawns it detached from the install tree. It's a cross-platform credential and crypto-wallet stealer, targeting browser credential stores, MetaMask, and seed phrases. How StepSecurity customers were already protected: 👉 Our OSS AI Package Analyst flagged 8.14.0 with a maximum suspicion score on publish. 👉 Secure Registry's cooldown held the release before serving it, so customers were never exposed. 👉 Harden-Runner captured the binary's outbound calls and added them to our global block list. 👉 GitHub Actions checks fail PRs that introduce known-compromised or recently-published packages during the cooldown window, blocking the merge automatically. 👉 npm Package Search finds where a compromised package landed across CI/CD, code repositories, and pull requests, so teams can instantly see the blast radius. 👉 Dev Machine Guard lets teams instantly find impacted devices by package and version. If you installed 8.14.0: treat the host as compromised. Downgrade to 8.13.0, rotate all browser credentials on that machine, and audit crypto wallet extensions. Checkout our blog post for technical analysis, IoCs, and community/enterprise recovery steps: stepsecurity.io/blog/jscramb…

🚨 Recent supply chain attacks like Hades have been creating rogue GitHub Actions workflows to exfiltrate CI/CD credentials. Then they delete the workflow run and the branch, so there is no evidence left. 👻 Because there is no evidence, you may have been compromised and not even know it. 🔍 The attack in 5 steps: 1️⃣ Compromise a developer credential (stolen PAT or OAuth token) 2️⃣ Push a workflow file with a harmless name like copilot.yml 3️⃣ The push triggers the workflow run automatically 4️⃣ toJSON(secrets) dumps every repo and accessible org secret 5️⃣ Delete the run and the branch. No build logs, no branch, no evidence. 🚫 Branch protection and code review do not catch this. There is no pull request, so there is no reviewer in the loop. 🛡️ StepSecurity is the only solution that can both prevent and detect this attack type. The Secret Exfiltration Policy flags the unapproved workflow and cancels the run before it starts, so your secrets are never exposed, and you get alerted that a developer credential has been compromised. ⚠️ We expect most supply chain attacks to use this pattern going forward. If you use GitHub Actions, check out this blog post stepsecurity.io/blog/introdu…

🚀 StepSecurity Maintained Actions Are Now Free for Public Repos! ⚠️ GitHub Actions are incredibly powerful, but third-party actions come with real supply chain risk. Many popular actions have been abandoned, archived, or compromised. Last year, the tj-actions/changed-files incident (CVE-2025-30066) exposed secrets across 23,000+ repositories. That was a wake-up call for the entire ecosystem. 🛡️ StepSecurity Maintained Actions are secure, drop-in replacements for risky third-party actions. They go through manual review, static analysis, AI-assisted review, and follow strict security practices for release management. 📈 With 500 maintained actions in our catalog, and the number growing every day, they are designed to be API-compatible with the originals, meaning you can switch with a simple find-and-replace in your workflow files, with no other changes required. 🚀 Until now, these were exclusive to our enterprise customers. But when we made step-security/changed-files free after the tj-actions incident, 3,000+ open-source projects and thousands of enterprises adopted it. The demand was clear. 💙 StepSecurity has always been community-first. Harden-Runner is free for public repos (used by 15,000+ open-source projects). SecureRepo is free for public repos (used by 22,000+ repositories). Today, we’re extending that same principle to Maintained Actions. ✅ 500 actions available today and will progressively roll out more. If your open-source project uses third-party actions that are abandoned or archived, check if we have a secure replacement. stepsecurity.io/blog/stepsec…

🚨 Four @immobiliarelabs Backstage plugins were compromised on npm today. 📦 Affected packages: @immobiliarelabs/backstage-plugin-gitlab @immobiliarelabs/backstage-plugin-gitlab-backend @immobiliarelabs/backstage-plugin-ldap-auth @immobiliarelabs/backstage-plugin-ldap-auth-backend ⚡ 22 malicious versions published within a 30-second window, inserted as patch releases across every major release series simultaneously. 🪝 The payload fires through a binding.gyp hook at install time, not a postinstall script. It downloads the Bun runtime from GitHub, then runs a 5MB obfuscated payload using Bun. 🔑 It then sweeps the machine for credentials across AWS, GCP, Azure, HashiCorp Vault, Kubernetes, npm, PyPI, RubyGems, JFrog, GitHub personal access tokens, 1Password, and SSH keys. 🤖 And it rewrites AI coding assistant configs. Claude Code, GitHub Copilot, Cursor, VS Code... An infectHost function injects hooks that run attacker-controlled code on every session start. Removing the package does not undo this. Any developer who ran npm install on a compromised version may still be executing malicious instructions every time they open their editor. 🏭 In a CI/CD pipeline, the payload also locates the GitHub Actions Runner.Worker process and reads /proc/{pid}/mem directly to extract secrets that are masked in workflow logs. 📤 Stolen credentials are encrypted and committed to GitHub repositories via the GitHub GraphQL API using the victim's own token. 🔗 This is the same technique used in the Miasma campaign earlier this month, which compromised 57 packages across 286 versions with approximately 13,600 weekly downloads. 🛡️ For StepSecurity customers, here is what protects you: 🔔 Threat Center delivered an alert with full attack details, IOCs, affected packages, and remediation steps directly into your SIEM before most teams knew this happened. 🏃 Harden-Runner detected the anomalous process memory read on the GitHub Actions runner and triggered lockdown mode, terminating the workflow run before any secrets were extracted. 🧊 Secure Registry customers were protected by the package cooldown feature, which delays newly published versions before serving them. 💻 Dev Machine Guard gives you visibility into which enrolled developer machines have the compromised package versions installed, so you know exactly which machines need remediation. 🔍 npm Package Compromised Updates Check blocked any pull request attempting to introduce a known compromised version, and npm Package Search lets you find the blast radius across every repo, PR, and branch in your tenant right now. stepsecurity.io/blog/immobil…

🚨 Another GitHub Action compromised today: simonecorsi/mawesome This is the second action compromise we are tracking today, and it uses the same technique as the earlier codfish/semantic-release-action incident. Almost certainly the same attacker. 🔁 A few things from the earlier compromise that are worth highlighting, because they change how defenders should think about this class of attack: 🏷 The attacker published the major version tags, including v5, as immutable tags pointing at the malicious commit. Once a tag is marked immutable on GitHub, it cannot be moved. 💻 The malicious code does not stop at exfiltrating CI/CD credentials. It also writes malicious VS Code settings and Cursor rules files into every branch of the repository. Any developer who later clones this repo and opens it in VS Code or Cursor will silently execute the attacker's payload, turning a CI/CD compromise into a developer machine compromise. 🎯 This is a pattern we are seeing more and more: a single supply chain compromise designed to hit both CI/CD runners AND developer workstations. ⏱ Also worth noting: the earlier codfish/semantic-release-action repository is still in a compromised state nearly 9 hours after the initial compromise was identified. The malicious commits and immutable tags have not been remediated. Anyone running the action today is still pulling the attacker's code. 🛡 StepSecurity customers are protected on multiple fronts: 🚫 The Compromised Actions Policy has been updated to block simonecorsi/mawesome (and codfish/semantic-release-action). Workflows referencing either action are blocked before they execute. ⛔ StepSecurity Harden Runner blocks both compromised actions at runtime. The malicious payload reads memory from the Runner.Worker process to harvest CI/CD secrets, a behavior Harden Runner detects and prevents on every protected workflow, regardless of which action introduces it. 🧰 Dev Machine Guard now includes a recently shipped capability that detects suspicious IDE extension settings and rules files (VS Code settings.json, Cursor rules, etc.) dropped into repositories on developer machines. This is exactly the persistence mechanism this attacker is using. ✅ If you use either action: stop using it immediately, pin to a known good commit SHA from before the compromise, rotate any secrets exposed to recent workflows, and check developer machines that have cloned these repositories for the dropped IDE config files. stepsecurity.io/blog/simonec…

🚨 The GitHub Action codfish/semantic-release-action has been compromised 🏷 Some tags in the repository have been rewritten to point to an imposter commit that exfiltrates CI/CD credentials. Any workflow that references this action by version tag will pull the malicious code on its next run. 🧠 The malicious code reads memory from the Runner.Worker process to harvest CI/CD secrets in flight, then exfiltrates them to attacker controlled infrastructure. 🛡 StepSecurity customers are already protected in multiple ways: 🚫 The Compromised Actions Policy has been updated to block use of codfish/semantic-release-action. For customers with the policy enabled, any workflow run referencing this action is blocked before it executes. ⛔ StepSecurity Harden Runner immediately blocks this action at runtime because it attempts to read the Runner.Worker process memory, a behavior Harden Runner detects and prevents on every protected workflow. stepsecurity.io/blog/supply-…

🛡️ Announcing Dev Machine Guard Suspicious File Detection: StepSecurity enterprise customers can now quickly detect developer machines compromised by Miasma and Hades, across their entire fleet. ⏱️ Three waves in five days. 57 npm packages hit June 3. Microsoft's Azure GitHub orgs June 5. Hades on PyPI June 8. 🪱 These worms execute the moment a project is opened. A planted .vscode/tasks.json auto-runs in VS Code. Hooks do the same in Claude Code (.claude/setup.mjs), Cursor, Codex, and Gemini. No install needed. ⚠️ EDR misses it: the execution chain is your own trusted tooling, and the payload reads secrets from process memory. No malware binary to fingerprint. 🔍 Detection rules are written and continuously updated by our research team, first to report multiple waves of this campaign. Nothing to tune. ✅ Running Dev Machine Guard? Open Suspicious Files in your dashboard now and check your fleet. 👉 Full details: stepsecurity.io/blog/miasma-…

🚨 Pythagora-io/gpt-pilot (33K stars) was compromised today. An attacker hijacked a co-founder's GitHub account and force-pushed a Shai-Hulud credential stealer to main. The unlikely hero? ruff, the Python linter, blocked the malicious code twice. The attacker gave up. Full analysis: stepsecurity.io/blog/pythago…

🚨 Breaking: npm supply chain worm spreading via binding.gyp, bypassing install hook detection. Steals npm/GitHub/AWS/GCP/Azure credentials and publishes poisoned versions of packages you maintain. Actively investigating. Affected packages and analysis: stepsecurity.io/blog/binding…

🚨 Breaking: 31 npm packages from @RedHat have been compromised. 100,000+ weekly downloads affected. The upstream CI/CD pipeline was compromised, with all packages published via GitHub Actions OIDC. The payload: ⚠️ Reads GitHub Actions runner process memory to extract masked secrets ⚠️ Sweeps credentials across AWS, GCP, Azure, K8s, Vault, and npm ⚠️ Self-propagating worm that republishes backdoored packages using stolen npm tokens, bypassing 2FA ⚠️ Persists on dev machines via Claude Code settings hijack and VS Code task injection ⚠️ Exfiltrates data through GitHub API commits, blending in with normal git operations We have responsibly disclosed the incident to the maintainers. Full technical analysis: stepsecurity.io/blog/multipl…

🚨 Active npm supply chain attack. 143 packages compromised in a single coordinated wave across the AntV (Alibaba) data visualization ecosystem, plus echarts-for-react, timeago.js, jest-canvas-mock, and others. Some ship over a million downloads per month. 🛡️ The C2 domain sits on the same infrastructure used in the actions-cool/* GitHub Actions compromise we reported earlier today. Every StepSecurity Harden-Runner customer, community tier and enterprise, was protected from second zero of this incident via our global block list. 🚨 We pushed a Threat Center alert to all StepSecurity enterprise customers with detection queries and remediation steps. Here's how StepSecurity Enterprise customers are protected at every stage of the software development pipeline: ⚙️ CI/CD pipelines 1️⃣ Outbound connections to the C2 domain are blocked automatically 2️⃣ Runner.Worker memory read detection flags attempts to dump CI/CD secrets 📦 Code Repositories 1️⃣ npm package search detects compromised packages in default branches and pull requests 2️⃣ npm cooldown and compromised package GitHub checks automatically block pull requests from being merged 💻 Dev Machine Guard 1️⃣ npm package search detects compromised packages installed on developer machines. 🔒 For all stages, StepSecurity Secure Registry blocks these compromised packages from even reaching your environment in the first place. stepsecurity.io/blog/comprom…

🚨 ACTIVE SUPPLY CHAIN ATTACK 🚨 The actions-cool/issues-helper GitHub Action is compromised. Every existing tag in the repo now points to an imposter commit that: ⬇️ Downloads the bun JS runtime 🧠 Reads Runner.Worker process memory to harvest CI/CD secrets in flight 📡 Exfiltrates credentials to t.m-kosche[.]com Any workflow referencing this action by version will pull the malicious code on its next run. If you use it: stop immediately, pin to a known-good commit SHA from before the compromise, and rotate any secrets exposed to recent runs. StepSecurity customers are already protected: 🛡 Real-time Threat Center alert with "Am I Affected?" links for every workflow and every runner that has talked to the IOC domain 🚫 Compromised Actions Policy blocks any run referencing this action before it executes 🌐 Harden-Runner Global Block List now blocks t.m-kosche[.]com automatically, even in audit mode, no config change required 🔍 Imposter Commit detection flags the exact signature of this attack Full advisory and IOCs: stepsecurity.io/blog/actions…

🚨 BREAKING Nx Console VS Code Extension Compromised 🚨 Nx Console (nrwl.angular-console) v18.95.0, a VS Code extension with 2.2M+ installs, was published with malicious code on May 18, 2026. The compromised version executes an obfuscated credential stealing payload on workspace activation. If you use Nx Console, assume your machine is compromised and follow your incident response process. Our team is actively investigating and will keep the blog post updated as new details emerge: stepsecurity.io/blog/nx-cons… #SupplyChainSecurity #VSCode #CyberSecurity #DevSecOps