If this package is installed
Remove it, treat the machine (or CI runner) as compromised, and rotate every secret, token and key it could access — from a different, clean machine.
Details
Source: amazon-inspector (533d78538183c16b774f6e5783cc1059558ca712fd129da9666361088485e055)
Package name is 'envfile-sync' but every user-facing artifact (README title, bin name, homepage, repository, bugs URL, badges, keywords, CHANGELOG) brands the package as 'envsync', a lookalike of an unrelated existing npm package. The advertised JS API is non-functional: exported sync/check/validate/init in src/index.js return hardcoded placeholders ({ ok: true, missing: [],...opts }) and never set the fields (r.added, r.example, r.inSync, r.createdExample) that bin/cli.js consumes — the documented surface is a stub. On module load, src/index.js:21-25 resolves bin/native/parser.node and calls process.dlopen(module, p), executing arbitrary native code from a 2.9MB undocumented Windows PE ('!This program cannot be run in DOS mode.'). The README explicitly denies any binary exists ('zero dependencies', 'No binary to install, nothing to audit'), and no JS export ever calls into a native parser API, so the binary's behavior is hidden from auditors and contradicts the package's documentation. The combination — typosquat branding to attract installs, stub JS to satisfy a casual reader, opaque native PE dlopen'd on import as the only real code path — is the canonical hidden-native-payload shape. Any consumer who imports envfile-sync on Windows runs the unverifiable native code with the host process's privileges.