Category: Breaches

From Aqua’s Trivy to Checkmarx’s KICS to LiteLLM, and now potentially GitHub itself: the same pattern, the same root cause. Long-lived credentials sitting in trusted environments with nothing to protect them.v

Source: https://www.linkedin.com/feed/update/urn:li:activity:7462597834907885568/

As of this morning, GitHub is investigating unauthorized access to its internal repositories after TeamPCP listed what it claims is the platform’s source code and internal organization data for sale on a cybercrime forum. GitHub stated the investigation is ongoing and that the attacker’s claim of approximately 3,800 repositories is “directionally consistent” with findings so far. The reported entry vector: a poisoned VS Code extension that compromised an employee device. GitHub says it has rotated critical secrets and found no evidence of impact to customer data outside its internal repositories.

If the claims hold, this would be the most consequential escalation in a campaign that has already compromised some of the most trusted tools in the developer ecosystem. The reported pattern is strikingly familiar: a poisoned trusted extension, credentials harvested from the environment it was running in, and lateral access to internal infrastructure. That pattern has played out at least four times already in the past two months.

Whether the target is a CI runner or a developer’s laptop, the mechanics are the same: a trusted tool with access to long-lived credentials is turned against its own environment. The entry point changes. The root cause does not.

According to Palo Alto Networks Unit 42, the group is believed to have exfiltrated data from more than 500,000 infected machines and harvested over 300 GB of credentials and secrets (citing vx-underground as the source for those figures). The first wave hit Aqua Security’s Trivy on March 19, 2026. Checkmarx’s KICS followed on March 21. LiteLLM on March 23. Telnyx on March 27. TanStack and durabletask have since been added to the list. And now, potentially, GitHub itself.

How the TeamPCP Supply Chain Attack Works

The pattern across every TeamPCP wave is the same. The attacker uses previously stolen credentials to poison a trusted tool’s release tags. Downstream CI/CD pipelines pull the poisoned version during a routine build. The payload executes before the legitimate tool logic, then harvests every long-lived credential it can find: cloud IAM keys via IMDS, secrets in /proc/<pid>/mem (bypassing GitHub Actions’ log masking), .env files, SSH keys, kubeconfig, Docker registry credentials, and publishing tokens for npm and PyPI. Those publishing tokens become the fuel for the next wave: 47 additional packages were poisoned in under 60 seconds.

Figure 1: The TeamPCP attack vector. Each stage feeds the next using credentials harvested from the previous one.

The root cause is not the compromised tool. It is the long-lived, broadly scoped credentials sitting in every runner waiting to be harvested. Rotation does not fix this: Aqua Security rotated credentials after a February breach, but the rotation was incomplete, and TeamPCP came back weeks later. SBOM tools cannot detect a malicious version of a package whose previous release was clean. SHA pinning helps but breaks the moment a maintainer account is hijacked. The structural fix is to remove the thing being harvested.

How Hush Eliminates the Attack Surface

At Hush, we built Universal Access Management around a simple thesis: the long-lived static credential is not a security primitive. It is the vulnerability. Our platform replaces standing credentials with policy-driven, just-in-time access tied to verified workload identity, alongside a runtime sensor that sees every non-human identity in your environment.

Figure 2: Hush as the structural defense against the TeamPCP attack vector.

SPIFFE identity as a service

Hush issues each workload a cryptographically signed SPIFFE ID, derived from attributes like its Kubernetes namespace, service account, node identity, and container image. You do not stand up your own SPIRE server. When the workload needs access to a resource, Hush evaluates a policy in real time and a Dynamic Credential Provider mints a short-lived credential scoped to the task at hand. The credential is generated only when access is actively requested. The task completes. The credential expires.

Two paths: fully secretless, or Hush-orchestrated Vault

