CI Supply Chain: Unverified Installer Pipe and Mutable Action Tag Enable Test Result Forgery

Reported Feb 21, 2026

Severity High

Platform CI/CD (GitHub Actions)

Vulnerability Class Supply Chain (CWE-494, CWE-829)

Target Type Blockchain Naming Service

Impact Forged "passing" status check on on-chain contract changes

The Risk

The blockchain naming service used an automated build process that downloaded and immediately ran a remote setup script every time it tested code changes. If that remote script were ever swapped or tampered with, attacker-supplied code would execute on the build machine and could be made to fake a green "tests passed" badge on changes that were actually broken or malicious. Because the project ships smart contracts that control valuable on-chain names, a hidden change slipping through behind a forged green check could be merged and deployed, leading to outcomes like names being seized or payments being redirected.

The Vulnerability

The repository's smart contract test workflow contained two distinct supply chain trust failures.

Unverified Remote Installer

The workflow fetched a Python installer over HTTPS and piped it directly into the interpreter:

curl -fsSL "https://example.dev/scripts/install_cli.py" | python3

There was no version pin, no checksum verification, no signature check, and no vendored copy in the repository. Whatever bytes the upstream host returned at the moment of the run would execute on the runner.

Mutable Action Reference

The workflow referenced a popular checkout action by tag (@v4) rather than by an immutable commit SHA. Tag references can move silently to point at different code without any change to the calling repository.

The Attack

To demonstrate impact safely without touching production, a local proof-of-concept simulated a malicious installer. The simulation:

Dropped a fake CLI binary into the same install location used by the legitimate installer.
Placed that location ahead of the real CLI on PATH.
Made the fake binary respond to the test command with a forged "PASS" output and exit code zero.

Running the repository's own test script after the simulated install produced a green "all tests passed" result, even though no real tests had run. The forged binary was the one resolved by command -v, confirming the attack path.

Mapping to Program Impact

The repository contains the on-chain contracts for the naming service. If the integrity of the test step is broken, a malicious contract change can land behind a green check and later be deployed. That maps directly to the program's highest impact buckets, including domain takeover and payment redirection on minting flows.

The Impact

Arbitrary code execution on the CI runner if the upstream installer is ever modified or compromised.
Forged test results: the test status check can be made to report success while running attacker-controlled code.
Broken release gate: code that should fail review can pass into main behind a green badge.
Downstream on-chain risk: malicious contract changes can flow into deployment, threatening user-owned names and payment routes.

Remediation

Replace the curl-pipe install with a pinned, integrity-verified installation method, or vendor a reviewed installer in-repo.
Pin the checkout action and any third-party action to an immutable commit SHA, not a moving tag.
Add an explicit workflow permissions: block applying least privilege so the job cannot inherit broader defaults.
Verify CLI checksums or signatures after install, before any test or build step relies on the binary.
Treat CI runners as part of the production trust boundary and audit the workflow accordingly.