Summary

The SQL sanitizer that produces db.statement and db.query.text can misread block comments and backslash-escaped quotes. When it does, later string literals appear unsanitized in span attributes. Passwords or other secrets written directly into SQL can then reach observability backends even with query sanitization enabled.

Impact

Affected: the Java agent, and SQL client library instrumentations (including JDBC) that use the shared SQL analyzer in io.opentelemetry.instrumentation:opentelemetry-instrumentation-api-incubator. Both the default and the database stable semantic convention modes are affected.

This is the same class of information disclosure as GHSA-rwqx-fvqh-6wm4.

Patches

Upgrade the Java agent to 2.33.0 or later. For library instrumentation, upgrade to a release that uses opentelemetry-instrumentation-api-incubator 2.33.0-alpha or later.

With the fix, quotes and -- markers inside block comments no longer hide where the comment ends. Quoted values that open and close inside a comment are still sanitized. When nested comments or backslash escaping make the boundaries ambiguous, the sanitizer replaces the rest of the query with ? and skips extracting the query summary and target.

The fix was merged in #20818 and backported to the 2.x release line in #20864.

Details

Quotes and comment markers inside block comments

SELECT name FROM users /* don't cache */ WHERE password = 'hunter2'

• Vulnerable db.query.text: SELECT name FROM users /* don?hunter2'
• Patched db.query.text: SELECT name FROM users /* don't cache */ WHERE password = ?

The vulnerable sanitizer treats the apostrophe in don't as the start of a string literal that ends at the opening quote of 'hunter2'. It replaces that span with ? and leaves hunter2 in the output. Other quote characters, -- markers, and nested block comments inside a block comment can expose later literals the same way.

Backslash-escaped quotes

SELECT name FROM users WHERE name = 'O\'Brien' AND password = 'hunter2'

• Vulnerable db.query.text: SELECT name FROM users WHERE name = ?Brien?hunter2'
• Patched db.query.text: SELECT name FROM users WHERE name = ?

The vulnerable sanitizer recognizes doubled single quotes ('') as escapes, but not backslash-escaped quotes (\'). MySQL and MariaDB accept \' under their default sql_mode, and PostgreSQL accepts it in E'...' strings. Whether \' is an escape depends on the database and its settings, so the patched sanitizer replaces everything from that literal onward with ?.

Mitigation and previously exported data

Use parameterized SQL with bound values instead of writing secrets directly into query text. Don't rely on query sanitization alone to protect secrets.

Upgrading does not remove values that were already exported. Check retained telemetry for exposed values, restrict access to it or delete it as needed, and rotate any exposed credentials.