Topic starter
10/07/2026 9:16 pm
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.
Editorial analysis by NHI Mgmt Group, based on content published by Truffle Security: “Admin on Apache Org Exposed for 2.5 Years in Deleted PyPI Package”.
Key questions
Q: What breaks when a deleted software package still contains secrets?
A: The assumption that deletion ends exposure breaks first.
Q: Why is package deletion not enough for secret remediation?
A: Because deletion changes visibility, not credential validity.
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.
Practitioner guidance
- 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.
- Search historical package metadata for leaked secrets Review public release metadata, not just current package listings, to find deleted artifacts that still contain credentials.
- Separate artifact retention from credential validity Create a policy that treats artifact deletion, repository deletion, and secret revocation as distinct controls with different outcomes.
Bottom line: Deleting a package does not necessarily remove the secret it contained, so remediation based on artifact removal alone is incomplete.
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
👉 Read Truffle Security's analysis of deleted PyPI packages and live secret exposure →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
10/07/2026 9:39 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Deleted PyPI packages can still expose live secrets for years