What is the CVSS score of EUVD-2026-41151?

EUVD-2026-41151 has a CVSS 3.1 base score of 6.5 (Medium). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N. EPSS exploitation probability: 0.2%.

Is there a public PoC exploit available for EUVD-2026-41151?

Yes, a public proof-of-concept exploit is available for EUVD-2026-41151. Prioritise patching immediately. EPSS: 0.2%.

Is there a patch available for EUVD-2026-41151?

Yes, a patch is available for EUVD-2026-41151. Update the affected software to the latest version immediately.

OpenTelemetry Java Instrumentation EUVD-2026-41151

| CVE-2026-54704 MEDIUM

Insertion of Sensitive Information into Log File (CWE-532)

2026-07-01 GitHub_M

GHSA-rwqx-fvqh-6wm4

Java Information Disclosure Opentelemetry Java Instrumentation Open Telemetry

6.5

CVSS 3.1 · Vendor: GitHub_M

Severity by source

Vendor (GitHub_M) PRIMARY

6.5 MEDIUM

AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

vuln.today AI

6.5 MEDIUM

Leaked credentials export to network-accessible telemetry backend (AV:N); observability backend read access required (PR:L); no integrity or availability impact from credential disclosure alone.

3.1 AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

4.0 AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N

Primary rating from Vendor (GitHub_M).

CVSS VectorVendor: GitHub_M

Attack Vector

Network

Attack Complexity

Low

Privileges Required

Low

User Interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

None

Availability

None

Lifecycle Timeline

Patch available

Jul 01, 2026 - 23:02 EUVD

Analysis Generated

Jul 01, 2026 - 22:24 vuln.today

DescriptionCVE.org

OpenTelemetry Java Instrumentation provides OpenTelemetry auto-instrumentation and instrumentation libraries for Java. In versions prior to 2.28.0, the JDBC auto-instrumentation may fail to sanitize passwords in SQL CONNECT statements when the password is double-quoted. As a result, clear-text database passwords can be added to trace span attributes and exported to observability backends. This issue has been fixed in version 2.28.0.

AnalysisAI

OpenTelemetry Java Instrumentation prior to 2.28.0 leaks clear-text database passwords into distributed trace span attributes when JDBC auto-instrumentation encounters double-quoted passwords in SQL CONNECT statements, bypassing the sanitization logic. These poisoned spans are then exported to any configured observability backend - Jaeger, Zipkin, OTLP collectors, or third-party SaaS monitoring - making database credentials visible to all parties with telemetry read access. No public exploit or confirmed active exploitation exists at time of analysis, but the impact of credential exposure is high given downstream database access risk.

Technical ContextAI

OpenTelemetry Java Instrumentation is an agent-based library (CPE cpe:2.3:a:open-telemetry:opentelemetry-java-instrumentation:*:*:*:*:*:*:*:*) that intercepts Java application internals - including JDBC database drivers - via bytecode manipulation to auto-generate distributed trace spans. When recording JDBC connection events, the agent captures SQL CONNECT statement metadata as span attributes. CWE-532 (Insertion of Sensitive Information into Log File) describes the root cause class: the sanitization routine that should redact credential values before recording them fails when the password token uses double-quote delimiters, likely because the parser only handles single-quoted or unquoted string literals. The resulting span attributes containing plaintext passwords are forwarded to any configured OpenTelemetry exporter endpoint over the network, following the OTLP protocol or vendor-specific exporter integrations.

RemediationAI

Upgrade to OpenTelemetry Java Instrumentation version 2.28.0 or later; this is the vendor-confirmed fixed release per GHSA-rwqx-fvqh-6wm4 (https://github.com/open-telemetry/opentelemetry-java-instrumentation/security/advisories/GHSA-rwqx-fvqh-6wm4). If immediate upgrade is not feasible, disable JDBC auto-instrumentation by setting the agent property otel.instrumentation.jdbc.enabled=false at startup - this eliminates the credential leakage path but also removes all JDBC-related span data, degrading database observability. As a secondary compensating control, restrict read access to all observability backends (Jaeger, Zipkin, OTLP collectors, monitoring SaaS) to the minimum required personnel, reducing the window for credential harvesting even if leakage continues. After patching or mitigating, audit stored trace data in all observability backends for spans containing SQL CONNECT attributes with password values, and rotate any database credentials that may have been captured during the exposure window.