PyPI Admin GitHub Token Leak 2024: How a Token in a Compiled Python File Sat in a Public Docker Image for 15 Months

On 8 July 2024, PyPI administrator Ee Durbin published an incident report revealing that a GitHub personal access token with administrator access to the Python, PyPI, Python Software Foundation and PyPA organisations on GitHub had been exposed in public Docker images for more than a year. Durbin had hardcoded the token into a local copy of Cabotage, the platform that deploys PyPI, to get around GitHub API rate limits. The source change was never committed, but compiled .pyc files containing the token ended up in images pushed to Docker Hub on 3 March 2023 and 20 July 2023. JFrog researchers found it with a secrets scanner that reads binaries and reported it on 28 June 2024. The token was revoked 17 minutes later. PyPI reviewed the audit logs and account activity available and found no indicators of malicious activity. JFrog said the token could have enabled one of the worst supply chain attacks imaginable.

At a glance

What happened

Cabotage is the deployment platform that runs PyPI. While working on it locally, Durbin hit GitHub API rate limits and, as his incident report explains, hardcoded a personal access token into the _fetch_github_file function in build.py. The change was never meant to be pushed. But a staging deployment script used git stash and git stash pop around the build, the application ran in Docker on a shared volume, and the project's .dockerignore did not exclude __pycache__ or *.pyc files. The compiled bytecode, with the token inside, went into the image even though the source did not. Durbin later called the shortcut "an act of laziness," as quoted by CSO Online.

Two images carrying the token were pushed to Docker Hub: cabotage/cabotage-app:v3.0.0b35 on 3 March 2023 and v3.0.0b110 on 20 July 2023. JFrog's researchers found it when their secrets scanning engine examined the compiled file __pycache__/build.cpython-311.pyc. JFrog describes it as "a leaked access token with administrator access to Python's, PyPI's and Python Software Foundation's GitHub repositories." With that access, an attacker could have changed the source of CPython or PyPI itself.

JFrog's Brian Moussalli reported the token to PyPI's security address and to Durbin at 7:09am Eastern on 28 June 2024. The token was destroyed at 7:26am. The images had already been removed from Docker Hub on 21 June for unrelated reasons. Durbin then reviewed "more or less all GitHub audit logs and account activity available" and concluded: "No indicators of malicious activity were found." He noted that GitHub's security logs do not go back more than 90 days, so the token's creation date is unknown. PyPI published its incident report on 8 July and JFrog its research the next day.

PyPI changed how it builds and deploys. Cabotage now builds only from clean source checkouts on self-hosted infrastructure, its internal registry admits only designated Kubernetes service accounts, and Durbin said he would avoid long-lived personal tokens and give any token a built-in expiry. "This is a great reminder to set aggressive expiration dates for API tokens (if you need them at all)," he wrote, as quoted by CSO Online.

Timeline

How it happened: the identity attack path

1. A human token used as a machine credential. A personal access token with all of the administrator's organisation rights was put into application code to call the GitHub API.
2. Left in a build artefact. The source change stayed local, but compiled bytecode holding the token was left on a shared volume.
3. Shipped in a public image. With no .dockerignore rule for .pyc files, the bytecode was built into images published on Docker Hub.
4. Exposed for 15 months. Anyone who pulled the images and inspected the bytecode could have recovered a working admin token.
5. Found and revoked. JFrog's binary scanning found it, and PyPI revoked it 17 minutes after the report.

Impact

• Exposure: a working token with admin access to the GitHub organisations behind CPython, PyPI, the PSF and PyPA was public in Docker Hub images for about 15 months.
• No confirmed misuse: PyPI found no indicators of malicious activity in the logs and account activity available, which cover only the most recent 90 days.
• Potential: an attacker could have pushed code to CPython or PyPI repositories, changed settings or planted backdoors, affecting the whole Python ecosystem. JFrog's view was that "Creating the 'one ring to rule them all' is always a bad idea," as quoted by CSO Online.
• Response: revocation within 17 minutes and changes to PyPI's build and token practices.

What this means for NHI governance

This case shows how human and non-human identity blur. The token was a personal access token, tied to a person and carrying everything that person could do. It was being used as a machine credential by an application. That is a common pattern, and it means a single leak exposes the full privileges of an administrator rather than the narrow access the task needed. A GitHub App or fine-grained token scoped to reading one repository would have made the same leak close to harmless.

It also shows that secret scanning has to cover what is shipped, not only what is committed. Compiled files, container layers, packages and build caches all carry secrets that never appear in a repository. The same lesson runs through the RWTH Aachen study of Docker Hub images and GitGuardian's PyPI research. See our Secrets Management Guide and Guide to the Secret Sprawl Challenge.

Recommendations

• Revoke and rotate as soon as a token is reported. PyPI destroyed the token in 17 minutes; have the contacts and authority in place to do the same. See our Leaked Credential Response Playbook.
• Do not use personal tokens as machine credentials. Use GitHub Apps or fine-grained tokens scoped to the repositories and permissions the job needs. See our NHI Authentication Guide.
• Set expiry on every token. Long-lived classic tokens with no expiry should be replaced, as Durbin recommends. See our Token and Session Security Guide.
• Scan build outputs, not just source. Scan container images, packages and compiled files for secrets before publishing. See our Secrets Management Guide.
• Build only from clean checkouts. Build release images in automated systems from clean source, and exclude caches and compiled files with .dockerignore.
• Keep audit logs longer than the platform default. Export source control audit logs so a long exposure can be investigated in full.

Frequently asked questions

Was PyPI or Python's GitHub hacked in 2024?

No compromise has been confirmed. An administrator's GitHub token with admin rights to the Python, PyPI, PSF and PyPA organisations was exposed in public Docker images for about 15 months. JFrog found it, PyPI revoked it within 17 minutes and found no indicators of malicious activity in the logs available.

How did the PyPI admin token leak?

The token was hardcoded during local development to avoid GitHub API rate limits. The source change was not committed, but compiled .pyc files containing it were built into Cabotage Docker images that were pushed to Docker Hub, because .dockerignore did not exclude them.

Who found the leaked PyPI token?

JFrog's security research team found it with a secrets scanner that inspects binary files, and reported it to PyPI on 28 June 2024. PyPI disclosed the incident on 8 July 2024.

Related NHI Mgmt Group resources

PyPI secrets exposure 2023 · Secrets in Docker Hub images 2023 · Home Depot token exposure 2025 · Secrets Management Guide · Leaked Credential Response Playbook

How NHI Mgmt Group can help

Personal tokens doing machine work are among the riskiest non-human identities in any organisation, because they carry a human's full privileges and rarely expire. We help teams find them, replace them with scoped machine identities and build fast revocation into incident response. See our NHI and AI agent security training.

References

• PyPI blog: Incident Report: Leaked GitHub Personal Access Token (8 July 2024)
• JFrog: Binary secret scanning helped us prevent (what might have been) the worst supply chain attack you can imagine (9 July 2024)
• CSO Online: Python GitHub token leak shows binary files can burn developers too (11 July 2024)