Go Module Proxy Cache Poisoning Attack Targets CI/CD Secrets and Cloud Tokens

Go Module Proxy Cache Poisoning Attack Targets CI/CD Secrets and Cloud Tokens

A newly reported software supply-chain campaign is targeting Go module dependencies with malicious packages designed to reach sensitive information inside development and build environments.

According to a September 21, 2026 report from Insomnia's dependency-intelligence team, two malicious Go packages were identified as part of a proxy cache-poisoning campaign. The packages had a combined 76,129 downloads, while Insomnia reported 692 affected organisations and a detection time of 11 days.

The report says the payload was specifically engineered to exfiltrate CI/CD secrets and cloud-provider tokens, making the incident relevant not only to Go developers but also to security and DevOps teams responsible for software build pipelines.

What Is Go Module Proxy Cache Poisoning?

Go applications commonly rely on external modules to provide libraries and functionality. These dependencies can be retrieved through module proxies, which can cache module content so that developers and build systems can download dependencies efficiently.

Cache poisoning introduces a security problem when a build system receives or trusts malicious dependency content instead of the expected source.

In the reported campaign, Insomnia says substituted go.sum entries point toward attacker-controlled forks. Those forks then compile an additional init() function into the resulting package.

The important point is that the malicious activity is placed inside a dependency that may appear to be part of an ordinary Go software project.

Why the go.sum File Matters

Go projects use go.sum to record cryptographic checksums for module versions. These checksums help verify that downloaded module content matches expected data.

The reported campaign involves substituted entries that redirect dependency resolution toward attacker-controlled forks. According to Insomnia, the malicious forks include an additional initialization function that can execute as part of the package.

This illustrates why dependency integrity needs to be considered alongside traditional application security.

Two Malicious Go Packages Identified

Insomnia identified two packages in the reported cluster:

• github.com/stretchr/[email protected]

• github.com/spf13/[email protected]

The report lists 2 malicious packages and 76,129 total downloads. It also reports 692 affected organisations and an 11-day time to detection.

These figures describe the activity reported by Insomnia and should not be interpreted as a measurement of all potentially affected Go projects globally.

The Payload Targets the Build Pipeline

The reported activity becomes more significant when the dependency is used inside automated build environments.

Insomnia says the payload was designed to exfiltrate CI/CD secrets and cloud-provider tokens.

CI/CD environments can contain credentials required to build, test, package or deploy applications. Cloud-provider tokens can also provide access to cloud resources, depending on how the affected environment is configured.

The source does not provide specific information about the individual organisations affected, the exact secrets accessed, or the confirmed downstream impact on those organisations.

Additional details were not disclosed in the announcement.

Why CI/CD Environments Are Important

Modern software development frequently depends on automated pipelines.

A typical pipeline may perform several stages:

1. Retrieve source code.

2. Resolve software dependencies.

3. Run security and quality checks.

4. Compile or package the application.

5. Build containers or other deployment artifacts.

6. Publish or deploy the resulting software.

A malicious dependency introduced early in this process can therefore become part of an automated execution environment.

The reported Go campaign demonstrates the importance of treating third-party dependencies as part of the software attack surface rather than as isolated pieces of application code.

What Insomnia Says Defenders Should Check

The source recommends several defensive actions for organisations investigating potential exposure.

Insomnia specifically lists commands for scanning lockfiles against its supply-chain threat feed, identifying exposed CI secrets and generating a software bill of materials.

The commands published in the report are:

insomnia sbom --scan ./ --feed supply-chain-live

The report describes this as a way to scan an organisation's lockfiles against the Insomnia threat feed.

For secret discovery, it lists:

insomnia secrets --scan ./ --rules default --include-history

The source describes this command as a way to enumerate potentially exposed CI secrets by pattern.

It also provides an SBOM generation command:

insomnia sbom --format cyclonedx-json --output sbom.json

The report says this generates an SBOM in CycloneDX JSON format.

These commands are presented by Insomnia as its own defensive tooling. Organisations should validate commands and security recommendations against their own environment and security processes before deployment.

SBOMs Become More Relevant in Dependency Security

The report also highlights software bills of materials, or SBOMs, as part of supply-chain security.

