CVEasy Weekly

This Week in Exposure

Week 33 · August 4 to August 10, 2026

This week two attacks walked straight past the exact control built to stop them. Metabase's password reset returned a 400 and handed back an administrator session anyway. An npm worm shipped through keyv carrying a Sigstore provenance signature that validated on every mirror that checked it. The reassuring signal in both cases, a rejected reset and a green attestation, was true and useless at the same moment.

A control that returns the right answer while the attacker is already through is worse than no control, because it tells your queue to stand down. Here is what mattered this week, ranked by real exposure against your inventory, not by the base score.

Top Exposures This Week

1. A Metabase password reset that returned admin

GHSA-vwf4-m7j8-wcjf · Metabase (branches 0.58.x through 0.63.x, enterprise 1.x tags)

An unauthenticated POST to /api/session/reset_password ran attacker SQL against Metabase's own metadata store, and a failed reset that returned 400 was followed within seconds by a GET to /api/user/current that returned 200. The application database is not the analytics warehouse. It holds users, sessions, permissions, and the encrypted credential for every data source the instance has ever queried, and the admin surface decrypts those on demand through legitimate APIs. There is no second bug to chain.

Risk read: Confirmed in the wild. Metabase Cloud caught live abuse on August 3, and on August 7 and 8 named two breached customers, Framework and Tally, whose notices (summarised by BleepingComputer and The Hacker News) describe theft of customer names, email addresses, phone numbers, and shipping addresses pulled from analytics warehouses through legitimate queries. The exploitation signal alone lands this at ACT, the top TRIS band, at CVSS 10.0. The blast radius is every data source wired into the instance, Snowflake, BigQuery, Postgres, Redshift, exfiltrated through the same download endpoints an analyst uses. Exposure is what splits the fleet: an internet-facing production instance with a live Snowflake service account is not the sandbox an analyst spun up for a demo, and a base score of 10 sorts them side by side. Upgrade to the fixed release for your branch, 0.58.24, 0.59.21, 0.60.17, 0.61.11, 0.62.9, or 0.63.5, with the enterprise 1.x tag matching your track.

Read the reset-to-exfiltration walk →

2. A worm that shipped through keyv wearing a valid provenance seal

Mini Shai-Hulud npm worm · keyv, cacheable, and 8 sibling caching packages

On August 4, an attacker holding the maintainer's GitHub credentials pushed to the main branch of keyv and, between 09:35 and 10:28 UTC, republished ten packages that anchor Node.js caching, keyv@6.0.0, cacheable@2.5.1, flat-cache@6.1.24, file-entry-cache@11.1.6, and cacheable-request@13.0.20 among them. Each package.json had its scripts block rewritten to a single {"preinstall":"node setup.mjs"} that fires on any fresh install. The set carries over two billion combined monthly installs per Armorcode telemetry, and every poisoned release shipped a Sigstore provenance attestation that still validated on the mirrors that checked it.

Risk read: Active exploitation, reversed by Datadog Security Labs. Any developer laptop or CI runner that ran a fresh install against these packages in the Aug 4 window should be treated as compromised: the stealer lifts SSH keys, npm and GitHub tokens, AWS keys through the standard credential chain, Kubernetes service account tokens, and every environment variable in the process, so rotation is mandatory rather than conditional on egress evidence. The blast radius does not stop at the host. The worm queries the npm tokens API for any write-capable token marked bypass_2fa and republishes itself into those packages, so one poisoned runner becomes the next batch of poisoned releases. Exposure here is pin and lockfile discipline: an install run with scripts disabled never reaches the preinstall hook.

Read how a genuine attestation signed a worm →

Threat Actor Spotlight

Datadog and Chainguard track the keyv campaign as Mini Shai-Hulud, a follow-on to the earlier Shai-Hulud wave that hit TanStack, Mistral AI, UiPath, and OpenSearch packages. No individual crew has been named in the public record, and I am not going to attach one to a supply-chain event that does not support it. The technique is the lesson. npm provenance uses Sigstore to bind a tarball to the commit, workflow, and repository that built it, and this worm walked that whole ceremony correctly, so the attestation is genuine. It faithfully binds an attacker-controlled source tree and an attacker-controlled build to the package, and every provenance client accepts it because that is exactly what the standard promises. Provenance attests where code came from. It never attests that the code is safe to run. Hardening takeaway: read a valid provenance signature as proof of origin, not a clean bill of health. Pin exact versions, commit a lockfile, run CI installs with scripts disabled by default (npm ci with ignore-scripts), and rotate any secret that a compromised install window could have reached rather than waiting for egress logs to confirm the loss.

Signed CVEasy threat-intel IOC bundle current as of 2026-08-10. The desktop app verifies the ED25519 signature before import.

A 400 on a reset and a green provenance seal both told you nothing was wrong, and both were correct about the narrow thing they measured and blind to the breach in progress. That is the failure mode a base score shares: it grades the bug in the abstract and says nothing about the internet-facing instance with a live warehouse credential or the CI runner that pulled a poisoned tarball an hour ago. Scoring the event against your own inventory is the work, and it is the gap TRIS closes inside our CTEM platform, the gap I want this letter to close for you every Monday.

Patch well,
Chris Boker
Founder, CVEasy AI