# GitHub Advisory malware sweep, 22 August 2026

> 13 new GHSA CWE-506 malware advisories in the 24h ending 2026-08-22. PyPI `requests-crypt` is the **fourth** variant of the `2026-08-reqcrypt` HTTP-response `exec()` register; `boto4` is a Telegram-bot-controlled miner + LAN worm. npm side: `lumen-pages-community`/`@gfe/lx-watcher` dep-confusion beacons, `fuel-react` env exfil, and a new JFrog/Lazarus rollup-family sibling.

- Published: 2026-08-22
- Severity: high
- Kind: 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.
- Ecosystems: npm, PyPI
- Scope: 11 packages, 30 compromised versions
- Tags: dependency-confusion, infostealer, credential-theft, typosquat, obfuscation, worm, ci-cd-compromise
- Also known as: 2026-08-22 GHSA sweep, requests-crypt 2026-08-reqcrypt variant 4, boto4 telegram-c2 miner worm, scrambleeer reverse shell, lumen-pages-community 9.9.9 dep-confusion, @gfe/lx-watcher webhook.site beacon, fuel-react env exfil, @postman-cse/okta-aio-linux-arm64 typosquat, rollup-packages-node-polyfills JFrog rollup sibling
- Detected by: GitHub Advisory Database, OpenSSF malicious-packages, OpenSSF Package Analysis
- Incident ID: multi-2026-08-22-ghsa-malware-sweep

## Affected packages (11)

Only the exact versions listed were named by the source advisories. Other versions are not implicated.