For workloads you are ready to convert, Hush operates as a Secretless Access Management Platform: credentials originate from Hush’s internal secret abstraction engine, fully managed and rotated. For everything else, Hush orchestrates your existing secret backends (HashiCorp Vault, AWS Secrets Manager, Kubernetes Secrets) via policies tied to verified SPIFFE identity. Either way, the workload no longer holds a long-lived static credential at rest, and the SaaS control plane never sees secret material.

Runtime observation of every non-human identity

Hush deploys an eBPF-based sensor (with a Java agent for JVM workloads and a Lambda layer for serverless) that watches every non-human identity in flight. It sees which workload reads which credential from which location. It flags identity behavior in real time, regardless of whether the binary is signed, trusted, and called “Trivy”. Static scanning cannot find malicious behavior in trusted binaries. Runtime observation can.

TeamPCP Against a Hush-Protected Pipeline

Here is what happens when the same attack hits a Hush-protected environment.

What the payload attempts at each step, and what Hush does about it.

Step 1 — Poisoned Trivy action scrapes for secrets Payload: Attacker injects malicious code into the legitimate scan. The payload escalates scanner privileges and sweeps the runner for credentials — .env files, .npmrc, .dockerconfig, kubeconfig, and any backup or config files that typically hold long-lived API keys or service tokens.

→Hush response: No secrets stored on disk. Credentials are never written to the filesystem. Cloud access is mediated by the Hush Dynamic Credential Provider — credentials are issued on demand, only when a workload is actively making a request. The scan finds nothing to take.

Step 2 — Searches for publishing tokens to propagate Payload: Payload looks for npm tokens, PyPI publishing tokens, and GitHub PATs to infect downstream packages and trigger Stage 2 worm propagation.

→Hush response: No publishing tokens. Stage 2 cannot start. Long-lived tokens do not exist in the runner. The self-propagating worm loop is cut. Nothing to harvest, nothing to push.

Bottom line: The build ships. The legitimate scan completes. Your team has nothing to rotate, because nothing was exposed.

The payload finds no credentials, no secrets on disk, and no publishing tokens in the runner. The one short-lived token it extracts from process memory expires before TeamPCP’s C2 can use it. Stage 5 propagation cannot start. The build ships. Your team has nothing to rotate.

What to Do Now

Practical guidance for security practitioners:

• Audit every long-lived GitHub PAT, PyPI token, and npm token in your organization. Shorten lifetimes or replace with OIDC.
• Pin third-party GitHub Actions to commit SHAs, not version tags.
• Restrict outbound network egress from CI runners.
• Verify that any past credential rotation was actually complete.
• Inventory your non-human identities: how many exist, who owns them, and what they can reach.
• Add runtime observability for NHIs. SBOM tools and static scanners will not tell you about behavior.

The static credential was a primitive that made sense for a different era of computing. The TeamPCP campaign is what it looks like when that era ends.

See how Hush protects your environment

If you want to see how this looks in your own environment, my team is happy to walk through it. Request a demo at hush.security/demo. or start for FREE  
The TeamPCP playbook depends on something to steal. Let’s stop leaving it lying around.

Shai-Hulud Proved It: Attackers Hunt NHIs First, Because That’s Where the Power is

Shai-Hulud wasn’t loud for the sake of noise, it was a powerful, well-structured attack that understood the modern software ecosystem better than many defenders do. And it validated the clearest trend in 2025 security: attackers prioritize non-human identities (NHIs) over everything else.

Shai-Hulud’s Behavior Made Attacker Priorities Obvious

When the worm executed, it immediately searched for automation credentials. It pulled CI/CD runner tokens from environment variables, harvested GitHub PATs from local configs, and scraped cloud access keys from developer machines and build logs. These weren’t random secrets, they were machine identities with the authority to deploy, publish, and operate real infrastructure.

A single stolen npm publish token allowed the attacker to republish more than twenty packages in one hop. Stolen GitHub PATs gave access to private repos and workflows. Cloud keys from AWS, GCP, and Azure provided infrastructure-level permissions. The worm didn’t need human credentials; NHIs already carried the power to move laterally, escalate, and replicate.

