Deleted PyPI packages can still expose live secrets for years

At a glance

What this is: TruffleHog shows that deleted PyPI packages can remain retrievable and still contain live secrets, turning package deletion into a false sense of remediation.

Why it matters: IAM, PAM, and NHI teams need to treat public-package exposure as a credential compromise event because deletion does not reliably remove access paths or revoke secrets.

👉 Read TruffleHog's analysis of deleted PyPI packages exposing live secrets

Context

A deleted package is not the same as a revoked credential. In this case, the package artifact remained reachable through object storage even after the registry UI returned 404, which means the exposure window continued long after the owner believed the code had been removed.

For IAM and NHI programmes, this is a classic secret-remediation failure: public distribution channels, backup object stores, and metadata services can preserve access paths that deletion workflows do not touch. The result is hidden persistence, not real removal.

The primary issue is not package hygiene alone. It is whether security teams treat any secret that has entered a public ecosystem as compromised and manage it with revocation, rotation, and exposure hunting rather than with deletion alone.

Key questions

Q: What breaks when a deleted software package still contains secrets?

A: The assumption that deletion ends exposure breaks first. If the artifact remains retrievable or its metadata still points to downloadable content, the secret is still a live credential risk. Security teams must treat the secret as compromised until it is revoked, rotated, and verified inactive across every place it could be replayed.

Q: Why do deleted packages create NHI governance risk?

A: Because the risky object is usually a credential, not the package itself. API keys, PATs, and cloud tokens inside deleted artifacts can still grant access to repositories and services, which turns software retention into identity exposure. That makes deletion a poor proxy for revocation in any IAM or NHI programme.

Q: How do security teams know if a leaked package secret is still dangerous?

A: They test the credential against the services it could access and confirm whether it has been revoked or expired. If the secret still authenticates, the risk is active regardless of whether the source package is deleted. The key signal is live authorisation, not the visibility of the artifact.

Q: What should teams do after a secret is found in a public package?

A: They should contain the exposure by revoking or rotating the credential, tracing its downstream permissions, and reviewing every related repository, cloud account, and automation path. The correct response is lifecycle action on the identity, not just removal of the file that contained it.

Technical breakdown

Why deleted package artifacts remain reachable

PyPI can remove the package entry from its API while the underlying object storage still serves the tarball through a direct URL. That creates a split between logical deletion and physical retention. From an identity security perspective, the code package is not the only asset in play. Any embedded secret, token, or key inside the artifact remains a live credential risk until it is revoked. The central failure is assuming registry deletion equals secret removal.

Practical implication: Treat package deletion as an administrative change, not a security control, and search exposed artifacts before assuming the secret is gone.

How metadata reconstructs hidden access paths

The article shows how public BigQuery metadata can be used to reconstruct download paths for deleted releases. Because the metadata is not removed when a package disappears, attackers or researchers can enumerate package names, recover object paths, and retrieve the original files. This is a governance problem as much as a technical one, because the access path survives through another system even when the front door closes.

Practical implication: Inventory where build and package metadata is retained, then assume that any public metadata may still lead to recoverable secrets.

Why leaked secrets in packages become NHI incidents

Secrets in source packages are non-human identities in practice: API keys, PATs, and cloud credentials that grant machine access without human presence. Once those credentials are exposed, they can be used for org admin, repository access, or downstream service control. The issue is not just leakage but standing privilege that remains valid after the package is deleted. That is why secret exposure in software supply chains is an NHI governance issue, not only a code hygiene issue.

Practical implication: Classify exposed package secrets as NHI compromises and drive them through revocation, rotation, and downstream entitlement review.

Threat narrative

Attacker objective: The attacker objective is to recover valid secrets from deleted software artifacts and use them to gain privileged access to repositories, cloud services, and downstream supply-chain assets.

1. Entry occurred when credentials were embedded in published PyPI packages that later became publicly retrievable through deleted-artifact storage paths.
2. Escalation occurred when a base64-encoded GitHub PAT in one package granted admin access to the Apache and Astronomer organisations, while other packages exposed additional OAuth tokens and cloud keys.
3. Impact followed when exposed secrets could be used to compromise repositories, admin workflows, and downstream supply-chain systems before the organisations revoked the credentials.

Breaches seen in the wild

• Google Firebase misconfiguration breach — Firebase misconfigurations exposed 19.8M secrets across developer instances.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Deletion is not revocation, and that distinction breaks NHI remediation logic. The article shows a credential can remain recoverable even after the package that contained it is deleted, which means the secret itself must be treated as the security object. Deletion removes visibility, not necessarily accessibility. The practitioner conclusion is simple: remediation must start from credential state, not artifact state.

Ghost persistence is the right concept for retained package artifacts with embedded secrets. A registry can present a clean 404 while object storage still serves the file and public metadata still reveals how to retrieve it. That combination creates a hidden persistence layer for secrets that most hygiene workflows never inspect. Security teams need to assume package deletion may mask, not eliminate, exposure.

