pystr-codec runs a worm at every Python start that steals tokens and republishes itself

The short version

If you install pystr-codec 0.1.1, Python runs its startup file every time Python starts. Once per machine, that file downloads Bun from Bun’s official GitHub releases. Then it runs a 17 MB script that ships inside the package.

The script reads the keys and tokens that a developer keeps on the machine. It checks which ones can publish code. It then uses them to publish new releases of the victim’s own packages and to add workflows to the victim’s GitHub repositories.

Nothing runs during pip install. The code runs at the next Python start.

Timeline

• 31 Oct 2026, 22:21 UTC Version 0.1.0 goes up on PyPI. It carries the library code only.
• 31 Oct 2026, 22:46 UTC Version 0.1.1 goes up on PyPI, 25 minutes later. It adds the startup file and the 17 MB script.
• 31 Oct 2026, 22:58 UTC Vigilance flags it. The watcher compares 0.1.0 against 0.1.1 and sees a file that runs at every Python start. The old version had no such file. Twelve minutes after upload, with no signature and no prior report of this package anywhere.
• 31 Oct 2026, same evening We decode the script offline and report the package to the PyPI security team.
• 31 Oct 2026, 23:13 UTC PyPI still serves the package. OSV has no record for it.

What the update changed

Version 0.1.1 adds two files to the one wheel the package ships. Every other file stays the same, apart from the package metadata.

pystr_codec-0.1.0 → 0.1.1   py3-none-any

+ pystr_codec-setup.pth        1,391 bytes
+ pystr_codec/ci.js       17,908,149 bytes

Python reads every .pth file in site-packages at start. It runs any line that starts with import. This file holds one such line. Shortened, it does this:

if no file named .bun_ran in the temp folder:
    find ci.js on the Python path
    download bun-v1.2.18/bun-<os>-<arch>.zip from github.com/oven-sh
    unpack bun into <temp>/b/
    run: bun run ci.js
    create <temp>/.bun_ran

What the script does

We decoded ci.js offline in a locked container. It has three layers:

1. A hex string, shifted by a letter cipher, then passed to eval.
2. Two AES-128-GCM blobs, with the keys in the file. One is a helper that downloads Bun. The other is a 10.96 MB compressed script that runs in a new Bun process.
3. A bundle scrambled with a common JavaScript obfuscator. Its text table decodes with a changed base64 alphabet.

The decoded text names each part of the program in its log lines. These are the parts:

We read the text of the program. We did not run it, so we did not see where the dispatcher sends its results.

The same family

This loader matches the “Hades” wave of the Mini Shai-Hulud and Miasma worm. Socket reported that wave in June 2026: 37 wheels across 19 PyPI packages, each with a *-setup.pth file that downloads Bun and runs an obfuscated script. The Hacker News and GitLab covered it too.

We are the first to report pystr-codec. We are not the first to report this worm.

What the records showed

On 31 October 2026 at 23:13 UTC, OSV had no record for pystr-codec. Nothing runs during pip install, so an install-time sandbox sees a clean package. The payload sits under three layers of encoding and encryption, so a text search of the package finds no address and no secret path.

Who is behind it

The package metadata names no author, no home page, no licence and no project links. Both versions went up on the same day, 25 minutes apart. We did not identify the PyPI account behind it.

If you ran this

This applies to anyone who installed pystr-codec 0.1.1 and then started Python.

1. Uninstall the package: pip uninstall pystr-codec.
2. If pystr_codec-setup.pth is still in site-packages, delete it.
3. Delete .bun_ran, b and b.zip from the temp folder.
4. Rotate your credentials from a machine you trust:
   • SSH keys
   • AWS, Google Cloud and Kubernetes credentials
   • npm, PyPI, RubyGems and JFrog tokens
   • GitHub and GitLab tokens
5. Read the release history of every package your tokens can publish. Look for a release you did not make.
6. Read the workflows in every repository your GitHub token can write to. Look for a workflow or a force-push you did not make.

Indicators

Disclosure

Reported to the PyPI security team on 31 October 2026. We executed none of the malicious code. Everything here comes from the package files and the public PyPI records.

If you are the maintainer and you believe this is wrong, write to support@vigihq.com and we will publish a correction on this page.