PyPI package 999.9.9 harvested SSH keys

A PyPI package named anthropickit, released on June 14, 2026, attempted to steal SSH keys and environment secrets from any machine that installed it. Its version number was 999.9.9—an intentionally extreme value designed to outrank a legitimate internal package with the same name.

The package may be connected to an incident Anthropic described in a recent report, but that remains unconfirmed. Aikido says it contacted Anthropic and has not received a response. The timing and behavior match the report’s account closely: an internet-connected agent encountered instructions for a fictional company, found that a referenced PyPI package did not exist, and decided that publishing a malicious replacement was part of a capture-the-flag exercise.

What anthropickit did during installation

The package contained little more than a setup.py. Its payload ran at installation time, before the package was imported, and attempted to collect:

• The host name and current user
• Files in ~/.ssh, excluding known_hosts, known_hosts.old, and authorized_keys
• Environment variables containing KEY, SECRET, TOKEN, PASS, AUTH, or API

That exclusion list is narrowly targeted. It skips files that are generally less useful to an attacker while retaining private keys and SSH configuration, which can reveal the servers and usernames used by a developer. The environment-variable sweep was broader, potentially capturing credentials alongside unrelated variables such as API_URL.

Recommended reading

COLDCARD flaw linked to $88.6 million Bitcoin theft

The collected data was posted as JSON to a hardcoded Pipedream endpoint. Pipedream is a legitimate service that provides disposable HTTPS endpoints capable of receiving POST requests. That gives an attacker encrypted traffic to a reputable domain without requiring them to operate a dedicated server.

The channel was also fragile: there was no authentication, fallback address, or redundancy. Once the endpoint was reported or its workflow removed, the exfiltration path would stop working.

Multiple signs of an unfinished payload

The package’s first operational import included requests, but the package did not declare it as a dependency. There was no install_requires entry or build requirement. Because modern pip may build source packages in an isolated environment, the import could fail before the payload executed if requests was unavailable.

A more careful implementation would have used Python’s built-in urllib. The author instead appears to have assumed that requests would already be installed, a gamble more likely to work on developer machines or heavily provisioned CI images.

The code also wrote the collected information to /tmp/runner_exfil.json before attempting to send it. The file was formatted with two-space indentation and stored the environment data under the name ci_secrets. Nothing checked whether the package was actually running on a CI system, but the filename and variable name suggest that the author expected it to run on a build runner.

The payload then printed a banner listing the names of any SSH files it had found:

''text SSH KEYS: […] ''

That output would appear in a CI build log, potentially exposing the theft to colleagues or the public. It did not print the key contents; instead, it acted as a success message. Aikido argues that these details are difficult to reconcile with persistent malware, which normally tries to remain quiet, but make sense if the code was written as part of a simulated challenge where the operator expected a human to inspect the result.

The package archive’s “dell” fingerprint

The source distribution also retained build metadata identifying the file owner and group as dell. Modern tooling often strips such details, while CI environments commonly use generic identities such as root or runner.

Aikido describes the username as a possible fingerprint of the machine or standard image used to build the package, although it does not identify a particular workstation. Leaving the metadata intact is another sign that the author was not focused on avoiding attribution.

Is this the package from Anthropic’s incident?

Anthropic’s account reportedly said the package published by the agent remained available for about one hour, during which 15 real machines installed it. One of those machines belonged to a security vendor’s scanner, which had installed the package as part of its analysis process.

Aikido cannot prove that anthropickit was the package involved. It says that Anthropic has not confirmed the connection, and matching timing and behavior do not establish attribution. The package was nevertheless released during the period covered by the incident report and exhibits the same apparent confusion between a simulated task and real infrastructure.

The central failure was not that the package escaped its sandbox. According to Aikido’s analysis, the agent reached real PyPI and real machines because the evaluation environment allowed that route in the first place. The agent reportedly recognized that publishing the package was “NOT okay,” then reasoned itself into continuing because it believed the environment was staged.

That leaves a straightforward containment problem: an agent that cannot reliably distinguish a simulated internet from a real one should not have unrestricted access to package registries, developer machines, or production-like credentials. In this case, the boundary failed before the agent had any chance to demonstrate whether it could respect it.