We offer a free Shai-Hulud impact assessment to help determine whether your environment was affected and to identify any exposed secrets. Request your free check here: https://www.hush.security/shai-hulud-assessment
What makes our check different
Unlike static/API scans, our assessment inspects secrets in runtime, outside-in and inside-out, to find active abuse paths and deliver a prioritized remediation report.

Why NHIs Made the Attack So Effective

Shai-Hulud didn’t rely on fragile tricks. It leaned on identity realities: NHIs are everywhere, heavily privileged, and rarely monitored.

TruffleHog embedded in the payload searched through git histories, CI caches, and artifact directories, all places where forgotten NHIs hide long after their supposed rotation. That’s why the worm exfiltrated thousands of valid automation credentials. It understood that machine identities live longer than developers expect and accumulate more privilege than anyone tracks.

Propagation was driven entirely by NHI permissions. The worm enumerated every package a compromised identity could publish and used that privilege graph to spread. It wasn’t exploiting vulnerabilities, it was exploiting how software engineering works.

What the Attack Validates

Shai-Hulud proved that the fastest way to gain real control in a modern environment is through the identities that automate everything. NHIs publish packages, trigger pipelines, deploy infrastructure, sign builds, and access cloud resources. Their compromise leads directly to production impact.

Attackers know this. Shai-Hulud showed it plainly.‍

What Organizations Must Do Next

The takeaway isn’t to dismiss the attack, it was powerful. The takeaway is to align defenses with what attackers already prioritize.

Organizations need visibility into NHIs, lifecycle control for tokens and keys, and a recognition that CI/CD is now a production attack surface.

Shai-Hulud exposed the gap between how companies treat machine identities and how attackers exploit them.

‍

We offer a free Shai-Hulud impact assessment to help determine whether your environment was affected and to identify any exposed secrets. Request your free check here: https://www.hush.security/shai-hulud-assessment
What makes our check different
Unlike static/API scans, our assessment inspects secrets in runtime, outside-in and inside-out, to find active abuse paths and deliver a prioritized remediation report.

‍

When my co-founders and I started Hush Security, one thing was painfully clear: the way companies manage secrets is broken for today’s world. Vaults and secret managers solved yesterday’s problem, storing static secrets for predictable, human-driven systems.

But today’s environments are anything but predictable. Cloud-native architectures, microservices, ephemeral workloads, CI/CD pipelines, and now agentic AI have turned machine-to-machine communication into a fast, dynamic, and complex mesh. In this reality, static secrets aren’t just outdated, they’re a liability.

Having worked together for the past decade driving product innovation in cloud security, Shmulik Ladkani, Chen Nisnkorn, Alon Horowitz, and I decided it was time to disrupt the machine-to-machine access space. Instead of building more secret scanners, we founded Hush Security to deliver technology that empowers security and operations teams to completely rethink how they manage machine access, replacing outdated approaches of secrets and vaults with a solution built for today’s scale, speed, and complexity.

Why Vaults Are Failing

Vaults were built for an era when environments were static and identities were few. A secret could be created, stored in the vault, rotated occasionally, and remain valid for months, or even years. That worked when you had monolithic apps, running on-prem and mostly talking to each other in a walled garden.

Today, environments change by the second. Containers spin up and down in milliseconds, and they converse with SaaS and services, both internal and external across the internet. Developers deploy dozens of changes daily. AI agents execute workflows we didn’t anticipate in advance. In this world:

• Secrets sprawl across pipelines, repos, and multiple vaults (“vault sprawl”).
• Long-lived, static credentials outlast the workloads they’re tied to.
• Human processes and labor can’t keep up with modern machine access needs.
  ‍

The result? An operational mess for DevOps, blind spots for security, and a wide fertile attack surface for adversaries.

Breaches prove the point. In one of many identity-related attacks, back in 2022, Uber had privileged access management (PAM) in place and strong security measures, yet attackers still gained full access after finding a hardcoded vault admin password in a script. A single leaked credential unraveled everything. In a recent breach involving Salesloft Drift, hundreds of OAuth tokens were exfiltrated and abused, compromising 700 tech companies.