An SBOM provides an inventory of software components and dependencies used by an application or build environment. This can help security teams understand what software is actually present and investigate potentially affected components.

Insomnia says its platform can emit CycloneDX 1.6 and SPDX 2.3 SBOMs as outputs of its engagements.

For organisations managing large numbers of applications, maintaining an accurate dependency inventory can make it easier to identify where a vulnerable or suspicious component is being used.

However, an SBOM by itself does not prevent a malicious dependency from entering a software environment. It is one component of a broader software supply-chain security process.

The Broader Supply-Chain Security Issue

The reported incident highlights a broader industry shift toward attacks that target software development processes rather than directly attacking production applications.

Developers depend on public package ecosystems because reusable components reduce development effort. That same dependency model creates an opportunity for attackers to introduce malicious code through compromised, substituted or deceptive packages.

For enterprises, this could mean that dependency security needs to cover more than vulnerability scanning.

Security teams may also need visibility into:

• Which dependencies are actually used.

• Where dependencies originate.

• Whether dependency versions are pinned.

• Whether integrity information has changed.

• What credentials are available to build systems.

• Which cloud identities are accessible from CI/CD runners.

• Whether unexpected dependency changes can be detected before deployment.

Insomnia's report specifically recommends signed commits, dependency versions pinned by hash and SBOM review as part of release gates.

The company also states that its CI plugin can block a pipeline when lockfile drift is detected.

Registry Trust Remains a Security Concern

One of the central issues raised by the report is trust in software registries and dependency sources.

A developer may intentionally select a legitimate package, but the security of the resulting application also depends on the integrity of the dependency resolution and build process.

That creates multiple points that organisations need to monitor.

A secure development process therefore needs to consider the entire chain:

Developer → Source Repository → Dependency → Module Resolution → Build Pipeline → Deployment

A weakness at any stage can potentially affect the integrity of the software produced downstream.

What Organisations Can Learn From the Report

The reported campaign reinforces several practical software-security considerations.

1. Dependencies Are Part of the Attack Surface

Third-party packages should be treated as software components that require security visibility. The application itself may be secure while one of its dependencies introduces unwanted code.

2. Build Secrets Need Strong Isolation

CI/CD environments should be designed so that a compromised build step does not automatically expose every credential available to the pipeline.

The report specifically identifies CI/CD secrets and cloud-provider tokens as targets of the observed payload.

3. Dependency Integrity Matters

Hash pinning, lockfile monitoring and dependency-change review can provide additional controls around software components entering a build.

Insomnia specifically recommends pinning dependency versions by hash and monitoring lockfile changes.

4. SBOM Visibility Can Support Incident Response

When a malicious package is discovered, knowing where that package is deployed can reduce the time required to identify potentially affected projects.

This is one reason SBOMs have become an important part of modern software supply-chain security.

5. Detection Should Extend Beyond Production

Traditional security monitoring often focuses heavily on production infrastructure.

The reported incident shows why development environments, package resolution systems and CI/CD infrastructure also deserve security monitoring.

What Is Not Yet Known

The Insomnia report provides information about the two packages, reported downloads, affected organisations, payload behaviour and defensive recommendations.

However, several details are not provided in the announcement.

The source does not identify the affected organisations by name, provide a complete list of compromised environments, or disclose specific confirmed data theft from individual victims.

It also does not provide detailed information about the exact cloud providers or individual CI/CD platforms affected.

The company did not provide specific information about this area.

These limitations are important when assessing the scope of the incident.

Conclusion

The reported Go module proxy cache-poisoning campaign illustrates how software supply-chain attacks can move beyond application vulnerabilities and target the infrastructure used to build and deploy software.

Insomnia reports two malicious packages, 76,129 combined downloads and 692 affected organisations, with payloads designed to target CI/CD secrets and cloud-provider tokens.

For development and security teams, the incident reinforces the importance of dependency integrity, lockfile monitoring, protected CI/CD credentials and accurate software inventories.

The broader lesson is that software supply-chain security requires visibility across the complete development path, from dependency selection to automated builds and final deployment.

Organizations that understand exactly which dependencies enter their pipelines, what those dependencies can access and where their credentials are exposed are better positioned to investigate suspicious dependency activity when it occurs.