Corgea’s weekly briefing shows supply-chain attacks are widening

At a glance

What this is: Corgea’s weekly briefing shows supply-chain attacks spreading across package ecosystems and developer tooling, with one poisoned VS Code extension leading to access to roughly 3,800 internal repositories.

Why it matters: This matters because the control boundary now includes developer workstations, package registries, build paths, and the identity-bearing tokens those environments can expose or abuse.

By the numbers:

• GitHub disclosed unauthorized access to roughly 3,800 internal repositories after the poisoned extension reached a developer workstation.

Context

Supply-chain compromise is no longer limited to a single vulnerable package or a one-off malicious release. In this briefing, the attack surface spans package registries, IDE extensions, build scripts, and developer workstations, which means the security boundary is now the software supply chain plus the identities and secrets living inside it.

For IAM and NHI teams, the relevant issue is not just code integrity. It is whether developer tooling, tokens, and workstation-level access are treated as governed assets with lifecycle controls, revocation paths, and monitoring comparable to other privileged entry points. The briefing’s examples show that this is now a typical attack path, not an edge case.

Key questions

Q: What breaks when developer tooling can reach repository secrets and cloud tokens?

A: When IDE extensions, packages, or autoloaded code can reach identity material, a single workstation compromise can become repository theft, pipeline abuse, and downstream cloud access. The failure is not just malware execution, but excessive trust in developer endpoints as if they were low-risk clients. That is why secret scoping and token lifecycle controls matter as much as malware prevention.

Q: Why do package and extension attacks create such broad impact?

A: Because they often execute inside trusted workflows that already have access to source code, build systems, cloud tokens, and cached sessions. Once the malicious component runs in that context, it can collect credentials, persist through developer automation, and pivot into systems that were never directly exposed to the original package.

Q: What are the signs that a supply chain compromise has reached identity exposure?

A: Look for unexpected secret access, unexplained token use, new startup services, abnormal package install events and credential rotation pressure after a dependency update. In practice, the warning signs are often downstream, because the malicious package may disappear before defenders notice. The key signal is that secrets were present on the affected host or runner.

Q: Should teams treat repository tokens and workstation sessions as high-risk NHIs?

A: Yes. Any token or authenticated session that can be replayed into source control, CI, or cloud services should be governed as a non-human identity with inventory, expiry, scope limits, and rapid revocation. That is the control model that matches the attack path described in the briefing.

Technical breakdown

Why IDE extensions behave like privileged software

A modern IDE extension can read files, reach package managers, invoke shell commands, and inherit workstation context that includes browser sessions, cloud tokens, and source control credentials. That makes it closer to executable code with ambient authority than to a harmless productivity add-on. In the GitHub case, the poisoned VS Code extension became the bridge from package compromise to workstation compromise and then to internal repository access. The security failure is the assumption that extension trust is bounded by the editor UI. In practice, the extension runtime expands the blast radius across the developer endpoint, the local credential store, and the organisation’s source repositories.

Practical implication: Treat extensions as code that can inherit workstation-wide privileges and control them through allowlisting, review, and endpoint monitoring.

How package ecosystems become post-compromise infrastructure

Malicious packages now serve two functions at once. First, they deliver initial execution through install hooks, import-time code, or build scripts. Second, they act as collection and persistence infrastructure by scanning for secrets, writing startup hooks, or altering developer workflows. TrapDoor is a clear example: it targeted wallets, SSH keys, GitHub tokens, cloud credentials, and AI coding-tool context, while also attempting persistence through shell profiles, git hooks, cron, and systemd. This is why software supply-chain defence cannot stop at signature checks or provenance alone. The attacker objective is operational access, not just code insertion.

Practical implication: Hunt for package behaviour at install and runtime, and separate integrity controls from secret-exposure detection across developer environments.

Why repository access is now an identity problem

Internal repositories are not simply storage locations for source code. They are identity-bearing systems because access is mediated through tokens, service accounts, and workstation-authenticated sessions that can be stolen, replayed, or chained into broader compromise. The GitHub breach shows how a compromised employee workstation and a poisoned extension can collapse the separation between endpoint trust and repository trust. That is an NHI governance problem as much as a software-supply-chain problem, because the exposed tokens and authenticated sessions are non-human credentials with high downstream reach. Teams that still manage source access as a purely developer-productivity issue will miss the control boundary.

Practical implication: Inventory repository tokens, CI credentials, and workstation-authenticated sessions as governed NHIs with explicit revocation and monitoring.

Threat narrative

Attacker objective: The attacker objective was to move from trusted developer tooling into internal source repositories and the secrets and access paths they contain.

1. Entry occurred through a malicious VS Code extension that reached a GitHub employee workstation after upstream supply-chain compromise.
2. Credential access followed when the workstation context exposed repository access that could be used to retrieve internal source assets.
3. Impact was the unauthorized exposure of roughly 3,800 internal repositories, demonstrating that one poisoned extension can become a repository-scale event.

Breaches seen in the wild

