DependencyWatch.io
Talk to PrecursorScan a lockfile

GitHub Advisory malware sweep, 24 October 2026

HighAdvisory sweepnpmPyPI

GHSA 2026-10-23/24 batch (~28 advisories). Headlines: PyPI 2026-10-voice-synthesis-profiles wave 2 (21 kam193-tracked loader packages continuing yesterdays 43-pkg campaign); PyPI sitecard kam193 SSH-tunnel backdoor (13 versions, lure masquerading as a dev-workspace SSH access tool, "session reported to a hardcoded location"); npm @k18k/entrypoint-sdk- platform-binary cluster (3 OS variants under a plausible-sounding "tunnel gateway SDK" lure); and single-slug npm platform-binary droppers under orqiva-runtime-, overarch-windows-x64-yr, @liauto/win32-x64`.

Published 24 Oct 2026

Check your package-lock.jsonSource advisory
At a glancemulti-2026-10-24-ghsa-malware-sweep
28
Packages tracked45 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
24 Oct 2026
Ecosystems
npmPyPI
Threat actor
kam193-tracked operator (campaigns 2026-10-voice-synthesis-profiles, 2026-10-sitecard)
Detected by
GitHub Advisory Database, OpenSSF malicious-packages, kam193 bad-packages
Also known as
2026-10-24 GHSA sweep, 2026-10-voice-synthesis-profiles wave 2, 2026-10-sitecard kam193 SSH-tunnel backdoor

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-23 06:00 UTC (yesterdays sweep cut-off) and 2026-10-24 06:00 UTC (todays ingest-window start), the GitHub Advisory Database published ~28 fresh malware advisories across PyPI and npm. Todays batch is dominated by a 21-package day-2 continuation of the kam193 2026-10-voice-synthesis-profiles PyPI loader campaign and a confirmed-payload SSH-tunnel backdoor PyPI lure (sitecard, 13 versions). The npm side is quieter: three OS-specific sub-packages under a self-described "tunnel gateway" SDK (@k18k/entrypoint-sdk-*`), plus three single-slug scoped Windows-binary droppers under plausible "AI platform" / "unofficial Chinese-EV CLI" brand lures.

Headlines

PyPI 2026-10-voice-synthesis-profiles wave 2 (Cluster A, 21 packages): day-2 of the kam193 loader campaign opened on 2026-10-22. The slug-generator dictionary rotated between day 1 (ttsdock, voicekit, voxweaver, ttsprobe + 43 others) and day 2 (worker/queue/task/load/pier/haul suffixes - flintqueue, juniperrun, larchworker, etc.), but the campaign tag persists and the loader behaviour is identical: setup.py or the package body downloads and executes a remote script at install time, with no in-package payload.

PyPI sitecard SSH-tunnel backdoor (Cluster B, 1 package / 13 versions): a plausible-sounding "temporary SSH access cards for development sites and workspaces" dev tool, with a reputation-building 0.1.0 through 0.1.14 release history ending 2026-10-18, flagged by kam193 and OSSF on 2026-10-23. OSSFs payload summary is explicit: the package creates an unauthenticated SSH session exposed through a tunnel relay and beacons the session endpoint to a hardcoded operator location. This is a direct remote-access primitive, not a defer-to-later loader. Classification: malicious-package (lure from first publish), severity high`.

*npm `@k18k/entrypoint-sdk- platform-binary tunnel-gateway lure** (Cluster C, 3 OS variants at 0.2.0/0.2.1): the parent SDK is still live on the registry at 0.2.1 and advertises itself as a "Node.js SDK that connects a local application to an Entrypoint gateway through a tunnel" with adapters for node:http, Fastify, and Hono. The three sibling platform-binary sub-packages (darwin-arm64, darwin-x64, linux-x64) are each flagged with CWE-506. The "tunnel gateway" framing is a textbook C2 reverse-tunnel primitive and the pattern-match to yesterdays @pkgship/frp[c|s]-linux-amd64 reverse-proxy droppers is near-exact.

