eve 1.0.0
PkgFire would stop this release from installing.·Checked 17 minutes ago·Published 15 November 2026
Why
-
blockRelease suspect
PkgFire reviewed this release when it was published and compared it with 0.91.0. It has the shape of a hijacked release. It stays blocked until the PkgFire operator has checked it; if you have checked it yourself, add the package to Always allow. Files 0.91.0 also shipped gained what they did not have there: a long encoded blob (dist/src/compiled/@vercel/sandbox/index.js); running other programs (dist/src/compiled/commander/index.js); network access (dist/src/internal/nitro/host/start-development-server.js). The package could already do this elsewhere; code injected into an existing file looks like this, and so does a refactor. Its code calls api.telegram.org, which 0.91.0's code did not call. Static analysis finds behaviour 0.91.0 did not have: threat-runtime-keylogging.
Provenance
A registry signature proves the registry served these bytes unaltered. Build provenance proves which workflow built them from which commit; a stolen publishing token can fake the first but not the second.
- Signature
- Verified against the registry's key
- Build provenance
- Attested · source commit ↗
Licence and upkeep
- Licence
- Apache-2.0
- Source
- github.com/vercel/eve ↗
- OpenSSF Scorecard
- None published for this repository, which is common for small projects and not the same as scoring badly
What the code does
On its own this is weak signal: plenty of honest libraries read files or talk to the network. What PkgFire watches is a release gaining something the one before it did not.
Code reading
PkgFire's own reading of the files: what the code can do.
Source patterns
Patterns found in the source, including those malware is known to use.
Check every dependency before it installs
This page is one release. PkgFire checks every package in your lockfile, on every install and in every pull request, and blocks the bad ones before they run.