Updater accepts an artifact outside its publisher trust policy
The real update decision accepts modified bytes or an unrelated publisher identity before activation.
Candidate CWE: CWE-494 · CWE-347
Test hypothesis#
Use the product's local updater fixture or production-equivalent verifier. Compare a genuine update, an inert corrupted copy, a wrong-publisher fixture and an applicable metadata/artifact mismatch. Hold the trusted publisher policy fixed and show the attacker's actual replacement/distribution control. Record download, verification, staging and activation separately.
Evidence required#
Preserve expected signer/source policy, exact accepted artifact digest, verifier version, verification order, staging permissions and the harmless consumed marker or activation result. Distinguish a correctly authenticated artifact from the separate question of whether its build contents are trustworthy.
Rule out false positives#
A failed standalone signature check does not show updater acceptance. Attacker-added trust roots, disabled production verification, rejected substituted artifacts, or a setup that bypasses the real distribution boundary invalidate that claim. No particular signing technology is universally required when other controls satisfy the actual threat model.
Playbook and command references#
- Update signatures, rollback and privileged installation — Test the update decision and installation boundary while preserving production signer and privilege assumptions.
- CI and releases: trace untrusted input into privileged work — Audit workflow events, shell interpolation, untrusted builds, artifact consumers, and release identity as one privilege chain.
- OSS lab: pin, install, prove, reset — Turn an eligible release into a repeatable synthetic environment with preserved versions, realistic controls, and an explicit reset recipe.
Find the associated command snippets
Referenced by these target playbooks#
Report checklist#
- Capture the affected version, configuration, identities, and object ownership.
- Preserve a valid baseline and a negative control.
- Reproduce the forbidden data access, action, or state change on controlled fixtures.
- Explain the intended security rule and why the observed behavior violates it.
- State prerequisites, uncertainty, cleanup, and the smallest demonstrated impact.
Conditional ATT&CK mapping#
- T1195.002 · Supply Chain Compromise: Compromise Software Supply Chain — Only if: A controlled release/update workflow accepts modified application code or a substituted compiled artifact before delivery to its final consumer; prove consumption in a lab. Not established by: Access to a build log, ability to upload an unused artifact, or an ordinary software vulnerability does not establish malicious software distribution.