GPT Pilot: ten months of a hidden credential stealer in core/telemetry, and a project left unmaintained

A malicious commit sat in the tree from August 2025 to June 2026

The README opens with a caution, not with an introduction, and that ordering is the point. Malicious code was found in the repository and has been removed. A supply-chain worm, described as a credential stealer, was hidden in the core/telemetry directory from August 2025 until 11 June 2026.

The notice dates the three events precisely. On 2025-08-24 a commit was pushed whose message was Revert 'Implemented weekend discount', which is what a routine revert looks like. It was publicly reported on 2026-06-08 by an external security researcher. The malicious files were removed on 2026-06-11.

The mechanism is described in the next section and it is worth reading in full rather than skimming, because the reassuring part of this story is narrow: the code only executed if the program was actually run, and a copy you cloned and never ran is not affected. The exposure window is therefore a list of machines, not a list of clones, and the README gives you the instructions for finding out which category you are in.

The payload harvested cloud keys, GitHub and npm tokens, and SSH keys

Here is what the commit added. A hidden loader, core/telemetry/_hooks.py, was wired in through core/telemetry/__init__.py so that it started automatically whenever the program ran. That loader silently downloaded the Bun JavaScript runtime and used it to execute an obfuscated payload, core/telemetry/_runtime.bin.

The payload is named as a Shai-Hulud-class supply-chain worm. It harvests credentials and secrets from the machine, with the README listing cloud and AWS keys, GitHub and npm tokens, SSH keys and similar, and it can use the stolen access to spread to other projects.

Two details make this worth understanding rather than merely worrying about. The first is that a telemetry package is exactly where a reviewer does not look, because telemetry is expected to reach outside the process, and reaching outside the process is the whole point of it. The second is that the payload used a JavaScript runtime downloaded at run time, which means a network-restricted machine would have been a different case from a laptop on a normal connection.

The ability to spread to other projects is the part that turns a local incident into a supply-chain one, and it is why the README's first instruction is to rotate credentials rather than to delete files.

The README's own checklist, in the order it gives it

If you cloned and ran GPT Pilot from source between August 2025 and 11 June 2026, the notice says to assume the payload may have executed and then gives three steps.

First, rotate every credential that was present on the machine: GitHub and npm tokens, cloud and AWS keys, SSH keys, and API keys. Every one of them, not the ones you think matter, because the description of the payload is that it harvests credentials and secrets rather than a chosen subset.

Second, check for indicators of compromise, and the README lists them: the files core/telemetry/_runtime.bin, core/telemetry/_hooks.py, or core/telemetry/.loader.lock; an unexpected bun binary; or temporary folders named with an rt- prefix.

Third, treat the machine as potentially compromised until you have verified that it is clean.

That is a short list and it is a good one, because each item is a file or a directory name you can look for. What the checklist deliberately does not offer is a tool to run, and that is the right call on a machine you now suspect.

The project says it is not maintained, and explains why the commit survived

The README states the project's status twice, in different registers. In the body it says this repository is not being maintained anymore and points to Pythagora.ai for more information. In the security notice it says the repository is no longer actively maintained, which is why the malicious commit went unnoticed for an extended period, and that the notice and the file removals are a security cleanup and not a resumption of development.

That second sentence is the one to hold on to. It removes the most natural assumption a reader would bring, which is that the fix implies the project continues. It does not. The last push to the repository was 2026-06-18, a week after the removals, and the project has no GitHub releases, so there is no tagged version to compare against and no branch that represents a supported state.

For anyone who was using GPT Pilot, the consequence is that there is nowhere to upgrade to from here. The article on the Pythagora site is the successor, and this repository is now the record of what happened and of what the project was.

The documented install is eight commands, and it is a research tool

The project itself was an experiment with a stated thesis. GPT Pilot aims to research how much can be done with LLMs to generate fully working, production-ready apps while the developer oversees the implementation, and the main idea is spelled out plainly: AI can write most of the code for an app, maybe ninety-five percent, but for the rest, five percent, a developer is and will be needed until full AGI arrives. There is a wiki page of example apps, and a blog post about what the team learned in six months of working on a code generation pair programmer.

The requirements are Python 3.9 and later, and the documented setup is a clone, a virtual environment, an install, a config file copied from an example, and one command to start:

git clone https://github.com/Pythagora-io/gpt-pilot.git
cd gpt-pilot
python3 -m venv venv
source venv/bin/activate
pip install -r requirements.txt
cp example-config.json config.json
python main.py

The configuration names three model providers, openai, anthropic and groq, with Azure and OpenRouter supported through the openai setting, and it notes that a null API key is read from the environment. The database is SQLite by default with PostgreSQL also supported, there is a setting for paths GPT Pilot should not track in the workspace, and generated code lands in a workspace folder named after the app you enter at startup.

The manifest describes pythagora-core, not gpt-pilot

Read the build file and you are looking at a different project. The package is named pythagora-core at version 2.0.10, described as building complete apps using AI agents, authored by one person, and the repository URL in the manifest points at Pythagora-io/pythagora-core rather than at gpt-pilot.

The licence line is the detail to notice. The manifest declares FSL-1.1-MIT, which is a different grant from MIT, so the LICENSE file in the repository is the document to read rather than an assumption based on the project's history. The GitHub licence field for the repository is unresolved.

The dependency list explains the architecture. Three model SDKs, openai, anthropic and groq, which matches the three providers the configuration offers. A prompt toolkit, which is how the interactive session works. tiktoken for counting. sqlalchemy with aiosqlite and alembic for the database layer. psutil for system information. tenacity for retries. And pydantic for the data model.

The tooling is ordinary and well configured: Poetry for the build, ruff at a line length of 120 targeting Python 3.9, and pytest with a ten second timeout per test and coverage measured over the core package, with database migrations and template files omitted from the report.

The container runs as uid 1000 with passwordless sudo and five exposed ports

The Dockerfile describes a cloud development environment rather than a service image. It starts from Ubuntu 22.04, sets a default target platform, and copies a VS Code extension package into an initialisation directory before anything else, which is a strong hint about what the image is for.

It installs dependencies through a setup script, builds a virtual environment, and adds the requirements file, the entry point, the core package and a Docker-specific configuration. It exposes five ports: 27017, which is the MongoDB port, and 8000, 8080, 5173 and 3000.

Then it creates a group and a user with uid 1000, sets a password, adds that user to sudo, and writes a sudoers entry granting it access without a password. So the image runs as a non-root user, and that user can become root without a password.

That combination is defensible for a container whose whole purpose is to run an editor and an agent together, and it would not be defensible for anything exposed. The honest way to read the file is as documentation of intent: this is a machine you log into, not a service you expose, and the five open ports are the editor, the agent and the database talking to each other.

Editorial conclusion

Use this repository as a security case study and as a record of the project's design, not as software. The project is explicitly unmaintained, there is no patched branch to move to, and the manifest now describes a different, renamed project at version 2.0.10 under a source-available licence rather than an MIT grant. If you cloned and ran GPT Pilot from source between August 2025 and 2026-06-11, follow the README's own checklist before anything else: rotate every credential that was present on the machine, check for the three telemetry files, an unexpected bun binary and temporary folders named rt-*, and treat the machine as compromised until you have verified it. If you were not affected, the honest summary is that having a copy you never ran is not affected, and the interesting question is why a ten-month-old credential stealer went unnoticed in a repository nobody was reviewing.

Frequently asked questions

Official sources

1. Official README
2. Project repository