Reporting describes compromised developer and publishing paths that made poisoned packages and repositories look legitimate enough to reach normal workflows.
Miasma response
Free incident access
Offline collectors
OSV MAL matching
A CVE just dropped. Where did it land?
Find out where the poisoned developer artifacts landed.
If you are responding to the Miasma supply-chain incident right now, the VersionGopher team wants to help you inventory developer workstations, CI runners, build caches, and recovered filesystems before this spreads any further.
We can provide free access to hosted analysis tools, offline
collectors, OSV package-risk matching, import support, and triage
guidance. This is a rolling supply-chain disaster, and the first
priority is helping teams find out whether they were exposed.
For Miasma response scans, enable metadata probes with
-m.
The probe is bounded, read-only, and metadata-only. It adds useful incident clues such as embedded URLs, build paths, library names, compiler hints, and reverse-DNS identifiers to the JSONL.
Linux, macOS, ARM, MIPS, PowerPC, or OpenWrt shell
host=$(hostname 2>/dev/null || echo host); out="versiongopher-${host}-miasma-response-schema-v3-$(date -u +%Y%m%d-%H%M%S).jsonl"; sudo ./version_gopher -s -m -J > "$out"
Windows PowerShell as Administrator
$prefix = "versiongopher-${env:COMPUTERNAME}-windows-x64-miasma-response-schema-v3-$(Get-Date -Format yyyyMMdd-HHmmss)"; .\version_gopher-windows-x64.exe -s -m -o $prefix -j
Why this incident is different
The trigger moved from package install scripts to repository and editor surfaces. Teams need to inspect real filesystems without executing package managers or opening suspect workspaces first.
SLSA and build attestations help explain a build, but they do not prove the human or token behind a legitimate workflow was uncompromised.
Repository-local agent instructions, editor tasks, and prompt-risk files are now part of the software supply chain and need to be inventoried.
How VersionGopher can help right now
Start with passive collection, then turn package identities and artifact paths into a triage list your responders can actually use.
Collect offline evidence
Run a native collector with
-m on workstations, CI runners, build caches, package mirrors, staging hosts, or recovered disks.
Import scans safely
Upload VersionGopher JSONL or OSV Scanner reports without executing package-manager code on the target system.
Match package risk
Use OSV Package Risk and `MAL-*` malicious-package advisories to identify exact npm and PyPI package/version exposure.
Prioritize cleanup
Separate known malicious package hits, ordinary advisories, AI-agent hook evidence, and credential-risk artifacts.
Signals to look for
These are not abstract SBOM questions. They are the local evidence questions that decide credential rotation, runner rebuilds, and developer-machine containment.
`pkg:npm/...@version` and `pkg:pypi/...@version` records that can be checked against OSV advisories and `MAL-*` records.
`package-lock.json`, `node_modules`, `.npmrc`, `.claude`, `.gemini`, `.cursor`, and `.vscode` evidence that shows where risk may have landed.
Private-key indicators, package-manager config, cloud-adjacent paths, scan provenance, and repeat scans that show what changed.
-m adds bounded embedded URLs, build paths, library names, compiler hints, and reverse-DNS identifiers without unpacking or executing suspect files.
Incident reporting and references
Start here for the public reporting, OSV context, and build provenance background behind this temporary response page.