Security1 distinct publisher2 min readPublished
The count of places this worm looks for secrets more than doubled between builds, and the additions sit in CI/CD and developer tooling, which is where the standing tokens that make a supply chain attack portable actually live.
The Watch · Security desk

Compiled by The WatchSomething wrong?How this is made
469 minus 189 is 280 paths added, a search radius about 2.5 times wider than the earlier builds of the same worm [4]. None of that widening requires an exploit. Each path is a file read on a host the operator already controls, which makes adding paths close to free and means the number goes up again in the next build.
What the number buys depends on what sits at the end of the chain. The reported sequence runs in steps: a token lifted from a developer workstation opens source code, that source code carries cloud credentials that open infrastructure, and a GitHub token grants write access to further repositories [6]. One credential class breaks that pattern. A package publishing token converts theft into distribution, because the build ships through a channel other developers and build systems consume automatically [7]. The rest of the chain moves an attacker sideways, but publishing authority moves the attack outward.
The sourcing behind the count deserves scrutiny. Both supplied copies of this report are the same thehackernews.com article [15]. The material carries no victim count and no list of compromised packages [16]. 469 measures the malware's search scope, and it says nothing about what was actually taken. The AI development tool configuration entry is the newest place teams are finding access keys [8], and on this evidence it is a collection target whose exploitation hasn't been confirmed.
The remedy aimed at the worst link is a token lifecycle change rather than another scanner. Short-lived verified authentication via OpenID Connect or similarly scoped mechanisms removes the standing publishing secret there is to steal, and the piece credits recent Docker and GitHub Actions updates with pushing trusted publishing in that direction [11][12]. Where a long-lived publishing token has to stay, it carries the blast radius of the packages it signs and should be inventoried on those terms [11]. Registry and dependency defense still does work; the ingredient a worm like this actually needs sits underneath it [14], in the standing authority that CI/CD, cloud tooling and now agent configuration keep on disk.
Ranked by verification strength, evidence, and original report placement.
In early August, GitGuardian researchers found that a recent Shai-Hulud infostealer worm variant had evolved to scan for credentials across 469 locations.
The 469 locations span developer environments, CI/CD tooling, cloud configurations, and AI tool configs.
Earlier variants of the Shai-Hulud infostealer worm checked 189 paths.
Shai-Hulud belongs to a class of supply chain attacks that search compromised environments for credentials they can use to continue the attack.
A token found on a developer workstation might open access to source code; that code likely contains cloud credentials granting access to infrastructure; a GitHub token might allow write access to additional repositories.
A package publishing credential lets an attacker publish software through a channel developers, build systems and organizations already trust and consume automatically, forward propagating the attack.
Distinct publishers with included, body-backed reporting in this cluster.
2 articles · September 3, 2026
Follow any of these and your For You feed starts watching them — no settings page required.
security
Reading OIDC tokens out of runner memory: ChainDrop and the poisoned build1 distinct publisher
build
56 build-pipeline attacks, one vendor's alert queue, and the February jump nobody can attribute yet1 distinct publisher
science
TeamPCP hid its infostealer inside the scanners that audit everyone else's code1 distinct publisher
build
Your CI Build Is Slow Because The Cache Is Empty, Not Because The Base Image Is Fat1 distinct publisher
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
One vendor's count, printed twice
The two numbers carrying this story — 469 paths now, 189 before — come from GitGuardian's own researchers and reach us only through The Hacker News, with no link to the analysis, no sample hash, and no second party counting. The arithmetic holds and the named path categories are the ones practitioners would expect, which is why this scores mid-range rather than low. But a reader who wants to check the jump has nowhere to go, and the duplicate posting adds volume, not verification.
No spread, no uptake
Neither side of this story is counted. On the attacker's side there is no tally of compromised packages, no named organisation and no event dated after the early-August finding. On the defensive side, trusted publishing and OIDC are described as gaining ground because Docker and GitHub Actions shipped something unspecified — no registries enumerated, no share of maintainers migrated, no before-and-after. We decline to put a number on either.
Real number, borrowed weight
Nothing here is fabricated and the trend argument is sound: attackers reuse standing authority instead of breaking trust, and the newly scanned paths are exactly where standing tokens live. The overstatement is structural. One malware finding, with no measured harm attached, is used to launch a general programme for turning secrets detection into credential risk management — the discipline the source sells. 'Preventing the next Shai-Hulud starts with securing the credential layer' is an assertion the reporting never has to earn, because no consequence of this variant is ever quantified.
The remedy is the product
The research is GitGuardian's, the conclusion is that organisations need to inventory, validate, attribute and prioritise their secrets, and the piece slips into the first person to make the case — 'we should encourage all software makers' — without ever pausing to say what the company sells. Much of the advice costs nothing and would be right regardless: kill cleartext publish tokens, prefer short-lived OIDC. The tell is the ordering, which moves from a malware count to secrets-management maturity in a straight line, and the choice of the 100,000-findings framing, which is a dashboard's problem statement.
Thin, but transparently thin
One publisher relaying one interested researcher is a weak base, and the second copy does nothing to strengthen it. What keeps this from scoring lower is that the provenance is unambiguous: we know who counted, who printed it, and exactly which parts are advocacy. Discounting is possible here in a way it is not when a number arrives unattributed.