npm overarch-windows-x64-yr + @liauto/win32-x64 + orqiva-runtime-win32-x64 (Cluster D, 3 scoped single-slug Windows x64 platform binaries): plausible-looking parent lures (overarch publishes as an "Autonomous AI Software Engineering Platform", @liauto/cli as an "Unofficial CLI for LiAuto/LiXiang vehicles"), each pulling an OS-specific native binary that GHSA flagged as embedded malicious code. orqiva-runtime is a standalone orphan without a parent in the registry.

Classification

sweep. Severity high (upgraded from the sweep baseline medium) because Cluster A continues a confirmed remote-code loader campaign, Cluster B carries a confirmed unauthenticated-SSH-exposure backdoor, and Cluster C carries bundled native binaries behind a tunnel-gateway lure. Cluster D is medium. No cluster reaches critical - all are lures, loaders, or platform-binary droppers for packages with no legitimate established dependents.

Discovery

GitHub Advisory Database, OpenSSF malicious-packages (Cluster A + B representative sources), kam193 bad-packages (campaign tags 2026-10-voice-synthesis-profiles and 2026-10-sitecard).

typosquatmaintainer-takeovercredential-theftobfuscationdns-exfiltration
Affected packages

28 packages 45 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 - PyPI 2026-10-voice-synthesis-profiles wave 2 (malicious-package; 21 kam193-tracked loader packages all 0.1.0, all published 2026-10-23; the GHSA records uniformly state "Downloads and executes a remote malicious script" with no captured payload - the loader fetches the actual code at install time from a remote URL, so the install hosts outbound DNS/HTTP log is the primary evidence surface; same OSSF MALICIOUS` + CWE-506 classification as the 2026-10-22 wave 1 cluster, confirming continued operator cadence): flintqueue@0.1.0 (GHSA-5wvh-v7gw-jq6x), juniperrun@0.1.0 (GHSA-c47g-m8f4-2x58), larchworker@0.1.0 (GHSA-jw6c-mfj3-856p), cobbleload@0.1.0 (GHSA-hcm3-q2fr-q9gp), sedgehaul@0.1.0 (GHSA-rh3j-52jm-8f52), jobwharf@0.1.0 (GHSA-38vx-x27v-x869), marshrunner@0.1.0 (GHSA-hp4v-c7rq-5vf9), ferretqueue@0.1.0 (GHSA-hq73-fx2j-79q2), loadferry@0.1.0 (GHSA-8r2g-p8j9-xg33), brambletask@0.1.0 (GHSA-m799-pwxv-jwc5), reedworker@0.1.0 (GHSA-r9rp-cwq6-9q24), runpier@0.1.0 (GHSA-rfx9-3g43-jfm5), slatejob@0.1.0 (GHSA-q5q5-m7hc-2f2w), otterload@0.1.0 (GHSA-pq46-67wf-pfgj), kestreljob@0.1.0 (GHSA-89w7-f367-29w4), thornqueue@0.1.0 (GHSA-529c-8cpg-cghq), workslip@0.1.0 (GHSA-fh28-g9hg-7pvr), thistlerun@0.1.0 (GHSA-c2x8-63g6-vfhv), taskquay@0.1.0 (GHSA-7q8j-w7hr-738m), badgertask@0.1.0 (GHSA-q5pw-gcmm-56cx), brookworker@0.1.0 (GHSA-474w-43pc-7p69). Severity high for this cluster (confirmed remote-code loader behaviour in a coordinated campaign, limited reach because nothing legitimate depends on these names)
  • Cluster B - PyPI sitecard kam193 SSH-tunnel backdoor (malicious-package; 1 package, 13 versions 0.1.0..0.1.14 skipping 0.1.4/0.1.5, published 2026-10-23 as GHSA-9wjg-8fcv-pxj2, OSSF MAL-2026-18242, kam193 source hash 49be8995374d0e3d2bcb8f163675221e14bfb6d7d968a6fa5d8165e4f493997d, campaign tag 2026-10-sitecard, reason "backdoor"; the PyPI project page describes sitecard as a dev-tool that "Issue[s] temporary SSH access cards for development sites and workspaces" - a plausible-sounding lure - and the OSSF advisory`s payload summary is explicit: "created session is accessible without any auth and reported to a hardcoded location", i.e. an unauthenticated SSH session exposed through a tunnel relay and the session metadata beaconed to the operator; the 13-version release train 0.1.0 through 0.1.14 across days predating the Oct 23 flag indicates the package was reputation-building as a plausible devtools utility before being disclosed, so some real users of the lure DID exist): sitecard versions 0.1.0, 0.1.1, 0.1.2, 0.1.3, 0.1.6, 0.1.7, 0.1.8, 0.1.9, 0.1.10, 0.1.11, 0.1.12, 0.1.13, 0.1.14. Severity high for this cluster (confirmed unauthenticated-SSH-exposure + hardcoded-C2-beacon backdoor; the SSH-tunnel exposure is a direct remote-access primitive, not a defer-to-later loader)
  • *Cluster C - npm `@k18k/entrypoint-sdk- platform-binary tunnel-gateway lure (malicious-package; 3 OS-specific platform packages 0.2.0, 0.2.1, all 2026-10-23, all CWE-506; the parent SDK @k18k/entrypoint-sdk is still live on the npm registry at 0.2.1 and advertises itself as a "Node.js SDK that connects a local application to an Entrypoint gateway through a tunnel" with adapters for node:http, Fastify, and Hono - a self-described "tunnel gateway" SDK that resolves OS-specific binary dependencies at install time; the three sibling platform-binary sub-packages were each flagged by GHSA as embedded malicious code, so the parent SDK is effectively a wrapper that pulls malware for whatever host OS/arch its user is on; the "tunnel gateway" framing is a canonical C2 reverse-tunnel primitive and the matching Shai-Hulud / @or-sdk / @pkgship/frp operator pattern)**: @k18k/entrypoint-sdk-darwin-arm64@0.2.0, 0.2.1 (GHSA-8wf7-8825-99q7), @k18k/entrypoint-sdk-darwin-x64@0.2.0, 0.2.1 (GHSA-j58m-rwhr-923h), @k18k/entrypoint-sdk-linux-x64@0.2.0, 0.2.1 (GHSA-9fhg-r3w6-g7r4). Severity high` for this cluster (bundled native binaries + self-described tunnel-gateway behaviour = reverse-tunnel staging primitive)
  • Cluster D - npm single-slug scoped platform-binary droppers (malicious-package; 3 packages across 2026-10-23 and 2026-10-24, all CWE-506 boilerplate, no vendor runtime payload analysis available; two of the three parent slugs are plausible-looking lures - overarch publishes itself as "Autonomous AI Software Engineering Platform, D-HFR Mesh, Full-Screen Dark TUI" author "Yatharth Roy / The Thursday AI Company of New Delhi" and @liauto/cli publishes itself as an "Unofficial CLI for LiAuto/LiXiang vehicles" by maintainer licli on a random stun.coldest8b@icloud.com iCloud address, both reading as plausible AI-platform / Chinese-EV-SDK brand lures that would receive developer trust by name alone; the orqiva-runtime parent does not exist in the npm registry, so orqiva-runtime-win32-x64 is a standalone slug not tied to any parent package): orqiva-runtime-win32-x64@0.1.0 (GHSA-8j59-g9mq-7hf9, 2026-10-23, orphan platform-binary slug), overarch-windows-x64-yr@1.4.0, 1.5.0, 2.0.0 (GHSA-v5v8-j5gm-pq8v, 2026-10-24, Windows x64 CLI platform binary with bin: Overarch.exe entry, parent overarch@2.0.0 is live on the registry as an "Autonomous AI Software Engineering Platform" lure), @liauto/win32-x64@0.1.2-b2 (GHSA-32x9-4g9x-5cxj, 2026-10-24, win32-only x64-only package described as "Native binary for licli (windows x64)", parent @liauto/cli@0.1.2-b2 is live on the registry as an "Unofficial CLI for LiAuto/LiXiang vehicles" lure). Severity medium for this cluster (CWE-506 boilerplate advisories without vendor runtime analysis; parent lures appear plausible but the install-time runtime behaviour is uncaptured)
  • Operator continuity: kam193 continues the 2026-10-voice-synthesis-profiles family into a second day on PyPI (21 new 0.1.0 loader slugs 2026-10-23 adding to the 43-pkg 2026-10-22 wave, so the total catalogued pool is now ~64 packages across two days). The slug naming pattern has shifted from the Oct 22 TTS/voice-pun names (ttsdock, voicekit, voxweaver, ttsprobe) to generic worker/queue/task/load/pier/haul suffixes (flintqueue, juniperrun, larchworker, cobbleload, sedgehaul, jobwharf, marshrunner, ferretqueue, loadferry, brambletask, reedworker, runpier, slatejob, otterload, kestreljob, thornqueue, workslip, thistlerun, taskquay, badgertask, brookworker), suggesting the operator rotated its slug-generator dictionary between days to defeat prefix-based blocklists; the TTS-themed campaign tag 2026-10-voice-synthesis-profiles persists even though the day-2 slugs no longer carry voice-themed vocabulary. The 2026-10-journey-test-helloshell + journey-teste-shellhello kam193 reverse-shell family from Oct 22-23 appears idle today - no new journey* slugs flagged in the Oct 23/24 window. No new activity today from yesterdays @ecg-internal/ or @grabcad/ dep-confusion probe clusters (operator cadence suggests those were a single-day burst). No new activity from the 2026-10-22 @pkgship/frp[c|s]-linux-amd64 reverse-proxy binary drop - todays Cluster C @k18k/entrypoint-sdk-* fills the same "self-described tunnel gateway + bundled OS-specific binary" niche with a different scope. Carve-outs LiteLLM 1.107.0, Tailwind Animate.css fake-interview, Apex Accelerator REF8801, TensorLake AI, hridoy FB credential stealer all remain confirmed-recovered with no wave-2 malicious republish observed (verified by GHSA search on each operator name - no new advisories after their respective incident dates)