• GitHub internal repositories breach 2026: A stolen GitHub CLI token let attackers publish a poisoned Nx Console extension that harvested secrets and exfiltrated 3,800 GitHub repos.
• Laravel-Lang Composer compromise 2026: A stolen GitHub PAT let an attacker rewrite every Laravel-Lang release tag in May 2026, serving a PHP stealer of cloud, CI and SSH credentials.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Supply-chain security has become an identity governance problem, not only a software integrity problem. The briefing’s examples show that packages, extensions, and build hooks now target credentials as deliberately as code. Once a malicious component can inherit developer trust, the relevant control question becomes who or what can issue, reuse, and revoke access in that path. Practitioners should treat repository tokens, workstation sessions, and CI credentials as governed identities, not incidental secrets.

Developer tooling now has blast-radius characteristics that many programmes still do not model. IDE extensions, package install hooks, and build-time scripts can all reach beyond the narrow function they appear to serve. That creates what can be described as tooling trust expansion: a small trusted component gains access to files, tokens, and repositories that far exceed its apparent purpose. Teams should align control design to that expanded trust boundary, not to the tool’s marketing description.

Package ecosystems are now both delivery channels and persistence layers. The briefing shows attackers using npm, PyPI, Crates.io, and Composer not only to execute code but also to harvest secrets and establish follow-on access. That means provenance checks alone are insufficient when the payload’s real value is credential theft and downstream access. Practitioners should make secret detection, endpoint telemetry, and credential revocation part of the same supply-chain response model.

The line between NHI governance and secure development is collapsing. Source repositories, workstation sessions, and automation tokens all behave like non-human identities once they can be replayed, delegated, or used across systems. If those assets are not inventoried with the same discipline as human access, the organisation will keep discovering supply-chain incidents only after the repository boundary has already been crossed. The practical conclusion is to govern developer credentials as first-class NHIs.

From our research library:

• 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.
• Read next: Agentic AI Identity Guide

What this signals

Tooling trust expansion: IDE extensions and package hooks now act like privileged execution paths, so security teams should review them with the same rigor applied to CI runners and deploy keys. The practical shift is from trusting the developer tool to controlling the authority it can inherit.

The control question is no longer whether a package is signed, but whether it can reach secrets, sessions, and repositories at the point of execution. That pushes supply-chain defence toward endpoint telemetry, token scoping, and revocation-ready inventory rather than provenance alone.

For practitioners

• Map developer tooling to privileged trust zones Classify IDE extensions, package hooks, and build scripts by the data, credentials, and commands they can reach, then restrict high-risk tooling to approved lists and monitored endpoints.
• Inventory repository-bearing credentials as NHIs Track GitHub tokens, CI secrets, service accounts, and workstation sessions in one inventory so revocation can be triggered when endpoint or supply-chain compromise is suspected.
• Separate integrity controls from secret-exposure controls Use provenance, signing, and dependency verification to reduce tampering risk, but pair them with secret scanning and endpoint telemetry because many campaigns are designed to steal tokens rather than alter code.
• Monitor for install-time and runtime package behaviour Alert on package install hooks, unexpected network calls, shell profile edits, git hook writes, and persistence artefacts such as cron or systemd changes.
• Shorten the usable life of developer tokens Replace standing access with short-lived credentials where possible and tighten revocation workflows so a compromised workstation does not retain broad repository reach.

Key takeaways

• Supply-chain compromise now uses developer tooling as a route to secrets, sessions, and internal repositories, which makes the endpoint part of the software trust boundary.
• The GitHub incident shows how one poisoned extension can scale into repository-wide exposure, so the blast radius is determined by access inheritance as much as by the original package flaw.
• The strongest control response is to govern developer tokens, extensions, and build hooks as privileged assets with inventory, monitoring, and rapid revocation.

Key terms

• Developer Tooling Trust: The assumption that approved development tools are safe to run inside a workstation or engineering environment. In practice, extensions, plugins, and add-ons can inherit broad permissions and become identity-adjacent access paths when their trust is not bound to device posture and session scope.
• Secret Exposure Surface: Secret exposure surface is the set of places where credentials can be read, copied, or misused by systems and integrations. It includes environment variables, configuration stores, runtime memory, and connected tools. Reducing the surface means limiting both storage and reachability, not just encrypting data at rest.
• Repository-Bearing Credential: A token, session, or service account that can access source control, build systems, or related automation. These credentials are high value because they can reveal intellectual property, alter code paths, or provide a path into downstream infrastructure if they are stolen or reused.
• Tooling Trust Expansion: The pattern where a seemingly narrow developer tool inherits broad access to files, sessions, and repositories once installed on a workstation. The risk is not the feature set itself, but the widened authority that attackers can exploit once the tool is compromised or impersonated.

Deepen your knowledge

NHI Mgmt Group’s NHI Foundation Level course covers NHI governance, machine identity security, and secrets management in practitioner terms. It is designed for teams that need to connect identity controls to real operational risk across development and security programmes.