Package secrets are workload identities with an unbounded exposure lifecycle. The GitHub PAT in this case granted org admin access, which makes it an NHI issue, not just a software supply-chain issue. Once a secret is published, its lifespan is detached from the package lifecycle and tied to wherever that credential can be replayed. The practitioner implication is that credential governance must extend into build, packaging, and release workflows.

Access reviews cannot compensate for secrets that outlive their container. Review processes are built around visible assets and current ownership, but this case shows a secret can survive after the owner deletes the package and stops thinking about it. That breaks the governance assumption that removal of the source artifact reduces risk in a timely way. The conclusion for IAM and PAM teams is to review exposure paths, not just entitlement lists.

Secret sprawl in public ecosystems creates blast radius far beyond the original project. One package can expose admin-level access to multiple organisations and downstream systems, which means the security boundary is not the code repository alone. This is where NHI governance meets software supply-chain security: a single credential can traverse multiple administrative domains. Practitioners should treat any public exposure as a cross-domain identity event.

From our research:

• 88.5% of organisations acknowledge that their non-human IAM practices lag behind or are merely on par with their human identity and access management efforts, according to The 2024 Non-Human Identity Security Report.
• 23.7% of organisations share secrets through insecure methods such as email or messaging applications.
• For related guidance: The Guide to the Secret Sprawl Challenge explains how exposed credentials spread across build, release, and storage systems.

What this signals

Ghost persistence is becoming a practical governance blind spot. If a registry can hide an artifact without removing the file, then lifecycle controls need to move from the visible package to the credential hidden inside it. That is especially true when 88.5% of organisations already say their non-human IAM practices lag behind or merely match human IAM, according to The 2024 Non-Human Identity Security Report.

Teams should expect supply-chain exposure handling to converge with NHI lifecycle governance. A leaked token in a public package is not a code-quality issue in isolation. It is a credential lifecycle event that should trigger revocation, scoped access review, and downstream dependency inspection.

Secret sprawl will keep defeating deletion-based remediation. Public metadata, object storage, and package mirrors create a retention layer that security teams do not always account for. The practical response is to build exposure hunting into release, deprecation, and offboarding workflows so removed code does not continue to leak live identity.

For practitioners

• Revoke first, rotate immediately Treat any secret discovered in public packages, commits, or releases as compromised and revoke or rotate it before investigating scope.
• Search deleted artifacts as part of exposure response Include package registries, deleted releases, cached artifacts, and object storage in the same hunting workflow because deletion may not remove the file.
• Map embedded secrets to downstream admin scope Trace every exposed token to the repositories, cloud accounts, and SaaS organisations it can reach, then review the entitlement path for standing privilege.
• Classify public-package secrets as NHI incidents Route exposed PATs, API keys, and cloud credentials through NHI governance, incident response, and credential lifecycle controls rather than treating them as simple code clean-up.
• Add exposure scanning to release and deletion workflows Scan package releases before publication and again after deletion so teams detect embedded secrets and stale copies that remain in storage or metadata services.

Key takeaways

• Deleted packages can still contain live credentials, so deletion is not a valid substitute for revocation.
• A single leaked PAT or API key can still reach org-admin scope, which makes package secrets an NHI governance issue.
• Security teams need exposure hunting, credential revocation, and downstream entitlement review, not file deletion alone.

Key terms

• Ghost Persistence: The retention of a deleted software artifact in backend storage or metadata systems after the user interface says it is gone. In identity terms, it matters because embedded secrets can remain recoverable and replayable even when the package appears removed from circulation.
• Credential Revocation: The act of making a credential unusable so it can no longer authenticate or authorise access. For NHI governance, revocation is the security action that matters after public exposure, because deletion of the surrounding file or package does not invalidate the secret itself.
• Standing Privilege: Persistent access that remains valid until someone explicitly removes it. In this article’s context, a leaked PAT with admin scope is more dangerous because it can be reused at any time, making the credential itself a long-lived identity risk across systems.
• Secret Sprawl: The uncontrolled spread of credentials across code, build systems, release artifacts, logs, and storage. The risk is not only leakage but also the number of places a secret can survive after publication, making discovery, revocation, and lifecycle ownership harder to maintain.

What's in the full report

TruffleHog's full article covers the operational detail this post intentionally leaves for the source:

• The exact BigQuery queries used to reconstruct deleted PyPI download paths and enumerate affected packages.
• The scanning workflow used to validate secrets inside recovered artifacts, including command-line examples and detection coverage.
• The breakdown of secret types, package counts, and version patterns that explain how widely the exposure spread.
• The response details for the Apache and Astronomer credential disclosure, including verification and revocation timing.

👉 The full TruffleHog post covers the recovery method, secret counts, and exposure patterns across deleted releases.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.