Vaults can store secrets securely, but they can’t stop secrets from leaking, being reused, forgotten or being abused.

Agentic AI Makes It Worse

Agentic AI, autonomous agents that carry out autonomous business workflows, and connect programmatically on behalf of users and applications without governance and oversight, magnifies the problem. These agents make real-time decisions: querying databases, deploying services, calling APIs.

Traditional secret provisioning workflows fail here because:

• Secret excessive sprawl – Agents and MCPs require lots of access, extending the risk and the attack surface.
• Vibe coding and Shadow AI – secrets are embedded in code, unsupervised and unmanaged.
• Principle of least privilege breaks – giving AI broad, long-lived access is a security nightmare.
  ‍

The result? Either AI agents are blocked from doing their jobs, or they’re given wide privileges tokens that violate the Zero Trust approach. Neither is acceptable. And with AI agents exploding in number, along with the number of exposed and abused secrets, the status quo isn’t acceptable, either.

It’s time for something new.

The Shift: From Vaults to Secretless Access

Managing secrets better isn’t enough, nor creating “better” vaults. We need to stop chasing static secrets altogether and rethink this access model.

If you think about it, this challenge has already been solved in a closely related domain: the human workforce identity. Vendors have spent decades refining solutions for managing human access. Just look at SSO, IGA, and PAM. These technologies proved that structured, scalable identity management can work. The question is, why not apply the same proven approach to an even bigger problem, machine access?

At Hush Security, we built a secretless, policy-based access model, in this model, a service or AI agent proves its identity and gets exactly the access it needs, for exactly the time it needs it,  it otherwise has no key or token to save, use, rotate and leak.

The Future of Machine-to-Machine Communication

This is the next phase of zero trust for machines. Instead of static secrets, machines will authenticate with cryptographic identity and dynamic trust, using modern concepts like:

• Zero Trust & Least Privilege Access – machines only get the minimum access they need to perform their tasks. This limits the blast radius if an account is compromised.
  ‍
• SPIFFE/SPIRE – Industry-backed workload identity frameworks for dynamic, crypto-based authentication.
• Workload Identity Federation – Policy-driven trust relationships cross clouds, SaaS and hybrid environments.

Analysts are already pointing in this direction. Close to half of companies will soon adopt a secretless approach according to Gartner. The CNCF, NIST, and other frameworks advocate for identity-first, passwordless machine authentication.

It’s the same evolution humans went through, from memorizing passwords to passwordless authentication, now applied to machines.

Why We Built Hush Security

Before Hush, I’d spent years chasing down API keys, untangling sprawl, and firefighting secret exposures. Every rotation was a stressful, error-prone and labor-intensive event. One incident, a leaked key that caused an emergency response, made me realize: secrets aren’t the endgame.

We don’t need better vaulting. We need no vaulting at all.

That’s the vision behind Hush: eliminate management of static secrets, end the vault era, and replace them with real-time, policy-driven identity for every machine, service, and AI agent. The payoff is massive:

• Security – Eliminate the risk, remove static keys from an attacker’s reach
• Simplicity – Eliminate the burden-intensive and risk-prone process of secret provisioning, storage, usage and rotation.

Oh, and everything is transparent and happening behind the scenes – no unnecessary code changes and lengthy years of implementation time.

The Bottom Line

Static secrets are a relic of a slower, simpler era. Vaults served their purpose, but they can’t keep up with cloud-native scale, AI-driven automation, and modern security expectations.

The future of machine-to-machine communication is secretless, policy-based, and identity-first. The technology exists. The standards are here. The industry is moving in this direction.

At Hush Security, we’re building the platform to make it happen, so you can innovate at full speed without worrying that the keys to the kingdom will end up in the wrong hands. We also made the technology nearly transparent to use, so adopting it would not slow your teams and your business.

So how about eliminating risk, reducing burden, and scaling your NHI security?