GHSA-qqmp-wf37-98f9 Multiple @opentelemetry/instrumentation-* packages expose database username via unconditional db.user span attribute

• npm @opentelemetry/instrumentation-cassandra-driver: < 0.66.0 → fixed in 0.66.0 • npm @opentelemetry/instrumentation-tedious: < 0.40.0 → fixed in 0.40.0 • npm @opentelemetry/instrumentation-oracledb: < 0.46.0 → fixed in 0.46.0 • npm @opentelemetry/instrumentation-mongoose: < 0.67.0 → fixed in 0.67.0 • npm @opentelemetry/instrumentation-mysql: < 0.67.0 → fixed in 0.67.0 • npm @opentelemetry/instrumentation-knex: < 0.65.0 → fixed in 0.65.0 • npm @opentelemetry/instrumentation-mysql2: < 0.67.0 → fixed in 0.67.0 • npm @opentelemetry/instrumentation-pg: < 0.73.0 → fixed in 0.73.0

Impact Multiple `@opentelemetry/instrumentation-*` packages recorded the database connection username as the `db.user` span attribute on every instrumented database operation. This attribute was emitted unconditionally — it was not gated by `enhancedDatabaseReporting` or any other opt-in flag, and it was the default behaviour for all users of the affected packages until the patched releases shipped on 2026-07-23. The attribute is forwarded to every configured observability backend (Jaeger, Zipkin, Datadog, OTLP collectors, etc.). Depending on the database account naming convention in use, the exported value may reveal: • Internal service account names that disclose architecture topology. • Role-encoded usernames (e.g. `admin_readwrite`, `app_readonly_prod`) useful for privilege inference. • Database account naming patterns useful for credential enumeration. Affected packages (all are vulnerable from the first published version through the version listed below): | Package | Vulnerable range | Patched version | |---------|-----------------|-----------------| | `@opentelemetry/instrumentation-cassandra-driver` | `< 0.66.0` | `0.66.0` | | `@opentelemetry/instrumentation-knex` | `< 0.65.0` | `0.65.0` | | `@opentelemetry/instrumentation-mongoose` | `< 0.67.0` | `0.67.0` | | `@opentelemetry/instrumentation-mysql` | `< 0.67.0` | `0.67.0` | | `@opentelemetry/instrumentation-mysql2` | `< 0.67.0` | `0.67.0` | | `@opentelemetry/instrumentation-oracledb` | `< 0.46.0` | `0.46.0` | | `@opentelemetry/instrumentation-pg` | `< 0.73.0` | `0.73.0` | | `@opentelemetry/instrumentation-tedious` | `< 0.40.0` | `0.40.0` | Patches Fixed in the coordinated release on 2026-07-23 via feat!: only emit stable http, network and database attributes (#3585). Upgrade to the patched version listed in the table above for each instrumentation package in use. Workarounds No configuration-level workaround exists in the affected versions: the `db.user` attribute cannot be suppressed without patching. As a partial mitigation, a custom `SpanProcessor` can be used to strip `db.user` from spans before they leave the process: ```ts // Example: drop db.user in a custom SpanProcessor class StripDbUserProcessor implements SpanProcessor { onStart(span: Span) { span.setAttribute('db.user', null); } onEnd() {} shutdown() { return Promise.resolve(); } forceFlush() { return Promise.resolve(); } } ``` Users who control the downstream collector can also filter the attribute at the collector pipeline level.