TL;DR: Deleting a PyPI package does not remove its underlying artifact, and Truffle Security recovered 678,376 deleted releases containing 190 unique live secrets, including a GitHub PAT with admin access to Apache and Astronomer. Deletion is not revocation, and once a secret reaches a public ecosystem, rotation and revocation become the only reliable response.
At a glance
What this is: This research shows that deleted PyPI packages can still expose live secrets through persistent object storage, making package deletion an unreliable remediation step.
Why it matters: IAM, PAM, and NHI teams need to treat public secret exposure as irreversible until credentials are revoked and rotated, because deletion alone leaves a recoverable attack surface.
👉 Read Truffle Security's analysis of deleted PyPI packages and live secret exposure
Context
A deleted software package can still contain recoverable credentials long after the package name returns 404, which means the governance problem is not deletion but secret revocation. In this case the primary identity issue is NHI credential persistence inside published artifacts, not application code quality or package hygiene alone.
For IAM practitioners, the failure mode is familiar: once a secret enters a public ecosystem, the organisation loses control over who can retrieve it. That makes artifact deletion a weak signal for remediation, because the underlying credential may remain valid even when the package appears gone.
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 is package deletion not enough for secret remediation?
A: Because deletion changes visibility, not credential validity. A leaked secret can continue to authenticate to downstream systems long after the package disappears, so remediation has to focus on revocation, rotation, and downstream access review rather than removal alone.
Q: How do security teams find secrets in deleted software packages?
A: They should query historical package metadata, reconstruct storage paths where possible, and scan recovered artifacts for verified secrets. That approach matters because deleted releases may not surface in normal registry searches, even though their contents are still recoverable.
Q: What should teams do first after finding a credential in a public package?
A: Revoke the credential immediately, then confirm whether the same secret appears in forks, build logs, or other published artifacts. Public exposure means the secret should be treated as compromised even if the original package has already been deleted.
Technical breakdown
Why deleted PyPI artifacts remain reachable
PyPI can remove the registry pointer for a deleted package while the underlying object storage continues to serve the tarball through its direct file URL. That creates a split-brain state: the package is absent from the catalog, but the artifact still exists and can be fetched if someone knows or reconstructs the storage path. In practical terms, the public index and the storage layer are governed differently, which means deletion at the registry layer does not equal eradication at the object layer.
Practical implication: Treat package deletion as catalog cleanup, not secret remediation.
How public metadata can reconstruct hidden downloads
The article shows that PyPI’s public BigQuery metadata can be used to rebuild the object storage path for deleted releases. Because the metadata remains available even after deletion, an investigator can enumerate package names, identify deleted entries, reconstruct download URLs, and then scan the recovered artifacts for embedded secrets. That means the exposure surface includes not just live packages but also historical releases that appear removed from normal discovery flows.
Practical implication: Assume historical package metadata can make deleted artifacts discoverable again.
Why embedded secrets survive package deletion
Secrets embedded in package code remain valid until the issuing system revokes or rotates them, regardless of whether the package stays published, is deleted, or is republished. The article’s Apache and Astronomer case shows the operational risk clearly: a credential inside a deleted package still granted administrative access. The control failure is not just secret leakage, but the false belief that artifact removal invalidates the credential.
Practical implication: Design incident handling around revocation, not artifact removal.
Threat narrative
Attacker objective: Use recoverable package secrets to reach privileged access in SaaS, source control, or downstream supply chain systems.
- Entry occurs when a secret is committed into a package and published to PyPI, where it becomes part of a publicly accessible artifact.
- Credential access happens when the deleted package can still be downloaded from object storage or reconstructed from public metadata.
- Impact follows when the exposed secret grants administrative access or reaches downstream systems before revocation closes the window.
Breaches seen in the wild
- PyPI secrets exposure 2023: Researchers found 3,938 unique secrets in published PyPI packages, 768 still valid; a new release or yank does not remove them.
- Miasma and Hades Supply Chain Worms: Self-propagating supply chain worms Miasma and Hades compromise npm, PyPI, and Azure credential stores.
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: The control assumption that a removed package is no longer reachable fails when the storage layer preserves artifacts after registry deletion. That is a governance failure, not a user mistake, because the organisation has no assurance that deletion actually destroys the sensitive object. Practitioners should treat public artifact exposure as an irrevocable event until credentials are rotated or revoked.
Ghost persistence creates a long-tail exposure window: Historical releases can outlive the lifecycle decisions made by the package owner, so secret exposure is no longer bounded by the current state of the repository or registry. This widens the identity blast radius from a single bad release to every version that inherited the same credential. The practical conclusion is that artifact history must be governed as aggressively as live delivery paths.
Public metadata turns deletion into a recoverability problem: The BigQuery dataset and object storage path structure mean that deleted packages can remain algorithmically rediscoverable even when they disappear from normal package lookup. That makes inventory and ownership insufficient on their own. The real issue is whether the organisation can prove secret invalidation independent of artifact visibility.
Ephemeral artifact trust debt: Package ecosystems that preserve historical blobs accumulate hidden credential liability every time a secret is published, even if the package is later removed. That liability is invisible to teams that measure only live-package state. The implication is that remediation must shift from repository state to credential state, because exposure persists after deletion.
Lifecycle controls must follow the secret, not the package: NHI governance breaks when offboarding logic is tied to artifact deletion instead of credential revocation. A package can disappear while the secret inside it remains active across external systems. Practitioners should reframe the control boundary around the credential’s lifecycle, not the artifact’s lifecycle.
What this signals
Ghost persistence: When package registries retain downloadable artifacts after deletion, identity governance has to move from object removal to credential invalidation. The operational question is not whether the package still exists in the UI, but whether any secret embedded in it can still authenticate elsewhere.
Public artifact history is now part of the attack surface for software supply chains. If a package can be reconstructed from metadata and storage paths after deletion, then secret scanning has to extend beyond live repositories into historical release inventory and incident response workflows.
For practitioners
- Revoke exposed credentials before deleting artifacts When a secret has been published to any public ecosystem, assume it can be recovered and used regardless of later package deletion. Revoke the credential first, then remove or quarantine the artifact so the cleanup order does not leave a live token behind.
- Search historical package metadata for leaked secrets Review public release metadata, not just current package listings, to find deleted artifacts that still contain credentials. Build this into incident response so secret hunting covers the full publication history, including packages that no longer appear in the registry.
- Separate artifact retention from credential validity Create a policy that treats artifact deletion, repository deletion, and secret revocation as distinct controls with different outcomes. Document which action removes visibility and which action removes access, because only revocation changes the credential state.
- Scan every release for embedded secrets before publishing Use secret scanning on source trees, build outputs, and packaged artifacts so credentials are caught before they reach public distribution channels. The important control point is pre-publication because post-publication deletion does not guarantee disappearance from storage.
- Track secret ownership across package lifecycles Assign an owner to each credential that appears in released software and require explicit confirmation when packages are deleted or deprecated. Ownership matters because revocation and replacement depend on knowing who can act on the exposed secret.
Key takeaways
- Deleting a package does not necessarily remove the secret it contained, so remediation based on artifact removal alone is incomplete.
- The article recovered 678,376 deleted releases and 190 unique live secrets, showing that historical package data can still expose active credentials.
- The control that matters is credential revocation and rotation, backed by historical scanning of package releases and metadata.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Deleted packages still expose live secrets because artifact removal does not remove access. |
| NHI-02 — Secret Leakage | The article is about credentials leaking into public PyPI artifacts and remaining recoverable. | |
| NHI-07 — Long-Lived Secrets | Secrets in deleted packages can stay valid long after publication, extending exposure windows. | |
| Recommendation — Treat package deletion as incomplete offboarding until every embedded credential is revoked. Scan released artifacts for leaked secrets and revoke anything exposed in public distribution channels. Replace long-lived package secrets with short-lived credentials and enforce rapid rotation after exposure. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Credential lifecycle and revocation are central to the remediation problem described here. |
| Recommendation — Apply IA-5 to enforce prompt rotation and revocation of exposed authenticators. | ||
| MITRE ATT&CK | TA0006 — Credential Access | Recovered package secrets provide direct credential access to downstream systems. |
| Recommendation — Map leaked package secrets to TA0006 and prioritise the exposed authenticators for containment. | ||
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.
- Secret revocation: Secret revocation is the process of invalidating exposed credentials so they can no longer be used. In practice, it must include every system that trusts the secret, because a credential that remains valid after disclosure is still an active attack path.
- Artifact Deletion: The removal of a package or release from a registry interface or catalog. It changes discoverability, but it does not necessarily destroy stored content or invalidate credentials embedded in that content, so it should never be treated as a security control on its own.
- Historical Package Metadata: Public or retained release data that describes previously published software artifacts even after the artifact is no longer visible in the registry. Attackers and defenders can use it to reconstruct download paths, identify deleted versions, and locate secrets that still exist in storage.
What's in the full report
Truffle Security's full article covers the operational detail this post intentionally leaves for the source:
- The exact PyPI recovery method used to enumerate deleted releases from public metadata
- Step-by-step reconstruction of object storage URLs for deleted package artifacts
- The TruffleHog scanning workflow used to detect verified secrets in recovered tarballs
- The PyPI policy response on when underlying storage is hard-deleted and why deletion has limited effectiveness
👉 Truffle Security's full post covers the recovery method, secret counts, and PyPI persistence details
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.
Published by the NHIMG editorial team on July 10, 2026.
Updated on October 5, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org