| Package | Ecosystem | Compromised versions |
|---|---|---|
| [@gfe/lx-watcher](https://dependencywatch.io/package/npm/@gfe/lx-watcher) | npm | 1.5.3, 1.5.4 |
| [@postman-cse/okta-aio-linux-arm64](https://dependencywatch.io/package/npm/@postman-cse/okta-aio-linux-arm64) | npm | 0.8.10, 0.8.11, 0.9.0, 0.9.1, 0.10.0, 0.10.1, 0.10.2, 0.10.3, 0.10.4, 0.10.5, 0.10.6, 0.10.7, 0.10.8, 0.10.9, 0.11.0, 0.11.1, 0.11.2, 0.11.3, 0.11.4, 0.11.5, 0.11.6 |
| [boto4](https://dependencywatch.io/package/pypi/boto4) | PyPI | 1.0.0, 1.0.2 |
| [fuel-react](https://dependencywatch.io/package/npm/fuel-react) | npm | 91.0.0 |
| [kelly-sizing](https://dependencywatch.io/package/npm/kelly-sizing) | npm |  |
| [lumen-pages-community](https://dependencywatch.io/package/npm/lumen-pages-community) | npm | 9.9.9 |
| [polymarket-trading-developer-tool](https://dependencywatch.io/package/npm/polymarket-trading-developer-tool) | npm |  |
| [requests-crypt](https://dependencywatch.io/package/pypi/requests-crypt) | PyPI | 0.1.0 |
| [rollup-packages-node-polyfills](https://dependencywatch.io/package/npm/rollup-packages-node-polyfills) | npm |  |
| [saas-f-testing](https://dependencywatch.io/package/npm/saas-f-testing) | npm |  |
| [scrambleeer](https://dependencywatch.io/package/pypi/scrambleeer) | PyPI | 0.1.0, 0.1.1 |

## What happened

The 24-hour window ending 2026-08-22 06:00 UTC published 10 new GHSA CWE-506 advisories on npm and 3 on PyPI. Highlights: the `2026-08-reqcrypt` HTTP-response backdoor campaign gained a fourth variant (now spelling `requests-crypt` in full), a wormable Telegram-C2 miner appeared under the AWS-adjacent `boto4` slug, and the JFrog/Lazarus rollup-polyfill impersonation register picked up a new `-node-polyfills` sibling. Two dependency-confusion beacons (`lumen-pages-community` and `@gfe/lx-watcher`) round out the day as reconnaissance primitives against organisations with matching private-scope names.

## Cluster A - PyPI `requests-crypt` fourth `2026-08-reqcrypt` variant (1 package)

| Package | Versions | GHSA | Campaign | Hash |
|---|---|---|---|---|
| `requests-crypt` | `0.1.0` | GHSA-cf52-hr54-m53p | 2026-08-reqcrypt | `eee14db4…b92b` |

The `2026-08-reqcrypt` campaign now has **four** tracked variants across four days:

- **2026-08-19** `reqcrypt@0.1.0` (folded into that day's sweep)
- **2026-08-20** `reqcrypt-dev@0.1.0` (folded into that day's sweep; hash `8e66755912…f3e4`)
- **2026-08-21** `reqcrypts@0.1.0-0.1.3` (folded into that day's sweep; hash `51643020…6c46`)
- **2026-08-22** `requests-crypt@0.1.0` (this file; hash `eee14db4…b92b`)

The payload shape is stable across all four variants: pose as a "requests wrapper", intercept HTTP responses, look for a specific field, `exec()` its contents. Only the package name and hash change. The name-rotation strategy has now expanded from suffix mutation (`-dev`, `s`) to **full-word prefixing** (`requests-crypt` instead of the abbreviated `reqcrypt`), showing the operator has moved past sequential takedowns and is running fresh dictionary variants. Expect a fifth republish within days (candidate names: `requests-crypto`, `crypt-requests`, `req-crypto`, `reqcrypt2`).

## Cluster B - PyPI `boto4` Telegram-C2 miner + worm (1 package)

| Package | Versions | GHSA | Campaign | Hash |
|---|---|---|---|---|
| `boto4` | `1.0.0, 1.0.2` | GHSA-ffh8-mpww-qp8g | 2026-08-boto4 | `b928f1f0…c0b2` |

The name `boto4` is the classic sequential-version typosquat of AWS `boto3` (the legitimate AWS SDK for Python). On install the package executes an embedded native executable that performs six behaviours: runs a **cryptominer**, exfiltrates IP address and username, establishes persistence, receives commands from a **Telegram bot** channel (C2 flows through `api.telegram.org`, which is difficult to block wholesale without disrupting real integrations), and **self-propagates worm-style across the local network**. The Telegram-bot C2 pattern is unusual for supply-chain malware and complicates network detection because Telegram is a legitimate service; the correlation lever is any build runner or non-developer host talking to `api.telegram.org` at all. The worm behaviour means one infected `pip install boto4` on a laptop or CI runner can spread to other hosts on the same L2 segment.

## Cluster C - PyPI `scrambleeer` reverse shell (1 package)

| Package | Versions | GHSA | Campaign | Hash |
|---|---|---|---|---|
| `scrambleeer` | `0.1.0, 0.1.1` | GHSA-jx7v-9c55-jw2v | 2026-08-scrambleeer | `52d5b1e9…9472` |

Standard reverse shell to a hardcoded destination. The typo pattern (`scrambleeer` with three `e`s) is too specific to be an organic typosquat catchment; more likely the operator is spraying a low-catchment name to see if OpenSSF flags it before pushing higher-visibility variants.

## Cluster D - npm `lumen-pages-community` v9.9.9 dependency-confusion (1 package)

| Package | Versions | GHSA | C2 | Hash |
|---|---|---|---|---|
| `lumen-pages-community` | `9.9.9` | GHSA-cf4g-g969-7qvx | `webhook.site/b00492c6-27ba-4ea0-a9cb-dd50b3770250/dc` | `b7c1d6b7…3808` |

The `9.9.9` version pin is the fingerprint of a **dependency-confusion probe**: a resolver misconfigured to prefer the highest available version across all configured registries will pick this public tarball over any lower-versioned internal `lumen-pages-community`. Postinstall runs `node dc.js`, harvesting hostname, username, CWD, platform, Node version, `CI` env var, and npm user-agent, and beacons them to a webhook.site collector. The metadata payload is deliberately **reconnaissance-shaped** - the operator is not stealing credentials, they are mapping which organisations use an internal `lumen-pages-community` name so a follow-up payload can be delivered to the confirmed catchments.

## Cluster E - npm `@gfe/lx-watcher` scoped dependency-confusion (1 package)

| Package | Versions | GHSA | C2 |
|---|---|---|---|
| `@gfe/lx-watcher` | `1.5.3, 1.5.4` | GHSA-7jmf-xqv3-ggfj | `webhook.site/df384ffa-1094-4bbf-a202-e8b345b3ed18/gfe` |

Same reconnaissance shape as Cluster D but with a **scoped** package name (`@gfe/*`) targeting whichever organisation runs a private `@gfe/*` scope. All three npm lifecycle hooks (preinstall, install, postinstall) fire the beacon, so `--ignore-scripts` is the mitigation. The main export is a **no-op `createWatcher` stub** - the package literally does nothing besides beacon, which is the cleanest possible signal for behavioural detection tooling.

## Cluster F - npm `fuel-react` postinstall env exfil (1 package)

| Package | Versions | GHSA | Hash |
|---|---|---|---|
| `fuel-react` | `91.0.0` | GHSA-77vr-cf3r-2v4w | `8e35f477…2c27` |

Standard postinstall env exfil - collects hostname and `process.env`, POSTs via HTTPS. The high version number (`91.0.0`) plus the React-adjacent name suggests either a name-collision typosquat of a legitimate `fuel-*` React binding, or another dependency-confusion probe. Any `.env`-sourced shell that ran `npm install` has leaked its full environment.

## Cluster G - npm `@postman-cse/okta-aio-linux-arm64` targeted Postman/Okta typosquat (1 package)

| Package | Versions | GHSA | Notes |
|---|---|---|---|
| `@postman-cse/okta-aio-linux-arm64` | `0.8.10-0.11.6` (~20 versions) | GHSA-h84r-259m-g3fg | No IOCs published; scope + platform-suffix specificity |

GHSA published no per-package IOC beyond the standard "considered fully compromised" boilerplate, but the naming is highly targeted: `@postman-cse` (Postman Customer Success Engineering?) + `okta-aio` (Okta All-In-One) + platform suffix `linux-arm64`. This is not a random dictionary pull - it targets a specific Postman internal build pipeline. Any Postman engineer with an internal `@postman-cse` scope should treat as an active dependency-confusion probe against their build infrastructure.

## Cluster H - npm `rollup-packages-node-polyfills` new JFrog / Lazarus rollup-family sibling (1 package)

| Package | Versions | GHSA | Attribution |
|---|---|---|---|
| `rollup-packages-node-polyfills` | `>=0` | GHSA-gp6f-mxh4-x3mh | Unverified in advisory; naming shape matches JFrog / Lazarus rollup register |

The naming pattern matches the [2026-07-03 JFrog / Lazarus / OtterCookie rollup-polyfill campaign](https://dependencywatch.io/incident/npm-2026-07-03-jfrog-lazarus-rollup-polyfill-ottercookie) already tracked - all packages in that register impersonate the legitimate `rollup-plugin-polyfill-node` under a different word-order slug. GHSA does not publish IOCs for this specific advisory, so attribution to Lazarus is **unverified**, but the naming pattern + the fact that this appeared in the **same 2026-08-21 GHSA batch** that formalised the two previously-tracked Lazarus rollup packages (`rollup-packages-polyfill-core`, `rollup-runtime-polyfill-core`; see JFrog file updates in this ingest) strongly suggests the same operator republishing under a fresh slug. This new package name also cross-references the JFrog file, which was updated in this ingest to include the two new GHSA IDs.

## Cluster I - npm CWE-506 no-IOC pulls (3 packages)

| Package | Versions | GHSA | Note |
|---|---|---|---|
| `polymarket-trading-developer-tool` | `>=0` | GHSA-qh4r-g8mr-v3xp | npm typosquat of Polymarket dev tooling (see also crates [polymarket-*](https://dependencywatch.io/incident/crates-2026-02-05-polymarket-typosquats)) |
| `kelly-sizing` | `>=0` | GHSA-vj74-3pcr-5p7j | Name suggests Kelly-criterion betting-math library; targeting unclear |
| `saas-f-testing` | `>=0` | GHSA-fvrj-4h6r-8rcg | Generic SaaS testing tool name |

All three are CWE-506 pulls where GHSA published no per-package behavioural detail. Defenders should treat as full RCE and rotate credentials the install shell could reach. The `polymarket-trading-developer-tool` npm entry is the second Polymarket-adjacent typosquat register - the first was on crates.io in February - so Polymarket / Web3 developers should treat all `polymarket-*` slugs on any registry other than the official published names as suspect.

## Registry state

All 13 packages yanked from their respective registries during the 2026-08-22 takedown window. Private mirrors that cached tarballs before takedown will keep serving them.

## Related tracked activity

- **`2026-08-reqcrypt` PyPI HTTP-response backdoor register** (Cluster A): now **four** variants (`reqcrypt`, `reqcrypt-dev`, `reqcrypts`, `requests-crypt`). Same operator, same shape, name-shuffling for takedown survival - suffix rotation exhausted, now on prefix / word-form rotation.
- **JFrog / Lazarus rollup-polyfill campaign** (Cluster H): the JFrog file at [/incident/npm-2026-07-03-jfrog-lazarus-rollup-polyfill-ottercookie](https://dependencywatch.io/incident/npm-2026-07-03-jfrog-lazarus-rollup-polyfill-ottercookie) was updated in this ingest to include GHSA IDs for the two previously-tracked packages (`rollup-packages-polyfill-core`, `rollup-runtime-polyfill-core`) that GHSA formalised on 2026-08-21.
- **Crates.io Polymarket typosquats** (Cluster I): [/incident/crates-2026-02-05-polymarket-typosquats](https://dependencywatch.io/incident/crates-2026-02-05-polymarket-typosquats). The new npm `polymarket-trading-developer-tool` extends the Polymarket-targeting pattern to npm.
- Discovery credits: `GitHub Advisory Database`, `OpenSSF malicious-packages`, `OpenSSF Package Analysis`. No named threat actor.

## Impact

- **Cluster A - PyPI `requests-crypt` fourth `2026-08-reqcrypt` HTTP-response backdoor variant (2026-08-22)**: `requests-crypt@0.1.0` (GHSA-cf52-hr54-m53p, hash `eee14db4ceeeedc62311a8926bc641b77f2cce3345e5f9b6083663f8931cb92b`, campaign `2026-08-reqcrypt`). Masquerades as "an HTTP request library with some additional functions"; the wrapper monitors every HTTP response for a specific field name and **secretly `exec()`s** whatever it finds there. This is the **fourth republish** of the campaign already tracked as `reqcrypt` on [2026-08-19](https://dependencywatch.io/incident/multi-2026-08-19-ghsa-malware-sweep), `reqcrypt-dev` on [2026-08-20](https://dependencywatch.io/incident/multi-2026-08-20-ghsa-malware-sweep), and `reqcrypts` on [2026-08-21](https://dependencywatch.io/incident/multi-2026-08-21-ghsa-malware-sweep). The operator has now shifted from suffix rotation (`-dev`, `s`) to a **spelling variant** (`requests-crypt` vs `reqcrypt` = full `requests` prefix), confirming the campaign is actively iterating on takedown-evasion nomenclature. Any project that calls the wrapper against attacker-controlled HTTP endpoints yields full Python RCE
- **Cluster B - PyPI `boto4` Telegram-bot C2 miner + wormable stealer (2026-08-22)**: `boto4@1.0.0, 1.0.2` (GHSA-ffh8-mpww-qp8g, hash `b928f1f0d3af6242391cc626a8601d24f60c70d862bfebe6cfe0777c13a8c0b2`, campaign `2026-08-boto4`). Impersonates AWS `boto3` by prefixing to `boto` + next integer. Executes an embedded native executable on install, then: (1) runs a **cryptominer**, (2) exfiltrates IP + username, (3) **implements worm-style self-propagation** on the local network, (4) receives remote commands via a **Telegram bot** channel. Because C2 is Telegram, egress-filtering on `api.telegram.org` is the correlation lever
- **Cluster C - PyPI `scrambleeer` reverse shell (2026-08-22)**: `scrambleeer@0.1.0, 0.1.1` (GHSA-jx7v-9c55-jw2v, hash `52d5b1e99e57b038247cf3b7f86a7514e75275a095ca3f3cf044d80cbe999472`, campaign `2026-08-scrambleeer`). Contains a hardcoded reverse shell. Any host that ran `pip install scrambleeer` yields an interactive shell back to the operator
- **Cluster D - npm `lumen-pages-community` v9.9.9 dependency-confusion beacon (2026-08-22)**: `lumen-pages-community@9.9.9` (GHSA-cf4g-g969-7qvx, hash `b7c1d6b7b99791f7bbd5999021f109bef569a6c681eda0bb6196b459b12a3808`). The `9.9.9` version is the classic dep-confusion sentinel: pick a version higher than any plausible internal semver so a misconfigured resolver picks this public tarball over the private one. Postinstall runs `node dc.js`, collecting hostname, username, CWD, platform, Node version, `CI` env var, and npm user-agent, and POSTs them to `https://webhook.site/b00492c6-27ba-4ea0-a9cb-dd50b3770250/dc`. **This is reconnaissance, not exploitation** - the operator is using this to map which organisations have an internal `lumen-pages-community` name, so they can follow up with a targeted payload against the confirmed catchments
- **Cluster E - npm `@gfe/lx-watcher` scoped dependency-confusion beacon (2026-08-21)**: `@gfe/lx-watcher@1.5.3, 1.5.4` (GHSA-7jmf-xqv3-ggfj). All three lifecycle hooks (**preinstall, install, postinstall**) POST installer metadata (hostname, OS username, CWD, timestamp, hook name) to `https://webhook.site/df384ffa-1094-4bbf-a202-e8b345b3ed18/gfe`. The main export is a **non-functional `createWatcher` stub** - the package does literally nothing besides beacon. Any organisation using an internal `@gfe/*` scope has now leaked infrastructure metadata to the operator
- **Cluster F - npm `fuel-react` v91.0.0 postinstall env exfil (2026-08-22)**: `fuel-react@91.0.0` (GHSA-77vr-cf3r-2v4w, hash `8e35f4772b8cba3555519c250662c67395bf57d89feed3feba7ea067b6bb2c27`). Postinstall collects `os.hostname()` + full `process.env` and POSTs via HTTPS. Full env means npm auth tokens, CI/CD secrets, cloud credentials, and any `.env` values leaked to the shell that ran `npm install`
- **Cluster G - npm `@postman-cse/okta-aio-linux-arm64` scoped Postman/Okta typosquat (2026-08-22)**: `@postman-cse/okta-aio-linux-arm64@0.8.10-0.11.6` (~20 versions; GHSA-h84r-259m-g3fg). Impersonates a Postman internal Okta AIO tool for ARM64 Linux. GHSA notes only that any host that installed it "should be considered fully compromised" - no C2, hash, or behavioural detail published, but the scope + platform-suffix specificity suggests targeted dependency-confusion against Postman internal ARM64 build infrastructure
- **Cluster H - npm `rollup-packages-node-polyfills` new JFrog / Lazarus rollup campaign sibling (2026-08-21)**: `rollup-packages-node-polyfills@>=0` (GHSA-gp6f-mxh4-x3mh). Naming shape matches the [2026-07-03 JFrog / Lazarus / OtterCookie rollup-polyfill campaign](https://dependencywatch.io/incident/npm-2026-07-03-jfrog-lazarus-rollup-polyfill-ottercookie) (`rollup-packages-polyfill-core`, `rollup-runtime-polyfill-core`) - all impersonate the legitimate `rollup-plugin-polyfill-node`. GHSA lacks IOCs, so attribution is unverified in this specific advisory, but the naming pattern + timing (same 2026-08-21 GHSA batch that formalised the two previously-tracked Lazarus rollup packages) strongly suggests the same operator republishing under a fresh slug after prior takedowns
- **Cluster I - npm CWE-506 no-IOC pulls (2026-08-21)**: `polymarket-trading-developer-tool@>=0` (GHSA-qh4r-g8mr-v3xp - npm typosquat of Polymarket dev tooling; unrelated to the crates.io `polymarket-*` campaign already tracked at [/incident/crates-2026-02-05-polymarket-typosquats](https://dependencywatch.io/incident/crates-2026-02-05-polymarket-typosquats) but plausibly same operator now moving to npm), `kelly-sizing@>=0` (GHSA-vj74-3pcr-5p7j), `saas-f-testing@>=0` (GHSA-fvrj-4h6r-8rcg). All three are CWE-506 pulls where GHSA published no per-package IOC beyond "considered fully compromised" - defenders should treat as full RCE

## What to do

1. Grep every lockfile (`package-lock.json`, `yarn.lock`, `pnpm-lock.yaml`, `requirements.txt`, `Pipfile.lock`, `poetry.lock`, `uv.lock`) for: `requests-crypt`, `boto4`, `scrambleeer`, `lumen-pages-community`, `@gfe/lx-watcher`, `fuel-react`, `@postman-cse/okta-aio-linux-arm64`, `rollup-packages-node-polyfills`, `polymarket-trading-developer-tool`, `kelly-sizing`, `saas-f-testing`
2. **For Cluster A (`requests-crypt`)**: uninstall from every virtualenv. Because this is the fourth variant of the `2026-08-reqcrypt` HTTP-response `exec()` shape, correlate scanner state across `reqcrypt`, `reqcrypt-dev`, `reqcrypts`, and `requests-crypt` when auditing whether the environment ever touched the campaign. Rotate any credential the Python process could reach on any host that installed and ever ran HTTP through the wrapper. Watch for further variants (`requests-crypto`, `req-crypt`, `crypt-requests`) - the operator has shifted from suffix to prefix rotation and will continue
3. **For Cluster B (`boto4`)**: uninstall and treat any host that installed it as fully compromised. Add `api.telegram.org` and `t.me` to egress-filtering deny lists for build runners and non-developer production hosts (Telegram has no legitimate use in CI/CD). Because `boto4` implements **worm-style self-propagation on the local network**, isolate any host that installed it before rebuilding: check other machines on the same L2 segment for lateral spread. The AWS `boto3` mismatch (`boto3` is legitimate; `boto4` does not exist) makes this trivially greppable in lockfiles
4. **For Cluster C (`scrambleeer`)**: uninstall from every virtualenv. Any host that installed it: assume the operator has already had an interactive shell and re-image. Rotate every credential the shell could have touched
5. **For Clusters D & E (`lumen-pages-community`, `@gfe/lx-watcher`)**: the immediate risk is **reconnaissance leakage** - the beacons tell the operator whether your organisation has an internal package under one of these names. Uninstall, then audit whether you have a private `lumen-pages-community` or `@gfe/*` scope; if so, treat as a targeted-attack precursor and lock your private registry proxy to explicit-scope-only resolution so future runs cannot fall through to the public registry. Add `webhook.site` and `oastify.com` to your DNS RPZ / perimeter deny for build runners and dev laptops - both are reconnaissance-primitive services with no legitimate build-time use
6. **For Cluster F (`fuel-react`)**: uninstall. Because postinstall exfiltrates full `process.env`, rotate every credential that was in the shell that ran `npm install` - npm auth tokens (`~/.npmrc`), CI secrets, cloud tokens, database URLs, API keys, and any `.env` value that was sourced into the shell
7. **For Cluster G (`@postman-cse/okta-aio-linux-arm64`)**: if you have a Postman internal build pipeline on ARM64 Linux and use the `@postman-cse` scope, lock private-registry resolution to explicit-scope-only; the platform-suffix specificity of this typosquat suggests targeted dependency-confusion against a real Postman build target
8. **For Cluster H (`rollup-packages-node-polyfills`)**: block at your registry proxy. Even without IOCs in the GHSA record, the naming shape matches the JFrog / Lazarus / OtterCookie campaign tracked in [/incident/npm-2026-07-03-jfrog-lazarus-rollup-polyfill-ottercookie](https://dependencywatch.io/incident/npm-2026-07-03-jfrog-lazarus-rollup-polyfill-ottercookie); if your registry ever resolved this name, treat any host that installed it as OtterCookie-compromised and rotate AI-coder credentials (Anthropic Claude API keys, Google Gemini keys, GitHub Copilot / Cursor / Windsurf / VS Code tokens), AWS/Azure/GCP credentials, and SSH/Zsh state from a separate clean device. The legitimate slug is `rollup-plugin-polyfill-node`
9. **For Cluster I (`polymarket-trading-developer-tool`, `kelly-sizing`, `saas-f-testing`)**: uninstall. Because the GHSA records provide no behavioural detail, treat as full RCE and rotate credentials the install shell could reach. For Polymarket / Web3 developers: the npm `polymarket-trading-developer-tool` typosquat sits alongside the earlier [crates.io Polymarket typosquats](https://dependencywatch.io/incident/crates-2026-02-05-polymarket-typosquats); pin to known-good vendor slugs and prefer scoped official packages
10. For all npm installs in CI, run with `--ignore-scripts` - this blocks Clusters D, E, F install-time beacons (though not Cluster A, which triggers on Python HTTP flow; or Cluster B, which is embedded in the imported code). For all `pip install` runs, prefer `--only-binary=:all:` where feasible
11. Verify that none of these packages still resolves via your private mirror - internal caches routinely keep serving yanked tarballs after the public takedown

## Check your own dependencies

- Check a package-lock.json against this incident: https://dependencywatch.io/check/package-lock-json
- Check a requirements.txt against this incident: https://dependencywatch.io/check/requirements-txt

The scan runs entirely in the browser; lockfile contents are never uploaded.

## References

- [GHSA-cf52-hr54-m53p - requests-crypt (PyPI, 2026-08-reqcrypt campaign, fourth variant)](https://github.com/advisories/GHSA-cf52-hr54-m53p) - GitHub
- [GHSA-ffh8-mpww-qp8g - boto4 (PyPI Telegram-bot C2 miner + worm)](https://github.com/advisories/GHSA-ffh8-mpww-qp8g) - GitHub
- [GHSA-jx7v-9c55-jw2v - scrambleeer (PyPI reverse shell)](https://github.com/advisories/GHSA-jx7v-9c55-jw2v) - GitHub
- [GHSA-cf4g-g969-7qvx - lumen-pages-community (npm v9.9.9 dep-confusion webhook.site)](https://github.com/advisories/GHSA-cf4g-g969-7qvx) - GitHub
- [GHSA-7jmf-xqv3-ggfj - @gfe/lx-watcher (npm scoped dep-confusion webhook.site)](https://github.com/advisories/GHSA-7jmf-xqv3-ggfj) - GitHub
- [GHSA-77vr-cf3r-2v4w - fuel-react (npm postinstall env exfil)](https://github.com/advisories/GHSA-77vr-cf3r-2v4w) - GitHub
- [GHSA-h84r-259m-g3fg - @postman-cse/okta-aio-linux-arm64 (npm scoped Postman/Okta typosquat)](https://github.com/advisories/GHSA-h84r-259m-g3fg) - GitHub
- [GHSA-gp6f-mxh4-x3mh - rollup-packages-node-polyfills (npm; naming matches JFrog/Lazarus rollup register)](https://github.com/advisories/GHSA-gp6f-mxh4-x3mh) - GitHub
- [GHSA-qh4r-g8mr-v3xp - polymarket-trading-developer-tool (npm)](https://github.com/advisories/GHSA-qh4r-g8mr-v3xp) - GitHub
- [GHSA-vj74-3pcr-5p7j - kelly-sizing (npm)](https://github.com/advisories/GHSA-vj74-3pcr-5p7j) - GitHub
- [GHSA-fvrj-4h6r-8rcg - saas-f-testing (npm)](https://github.com/advisories/GHSA-fvrj-4h6r-8rcg) - GitHub
- [GitHub Advisory Database - recent npm malware advisories](https://github.com/advisories?query=type%3Amalware+ecosystem%3Anpm&sort=published-desc) - GitHub
- [GitHub Advisory Database - recent pip malware advisories](https://github.com/advisories?query=type%3Amalware+ecosystem%3Apip&sort=published-desc) - GitHub

---

Canonical page: https://dependencywatch.io/incident/multi-2026-08-22-ghsa-malware-sweep
Markdown version: https://dependencywatch.io/incident/multi-2026-08-22-ghsa-malware-sweep.md
Site index for agents: https://dependencywatch.io/llms.txt
DependencyWatch.io is operated by Precursor Security (https://precursorsecurity.com).