u/BattleRemote3157

strapi-plugin-events dropped on npm today. Three files. Looks like a legitimate community Strapi plugin - version 3.6.8, named to blend in with real plugins like strapi-plugin-comments and strapi-plugin-upload.

On npm install it runs an 11-phase attack with zero user interaction:

• Steals all .env files, JWT secrets, database credentials
• Dumps Redis keys, Docker and Kubernetes secrets, private keys
• Opens a 5-minute live C2 session for arbitrary shell command execution

The publisher account kekylf12 on npm is actively pushing multiple malicious packages right now and all targeting the Strapi ecosystem.

Check the account: npmjs.com/~kekylf12

If you work with Strapi or have any community plugins installed that aren't scoped under strapi/ - audit your dependencies now. Legitimate Strapi plugins are always scoped. Anything unscoped claiming to be a Strapi plugin is a red flag.

Full technical breakdown with IoCs is in the blog.

Supply chain attacks often rely on speed that is publish a malicious version, let automated builds pull it before detection catches up.

One defense is a cooldown period : refuse any dependency published within the last N hours.

CEL (Common Expression Language) doesn't expose now() by default since it's designed to be hermetic. This article actually walks through registering a custom now() function binding that returns the current UTC timestamp, using duration arithmetic to compare against package_published_at, and using the has() macro to handle packages so new they haven't been indexed yet - which is the edge case that will bite you if you miss it.

Go's govulncheck is solid for known CVEs. But it doesn't actually cover the full picturel like unmaintained packages, license violations or low OpenSSF Scorecard. Packages that simply shouldn't be in prod.

We have been building vet for filling this gap only.

vet is an open source SCA tool written in Go. It reads your go.mod / go.sum and evaluates each dependency against data from OSV, OpenSSF Scorecard, and other sources. The interesting part is how you express policy, it uses CEL rather than config files or flags

# Fail CI if any dep has critical CVEs or is unmaintained

vet scan -D . \
  --filter '(vulns.critical.size() > 0) || (scorecard.scores.Maintained == 0)' \
  --filter-fail

Or define a policy file you can version alongside your code:

# .vet/policy.yml
name: production policy
filters:
  - name: no-critical-vulns
    value: vulns.critical.size() > 0

  - name: maintained
    value: scorecard.scores.Maintained < 5

  - name: approved-licenses
    value: |
      !licenses.exists(p, p in ["MIT", "Apache-2.0", "BSD-3-Clause", "ISC"])

vet scan -D . --filter-suite .vet/policy.yml --filter-fail

The filter input is a typed struct - vulns, scorecard, licenses, projects, pkg , so writing and testing expressions is straightforward. There's also a GitHub Action for CI integration.

Repo: https://github.com/safedep/vet

One addition worth calling out separately, time-based cooldown checks.

Most supply chain compromises rely on speed where a malicious version gets published, automated builds pull it within hours before detection catches up. A cooling-off period is a blunt but effective guardrail. vet supports this via a now() function in its CEL evaluator (landed via community contribution PR #682):

bash

vet scan -D . \
  --filter-v2 '!has(pkg.insight.package_published_at) || (now() - pkg.insight.package_published_at).getHours() < 24' \
  --filter-fail

The !has(...) guard catches packages so new they haven't been indexed yet and those get blocked too. The duration is yours to set, 24h is a reasonable default, some teams go to 7 days.

Two versions of axios were published today through what appears to be a compromised maintainer account. No GitHub tag exists for either version. SLSA provenance attestations present in 1.14.0 are completely absent. Publisher email switched from the CI-linked address to a Proton Mail account( classic account takeover signal).

>