Trail of Bits test finds 23 of 25 package managers skip integrity checks on some downloads
Only two of 25 popular package managers verified every package they downloaded in a Trail of Bits test. Fewer than half checked lockfiles for tampering by default, leaving many open to a compromised repository that injects code, the post says.
The Watch · Security desk
One bar out of 25 package managers: 24 of the 25 did not verify signatures by default.
- No default signature check, claim 16 24 of 25 package managers 96% computed
No default signature check The rest of the 25
| Share | Part | Whole | Percent | Claim |
|---|---|---|---|---|
| No default signature check | 24 package managers | 25 package managers | 96% (computed) | 16 |
What happened
- Automatic lockfile hash verification was the default in about half of the managers tested.
- On signatures, only Go verified them by default, and the rest needed extra configuration, lacked verification code, or did not support signatures.
- The threat model assumes any web-facing server can be compromised, with Composer's Packagist and GitHub fetches as the example, while private signing keys stay secure.
Why it matters
- exposure Teams on managers without default verification are trusting the repository host and every web-facing server it pulls from, such as Packagist and GitHub for Composer.
- cost For the managers that do not verify automatically, integrity is a setup task that each team pays for, and the post's first table ranks managers by how much work that takes.
- decision A lockfile is where the hashes live, so the choice to commit one is also a choice about whether hashes get checked at all.
- precedent The author expects attackers to move to repositories if defences against developer compromise work. That is a forecast from the post, not a campaign anyone has reported.
This is a survey of design, not a bug with a CVE. The post does not cite a CVE or an attack in the wild.
The attacker's precondition is control of a server the package manager fetches from. The test harness grants it. The mitmproxy certificate authority is installed in each Docker image, so the addon can rewrite the plaintext of repository responses [9]. The author treats any web-facing server as compromisable, using Composer as the example because it fetches metadata from Packagist and packages from GitHub [10]. Private signing keys stay secure in the model [10]. A test attack counts as a success only if the sample code executes the injected malware [11].
The post's counts on defences are not identical. It says automatic hash verification was the default in about half of the managers [7], and separately that fewer than half used lockfiles that checked for tampering by default [5]. Fewer than half of 25 is at most 12 [14]. The excerpt does not give exact tallies for either. On the strictest measure, 23 of 25 managers did not verify every package they downloaded [15]. On signatures, 24 of 25 did not verify them by default [16].
The results hold for a particular configuration [3]. The author installed the latest version of each manager, followed quickstart guides for sample projects, infected popular packages from public repositories, and ran commands with default flags [1]. A team running other flags may see different results. The per-manager breakdown is in the post's two tables.
The author wrote that "This code integrity problem could be solved using cryptographic hashes or signatures, but many package managers are still vulnerable to this threat." [18] The forward-looking claim is also the author's. If mitigation of developer compromise succeeds, attackers will shift to the repositories that serve the code [17].
We think this belongs on a hardening backlog. It needs a repository compromise first, and the post's evidence is the design gap in the managers.
What to watch
- A report of a real repository injection that matches the test model would turn the author's forecast into an observed campaign.
- Default changes in the managers that fell short, since the author says some communities are already bringing improved designs to reality.
- The post's closing discussion of cryptographic designs that might be adopted in future, which the excerpt does not reach.
Clarity's read
What the record supports and how the coverage leans. The claims behind it follow.
Reality
- Evidence62
- Adoption
- Insufficient
- Hype gap−5
- Incentives
- Insufficient
- Confidence60
Claim ledger
Ranked by verification strength, evidence, and original report placement.
- [1]
The author installed the latest package manager versions, followed quickstart guides for setting up sample projects inside the container, picked popular packages from public repositories to infect, and ran package manager commands with default flags.
- [2]
There are conflicting opinions about whether to include lockfiles in source code repositories, so the author tested both configurations.
- [3]
The results in the post's tables are experimentally verified for a particular configuration, with caveats detailed in the post.
- [4]
Trail of Bits tested 25 of the most popular package managers to check whether they detect a compromised package repository injecting malicious code into legitimate packages.
- [5]
Of the 25 package managers reviewed, fewer than half used lockfiles that checked for tampering by default.
- [6]
Of the 25 package managers reviewed, only two verified the integrity of every package they downloaded.
- [7]
Automatic hash verification was the default behavior in about half of the package managers tested; others required extra configuration to include or verify hashes, used hashes in a cryptographically insecure way, or lacked hashes entirely.
- [8]
In the author's tests, only Go verified signatures by default; others required extra configuration, lacked verification code, or did not support signatures.
- [9]
The author built a testing harness using Docker containers and mitmproxy; traffic routes through a WireGuard network to a custom mitmproxy addon, and because the mitmproxy TLS CA is installed in the Docker image, the addon can fully manipulate plaintext from the package repository, simulating a compromised server.
- [10]
The author assumed any web-facing server could be compromised (for example, Composer fetches metadata from Packagist and packages from GitHub), but backend resources such as private signing keys remain secure.
- [11]
In the harness, the simulated repository embeds malicious code into downloaded packages, and the attack is successful if the sample code executes the malware.
- [12]
Table 1 categorizes managers by how much work it takes a developer to achieve integrity when fetching dependencies from a malicious repository.
- [13]
A cryptographic hash of a package's contents can be included in a lockfile and compared after downloading the package.
- [14]
Fewer than half of 25 package managers is at most 12.
- [15]
23 of the 25 package managers did not verify the integrity of every package they downloaded.
- [16]
24 of the 25 package managers did not verify signatures by default.
- [17]
The author argues that if mitigation of developer compromise succeeds, attackers will shift their focus to the next weakest link, the package repositories that serve the code.
- [18]
"This code integrity problem could be solved using cryptographic hashes or signatures, but many package managers are still vulnerable to this threat."
Get this ledger inside ChatGPT. Ask about any of our stories and the answer brings its figure, each claim’s verdict and the sources. Free, no account.
Sources
1 independent publisher whose own reporting we read for this story.
- blog.trailofbits.comPackage managers have an integrity problem
1 article · October 14, 2026
Topics and entities
Follow any of these and your For You feed starts watching them — no settings page required.
Topics
- Software Supply Chain SecurityFollow
- Package managersFollow
- Cryptographic integrity checksFollow