Notifications
Clear all
Topic starter
10/07/2026 9:16 pm
TL;DR: Deleting a PyPI package does not remove its underlying artifact, and TruffleHog 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.
NHIMG editorial — based on content published by TruffleHog: Admin on Apache Org Exposed for 2.5 Years in Deleted PyPI Package
Questions worth separating out
Q: What breaks when a deleted software package still contains secrets?
A: The assumption that deletion ends exposure breaks first.
Q: Why do deleted packages create NHI governance risk?
A: Because the risky object is usually a credential, not the package itself.
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.
Practitioner guidance
- 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.
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.
👉 Read TruffleHog's analysis of deleted PyPI packages exposing live secrets →
Deleted PyPI packages: are your secret remediation controls enough?
Explore further
10/07/2026 9:39 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Deleted PyPI packages can still expose live secrets for years
