express-guardian@1.4.3

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.