What to do

Clean-up steps

  1. For Cluster A (2026-10-voice-synthesis-profiles wave 2, 21 PyPI loader packages 0.1.0): grep every requirements.txt, pyproject.toml, Pipfile.lock, poetry.lock, uv.lock, pdm.lock, every conda env.yml, and every internal PyPI mirror for the following version-pinned slugs: flintqueue==0.1.0, juniperrun==0.1.0, larchworker==0.1.0, cobbleload==0.1.0, sedgehaul==0.1.0, jobwharf==0.1.0, marshrunner==0.1.0, ferretqueue==0.1.0, loadferry==0.1.0, brambletask==0.1.0, reedworker==0.1.0, runpier==0.1.0, slatejob==0.1.0, otterload==0.1.0, kestreljob==0.1.0, thornqueue==0.1.0, workslip==0.1.0, thistlerun==0.1.0, taskquay==0.1.0, badgertask==0.1.0, brookworker==0.1.0. On any hit on any Python environment on any host that ran pip install since 2026-10-23: treat the host as compromised (the loader fetches and runs remote code during install, so the fetched payload - whatever it was - executed in the install users security context). Rotate every environment-variable-sourced secret, every CI token, every cloud credential visible to the install process, and every private-key path reachable from the install users shell. Audit outbound DNS/HTTP from the install window to identify the remote script URL for IOC enrichment. Add the full day-1 (ttsdock/voicekit/voxweaver/ttsprobe + the 43 Oct-22 slugs) and day-2 (todays 21 slugs) kam193` 2026-10-voice-synthesis-profiles cohort to your public-PyPI denylist; the operator pattern suggests another dictionary rotation in 24-48h, so keep the kam193 campaign tag as a monitoring filter rather than enumerating slugs
  2. For Cluster B (sitecard PyPI SSH-tunnel backdoor, 13 versions): grep every requirements.txt, pyproject.toml, Pipfile.lock, poetry.lock, uv.lock, pdm.lock, every conda env.yml, every internal PyPI mirror, AND every running Python environment (not just install manifests) for ANY version of sitecard - specifically 0.1.0, 0.1.1, 0.1.2, 0.1.3, 0.1.6, 0.1.7, 0.1.8, 0.1.9, 0.1.10, 0.1.11, 0.1.12, 0.1.13, 0.1.14. On any hit on any host: treat the host as actively tunnelled (the payload opens an unauthenticated SSH session exposed through a tunnel relay and beacons the session endpoint to the operators hardcoded location, so any attacker who has the endpoint URL from the operators side can walk straight into a shell). Immediately kill any running sshd, SSH tunnel, devtunnel, srv.us relay, or Microsoft Dev Tunnels process on the host; audit any ~/.ssh/authorized_keys and ~/.ssh/known_hosts for unknown entries added since the sitecard install window; audit outbound TCP on 22, 443, and any ephemeral egress to known SSH relay services (srv.us, *.devtunnels.ms, *.devtunnels.visualstudio.com); rotate every SSH key on the host from a different machine; rebuild the host rather than attempt in-place cleanup. Add sitecard (all versions) to your public-PyPI denylist and the kam193 2026-10-sitecard campaign tag to your monitoring filter
  3. *For Cluster C (`@k18k/entrypoint-sdk- platform-binary tunnel-gateway lure, 3 npm sub-packages)**: grep every package.json, lockfile, and container image manifest for @k18k/entrypoint-sdk, @k18k/entrypoint-sdk-darwin-arm64, @k18k/entrypoint-sdk-darwin-x64, @k18k/entrypoint-sdk-linux-x64 at any version. On any hit on any Darwin/Linux host that ran npm install / pnpm install / yarn install since 2026-10-23: treat the host as a candidate reverse-tunnel implant (the "entrypoint gateway" framing is operationally equivalent to the frp server/client pair caught yesterday). Hunt for post-install native binaries dropped under node_modules/@k18k/entrypoint-sdk-*/; check for persistent outbound TCP connections to unknown hosts on persistent reconnect patterns; audit any launchd plists (Darwin) or systemd` user units (Linux) created since the install window. Rotate secrets from a different machine; rebuild the host
  4. For Cluster D (orqiva-runtime-win32-x64, overarch-windows-x64-yr, @liauto/win32-x64 scoped single-slug platform-binary droppers): grep every package.json and lockfile for orqiva-runtime-win32-x64, overarch-windows-x64-yr, overarch (parent lure), @liauto/win32-x64, @liauto/cli (parent lure), and licli (maintainer handle). On any Windows x64 build host, CI runner, or developer workstation that resolved any of these: treat the .exe binary dropped by overarch-windows-x64-yr (via the bin: Overarch.exe entry) or the licli native binary (via @liauto/win32-x64) as a candidate implant - run full AV/EDR scanning, hunt for persistence artefacts in Scheduled Tasks, Run keys, Startup folder, and Services, and rebuild the host rather than attempt in-place cleanup. If you deployed any "AI software engineering platform" tooling under the overarch brand name from npm since 2026-10-24, OR any "LiAuto/LiXiang CLI" tooling under @liauto/cli from npm since 2026-10-24, treat those as installed-malware artefacts
  5. Standing egress-denylist carry-forward from prior sweeps (keep in place; todays batch adds no new sharp network IOCs - all are CWE-506 boilerplate / kam193-tracked slugs with payload URLs still pending vendor extraction): continue to block networkservicesupp.flashhub.net:8443 (2026-10-22 @sudobility XMRig Monero pool), 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, 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, 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. New today for Cluster B: block known SSH relay services (srv.us, .devtunnels.ms, *.devtunnels.visualstudio.com`) on build/CI networks where no legitimate developer-tunnel use case exists
References

Sources

multi-2026-10-24-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