Package Manifest Poisoning

How package manifest poisoning works

package manifest poisoning targets the metadata that tells build tools what to fetch, trust, or resolve. By altering dependency declarations, repository pointers, or version metadata, an attacker can redirect an ordinary build toward hostile packages or maliciously modified artefacts without changing the main application code.

This attack succeeds because modern build pipelines often treat manifests as authoritative control data. When the manifest is tampered with, the package manager may resolve a dependency from the wrong source, prefer an unexpected version, or install code that appears legitimate but was introduced through poisoned metadata.

Why it is dangerous in software supply chains

The danger is not limited to a single package being swapped out. A poisoned manifest can influence every downstream environment that consumes the build output, turning one metadata change into a widespread trust failure across development, CI, staging, and production.

It is especially risky where build systems automatically resolve dependencies from public registries, mirror caches, or transitive package graphs. In those environments, a small change in a manifest can change the software that gets compiled, tested, signed, and deployed.

Open source supply chain programmes such as OpenSSF exist to harden these trust paths, because the security problem is not just malicious code, it is the integrity of the metadata that selects the code in the first place.

Where exposure is introduced

Organisations should look for exposure wherever package manifests are edited, generated, cached, or consumed. Risk rises when dependency resolution is automated, when multiple registries are allowed, when package names are similar across ecosystems, or when build jobs inherit trust from unaudited repository settings.

Exposure is also higher when the software bill of materials, lockfile, or dependency policy is missing or not enforced. If the build process can freely re-resolve dependencies, a tampered manifest may survive long enough to be compiled into signed artefacts and distributed as trusted software.

For identity-bearing build credentials and registry access paths, compromise of the build context can also expose tokens, publishing rights, or repository write access, which broadens a manifest attack into a broader supply-chain compromise.

Detection, review, and recovery after compromise

Detection starts with comparing committed manifests, lockfiles, and repository metadata against expected sources of truth. Teams should review package resolution logs, registry access history, and build provenance to identify when a dependency was fetched from an unexpected location or version set.

After patching or reverting the poisoned manifest, organisations should treat the build as potentially tainted until they confirm that no malicious artefacts were promoted, signed, or deployed. A post-incident review should also check whether dependency caches, internal mirrors, or publishing credentials were abused to preserve persistence.

Supply chain controls such as SLSA and OWASP SAMM help teams reason about provenance, build integrity, and secure delivery practices, while incident response should verify whether the compromise reached the artifact pipeline itself.

Practitioner Guidance

Why practitioners should care: Manifest poisoning is a metadata attack, so the most important control question is whether your build trust model assumes dependency declarations are honest by default. If it does, the pipeline can be subverted before any code review or runtime security control has a chance to help.

What to watch for: Unexpected dependency source changes, registry drift, unexplained version jumps, and lockfile mismatches are the practical warning signs. Build provenance, pinned resolution, and registry allowlisting make these changes easier to detect and harder to exploit.

Practitioner takeaway: Treat package metadata as a security boundary, not just a development convenience, and validate it with the same discipline you apply to executable code.

Related resources from NHI Mgmt Group

• How should security teams reduce the risk of compromised maintainer accounts poisoning widely used package ecosystems?
• Why do compromised release pipelines create more risk than simple package poisoning in supply chains?
• Package Poisoning
• Package Manifest