GitHub Advisory malware sweep - 2026-08-21 batch (npm `coin-fees` Burp Collaborator credential recon with CI-aware dormancy + PyPI `reqcrypts` third `2026-08-reqcrypt` HTTP-response backdoor variant)

What happened

The 24-hour window ending 2026-08-21 06:00 UTC published just two new GHSA CWE-506 advisories (one npm, one PyPI). Both carry per-package IOCs and both target credentials rather than shipping generic droppers, making this a quieter but higher-quality window than most of the recent daily sweeps.

Cluster A - npm coin-fees Burp Collaborator credential recon (1 package)

| Package | Versions | GHSA | IOCs | |---|---|---|---| | coin-fees | <= 20.1.1 | GHSA-c7m8-52wr-gcp3 | Hash f47c61fd…1703; C2 gwfqp5cm9r2jfs3d6mjpzt8y5pbkzanz.oastify.com on port 80 HTTP |

oastify.com is the public Burp Suite Collaborator DNS suffix, meaning the operator is using a legitimate offensive-security testing tool as their C2. That has three practical implications:

1. DNS query pattern is distinctive. Any DNS resolver log showing a workstation or CI runner querying a random-alphanumeric subdomain of oastify.com is either (a) an authorised security assessment against your infrastructure or (b) a Collaborator-based malware beacon. There is no third case.
2. The specific subdomain (gwfqp5cm9r2jfs3d6mjpzt8y5pbkzanz) is unique to this malware operator's Collaborator session - any time your DNS logs show that exact left-most label, the operator now knows which of your hosts installed coin-fees.
3. Blocking Collaborator wholesale is safe for developer laptops and build runners; only offensive-security testing teams have a legitimate use case, and they can operate their Collaborator from a segregated network.

The collected data set (hostname, OS, ~/.npmrc npm tokens, full env vars, local port scan) is standard supply-chain recon, but the CI/CD-detection dormancy flips the normal severity picture: OSS Package Analysis sandboxes and security researchers get nothing, while developer laptops - which are the exact hosts with high-value npm publish tokens in ~/.npmrc - get fully exfiltrated. Treat any dev machine that ever installed coin-fees as having leaked its publish tokens, and audit whether that developer's npm access was used to publish a downstream compromise.

Cluster B - PyPI reqcrypts third 2026-08-reqcrypt campaign variant (1 package)

| Package | Versions | GHSA | IOCs | |---|---|---|---| | reqcrypts | 0.1.0, 0.1.1, 0.1.2, 0.1.3 | GHSA-p5hw-cgm2-4cp2 | Hash 51643020…6c46; campaign 2026-08-reqcrypt |

The 2026-08-reqcrypt campaign now has three tracked variants over three days:

