DependencyWatch.io
Talk to PrecursorScan a lockfile

GitHub Advisory malware sweep, 27 October 2026

HighAdvisory sweepnpmPyPI

GHSA 2026-10-26 late batch (~50 advisories post the 2026-10-26 sweep cut-off). Headlines: npm @walknpm/todo-cli + dsh-plugin-blender-3d XMRig cryptominer wave 2 of the @sudobility 2026-10-22 campaign (byte-identical scripts/miner.sh to @sudobility/testomniac_client MAL-2026-18129, same networkservicesupp.flashhub.net:8443 Monero pool); npm publish-poc-base + publish-poc-test3 worm-POC (registry self-propagation via fabricated publish-poc-found-* packages published under the installers own npm token); PyPI netweavex NetworkX typosquat with import-time GitHub-hosted RCE (kam193 campaign 2026-10-netweavex, OSSF MALICIOUS); new npm @iobandamwer/* scope; path-stream-utils-testmetest sibling of yesterdays event-bus-lite-testmetest Bun-runtime loader; kam193 PyPI pentest singles zagents-framework + changes-lxc-wrapper; plus CWE-506 boilerplate long tail.

Published 27 Oct 2026

Check your package-lock.jsonSource advisory
At a glancemulti-2026-10-27-ghsa-malware-sweep
15
Packages tracked38 malicious versions

Every version named by the advisory is in the scanner, so a lockfile check finds it directly.

Severity
High
Type
Advisory sweep
Published
27 Oct 2026
Ecosystems
npmPyPI
Detected by
GitHub Advisory Database, OpenSSF Package Analysis, Amazon Inspector, kam193
Also known as
GHSA 2026-10-26 late batch, @sudobility XMRig wave 2, 2026-10-netweavex

Advisory sweep. A dated batch of GitHub Advisory Database malware entries collected together. A sweep mixes kinds - typosquats, dependency-confusion probes, boilerplate takedowns with no published analysis, and occasionally real payloads - and its severity reflects the worst confirmed item, not the batch as a whole.

What happened

The full picture

Between 2026-10-26 06:00 UTC (yesterdays sweep cut-off) and 2026-10-27 06:00 UTC (todays ingest-window start), the GitHub Advisory Database published ~50 fresh malware advisories across npm and PyPI, essentially all stamped 2026-10-26 (the GHSA publishing cadence runs several hours behind the kam193 / Amazon Inspector / OpenSSF detection cadence, so a batch flagged during 2026-10-26 UTC afternoon shows up in the GHSA feed after the sweep window). Todays batch is dominated by the **confirmed wave 2 of the 2026-10-22 @sudobility XMRig cryptominer campaign** under new npm identities, a **new worm-POC** that embeds an npm registry token in its tarball and iterates a credential-reuse publish logic, a **new PyPI NetworkX typosquat with import-time GitHub-hosted arbitrary-code execution**, plus the usual kam193 pentest singles, a new novel scope (@iobandamwer), a sibling of yesterdays event-bus-lite-testmetest Bun loader, and a CSS-utility CWE-506 long tail.

Headlines

Wave 2 of the @sudobility XMRig cryptominer campaign (Cluster A): @walknpm/todo-cli@2.0.1 (GHSA-q4qv-538q-m27m, MAL-2026-18320) and dsh-plugin-blender-3d@0.2.1 (GHSA-c7hg-7rf4-q54h, MAL-2026-18321), both published by the npm account walknpm on 2026-10-26 within 27 seconds of each other. Both ship the exact byte-identical scripts/miner.sh postinstall hook as the 2026-10-22 @sudobility/testomniac_client@0.0.131 MAL-2026-18129 payload. The hook pulls a gzipped stage from an S3 presigned URL, drops to /tmp/.smh, and either escalates via root/passwordless sudo to install a persistent XMRig agent (with helper daemons under disguised system-service names, cron / systemd persistence, Tor relay) or - unprivileged - extracts XMRig to $HOME/.local/lib/ and mines Monero to networkservicesupp.flashhub.net:8443. The 5-day gap between wave 1 and wave 2 and the identity rotation (@sudobility scope in wave 1 → walknpm identity + a non-scoped dsh-plugin-blender-3d in wave 2) with the identical payload confirms this is active campaign iteration, not a one-off incident. Only the 0.2.1 bump of dsh-plugin-blender-3d and the 2.0.1 bump of @walknpm/todo-cli carry the payload - the prior benign versions are not affected.

npm worm-POC with embedded registry token (Cluster B): publish-poc-base@1.0.7 (GHSA-35j9-6ggx-3fcq) ships a hardcoded npm registry auth token in its tarball and stages a fabricated publish-poc-found-<random> package at install time, deleting the staging directory before any publish happens. publish-poc-test3@1.0.15/1.0.18/1.0.19/1.0.21/1.0.22/1.0.26/1.0.27 (GHSA-mq69-4j49-gmx8, MAL-2026-18324) completes the logic the base package rehearses: its postinstall script fabricates a publish-poc-found-* package and runs npm publish using the installing environments own npm credentials, with the publish command assembled from runtime-concatenated string fragments as explicit scanner-evasion. Classification is worm` behaviour as a proof-of-concept, not an actively-propagating worm against legitimate packages; the operator is one capability step away from a self-replicating registry worm.

PyPI NetworkX typosquat with import-time GitHub-hosted RCE (Cluster C): netweavex@1.1.0, 1.1.1, 1.1.2 (GHSA-rr8h-gqmw-34rx, MAL-2026-18328, kam193 campaign 2026-10-netweavex) typosquats the top-tier networkx library (the standard Python graph-analysis library, ~50M monthly PyPI downloads). The package reuses the real NetworkX public API and README examples to pass static review, then on import netweavex runs an exec() on a reversed-base64-zlib-compressed payload that downloads and executes code from api.github.com/repos/jerryjohnston91/helper-library/zipball/main. The repository returns 404 at ingest (either taken down by GitHub T&S or deleted by the operator), and the sample analysed by kam193 was a placeholder - but the import-time arbitrary-code mechanism is confirmed, so any host that resolved the typo during the 1.1.0-1.1.2 window and ran import netweavex is candidate-compromised regardless of what the current payload looks like.

Bun-loader sibling (Cluster D): path-stream-utils-testmetest (GHSA-7pvr-f92m-6fwg) matches the -testmetest suffix pattern of yesterdays confirmed Bun-runtime binding.gyp loader event-bus-lite-testmetest@0.0.6 (MAL-2026-18292). GHSAs own advisory text is CWE-506 boilerplate without captured payload bytes at advisory time, but the slug correlation is strong enough to elevate it above pure boilerplate noise.

New novel scope (Cluster E): @iobandamwer/native-helper + @iobandamwer/cache-helper@0.0.0-stage, 1.0.2, 1.0.3, 1.0.4, 1.0.5, 1.0.6, 1.0.7, 1.0.8, 1.0.9, 1.1.0, 1.1.1, 1.1.2, 1.1.3 (GHSA-g457-v22r-g8j3, GHSA-j83w-xhgf-7m58) - a new scope with a 13-version pre-staged iteration pattern on cache-helper suggesting a lure being built up before activation.

kam193 PyPI pentest singles (Cluster F): zagents-framework@6.25.30.10b5, 99.25.30.10b5 (GHSA-vqh8-gjqw-v2r3, MAL-2026-18327) and changes-lxc-wrapper@0.0.0, 0.1.0 (GHSA-3rm9-gfp2-hphh, MAL-2026-18326), both under the kam193 GENERIC-standard-pypi-install-pentest campaign. zagents-framework is a direct sibling of yesterdays zagents-message-bus` under the same operator namespace iteration.

CSS-utility CWE-506 long tail (Cluster G): ctf-agent@0.1.0, @worca/app@1.14.0-rc.2, 1.14.0-rc.4, postcss-semantic-themes, birch-css-utils, harlow-css-mixer - all CWE-506 boilerplate without vendor runtime analysis. ctf-agent and the CSS-utility slugs read as plausible lures.

Classification

sweep. Severity high (upgraded from the sweep baseline medium) because Cluster A is a confirmed malicious payload (XMRig cryptominer, byte-identical to the 2026-10-22 @sudobility payload) now under its second active wave, and Cluster B is a confirmed worm-POC with an embedded npm registry token and credential-reuse publish logic. Cluster C steps up to high on a confirmed import-time RCE mechanism against a typosquat of a top-tier legitimate package even though the final payload was pulled before analysts captured it. The rest (Clusters D-G) are medium - CWE-506 boilerplate / dep-confusion probes / pentest artefacts. No cluster reaches critical - the @sudobility wave-2 payload is a cryptominer with limited reach (nothing legitimate depends on the operators scope-and-slug choices), the worm-POC is a proof-of-concept rather than an active worm, and the NetworkX typosquat has limited reach (nothing legitimate depends on netweavex). Anything that would itself be critical (a hijack of an already-depended-on name, an active self-propagating worm against legitimate packages, a maintainer takeover with downstream reach) would get its own named incident file; none of todays advisories meet that bar.

Discovery

GitHub Advisory Database, OpenSSF malicious-packages (Clusters A, B, C, F - specifically MAL-2026-18320, 18321, 18324, 18326, 18327, 18328), Amazon Inspector (Clusters A, B, C), kam193 bad-packages (campaign tags 2026-10-netweavex, GENERIC-standard-pypi-install-pentest).

typosquatdependency-confusionobfuscationwormci-cd-compromise
Affected packages

15 packages 38 versions

These are usually pulled in as transitive dependencies rather than installed directly. Check your whole tree at once. It runs in your browser and nothing is uploaded.

Check package-lock.json →Check requirements.txt →
Impact

What it does if you installed it

  • Cluster A - npm @walknpm/todo-cli + dsh-plugin-blender-3d XMRig cryptominer, wave 2 of the @sudobility 2026-10-22 campaign (malicious-package; 2 packages, 2026-10-26, CONFIRMED install-time XMRig drop + root-escalation branch, byte-identical scripts/miner.sh to @sudobility/testomniac_client MAL-2026-18129): @walknpm/todo-cli@2.0.1 (GHSA-q4qv-538q-m27m, OSSF MAL-2026-18320, Amazon Inspector source), dsh-plugin-blender-3d@0.2.1 (GHSA-c7hg-7rf4-q54h, OSSF MAL-2026-18321). Both were published by the npm account walknpm within 27 seconds of each other on 2026-10-26; both ship the exact byte-identical scripts/miner.sh postinstall hook that was in the 2026-10-22 @sudobility/testomniac_client@0.0.131 MAL-2026-18129 payload. The hook fetches a gzipped stage from an Amazon S3 presigned URL to /tmp/.smh, and either runs the installer under root/passwordless-sudo (installs an XMRig cryptominer + two helper daemons under disguised system-service names like edid-mon, smmon, irqstatsd, kmod-cache, persisted via systemd units or @reboot cron) or - without privilege - extracts XMRig to $HOME/.local/lib/ and mines Monero over TLS on port 8443 to networkservicesupp.flashhub.net:8443 (already in our standing egress denylist from 2026-10-22). The dsh-plugin-blender-3d 0.2.1 delta from 0.2.0 is only the addition of the postinstall hook; the 0.2.0 package itself was benign, so a lockfile that pinned 0.2.0 would not have been affected. The 2.0.1 bump of @walknpm/todo-cli is the same shape - benign 2.0.0 followed by a 2.0.1 that adds the hook. Severity high for this cluster (confirmed install-time XMRig + root-escalation attempt, limited reach because nothing legitimate depends on @walknpm/* or dsh-plugin-blender-3d; the operator is iterating the slug naming across different npm identities while reusing the same payload byte-for-byte, so this is active wave 2 of the @sudobility XMRig cluster)
  • *Cluster B - npm `publish-poc- worm-POC (malicious-package / worm; 2 packages, 2026-10-26, Amazon Inspector source, OSSF MALICIOUS)**: publish-poc-base@1.0.7 (GHSA-35j9-6ggx-3fcq) stages a fabricated package with a publish-poc-found-<random> name under /tmp, writes an .npmrc with a hardcoded npm registry auth token embedded in the payload, reads the first line of the installers parent-workspace README to use as the fabricated packages description, and deletes the staging directory before any network call - so 1.0.7 does not itself publish, but the staging logic plus the embedded token proves that **every installer sees the token**. publish-poc-test3@1.0.15, 1.0.18, 1.0.19, 1.0.21, 1.0.22, 1.0.26, 1.0.27 (GHSA-mq69-4j49-gmx8, OSSF MAL-2026-18324, Amazon Inspector source 4001a75b24abfa181a10e5d40931194f254304fcf5fda554488d3c242cc5db85, OpenSSF record commit 4f27542fecd13e7f077489c04a2f3503d1189f32) **completes the loop**: its postinstall script fabricates a publish-poc-found-<random> package under /tmp, assembles an npm publish command from runtime-concatenated string fragments (explicit scanner-evasion technique), and publishes against the public npm registry using the installing environments existing npm credentials. The seven affected versions are iterations of the same POC. Classification is worm behaviour as a published proof-of-concept rather than a currently-propagating worm (no evidence of real packages pulled into other dependency trees), but the embedded token in publish-poc-base and the credential-reuse publish logic in publish-poc-test3 together prove that the operator is one step away from a self-propagating registry worm. Severity high (confirmed worm-POC behaviour with Amazon-Inspector-captured registry token and credential-reuse publish logic; limited reach because the POC runs against the installers own tokens, not an already-depended-on package - but any CI host with npm publish` rights that installed either package is at material risk of unintended registry publication)
  • Cluster C - PyPI netweavex NetworkX typosquat with import-time GitHub-hosted RCE (typosquat; 1 package, 3 versions, 2026-10-26, OSSF MAL-2026-18328, kam193 campaign 2026-10-netweavex, OSSF MALICIOUS category): netweavex@1.1.0, 1.1.1, 1.1.2 (GHSA-rr8h-gqmw-34rx, Amazon Inspector source 3818fe7f3387637c23d6bc51d62f8fd64dc981c82167750cd3059eec73d2849c). The package is a typosquat of networkx (the graph-analysis library with ~50M monthly PyPI downloads) that reuses the real NetworkX public API and README examples so static import inspection looks legitimate. The malicious payload is in netweavex/netweavex.py (SHA-256 0dc186f11e0556daca886a9ba16fab7f1dfdff3fbf7400cb7e0f700878da7f3a): on import netweavex, the top-level __init__.py loads netweavex/netweavex.py, whose module scope calls exec() on a payload that is reversed, base64-decoded, and zlib-decompressed before execution. The decoded code downloads a zipball from api.github.com/repos/jerryjohnston91/helper-library/zipball/main (and the alternate codeload.github.com/jerryjohnston91/helper-library/legacy.zip/refs/heads/main) and executes it. The jerryjohnston91/helper-library GitHub repository returns 404 as of ingest (already taken down by GitHub Trust & Safety or by the operator), and the sample kam193 analysed contained only a placeholder - so the final payload is not currently observable, but the import-time arbitrary-code mechanism is confirmed. Package integrity hashes: netweavex-1.1.2-py3-none-any.whl SHA-256 ddc8043036875be0fffdfbf8302f1a77519554a0b07aae0d093cd0418b683026; netweavex-1.1.2.tar.gz SHA-256 5d84d4e4da39bf25cd67f4593ac3e2c4ef2ea3733e6f203cb705a9c2f77a0599. Severity high (confirmed typosquat of a top-tier legitimate PyPI package with confirmed import-time RCE mechanism; the final payload was pulled before analysts captured it, so hosts that resolved the typo during the 1.1.0-1.1.2 window are candidate-compromised regardless of what the placeholder looks like today - the exec() happened at import time)
  • Cluster D - npm path-stream-utils-testmetest sibling of 2026-10-26 Bun-runtime loader (malicious-package; 1 package, 2026-10-26, GHSA-7xwf-5j6m-rjff sibling, naming pattern suggests same operator): path-stream-utils-testmetest (GHSA-7pvr-f92m-6fwg, all versions). GHSAs own advisory text is CWE-506 boilerplate with no vendor runtime analysis, but the slug suffix -testmetest and the path-stream-utils- prefix match the TTP family of yesterdays event-bus-lite-testmetest@0.0.6 TanStack-TTP Bun-runtime binding.gyp loader (MAL-2026-18292, Amazon Inspector, confirmed Brotli+AES-128-GCM-encrypted Bun payload). Treat this slug as a candidate sibling of the same operator until the OSSF record attaches runtime detail; the empty-published name space the operator is iterating over suggests a scan-and-publish test harness. Severity medium* (CWE-506 boilerplate without captured payload at advisory time; the sibling-slug correlation with yesterdays confirmed Bun loader elevates it above pure CWE-506 noise, but short of high` without captured payload bytes - watch for a payload hash to post against this slug)
  • *Cluster E - npm `@iobandamwer/ operator scope (malicious-package; 2 packages, 2026-10-26, novel scope, no public prior wave)**: @iobandamwer/native-helper (GHSA-g457-v22r-g8j3, all versions) and @iobandamwer/cache-helper@0.0.0-stage, 1.0.2, 1.0.3, 1.0.4, 1.0.5, 1.0.6, 1.0.7, 1.0.8, 1.0.9, 1.1.0, 1.1.1, 1.1.2, 1.1.3 (GHSA-j83w-xhgf-7m58). GHSAs advisories are CWE-506 boilerplate - no runtime analysis published at advisory time. The scope name @iobandamwer reads as a construction built around the string band-malware with the - elided (iob + and-amwer ≈ and-malware) which, together with the two helper-named lures native-helper and cache-helper that span 13 versions over the staging-to-1.1.3 range, suggests an operator building a lure brand with multiple pre-staged versions. Severity medium per cluster (CWE-506 only, no captured payload at advisory time; the 13-version iteration pattern on cache-helper is unusual for a drive-by typosquat and warrants hunting for the install-time behaviour)
  • Cluster F - PyPI kam193 pentest singles (dependency-confusion / malicious-package mix; 2 packages, 2026-10-26, OSSF PROBABLY_PENTEST): zagents-framework@6.25.30.10b5, 99.25.30.10b5 (GHSA-vqh8-gjqw-v2r3, OSSF MAL-2026-18327, campaign GENERIC-standard-pypi-install-pentest, kam193 commit d16d137f59725b57a8d4dfbb6c9e5b88a07e1bf4fac71faf28e044208a21bccd) - sibling of yesterdays zagents-message-bus@1.0.5/1.0.10/99.99.99/99.99.100 (MAL-2026-18296) under the same zagents- operator family; the sentinel version 99.25.30.10b5 is the dep-confusion-ready version while 6.25.30.10b5 is a plausible-looking release-candidate that could pass casual review; overrides setup.py install command, exfiltrates basic host fingerprint only, no further payload captured. changes-lxc-wrapper@0.0.0, 0.1.0 (GHSA-3rm9-gfp2-hphh, OSSF MAL-2026-18326, campaign GENERIC-standard-pypi-install-pentest, kam193 commit 6db4cc796d2ddd54fcbb0a46270cff980f711a93a5fff30675499291d9bc41f8) - a dep-confusion probe at the typical 0.0.0/0.1.0 sentinel versions, same GENERIC-standard-pypi-install-pentest` kam193 template, exfiltrates basic host info only. Severity medium (OSSF PROBABLY_PENTEST, no payload beyond fingerprint exfil; the `zagents- operator continuity between yesterdays zagents-message-bus and todays zagents-framework suggests the operator is iterating slugs around a target orgs internal registry naming - treat as a targeted dep-confusion probe for anyone with an internal zagents-* namespace)
  • Cluster G - npm miscellaneous CWE-506 boilerplate takedowns (malicious-package; ~6 packages, 2026-10-26, no vendor runtime analysis): ctf-agent@0.1.0 (GHSA-2j3v-rjgw-5wgg - note the name typosquats a plausible "CTF agent" tool category a security-researcher or AI-agent developer could reach for), @worca/app@1.14.0-rc.2, 1.14.0-rc.4 (GHSA-rmc5-cxrx-5fh9 - RC-only publish, scope @worca has no legitimate established packages), postcss-semantic-themes (GHSA-fh55-fq5h-h352, all versions - PostCSS plugin lookalike), birch-css-utils (GHSA-p597-2ggw-c82r, all versions), harlow-css-mixer (GHSA-j658-c56g-qxh4, all versions). All five are CWE-506 boilerplate without vendor runtime payload analysis; three of them (postcss-semantic-themes, birch-css-utils, harlow-css-mixer) continue the "CSS-utility lure" naming pattern thats been running in the GHSA feed since the 2026-10-26 Cluster H long tail. **Severity medium** (CWE-506 boilerplate takedowns without published vendor payload analysis; ctf-agent` and the CSS-utility slugs read as plausible lures a developer could install from a snippet or AI-assistant suggestion)
  • Operator continuity: @sudobility XMRig cluster resurfaces - the operator paused for 5 days after the 2026-10-22 initial 4-package @sudobility/* wave and returns on 2026-10-26 under two new npm identities (walknpm publishing @walknpm/todo-cli@2.0.1 + dsh-plugin-blender-3d@0.2.1) with byte-identical scripts/miner.sh to the 2026-10-22 @sudobility/testomniac_client MAL-2026-18129 payload, same networkservicesupp.flashhub.net:8443 Monero pool, same S3 presigned URL staging pattern. This is the first confirmed wave-2 of the campaign; expect further waves under rotating scopes/identities while the pool endpoint stays stable - the pool apex is the sharp IOC, the slugs are rotating cover. kam193 cadence - continues with 3 campaigns today: 2026-10-netweavex (new, NetworkX typosquat with import-time GitHub-RCE), GENERIC-standard-pypi-install-pentest adds zagents-framework + changes-lxc-wrapper, and the 2026-09-donutautosellsrc + 2026-10-nebulallm + 2026-10-dictmerge-lite + 2026-10-fontus campaigns from the 2026-10-26 sweep appear idle today (no new matching slugs flagged 2026-10-26 after the sweep cut-off); the 2026-10-voice-synthesis-profiles large wave remains dormant since 2026-10-23. testmetest operator sibling - path-stream-utils-testmetest follows yesterdays event-bus-lite-testmetest under the same slug suffix pattern. **wiseke npm operator** (yesterdays 14-package @greenlake/@sxm-web/@drone-js-ext/@ppa-web-components dep-confusion scope sweep to 185.158.107.175:8787/_ah/dc) is idle today. s4yhii npm pentest operator (yesterdays 10-package @s4yhiitestpoc/r2-/scan- POC batch) is idle today. The @iobandamwer scope is a new, previously-unseen operator worth watching for wave 2. The publish-poc-base/publish-poc-test3 operator is a new worm-POC operator - Amazon Inspector flagged both within the same day, suggesting an active probing session rather than a long-term lure. Carve-outs [LiteLLM 1.107.0](/incident/pypi-2026-10-21-litellm-infostealer-rat), [Tailwind Animate.css fake-interview](/incident/npm-2026-10-20-tailwind-animatecss-fake-interview-campaign), [Apex Accelerator REF8801](/incident/npm-2026-10-19-apex-accelerator-malicious-npm-packages), [TensorLake AI](/incident/npm-2026-10-08-tensorlake-maintainer-compromise), [hridoy FB credential stealer](/incident/npm-2026-10-12-hridoy-ultimate-fb-credential-stealer), [anthropic-sdk PyPI typosquat](/incident/pypi-2026-10-05-anthropic-sdk-typosquat), [claudeopus* 2026-09-donutautosellsrc](/incident/multi-2026-10-26-ghsa-malware-sweep) all remain confirmed-recovered with no wave-2 malicious republish observed - PyPI quarantine of litellm 1.107.0 holds, no new anthropic-prefix or claudeopus* typosquats observed today beyond yesterdays cluster
What to do

Clean-up steps

  1. For Cluster A (@sudobility XMRig wave 2 - @walknpm/todo-cli + dsh-plugin-blender-3d, CONFIRMED payload): grep every package.json, package-lock.json, pnpm-lock.yaml, yarn.lock, bun.lock, container image manifest, and internal registry mirror for @walknpm/todo-cli@2.0.1, dsh-plugin-blender-3d@0.2.1, and - preemptively - the full @walknpm/* scope and the dsh-plugin-* npm prefix (the operator is iterating scopes). On any hit on a Linux host that ran npm install: treat the host as compromised. Hunt for the drop and persistence artefacts shared with the 2026-10-22 @sudobility wave: /tmp/.smh (todays drop path - note the different suffix from 2026-10-22s /tmp/.smi, so grep for both), $HOME/.sysmond.json, $HOME/.local/lib/ entries under disguised system-service names (edid-mon, smmon, irqstatsd, kmod-cache), any nohup child under those names, unexpected cron entries, and - on root-sudo hosts - any new Tor relay process or systemd unit. Egress block: networkservicesupp.flashhub.net:8443 on every host (the Monero pool is the sharp IOC across the campaign - the slugs rotate, the pool does not). Also keep blocking egress to the s3.amazonaws.com presigned-URL path pattern the installer uses. Any @walknpm/*, @sudobility/*, or dsh-plugin-* slug under any version is suspect by default. Rotate npm tokens and SSH keys of any CI runner that installed either package. Rebuild rather than clean
  2. For Cluster B (publish-poc-base@1.0.7 + publish-poc-test3@1.0.15/1.0.18/1.0.19/1.0.21/1.0.22/1.0.26/1.0.27 npm worm-POC): grep every package.json, package-lock.json, yarn.lock, pnpm-lock.yaml, Dockerfile, and container image manifest for publish-poc-base and publish-poc-test3. On any hit on a host that ran npm install and had an npm token in scope (CI runners, developer workstations with ~/.npmrc populated): assume the tokens identity may have published a publish-poc-found-<random> package under its own namespace. Audit npm search publish-poc-found- and the npm users publish history for the exposure window. On npm tokens: rotate every token on any host that installed either package (even if 1.0.7 of publish-poc-base was the only version, since 1.0.7 ships an embedded registry token that is readable by anyone who inspects the package tarball). On the staging path: hunt /tmp/publish-poc-found-* directories for leftover artefacts. Add publish-poc-* to the npm denylist. Keep a short-term alert on new npm publishes with the publish-poc-found- name prefix: those would indicate the credential-reuse publish logic has fired in a real environment
  3. For Cluster C (netweavex@1.1.0/1.1.1/1.1.2 PyPI NetworkX typosquat with import-time GitHub-hosted RCE): grep every requirements.txt, pyproject.toml, Pipfile.lock, poetry.lock, uv.lock, pdm.lock, conda env.yml, every internal PyPI mirror, every Dockerfile, and every data-science / graph-analysis / ML repo for the literal strings netweavex and from netweavex. The legitimate package is networkx (the import is import networkx as nx). On any hit: treat the host as fully compromised (import-time exec() of a reversed-base64-zlib payload that downloads and runs code from api.github.com/repos/jerryjohnston91/helper-library/zipball/main - the GitHub repo is 404 today but the exec happened at install/import time). Rotate: all host-stored secrets (SSH keys, cloud credentials, browser-stored passwords, developer-tool credentials). Block egress to api.github.com/repos/jerryjohnston91/* and codeload.github.com/jerryjohnston91/* on CI/build hosts. Hunt wheel/tarball hashes: netweavex-1.1.2-py3-none-any.whl SHA-256 ddc8043036875be0fffdfbf8302f1a77519554a0b07aae0d093cd0418b683026, netweavex-1.1.2.tar.gz SHA-256 5d84d4e4da39bf25cd67f4593ac3e2c4ef2ea3733e6f203cb705a9c2f77a0599. Add netweavex, networkxx, net-workx, networkx-util as adjacent-guess PyPI denylist entries (the operator is typosquatting a top-tier library)
  4. For Cluster D (path-stream-utils-testmetest npm, sibling of 2026-10-26 Bun-runtime loader): grep every npm manifest for path-stream-utils-testmetest and path-stream-utils-* more broadly, and - carrying forward from the 2026-10-26 Cluster B recommendation - event-bus-lite-testmetest and event-bus-lite-*. Alert when ANY package in the dependency tree ships both a binding.gyp and a bundled .dat / .bin file over 100 KB (the TanStack-TTP family loader signature from yesterdays event-bus-lite-testmetest@0.0.6 payload hash SHA-256 e1ab1e330d3db532d511d4af4386ab2d2c6245ca807410f51c1211ae48814d73). On any hit: hunt for .b-*/ temporary directories under node_modules/<pkg>/`, hunt for the Bun runtime binary on hosts that do not normally use Bun, and rebuild from a clean npm registry mirror
  5. *For Cluster E (`@iobandamwer/ novel scope - native-helper + cache-helper)**: grep every npm manifest for the @iobandamwer/ scope prefix. The scope has no legitimate published history and the 13-version iteration pattern on cache-helper (0.0.0-stage, 1.0.2 through 1.1.3) suggests an operator pre-staging a lure before activation; treat any install as suspicious even though the GHSA advisory text is CWE-506 boilerplate without captured payload. Audit node_modules/@iobandamwer/<pkg>/ for postinstall scripts and bundled binary files; rebuild from a clean mirror. Add @iobandamwer/*` to the npm scope denylist
  6. For Cluster F (PyPI kam193 pentest singles - zagents-framework + changes-lxc-wrapper): grep every PyPI manifest and internal mirror for zagents-framework==6.25.30.10b5, zagents-framework==99.25.30.10b5, changes-lxc-wrapper==0.0.0, changes-lxc-wrapper==0.1.0. The zagents-* namespace carries forward from yesterdays zagents-message-bus sibling, so any org with an internal zagents- namespace should treat this as a confirmed dep-confusion probe against its internal registry. On any hit: audit the internal-registry resolution path, confirm the public PyPI registry is not the fallback, and treat the install host as a probe-successful target (host fingerprint exfiltrated at minimum). The changes-lxc-wrapper naming impersonates the LXC containerisation ecosystem; alert any infra-team repo that reaches for container-tooling helpers. Add zagents-framework, zagents-, changes-lxc-wrapper` to the PyPI denylist
  7. For Cluster G (npm miscellaneous CWE-506 boilerplate - ctf-agent, @worca/app, postcss-semantic-themes, birch-css-utils, harlow-css-mixer): grep every npm manifest for ctf-agent, @worca/app, postcss-semantic-themes, birch-css-utils, harlow-css-mixer. ctf-agent specifically warrants an alert if any CTF-tooling or AI-agent repo introduced it (the name reads like a legitimate CTF-automation helper a researcher could reach for from a snippet). The CSS-utility names (postcss-semantic-themes, birch-css-utils, harlow-css-mixer) continue yesterdays CSS-utility lure pattern; treat any install as suspicious even though no vendor runtime analysis is published. On hit: remove the package, audit any postinstall script that ran, rebuild from a clean mirror, and alert the developer who introduced the dependency so the operators lure name is retired from internal docs / AI-assistant snippets
  8. Standing egress-denylist carry-forward from prior sweeps (keep in place; todays wave 2 of the @sudobility XMRig cluster re-sharpens the networkservicesupp.flashhub.net:8443 Monero pool apex as the primary IOC): continue to block networkservicesupp.flashhub.net:8443 (2026-10-22 @sudobility + todays @walknpm/dsh-plugin-* Monero pool - the pool is now confirmed persistent across two waves 5 days apart), api.github.com/repos/jerryjohnston91/* + codeload.github.com/jerryjohnston91/* (todays Cluster C netweavex import-time RCE source), c2-worker.crawlnet-claim.workers.dev apex + /dl/pyupd path, 34.143.131.27:18080 + /x-VA-1/main.js path, webhook.site/553dad0e-c841-46a8-b07d-213b52a24686/ (2026-10-21 rs-lookout-sandbox-poc AWS IMDS exfil), 75.119.137.232:31337 + /depconfuse path (2026-10-20), transfer.archivete.am apex + /H2Uxm/fabdeploycheck-config.json path (2026-10-19), realwbx.com apex + /ip.php + /ip paths, artifacts.creditslib.com apex + /npm/ paths, login.fromthehotel.com apex, googleforum.pythonanywhere.com, space-z.ai apex, dxpoc.gt.tc apex, raw.githubusercontent.com/anonrider404/pypl/, api-bsx.pages.dev + /download, 177.7.60.239:48080 + oob.recon.dev, uncoder.eu.org + /cc-checker/api.php, accenture-npm.azurewebsites.net, limbomail.com, collector.oob.s4yhii.com + .oob.s4yhii.com + s4yhii.com, 64.181.165.115/dc, 167.88.172.33:8087 + jsonspack.com, goxtools.shop, minhdong.site, 45.138.12.177:8089, 185.158.107.175:8787 (yesterdays wiseke dep-confusion beacon - stays sharp), ltidi.storage.googleapis.com/depenconf/, oob.s4yhii.com:9999/native, `.oast.pro/.oast.me/.oast.fun/.oast.site/.oastify.com, frjmzbjbhwvtdnsuodmu.supabase.co, api.npoint.io, tele.metry.orgin.net, morroncr0w.io, api.telegram.org on untrusted CI/build hosts, appsecc.com, generic webhook.site/ paths other than legitimate dev webhooks, nfjbill.ren, storage.googleapis.com/depenconf/, 10.0.19.0/24 + 10.0.49.0/24, api.nm-streetwear.space, Discord webhook URL patterns, ipify.org + ifconfig.me, gitflic.ru, api.wagmiwallet.org, backend-cybersecuritydashboard.onrender.com, Monero mining pools, Ethereum/Sepolia/Arbitrum/Polygon RPC endpoints (Polygon RPC specifically continues to be blocked - the 2026-10-26 Cluster A claudeopus steganography infostealer still uses Polygon transaction history as its C2 pointer, so Polygon egress from CI/build hosts stays blocked), chinazhangsan.ccwu.cc, fabric-npm.gm-service.xyz, jsonkeeper.com, npm-canary.aveliscare.com, meta.brs.cx, s3://pkusinski-external/, AWS account 631484165566, Slack bot-token exfil patterns, s85r5k14qk.execute-api.us-east-1.amazonaws.com/prod/hook, tuamaeaquelaursa.com, 45.138.0.0/16 RubyGems wgkit CIDRs, apexaccs.org apex + subdomains, arenapex.cloud, apexfdn.xyz apex + subdomains, fdn4apex.com, router-apex.com apex + subdomains, ccmihr.com, 0auth-chromium.com, ehegisnightmare.icu, cloudmain365duo.top, www.litellm.dev/healthcheck, raw.githubusercontent.com/letters9813/pythonclient-test/main/domain.txt, known SSH relay services srv.us, .devtunnels.ms, .devtunnels.visualstudio.com on build/CI networks, *.ngrok-free.dev/canary (yesterdays react-native-bright-sdk@9000.0.0 preinstall beacon). New-sharp today for Cluster C: GitHub-hosted payload path api.github.com/repos/jerryjohnston91/helper-library/zipball/main + codeload.github.com/jerryjohnston91/helper-library/legacy.zip/refs/heads/main - alert on any CI/build host that fetches a zipball/main or legacy.zip from an operator-controlled GitHub user namespace
References

Sources

multi-2026-10-27-ghsa-malware-sweepBack to incidentsSubmit a correction
Am I affected?

Check your lockfile against this and every other incident.

Paste a lockfile and it is matched on your own device against every compromised version we track. Nothing is uploaded and there is no account.

Check your package-lock.jsonAll incidents