Cremit

// methodology

How an incident gets indexed.

Scope

This index tracks supply-chain packages that exfiltrate credentials — across npm, PyPI, GitHub Actions, the VS Code Marketplace, and Hugging Face. That's the entire scope. Specifically:

  • In scope: packages that read AWS/GCP/Azure/Apple credential files, npm/PyPI publish tokens, GitHub PATs, SSH keys, browser cookies and password stores, OS keychains and password managers, AI tooling API keys (Anthropic, OpenAI, etc.), Slack/Discord tokens, crypto wallet files and seed phrases, GitHub Actions secrets, VS Code extension auth tokens, Hugging Face access tokens — and ship them off the host.
  • Out of scope: package-name pollution / tea.xyz reputation farms, generic typosquats with no credential-stealing payload, wallet drainers that target end-user dApp interactions rather than developer- machine credentials, and ransomware / destruction packages.

The narrow scope is the point. If you want the broader supply-chain firehose, OSV.dev and Socket.dev cover it. This index gives security teams and journalists a stable place to look up "what credential stealers shipped this week" without filtering noise.

Inclusion criteria for curated incidents

The curated archive applies a stricter bar than the live monitor:

  • Exposure must be attested by at least one primary source — a vendor disclosure, official advisory, court filing, or regulator filing.
  • Supported by at least one independent secondary source.
  • The credential or token theft must be the central finding (not an incidental detail of a different incident class).

Live monitor signals

Beyond the per-package cascade (heuristics → static analysis → classifier), the live monitor runs a campaign detector that surfaces coordinated activity single-event analysis would miss: one publisher pushing 2+ distinct impersonation names within 24 hours, two unrelated packages POSTing to the exact same webhook URL, or identical tarball hashes across different accounts. A local 1.5B model judges publisher clusters, but with adversarial-description guards in front of it — attackers deliberately ship descriptions like "security research PoC", "internal vendor utility", or "critical security patch for [brand] internal toolkit" to fool small models into treating coordinated impersonation as a legitimate product line. Those phrases bypass the LLM and surface the cluster as suspicious regardless of what the model would have said.

Sourcing

  • Primary sources are vendor security bulletins, official incident reports, regulatory filings, and law enforcement records.
  • Reporting sources are reputable security press (Bleeping Computer, The Record, KrebsOnSecurity, etc.).
  • Analysis sources are independent researcher write-ups, often with technical depth that primary disclosures lack.

Status values

  • confirmed — corroborated by at least one primary source.
  • suspected — circumstantial evidence; no primary disclosure yet.
  • rumored — claims circulating without verifiable evidence; we include them only when the claim itself has become a notable event.
  • resolved — confirmed event where remediation is documented and no further exposure is expected.

NHI Severity Index

A 0–10 score measuring the impact of the leaked NHI material along three axes:

  • Blast radius — how many systems or organizations the credential reaches: single-org → cross-platform → ecosystem-wide.
  • Reachability — where the credential lives: developer-env → staging → production.
  • Privilege level — what the credential can do once used: read-only → service → admin.

The score is editorial, not algorithmic. The rationale appears in the Cremit Analysis section of every incident page.

Review process

  1. Draft authored from primary + secondary sources.
  2. Frontmatter validated against a Zod schema; slug, sources, and dates are machine-checked.
  3. Editorial review by Cremit research before merge.
  4. Live entries are revisited when material new information surfaces.

Corrections

We will correct errors. Open an issue on the repository or email hello@cremit.io with the incident slug and the specific claim being corrected. We track last_updated on every entry.