CVE-2024-42368

What it actually does

The bearertokenauth server authenticator performs a non-constant-time string comparison when validating received bearer tokens against the configured value, enabling remote timing attacks that can recover the secret token.

Why it matters to the business

An attacker with network access can obtain a valid bearer token, inject fabricated or malicious telemetry data into the collector pipeline, and degrade the accuracy and trustworthiness of observability data used for monitoring and incident response.

How an attack unfolds

An attacker with network access to an OpenTelemetry collector using the vulnerable bearertokenauth authenticator iteratively sends candidate bearer tokens, measures the server response latency for each attempt, and uses the timing differences to narrow down and eventually guess the correct token, after which the attacker can submit fabricated telemetry.

How to fix it

Upgrade the OpenTelemetry Collector to version 0.107.0 or later, or apply the fix commit 23d56edfa124dd490927372f435c6f317704cbff in the opentelemetry-collector-contrib repository; replace any static bearer-token configurations with short-lived tokens or switch to a constant-time comparison authenticator.

How to confirm the fix worked

Confirm the running collector binary or container image reports version 0.107.0 or newer; inspect the bearertokenauth extension configuration and source to verify constant-time comparison (crypto/subtle.ConstantTimeCompare or equivalent) is in use; perform a controlled timing test with known-good and known-bad tokens to verify response times are independent of token correctness.

Typical attack path

1. Identify a collector endpoint protected by the bearertokenauth server authenticator
2. Craft and send multiple bearer-token authentication attempts with incrementally different token values
3. Measure and compare response times across attempts to perform statistical timing analysis
4. Recover the full valid bearer token
5. Use the recovered token to authenticate and inject fabricated traces, metrics, or logs

How to detect it

Review collector access logs for repeated authentication attempts from the same source IP or with varying bearer token lengths; look for unusually high volumes of 401 responses followed by a successful 200 from the same client; correlate with telemetry ingestion anomalies such as sudden spikes in trace or metric volume from a single authenticated source.

What your security team should do

• Immediately upgrade all collector instances to the fixed version 0.107.0 or the referenced commit
• Audit all deployments using bearertokenauth and rotate any long-lived bearer tokens
• Prefer short-lived, automatically rotated tokens or migrate to stronger authentication mechanisms
• Monitor EPSS and exploit maturity signals for any increase in observed attempts