scrambleeeer PyPI Reverse Shell: The Payload That Waits for You to Call It

The scrambleeeer PyPI reverse shell, flagged on August 22, 2026 under campaign 2026-08-scrambleeer, is a malicious-package compromise in which two PyPI projects advertised as a number-shuffling utility open a reverse shell to a hardcoded host when application code calls the library. No CVE applies and no CVSS score exists, because this is malware in a package rather than a vulnerability in one. This post is written for AppSec engineers, DevSecOps and platform teams, and detection engineers who own Python dependency policy as of August 2026, and covers the affected versions of scrambleeer and scrambleeeer, the published indicator, the first-hour runbook, and the structural reason install-time controls never saw the payload.

What Happened: The 2026-08-scrambleeer Campaign on PyPI

Two PyPI packages, scrambleeer and scrambleeeer, were classified as malicious under campaign 2026-08-scrambleeer on August 21 and August 22, 2026, with abuse categories revshell and action-hidden-in-lib-usage. The campaign record describes the behavior in one line: when the library is used, the code starts a reverse shell to a hardcoded location. Both projects are now quarantined by PyPI admins and cannot be installed or modified until a security review completes.

Two details in that table carry more weight than the rest. The first is the spelling ladder: scrambleeer uses three consecutive letter e characters and scrambleeeer uses four, and the campaign slug follows the three-letter spelling. The second is the account ladder: foofoo1337 published the first project and foofoo1338 published the second a day later, a sequential-account pattern consistent with burner-account iteration. Neither package squats a widely used PyPI project, and no download counts, actor attribution, or motive are published, so treat the publish pattern as an observation rather than an attribution.

How the Attack Chain Executes: Call Time, Not Install Time

The scrambleeeer PyPI reverse shell does not fire during pip install. The payload runs when application code imports the package and calls its shuffle function, at which point the calling process opens an outbound connection to bax.h4x[.]tv. That single design choice is what separates this campaign from the majority of malicious PyPI packages.

Stage 1: Distribution

Both projects shipped to PyPI as a source distribution and a wheel under a benign utility description, MIT licensed, requiring Python 3.9 or later. No install hook is needed for a call-time payload, so nothing in the packaging metadata looks unusual and nothing in the install log records an anomaly.

Stage 2: Adoption

A developer or an agentic coding tool installs the package, whether from a typo, an autocompleted suggestion, or a generated requirements file. Installation alone produces no malicious behavior, which means the package settles into a lockfile and survives install-time sandbox review with a clean record.

Stage 3: Trigger

Normal library usage reaches the payload. Time of install and time of execution are decoupled, and the outbound connection originates from whatever process happened to call the function: a developer laptop, a CI runner, or a production container. The campaign source publishes no port, no protocol, no file paths, and no function names, so the socket-level detail of this stage remains undocumented.

Stage 4: Impact

A reverse shell hands the operator interactive command execution inside the calling process, carrying that process's filesystem access, environment variables, and network position. On a CI runner, the practical scope is the job's injected secrets and its cloud identity. In a container, the scope is the workload's service account. Mapped to MITRE ATT&CK, the execution stage corresponds to T1059.006, Command and Scripting Interpreter: Python. That mapping is Kodem's, since the campaign source publishes none.

Why "Action Hidden in Library Usage" Changes the Detection Problem

Most malicious PyPI packages execute at install time through setup.py, a build hook, or a post-install script, which is exactly where install-script scanners and ephemeral install sandboxes watch. The action-hidden-in-lib-usage pattern moves execution past that checkpoint entirely, and the checkpoint is the most heavily instrumented moment in the whole dependency lifecycle.

Compare the two execution models directly. An install-time payload gets one narrow, well-observed window to fire, and the artifacts it leaves (a spawned shell during pip install, a child process from a build script) are the signals detection engineering has been tuned on for years. A call-time payload gets an open-ended window and a legitimate-looking caller. Nothing distinguishes the malicious invocation from the thousand other function calls in the same process.

The consequence for defenders is specific. Install-script static analysis has nothing to flag. An install sandbox observes a clean install and reports one. A lockfile diff review shows a plausible one-line addition of a small utility. The only reliable signal left is behavioral: a Python process that loads a package and then opens an outbound socket to an unrecognized host. That event, not the install log, is the detection.

The same logic generalizes past this campaign. Any dependency that behaves correctly until a specific function, argument, or environment condition is met inherits the same advantage, which is the direction dependency malware has been moving for several waves now.

Indicators of Compromise (IOCs) and Behavioral Signals

Hunt for one network indicator and two package strings. The only published IOC for campaign 2026-08-scrambleeer is the domain bax.h4x[.]tv, and the package indicators are scrambleeer versions 0.1.0 and 0.1.1 plus scrambleeeer version 0.1.0.

Package versions to block. Block at the project level rather than the version level. Both projects were published inside 48 hours from sequentially numbered accounts, so the whole name is untrusted, not just the three known versions.

Network indicators. The published campaign data gives a hostname and nothing further, so block and alert at the domain level rather than tuning a port rule against a value nobody has published.

Behavioral indicators. These are the signals that survive the absence of file-level IOCs.

Immediate Response: The First-Hour Runbook

Search before patching. Determine whether either package name exists anywhere in your dependency graph, then determine whether the package was ever imported, then rotate credentials only for the environments where the code actually ran. That third branch is what keeps the response proportionate.

