GitHub Advisory malware sweep - 2026-08-22 batch (PyPI `requests-crypt` = fourth `2026-08-reqcrypt` variant + PyPI `boto4` Telegram-C2 miner/worm + npm `lumen-pages-community` + `@gfe/lx-watcher` dep-confusion webhooks + `fuel-react` env exfil + `rollup-packages-node-polyfills` new JFrog-shape sibling + Postman/Okta typosquat + 3 CWE-506 no-IOC pulls)

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 es) 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 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-*) | | 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 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. 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.

Affected packages (11)

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, reqcrypt-dev on 2026-08-20, and reqcrypts on 2026-08-21. 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 (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 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. 1Grep 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. 2For 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. 3For 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. 4For 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. 5For 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. 6For 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. 7For 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. 8For 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; 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. 9For 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; pin to known-good vendor slugs and prefer scoped official packages
10. 10For 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. 11Verify that none of these packages still resolves via your private mirror - internal caches routinely keep serving yanked tarballs after the public takedown

References

• GHSA-cf52-hr54-m53p - requests-crypt (PyPI, 2026-08-reqcrypt campaign, fourth variant)

  github.com
  GitHub
• GHSA-ffh8-mpww-qp8g - boto4 (PyPI Telegram-bot C2 miner + worm)

  github.com
  GitHub
• GHSA-jx7v-9c55-jw2v - scrambleeer (PyPI reverse shell)

  github.com
  GitHub
• GHSA-cf4g-g969-7qvx - lumen-pages-community (npm v9.9.9 dep-confusion webhook.site)

  github.com
  GitHub
• GHSA-7jmf-xqv3-ggfj - @gfe/lx-watcher (npm scoped dep-confusion webhook.site)

  github.com
  GitHub
• GHSA-77vr-cf3r-2v4w - fuel-react (npm postinstall env exfil)

  github.com
  GitHub
• GHSA-h84r-259m-g3fg - @postman-cse/okta-aio-linux-arm64 (npm scoped Postman/Okta typosquat)

  github.com
  GitHub
• GHSA-gp6f-mxh4-x3mh - rollup-packages-node-polyfills (npm; naming matches JFrog/Lazarus rollup register)

  github.com
  GitHub
• GHSA-qh4r-g8mr-v3xp - polymarket-trading-developer-tool (npm)

  github.com
  GitHub
• GHSA-vj74-3pcr-5p7j - kelly-sizing (npm)

  github.com
  GitHub
• GHSA-fvrj-4h6r-8rcg - saas-f-testing (npm)

  github.com
  GitHub
• GitHub Advisory Database - recent npm malware advisories

  github.com
  GitHub
• GitHub Advisory Database - recent pip malware advisories

  github.com
  GitHub