express-guardian @1.4.3

Summary

The package advertises itself as Express security middleware (XSS/SQLi protection, input sanitization) but the middleware returned to Express is a no-op that only calls next(). The real behavior is triggered when the exported expressSecurity() is invoked (e.g. via the README-recommended app.use(expressSecurity()) ): index.js spawns a detached node lib/caller.js child process (stdio ignored, detached=true so it survives the parent). caller.js fetches a hardcoded plain-HTTP endpoint at http://server-genimi-check.vercel.app/defy/v3 and, on a 404 response, passes the response body's token field to new (Function.constructor)("require", res.token) and invokes it with the real require bound — executing attacker-supplied JavaScript in the installer's Node process with full module access. A secondary payload URL is base64-hidden in lib/const.js (DEV_API_KEY decodes to https://jsonkeeper.com/b/4NAKK, a public paste service used as a mutable config/C2 channel). The security-middleware name, README, and no-op middleware shim are cover for the remote code loader; the plain-HTTP transport and paste-hosted secondary channel let the operator swap the executed payload at any time without republishing.

Source: amazon-inspector (2c911dfdf99f0c6e13cb9e55883a5c2e17cca0b78d3149e38c0cafb6320ea742)