Notifications
Clear all
Topic starter
03/06/2026 2:22 pm
TL;DR: GitHub is investigating unauthorized access after a poisoned VS Code extension reportedly enabled internal repository exposure, with the attacker claim directionally consistent with GitHub’s findings and the campaign already tied to more than 500,000 infected machines and 300 GB of harvested credentials, according to Hush Security and Palo Alto Networks Unit 42. The central lesson is structural: standing credentials inside trusted environments remain the easiest thing to steal and the hardest thing to govern.
NHIMG editorial — based on content published by Hush Security covering the TeamPCP supply chain attack and GitHub investigation
By the numbers:
- The attacker claims approximately 3,800 repositories were accessed.
Questions worth separating out
Q: How should security teams reduce secret exposure in CI and developer workflows?
A: They should eliminate long-lived credentials wherever possible, replace them with short-lived or task-scoped access, and make sure secrets are never left on disk or in reusable environment variables.
Q: Why do trusted tools and extensions create such high credential risk?
A: Because trust in the tool does not limit what the tool can read once it is running in a privileged environment.
Q: What breaks when credential rotation is incomplete?
A: The old secret may still exist in overlooked systems, dependent tokens may keep working, and the attacker may already have copied what they need before rotation finished.
Practitioner guidance
- Inventory every standing developer and pipeline credential Map GitHub PATs, npm tokens, PyPI tokens, cloud keys, and internal publishing credentials to a named owner, a purpose, and a known expiry.
- Replace reusable secrets with short-lived access Move build and deployment flows toward OIDC or other task-scoped issuance so a compromised runner has less durable material to steal.
- Pin and validate trusted supply chain components Use commit SHA pinning for third-party actions, verify package provenance where possible, and review any workflow that consumes external extensions or release tags.
What's in the full analysis
Hush Security's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step description of the TeamPCP attack path across poisoned extensions, CI runners, and downstream package propagation.
- Detailed breakdown of the exact credential types harvested from files, memory, and local tooling, including publishing tokens.
- Hush-specific architecture for replacing standing secrets with policy-driven, just-in-time access tied to verified identity.
- Implementation examples for runtime observability across developer, container, and serverless environments.
👉 Read Hush Security's analysis of the TeamPCP supply chain attack on GitHub →
Long-lived credentials in trusted tools: what IAM teams are missing?
Explore further
03/06/2026 2:29 pm
Standing credential trust debt is the real failure mode here. The article is not mainly about a poisoned extension, it is about the amount of access that extension could inherit from the environment. Long-lived secrets in trusted developer and CI contexts create a hidden debt that attackers can cash out the moment execution is compromised. Practitioners should read this as a governance problem, not a tooling anomaly.
A few things that frame the scale:
- The group is believed to have exfiltrated data from more than 500,000 infected machines and harvested over 300 GB of credentials and secrets, according to AI Agents: The New Attack Surface report.
- Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
A question worth separating out:
Q: Who should be accountable for secrets hidden inside build and release pipelines?
A: Ownership should sit with the teams that operate the workflow and the identity controls that authorize it, not with the security team alone. If a pipeline can reach production systems, package registries, or internal repositories, its credential posture belongs in governance reviews, access recertification, and incident response planning.
👉 Read our full editorial: TeamPCP shows why long-lived credentials are still the real risk
