critical

CVE

Not assigned

CWE

CWE-506, CWE-200, CWE-522

Affected Surface

  • PyPI package `chaintest==0.1.0`, quarantined by PyPI on 2026-08-10 after publication
  • PyPI package `cubesat-upstream-driver==1.0.1`, published 2026-08-08 and cataloged as malicious/probably-pentest on 2026-08-09
  • PyPI packages `kotanku==0.1.0`, `btcflip==0.1.0`, `btcflx==0.1.0`, and `kotoraka==0.1.0`, cataloged 2026-08-09 through 2026-08-10
  • Python developer workstations, research hosts, build runners, and sandbox systems that installed or imported the affected packages

The last three days did not produce another keyv-scale worm, but they did produce a dense cluster of new PyPI findings that matter for application security because they attack the exact trust boundaries developers still automate: package name resolution, top-level Python import, and “harmless helper” APIs that run inside CI or research environments.

Three threads stand out from 9-10 August 2026:

  1. chaintest==0.1.0 used a name collision with a real Java testing project and was quarantined by PyPI the same day it was published.
  2. cubesat-upstream-driver==1.0.1 presented itself as telemetry glue code, but public analysis says its exported API returns harvested secrets instead of orbital-command results.
  3. kotanku, btcflip, btcflx, and kotoraka formed a same-day PyPI cluster that turns import into Monero wallet theft and Telegram exfiltration.

None of these findings is a CVE-style “patch this library and move on” issue. They are package trust failures, which means the right question is not just “did we pin the version?” but “did a developer laptop or runner execute this package at all?”

Affected packages

PackageVersionFirst public cataloging windowExecution boundaryReported goal
chaintest0.1.010 Aug 2026package install / host executionbroad crypto infostealer, persistence, remote commands
cubesat-upstream-driver1.0.19 Aug 2026import / API callharvest file and environment secrets
kotanku0.1.09 Aug 2026importwallet theft
kotoraka0.1.010 Aug 2026importwallet theft
btcflip0.1.010 Aug 2026importwallet theft
btcflx0.1.010 Aug 2026importwallet theft

chaintest: a fake PyPI package riding the name of a real ChainTest project

The highest-severity finding in this burst is chaintest==0.1.0.

The package name is useful precisely because it looks plausible. There is a legitimate open source project named ChainTest, maintained at anshooarora/chaintest, and its real published artifacts live in Maven Central under coordinates such as com.aventstack:chaintest-core. That means the PyPI package name is not random typo noise. It is the kind of cross-ecosystem name collision that can trap internal tooling, dependency-confusion setups, or an engineer who only recognizes the brand and not the registry.

Public package metadata also shows the release behavior was suspiciously short-lived:

  • released on 10 Aug 2026
  • quarantined by PyPI on 10 Aug 2026
  • uploaded without trusted publishing

The more important part is the payload description. Public cataloging describes chaintest as a cryptocurrency-focused infostealer with a wider post-compromise toolkit:

  • browser extension and local-storage theft
  • standalone wallet and password-manager theft
  • clipboard interception and clipboard replacement
  • keylogging
  • SSH-key theft
  • persistence across platforms
  • remote-command support

The same reporting also exposes the campaign IOC pair:

ephmral.info
204.168.151.58

That makes chaintest much more serious than a fake setup helper or credential checker. It is better understood as a host-compromise event packaged as a dependency.

Why the name matters

Most dependency-confusion discussions focus on:

internal package name
-> public registry package with same name
-> automated installer picks the public one

chaintest adds a slightly different but still dangerous angle:

real project name known from another ecosystem
-> developer assumes the name is legitimate everywhere
-> PyPI package gets installed on trust-by-recognition

That matters for mixed-language organizations. A Java- or QA-adjacent engineer who recognizes ChainTest from GitHub or Maven can still be tricked if internal bootstrap docs, LLM-generated install snippets, or ad-hoc scripts say “pip install chaintest” without validating that PyPI is actually the intended distribution channel.

cubesat-upstream-driver: a fake API that returns secrets instead of telemetry

cubesat-upstream-driver==1.0.1 is the cleanest example in this group of API-shape deception.

Its public package page advertises a normal-looking Python interface:

from cubesat_upstream_driver import handle_command

result = handle_command("PING")

That is exactly why the package is interesting for AppSec teams. It does not need a flashy installer or a noisy setup.py trick. It only needs a plausible function name and a believable domain story.

Public technical analysis says the package ships no real driver, protocol, or telemetry logic. Instead, the key exported behavior is secret collection:

  • read well-known file paths such as /flag and /root/flag.txt
  • glob for /**/flag*
  • scan os.environ for keys containing flag, secret, ctf, key, or token
  • cache the result in _BOOT_SECRET
  • return that collected data through handle_command

Reduced to the publicly described behavior, the package’s logic looks more like this than like a driver:

def _exfil_flag():
    # Read flag-like files and secret-shaped environment variables.
    ...