• 2026-08-19 reqcrypt@0.1.0 (folded into that day's Cluster H)
• 2026-08-20 reqcrypt-dev@0.1.0 (folded into that day's Cluster B; hash 8e66755912…f3e4)
• 2026-08-21 reqcrypts@0.1.0-0.1.3 (this file; hash 51643020…6c46)

The payload shape is stable across variants: pose as a "requests wrapper", intercept HTTP responses, look for a specific field, exec() its contents. Only the package name and hash change - which is why detection needs to key on both the campaign identifier and any future name in the same shape. Expect a fourth republish (reqcrypt2, reqcryptx, or similar) within days.

Campaign attribution is OpenSSF (kam193) via the bad-packages.kam193.eu PyPI research feed and the ossf/malicious-packages OSV repository (MAL-2026-14341).

Registry state

Both packages yanked from their respective registries during the 2026-08-21 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 B): now three variants (reqcrypt, reqcrypt-dev, reqcrypts). Same operator, same shape, name-shuffling for takedown survival.
• 2026-07-pyqt6darktheme PyPI cryptominer register (extended by libasync on 2026-08-20): no new siblings in this window.
• *Sui `@mysten/` typosquat register** (days 1-6, 2026-08-11 through 2026-08-19): no new items in this window either. The register appears to have gone dormant.
• Discovery credits: GitHub Advisory Database, OpenSSF malicious-packages, OpenSSF Package Analysis, kam193. No named threat actor.

Affected packages (2)

Impact

• Cluster A - npm coin-fees Burp Collaborator credential recon (2026-08-21): coin-fees@<=20.1.1 (GHSA-c7m8-52wr-gcp3, hash f47c61fd59fb65dc8c8932e3e913dd83f18fc8af1d5f06b03cae327228821703). Postinstall script decodes a hardcoded destination hostname, sleeps a randomised 30-120 seconds to dodge sandbox timeouts, then POSTs to gwfqp5cm9r2jfs3d6mjpzt8y5pbkzanz.oastify.com (a Burp Suite Collaborator subdomain, port 80 HTTP). Collected fields: hostname, OS release, working directory, effective user, ~/.npmrc npm auth tokens, full environment (CI/CD secrets), a local-port scan of the host, and Windows-specific reconnaissance when applicable. The malware stops execution when it detects a CI/CD environment (evasion) - meaning developer laptops and non-obvious CI runners get their creds exfiltrated while GitHub-Actions-style probes go quiet
• Cluster B - PyPI reqcrypts third 2026-08-reqcrypt HTTP-response backdoor variant (2026-08-21): reqcrypts@0.1.0-0.1.3 (GHSA-p5hw-cgm2-4cp2, hash 516430200454879e0449beefe11b3981553ecb85df586ed09d8057ea94016c46). 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 third republish of the 2026-08-reqcrypt campaign already seen as reqcrypt on 2026-08-19 and reqcrypt-dev on 2026-08-20; the operator is name-shuffling under a suffix (-dev) then a pluralisation (s) to survive each takedown. Any project that calls the wrapper against attacker-controlled or attacker-poisonable HTTP endpoints yields full Python 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 coin-fees and reqcrypts
2. 2For Cluster A matches (coin-fees): uninstall from every project. Rotate every credential the postinstall could reach: npm auth tokens from ~/.npmrc (npm token revoke then npm login to reissue), every env var that was in the shell that ran npm install (CI secrets, cloud tokens, database URLs, API keys), and any secret written into a .env the postinstall could cat. Because the malware only fires on developer/non-CI hosts, the risk concentrates on laptops - assume developer machines that installed coin-fees at any version have leaked their npm publish tokens. Add oastify.com and its wildcards to your DNS RPZ / perimeter deny for build runners and dev laptops - Burp Collaborator subdomains have no legitimate use in production traffic
3. 3For Cluster B matches (reqcrypts): uninstall from every virtualenv. Because this is the third variant of the same 2026-08-reqcrypt HTTP-response exec() shape, correlate scanner state across reqcrypt, reqcrypt-dev, and reqcrypts when auditing whether the environment ever touched the campaign. Rotate any credential the Python process could reach on any host that installed reqcrypts and ever ran HTTP through the wrapper, and treat CI runners that installed it as compromised. Watch for further name variants (reqcrypt2, reqcryptx, reqcrypto) as the operator keeps rotating
4. 4For all npm installs in CI, run with --ignore-scripts - this DOES block the Cluster A postinstall (though not Cluster B, which triggers on Python HTTP flow, not install). For all pip install runs, prefer --only-binary=:all: where feasible
5. 5Verify that neither package still resolves via your private mirror - internal caches routinely keep serving yanked tarballs after the public takedown

References

• GHSA-c7m8-52wr-gcp3 - coin-fees (npm Burp Collaborator credential recon with CI dormancy)

  github.com
  GitHub
• GHSA-p5hw-cgm2-4cp2 - reqcrypts (PyPI, 2026-08-reqcrypt campaign, third variant)

  github.com
  GitHub
• OpenSSF malicious-packages OSV entry MAL-2026-14341 (reqcrypts)

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

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

  github.com
  GitHub