MAL-2026-6589

--- _-= Per source details. Do not edit below this line.=-_

## 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.