security(registry): review four Vault artifacts quarantined as Amos infostealer

Incident

The authoritative retained-artifact reconciliation found and automatically quarantined four historical Vault macOS artifacts on 2026-07-30.

Evidence: Backfill run 30515482539, jobs backfill (shard:3/32:2/8) (90784247582) and backfill (shard:3/32:0/8) (90784247573); and continuation run 30521434475, job backfill (shard:3/32:7/8) (90802544104).

Scanner evidence for all four: ClamAV 1.5.3; database 28076 for the first three and 28077 for the fourth. The Registry copied the exact bytes and scan record into its private malware quarantine, removed every matching installable metadata reference, and deleted the original tarball/checksum/attestation objects.

Security invariants

• Do not restore or allow any digest based only on package identity or expected dual-use behavior.
• Preserve quarantined bytes and scan evidence privately for review; do not publish contents.
• Do not allow pkgx fallback augmentation to re-advertise a quarantined (domain, version, platform) tuple.
• A successful quarantine is a completed security action; catalog reconciliation must continue and still prove zero installable unattested artifacts.

Acceptance criteria

• Durable quarantine tombstones suppress fallback re-advertisement across process restarts/deploys.
• Public metadata and tarball/checksum routes do not expose quarantined artifacts.
• Tests prove quarantine removes installable references and fallback cannot recreate them.
• The catalog backfill can continue after a successful quarantine while retaining a prominent audit warning.
• Compare the exact artifacts with authoritative upstream release checksums/signatures and document whether this is upstream compromise, repackaging compromise, or a false positive.
• Reproduce the suspected false positive with current signatures and document the ClamAV/vendor review path; no digest allowlist was added.
• Close only after production strict-enforcement proof and the zero-gap retained-object audit pass.

Refs #220

Refs #224

Refs #226

A third exact artifact was quarantined by the same authoritative run:

• vaultproject.io@2.0.2, darwin-x86-64
• SHA-256: a8368949b46dbb306373ca4c74b93b9d88e5a018e77f8c1c74dce95aa5611acb
• ClamAV 1.5.3, database 28076
• Verdict/signature: blocked, Macos.Infostealer.Amos-10056367-1
• Evidence: run 30515482539, job 90784247573

The Registry copied the exact bytes and scan evidence into private quarantine, removed the installable metadata reference, and deleted the original tarball/checksum/attestation. Adjacent Vault Linux artifacts in the same run scanned clean. The acceptance criteria and no-restore rule apply to this digest as well.

Upstream provenance / false-positive reproduction

The containment remains fail-closed; no allowlist or restoration was made. Read-only analysis was performed against private quarantine bytes without executing them.

• Both HashiCorp 2.0.1 and 2.0.2 SHA256SUMS files have valid signatures from signing subkey 374EC75B485913604A831CC7C820C6D5CD27AB87 using the public key obtained from HashiCorp’s official security endpoint.
• HashiCorp documents that Vault CE 2.0.1 has no macOS artifacts, and its current signed manifest/directory contains Linux only. Therefore the Pantry-built 2.0.1 macOS artifact has no vendor binary for byte comparison.
• The official Vault 2.0.2 macOS archives exactly match HashiCorp’s signed checksums:
  • arm64 archive contains binary SHA-256 61dc9caffd589a49e32be396eff5e54d0a3d315146818f29dbe8d1eb82e12d5b
  • amd64 archive contains binary SHA-256 f1b9686a67235de0f40b1004d7e1e7a1c461b734ba1cacc9acba514e8fda4288
• Pantry’s retained binaries differ (12a39cdc... arm64, 2e63e78f... amd64), as expected because the recipe builds the tagged source with Pantry-specific linker flags.
• Crucially, production ClamAV 1.5.3 flags both HashiCorp-signed official 2.0.2 macOS binaries with the exact same Macos.Infostealer.Amos-10056367-1 signature as both Pantry-built 2.0.2 binaries. This reproduces a ClamAV signature false positive independently of Pantry packaging.
• The quarantined 2.0.1 Pantry binary also reproduces the signature; no official 2.0.1 macOS control exists.

Authoritative references:

• https://www.hashicorp.com/en/trust/security#release-archive-checksum-verification
• https://releases.hashicorp.com/vault/2.0.1/
• https://releases.hashicorp.com/vault/2.0.2/
• https://developer.hashicorp.com/vault/docs/updates/release-notes#vault-2-0-1
• https://www.clamav.net/reports/fp

The final issue gate remains strict-enforcement production proof plus the independent zero-gap retained-object audit. Refs #220 and #224.

The exact-main continuation found the remaining vaultproject.io@2.0.1 darwin-arm64 retained artifact in run 30521434475, job 90802544104 (shard:3/32:7/8).

• retained SHA-256: b6d09e86f7693c4479fe2e89d34cacbc34ede8ec2c5a9819afcaf63d83c25bb3
• ClamAV 1.5.3 / database 28077
• signature: Macos.Infostealer.Amos-10056367-1
• source route: 2.0.1/darwin-arm64

Containment completed at 07:36:43Z: the 82,497,117-byte archive and scan evidence are in private quarantine, its original tarball/checksum/attestation are gone, public metadata returns no entry, and final tarball/checksum reads are 404 with no artifact bytes. The catalog shard continued successfully under the new quarantine-continuation contract.

This is the fourth and expected counterpart to the already-contained macOS set. HashiCorp publishes no official 2.0.1 macOS control, while both signed official 2.0.2 macOS binaries reproduce the same ClamAV signature as documented above. No allowlist or release was made. Refs #226.

Current-definition production review remains fail-closed.

Exact workflow 30586973294 rescanned the private Vault 2.0.2 darwin-arm64 object (adcf7d117296e3fe50a99889e9a052579f450c50d66bbbafddc4217e644a88de) with ClamAV 1.5.3/28077. It again detected Macos.Infostealer.Amos-10056367-1, persisted fresh review evidence, returned still-quarantined, and intentionally failed for operator attention.

The lost metadata pointer was safely recovered from exact private sidecar evidence by 335014e84; direct download authorization was hardened in f295058ab. After successful deployment 30587350913, all four affected Vault Darwin routes across 2.0.1 and 2.0.2 return 404 with no redirect. Public metadata advertises none of those platforms and exposes no quarantine fields.

The independent official signed-archive reproduction still strongly indicates an upstream ClamAV false positive. No sample was submitted upstream because that requires explicit owner consent.

Closure evidence

The remaining production gates are satisfied.

• Strict binary attestation enforcement is live: repository variable PANTRY_REQUIRE_BINARY_SCAN_ATTESTATION=true; the legacy cutoff variable and production environment entry are absent.
• Deploy 30588527008 successfully rehearsed package EICAR rejection, isolated-binary EICAR rejection, and a clamd outage returning retryable 503 with zero writes before readiness recovered.
• Production /health and /ready report malware scanning enabled, required, and ready on ClamAV 1.5.3/database 28077.
• All four exact Vault 2.0.1/2.0.2 Darwin tarball and checksum routes still return 404 without a redirect. Public metadata advertises none of those four platform records.
• Current-definition review 30586973294 remains blocked with Macos.Infostealer.Amos-10056367-1; private review evidence is retained. No allowlist or restoration exists.
• Final post-rollout retained-object audit 30589326169 passed on current main; vaultproject.io and every other catalog domain report no unattested artifacts.

The evidence continues to support a ClamAV false positive because signed official Vault 2.0.2 macOS binaries reproduce the signature, but fail-closed containment remains the correct Registry decision. No upstream sample was submitted without explicit owner consent.