--- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (b10e41b9a87dc4927d3c4bc63b25bc1fa438cfae1bcf5f1d483204a18d5765f6) Package `exodus-checkout` self-identifies as a security-research dependency-confusion proof-of-concept targeting an internal Exodus payments SDK. It mimics the internal API surface (`generateMnemonicSigningKeys`, `signCharge`, `signRefund`, `signCancelSubscription` in src/index.js), but every exported function throws — there is no functional implementation. On `npm install`, src/canary.js runs a postinstall hook that performs a DNS lookup and HTTPS GET to a hardcoded serveo SSH-tunnel host (`96e03fa6c292469a-172-245-86-254.serveousercontent.com/canary-install`), passing the package's own name and version as query parameters. No installer data (env vars, filesystem, credentials) is read or transmitted — the beacon carries only the package's own identity. Installer-side impact: any build that resolves `exodus-checkout` from public npm (whether by typo, dependency confusion, or accidental inclusion) breaks at runtime because all exports throw, and emits a one-way network signal to a researcher-controlled tunnel domain that is not Exodus infrastructure and cannot be audited by Exodus or the installer. Routing to human review: name-impersonation of a vendor's internal namespace plus an install-time outbound beacon is the dependency-confusion shape, but the absence of any data exfiltration or remote-code-execution mechanism keeps this below the active-attack threshold.