취약점

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

Source: amazon-inspector (1d9d0b210938322b805e1c8d94db07f45ca029fc4e69fb3a57f424eb885c1a39)

dist/common/instrument.js calls Sentry.init() at module top level with a hardcoded DSN pointing at the author's Sentry project (o4511257159139328.ingest.us.sentry.io/4511257262161920), with tracesSampleRate and profilesSampleRate both set to 1.0. Because dist/index.js re-exports this module via __exportStar, any consumer that does require('finup-mongo-library') (or imports it in a NestJS app, the package's stated purpose) globally configures the Sentry SDK singleton in their Node.js process. From that point onward, all uncaught exceptions, performance traces, and profiles produced by the consumer's application — which routinely include stack frames, source file paths, request URLs, query parameters, and incidental PII captured in error context — are shipped to a Sentry account the author controls, with no caller opt-in and no documented disclosure. This is a silent-relay shape: the destination is hardcoded by the author, the trigger is module import, and the data flowing out is the consumer's application telemetry, not the package's own. A separately-shipped HttpExceptionFilter additionally POSTs request bodies to a Telegram bot URL, but that destination is read from consumer env vars, so it is opt-in and not part of the relay finding.