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.
Editorial analysis by NHI Mgmt Group, based on content published by Hush Security: “GitHub Is Investigating a TeamPCP Attack on Its Internal Repositories.”.
By the numbers:
- GitHub said the attacker’s claim of approximately 3,800 repositories was directionally consistent with findings so far.
- The first wave hit Aqua Security’s Trivy on March 19, 2026.
Key questions
Q: What breaks when trusted tools can read long-lived credentials on developer machines or CI runners?
A: The boundary between software execution and identity exposure breaks down.
Q: Why do reusable credentials increase supply chain risk in build systems?
A: Reusable credentials remain valid long enough to be copied, cached, logged, or exfiltrated.
Q: How do security teams know whether secret rotation is actually working?
A: Rotation is working only if exposed credentials are found quickly, revoked everywhere they are used and replaced before attackers can reuse them.
Practitioner guidance
- Audit standing developer and CI credentials Inventory GitHub PATs, npm tokens, PyPI tokens, cloud keys, and registry secrets that can be reached from workstations or runners.
- Replace reusable secrets with short-lived access Move high-risk build and developer workflows toward OIDC or other short-lived credential issuance so a compromised tool cannot hold a durable secret to reuse later.
- Pin and verify third-party build artefacts Lock extensions, actions, and packages to known-good commit references or approved versions, and separate publisher credentials from routine build access.
Bottom line: The article shows that the core problem is not a single poisoned extension but the presence of reusable credentials inside trusted execution environments.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
03/06/2026 2:29 pm
Long-lived credential exposure inside trusted execution environments is the core failure mode here: The attack did not need to defeat the developer tool model, only to inherit its trust. That means the real governance gap is not package trust alone but the decision to leave reusable credentials inside environments that execute unvetted updates. The practical conclusion is that trusted runtime access and standing secret presence cannot be governed as separate problems.
A few things that frame the scale:
- Internal repositories are 6x more likely to contain secrets than public ones (32.2% vs 5.6%), contradicting the assumption that private repos are safe, according to the State of Secrets Sprawl 2026.
A question worth separating out:
Q: Should organisations use short-lived tokens instead of standing credentials in CI/CD?
A: Yes, when the workflow involves external packages, extensions, or untrusted code execution. Short-lived tokens limit the value of a successful scrape and reduce the chance that one compromised runner can seed additional compromise. The key is to pair that move with tighter scope and separate publisher privileges.
👉 Read our full editorial: TeamPCP shows why long-lived credentials are still the real risk