1. Search every lockfile, SBOM, container image, and requirements file across all repositories for the literal strings scrambleeer and scrambleeeer, including transitive dependencies. Both projects are quarantined, so new installs already fail and the remaining risk lives in what is already resolved and cached.
2. Block both project names at the registry proxy or internal mirror (Artifactory, Nexus, or a self-hosted PyPI mirror) and purge them from every package cache, including the pip wheel cache and any pre-baked base images.
3. Determine execution, not just installation. Check whether any code path imported the package or called its shuffle function. This is the branch point of the entire response: an unimported package is a hygiene finding, while an imported one is an incident.
4. Query DNS, proxy, and egress logs for bax.h4x[.]tv and every h4x[.]tv subdomain across the window since August 21, 2026. Search further back than your own install date, since campaign publish dates and local resolution dates rarely align.
5. Rotate every credential reachable from any environment where the package was invoked: CI runner tokens, cloud role credentials, registry and publish tokens, and any secret injected into the affected job or workload. Scope the rotation rather than rotating globally, since an unscoped sweep delays the rotations that matter.
6. Inspect the affected hosts and runners for persistence and for other outbound connections in the same window. A reverse shell grants interactive access, so the host is a live-response target and not only a package problem.
7. Freeze publication from any affected pipeline until steps 3 through 6 complete, so a compromised runner cannot sign or push an artifact.
8. Record the negative result explicitly when nothing turns up. Write down which repositories, image registries, and log sources were searched and over what window, so the next variant does not restart the search from zero.

Why Conventional Tooling Caught the Package but Missed the Behavior

Manifest-based tooling can flag scrambleeer and scrambleeeer once the names reach a malicious-package feed, and that is worth having. Nothing in the manifest, the install log, or a vulnerability database describes what the package does when called, so the feed tells you a name is present and stops there.

The structural limits are worth naming precisely. Software composition analysis that reconciles a manifest against a vulnerability database has nothing to match, since a malicious package carries no CVE. An install-script scanner has no install hook to inspect. Provenance and signing attest to where an artifact came from, not to what the code inside does on invocation. Even the malicious-package feeds diverged on this campaign: automated summaries classified it as an infostealer while the campaign source classified it as revshell plus action-hidden-in-lib-usage. Both flagged the package correctly, and neither describes the runtime event you actually need to see.

Runtime intelligence closes that gap by observing execution instead of inventory. Kodem's runtime-powered SCA traces which packages load into memory and which functions execute, and flags shadow packages that load at runtime but never appear in a manifest, which is the difference between "scrambleeeer is in a lockfile" and "scrambleeeer executed on this runner." Kodem's Application Detection and Response (ADR) covers the second half, the outbound connection a build runner had no reason to open. For the distinction between a package being reachable and a package having actually run, see reachability to reality. For a cross-ecosystem campaign that reached PyPI through a different route, see the Kodem Mini Shai-Hulud PyTorch Lightning and intercom-client breakdown.

Hardening Your Pipeline Against the Next Call-Time Payload

Assume more call-time payloads are coming, since the pattern works and costs almost nothing to publish. The controls that matter constrain what a dependency can do once it runs, not only which dependencies you allow in. Build the open source security program around both halves.

1. Default-deny egress from CI runners and build containers, with an explicit allowlist for the package registries and internal services a build genuinely needs, so a reverse shell has nowhere to dial.
2. Route installs through an internal proxy with a review gate for newly published projects, and set a minimum project age or download threshold. Both scrambleeer and scrambleeeer were flagged within a day of first release.
3. Scope CI secrets to the job that needs them and give runners short-lived, narrowly scoped cloud identities, so an interactive shell inside a build inherits as little as possible.
4. Pin and hash-verify dependencies (pip install --require-hashes, or the equivalent in uv or poetry) so a silent version bump cannot introduce a new payload under an already-approved name.
5. Alert on first-time outbound destinations per pipeline and per workload. A build contacting a host it has never contacted before is a stronger signal than any package-name list.
6. Treat AI-generated and agent-installed dependencies as a distinct review path, since plausible-sounding trivial utilities are exactly what gets suggested and accepted without scrutiny.
7. Keep behavioral coverage in production and not only in CI, since a call-time payload can sit dormant through an entire build and fire on the first real request.

What This Campaign Signals About Dependency Malware in 2026

Campaign 2026-08-scrambleeer is small, unsophisticated, and was caught inside a day, which is precisely why the mechanism deserves attention. Moving execution from install time to call time costs an attacker almost nothing and removes the single checkpoint most dependency security is built around.

• The install-time checkpoint is becoming the least productive place to look, for the same reason it is the most instrumented.
• Burner-account publishing is cheap to iterate, and quarantining one name does nothing to raise the cost of publishing the next.
• Trivial utility packages with plausible descriptions are a growing delivery surface, especially where dependencies get suggested by tooling rather than chosen deliberately.

One falsifiable prediction: the next iteration of this pattern adds a condition to the trigger, so the payload fires only outside a sandbox, only on a non-CI hostname, or only after a delay. Watch for campaigns whose abuse classification pairs a usage-triggered action with a sandbox-evasion tag. Should the next scrambleeer-style package still fire unconditionally on first call, this prediction is wrong.

Frequently Asked Questions

References

1. Bad Packages Database. August 2026. scrambleeeer: campaign 2026-08-scrambleeer. Bad Packages.
2. kam193. August 2026. package-campaigns: PyPI campaign and abuse-category data. GitHub.
3. PyPI. August 22, 2026. scrambleeeer 0.1.0 (quarantined). PyPI.
4. PyPI. August 21, 2026. scrambleeer 0.1.1 (quarantined). PyPI.
5. MITRE. T1059.006: Command and Scripting Interpreter: Python. MITRE ATT&CK.
6. Kodem Security. April 30, 2026. Mini Shai-Hulud Strikes PyTorch Lightning and Intercom Client: Inside the Cross-Ecosystem Supply Chain Attack. Kodem Security.