GitHub Advisory PyPI CWE-506 sweep - 2026-08-08 batch (`riakcs` Basho Riak-CS Python client typosquat with setup.py install-time host reconnaissance)

What happened

On 2026-08-08, the GitHub Advisory Database and OpenSSF malicious-packages published one new PyPI CWE-506 advisory (GHSA-3849-8v46-m7qx, MAL-2026-13665) for the package riakcs. This is a small-scope one-package day for PyPI following the 10-package 2026-08-07 batch (see pypi-2026-08-07-ghsa-malware-sweep).

Cluster A - riakcs Basho Riak-CS Python client typosquat / host reconnaissance (1 package, 2026-08-08)

| Package | Versions | Notes | |---|---|---| | riakcs | 0.0.1, 0.5.0 | Basho Riak-CS Python client typosquat, setup.py install-time IP + username exfil |

Naming: riakcs (all-lowercase, no hyphen) evokes the Basho Riak CS distributed object-storage layer - the S3-compatible protocol-adapter that runs on top of a Riak KV cluster. The real Python ecosystem projects for talking to Riak-CS are either the official riak / riak-python-client (via Riak KV protocol buffers) or boto3 against the Riak-CS S3 endpoint. There is no legitimate maintained PyPI package called riakcs - the malicious upload occupies a plausible-real name that appears in copy-pasteable pip commands from stale tutorials, LLM completions, and internal-tooling scripts.

Behaviour: the malicious package overrides the setuptools install command class. When pip runs setup.py install, the override executes attacker code that harvests the installer's IP address and username and HTTP-GETs them to an attacker-controlled callback before completing the install. No further payload is dropped, no crypto-wallet keys are exfiltrated, and no persistent implant is established during the observed activity. This matches the reconnaissance-only profile characterised in the advisory as "limited risk".

Version pattern: 0.0.1 was the initial upload, 0.5.0 a subsequent version-jump both shipping the same payload. The version-jump is a common tactic to make the package look more mature to a developer skimming the PyPI page and to outrank plausible pre-1.0 alternative names in resolver ordering.

Attribution: OpenSSF malicious-packages records the source-provided credit as kam193 (the community researcher who has contributed a substantial fraction of the OpenSSF PyPI malicious-package corpus over 2024-2026). No named threat actor - MAL-2026-13665 identifier only.

Registry state: both versions yanked from PyPI during the 2026-08-08 takedown; PyPI JSON API confirms the current releases map is empty. Private mirrors (devpi, Artifactory, Nexus) that cached tarballs BEFORE the takedown WILL keep serving the original versions.

Downstream implications

Recon-only drops are the standard first phase of a two-stage dep-confusion / typosquat operation: publish a lightweight scoping payload, wait to see which orgs' CI IPs and usernames land in the callback log, and then follow with a targeted stage-2 payload under the same or a sibling name once a valuable-looking target is identified. Any org that hit riakcs during install should assume they are now on that shortlist and should proactively lock down internal-registry / mirror configuration for riak*, basho*, and other object-storage-shaped names.

Today's Aug 8 PyPI batch is much lighter than the Aug 7 batch (10 packages spanning alphalend-* Sui keystore theft, the 2026-08-flasq typosquat wave, cdktn-provider-azurerm HashiCorp typosquat, and atlas-internal dep-confusion recon - see pypi-2026-08-07-ghsa-malware-sweep). The pattern of a large batch followed by a one-package trailing day is consistent with how OpenSSF Package Analysis flushes its queue.

Affected packages (1)

Impact

• Cluster A - riakcs Basho Riak-CS Python client typosquat / host reconnaissance (1 package, 0.0.1 + 0.5.0, 2026-08-08): the package name evokes Riak CS (Basho's S3-compatible object-storage layer on top of Riak KV) - a plausible-real name for a Python client of the deprecated-but-still-deployed distributed object store. Any Python developer who ran pip install riakcs while doing storage-cluster tooling or migration work would hit this package
• Behaviour: overrides the setuptools install command to run attacker code at install time, exfiltrating basic host reconnaissance data (IP address + username) to an attacker-controlled callback before completing the pip install. No stage-2 payload is documented in the advisory - the drop is a reconnaissance-only run designed to profile hosts that resolve the package name
• Risk framing: the OpenSSF advisory itself flags this as "limited risk" relative to other 2026-08 drops - the package does not ship a RAT, credential stealer, or crypto-wallet drainer. The concrete exposure is: (a) your host IP + username are now in an attacker's target list, correlated with the fact you were interested in riakcs-shaped tooling; (b) any future stage-2 drop under the same or a sibling name is likely to be tuned to the environments the recon run identified
• Package versions 0.0.1 (initial upload) and 0.5.0 (later version-jump to look more legitimate) both ship the same install-time payload. Both were yanked from PyPI during the 2026-08-08 takedown; PyPI JSON API confirms releases: [] now

What to do

1. 1Grep every Python lockfile (requirements.txt, Pipfile.lock, poetry.lock, uv.lock, pdm.lock, conda-lock.yml) for riakcs. If matched, your host IP + username have been exfiltrated to the attacker - treat as reconnaissance-scope disclosure, not full compromise
2. 2If you actually need a Python client for Basho Riak-CS, use the official riak-python-client (which speaks to Riak KV directly) or the AWS SDK for Python (boto3) configured against the Riak-CS S3-compatible endpoint. There is no legitimate maintained riakcs-named Python package on PyPI
3. 3Configure .pip.conf or .pypirc to require an explicit --index-url for internal packages and reject implicit fallback to public PyPI, especially for any host that ran the malicious install - a stage-2 drop under the same or a sibling name is a likely follow-up
4. 4Verify your PyPI mirror (devpi / Artifactory / Nexus) is not still caching either yanked version - PyPI's public takedown does NOT propagate to your internal cache
5. 5For all pip install operations in CI, prefer pip install --no-build-isolation --no-deps --dry-run when auditing an unknown package to inspect its metadata without executing setup.py

References

• GHSA-3849-8v46-m7qx - riakcs (PyPI) install-time host reconnaissance

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

  github.com
  GitHub
• PyPI JSON API - riakcs project (yanked)

  pypi.org
  PyPI
• Basho Riak CS - S3-compatible object storage on Riak KV

  docs.riak.com
  Basho