OpenTelemetry JS Contrib CVE-2026-104872

Requires a deployment running any of the affected packages below their fixed versions (@opentelemetry/instrumentation-cassandra-driver <0.66.0, -knex <0.65.0, -mongoose/-mysql/-mysql2 <0.67.0, -oracledb <0.46.0, -pg <0.73.0, -tedious <0.40.0) with database connections configured using a username, AND those traces being exported to an observability backend. The db.user attribute is emitted unconditionally and is NOT gated by the enhancedDatabaseReporting flag or any other opt-in, so default configurations are affected. Limiting factors: the exposure is confined to confidentiality of database account names (no passwords, data, or query contents), and an actor must already have read access to the telemetry pipeline or backend to retrieve the leaked usernames - there is no direct network-triggered exploit against the application itself.

This is a low-to-moderate priority information-disclosure issue (CWE-532) that scores CVSS 5.8 largely because of the Scope-change (S:C) and network (AV:N) metrics, not because of direct attacker-driven compromise. The provided vector (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N) reflects that the affected OpenTelemetry instrumentation packages automatically emit the database connection username as the db.user span attribute by default, sending it across a trust boundary into the configured observability backend - hence S:C and C:L, with no integrity or availability impact. No EPSS score, KEV listing, POC, or SSVC data was supplied; exploitation status is 'no public exploit identified at time of analysis'. Note a conflict worth flagging: the AV:N/PR:N framing implies remote unauthenticated 'exploitation', but in practice this is passive leakage - an actor still needs read access to the telemetry backend to obtain the usernames, so the realistic privilege barrier is higher than PR:N suggests. The disclosed data (database account names) is low-sensitivity metadata, not credentials or secrets, so the true impact is reconnaissance value (topology, role, environment hints) rather than direct account compromise. Verify fixed versions against the GHSA advisory before remediation planning.

An insider or attacker who has gained read access to the organization's observability backend (e.g., a tracing/APM SaaS, Jaeger, or Grafana Tempo) inspects spans emitted by a Node.js service and reads the db.user attribute present on every database operation. From the account names they infer service-to-database topology, environment segregation (e.g., svc_billing_prod), and naming conventions useful for crafting later targeted attacks. No public exploit code is required or identified; the data is exposed automatically because the attribute is emitted by default.