_BOOT_SECRET = _exfil_flag()

def handle_command(_command):
    return _exfil_flag()

That design choice is subtle and dangerous. The package does not need its own network exfiltration path if a calling program, benchmark harness, or wrapper API will faithfully forward the returned value somewhere else. In other words, the package can weaponize the normal data flow of the application that imported it.

The public listing says the project homepage is github.com/cubesat-org/upstream-driver, uses CubeSat/driver keywords, and exposes a simple “dispatch commands to satellite subsystems” story. Public cataloging separately notes that it appears closer to a CTF-like or pentest-style trap than to a broad worm, but that should not be read as harmless. If you ran it in a secrets-rich environment, it still harvested secret material.

kotanku, kotoraka, btcflip, and btcflx: import-time Monero wallet theft

The wallet-stealer cluster is the most consistent family in this short time window. The public campaign grouping ties all four packages together:

  • kotanku==0.1.0
  • kotoraka==0.1.0
  • btcflip==0.1.0
  • btcflx==0.1.0

The package names and descriptions were presented as ordinary utility software, but public behavior descriptions show a much narrower operational target: Monero wallet theft.

The shared pattern is:

import package
-> resolve Windows or Linux Monero wallet path
-> terminate Monero-related processes to release file locks
-> archive wallet directory
-> upload the archive to a Telegram bot

Two details are especially useful for defenders:

  1. the bot token and target filesystem paths were reportedly base64-obfuscated in source
  2. the exfiltration fired as a top-level import side effect, not after a user called a suspicious function

For btcflip and btcflx, public analysis also describes:

  • hardcoded constant names such as TK, XMR_WIN, and XMR_LINUX
  • use of api.telegram.org sendDocument
  • companion status reporting through sendMessage
  • process termination for feather and monero

kotoraka is important because its behavior is described as the inner wallet-theft implementation, while btcflip reportedly triggers theft by importing that inner module. That means this was not just one bad package re-uploaded under one name. It was a small same-day package family with reuse and repackaging.

The common pattern is not the lure - it is the trust boundary

These findings look different on the surface:

  • crypto-focused host stealer
  • fake telemetry driver
  • fake wallet/HTTP helper packages

But the deeper pattern is the same:

plausible package name
-> normal package install or import
-> attacker code runs before any meaningful application-level validation

That is why these packages matter to application security, even when they do not target production servers directly. They run on:

  • developer laptops with SSH keys and browser sessions
  • CI runners with registry tokens and cloud credentials
  • research or challenge hosts with broad environment variables
  • notebooks or scripts where import happens long before code review or runtime scanning

Detection and hunting

Start by searching dependency definitions, notebooks, build scripts, and caches for the exact names and versions:

rg -n \
  "chaintest==0\\.1\\.0|cubesat-upstream-driver==1\\.0\\.1|kotanku==0\\.1\\.0|kotoraka==0\\.1\\.0|btcflip==0\\.1\\.0|btcflx==0\\.1\\.0" \
  requirements*.txt pyproject.toml poetry.lock uv.lock Pipfile Pipfile.lock setup.py

Search code and notebooks for import statements:

rg -n \
  "import chaintest|from chaintest|import cubesat_upstream_driver|from cubesat_upstream_driver|import kotanku|import kotoraka|import btcflip|import btcflx" \
  . --glob '*.py' --glob '*.ipynb' --glob '*.md'

Useful host and network hunting strings from the public reporting include:

ephmral.info
204.168.151.58
api.telegram.org
Monero
feather
_BOOT_SECRET
_exfil_flag
handle_command("PING")

For the wallet-stealer family, look for signs that Python imports were enough to trigger execution. Any notebook, REPL session, unit test, or helper script that imported the package may be the exposure point even if the rest of the program never ran.

Response guidance

If chaintest or the kotanku family ran on a real workstation, treat the host as compromised:

  1. rotate SSH keys, browser-backed sessions, wallet material, registry credentials, and any local secrets reachable from that host
  2. review shell history, downloaded artifacts, startup items, and persistence locations
  3. preserve package caches and process/network telemetry before cleanup when possible

If cubesat-upstream-driver was installed or imported:

  1. assume the environment variables and flag-like local files visible to that process may have been exposed
  2. review any wrapper service, notebook, or CTF harness that might have forwarded handle_command() output to logs, APIs, or shared storage
  3. rotate tokens and invalidate challenge or lab credentials that were present in that execution context

The broader lesson from this 9-10 August PyPI burst is that small packages are now routinely built to weaponize developer trust, not just runtime bugs. The malicious behavior begins at package resolution, import, and helper-function use - exactly where modern engineering workflows try to move fastest.

From research to remediation

Check whether this pattern exists in your codebase

Turn this research into a remediation workflow. Scan dependencies and package manifests for similar supply-chain risk, then prioritize fixes with reachability context.

Explore dependency scanning Explore secrets scanning Get Demo

References