<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>OpenTelemetry — CraftedSignal Threat Feed</title><link>https://feed.craftedsignal.io/vendors/opentelemetry/</link><description>Trending threats, MITRE ATT&amp;CK coverage, and detection metadata. Fed continuously.</description><generator>Hugo</generator><language>en</language><managingEditor>hello@craftedsignal.io</managingEditor><webMaster>hello@craftedsignal.io</webMaster><lastBuildDate>Thu, 07 May 2026 12:00:00 +0000</lastBuildDate><atom:link href="https://feed.craftedsignal.io/vendors/opentelemetry/feed.xml" rel="self" type="application/rss+xml"/><item><title>OpenTelemetry Collector Azure Auth Extension Authentication Bypass</title><link>https://feed.craftedsignal.io/briefs/2026-05-otel-auth-bypass/</link><pubDate>Thu, 07 May 2026 12:00:00 +0000</pubDate><author>hello@craftedsignal.io</author><guid isPermaLink="true">https://feed.craftedsignal.io/briefs/2026-05-otel-auth-bypass/</guid><description>A server-side authentication bypass vulnerability exists in opentelemetry-collector-contrib's azureauthextension versions 0.124.0 through 0.150.0, allowing attackers with a valid Azure access token to authenticate to any OpenTelemetry receiver that uses `auth: azure_auth` due to improper JWT validation.</description><content:encoded><![CDATA[<p>The <code>azureauthextension</code> in <code>opentelemetry-collector-contrib</code> versions 0.124.0 through 0.150.0 contains a server-side authentication bypass. The <code>Authenticate</code> method doesn&rsquo;t validate incoming bearer tokens as JWTs, leading to a vulnerability where any party holding a valid Azure access token can authenticate to any OpenTelemetry receiver using <code>auth: azure_auth</code>. The extension compares client tokens to its own minted tokens via string equality, using the client-supplied <code>Host</code> header to determine the token scope. An attacker can replay tokens minted for any Azure resource the service principal has a token for, by setting the <code>Host</code> header, which compromises authentication. This issue was introduced in PR #39178 and is present in versions v0.124.0 through v0.150.0.</p>
<h2 id="attack-chain">Attack Chain</h2>
<ol>
<li>Attacker obtains a valid Azure access token for the collector&rsquo;s service principal (SP) from a co-tenant workload, compromised peer, or leaked <code>Authorization:</code> header.</li>
<li>Attacker crafts an HTTP or gRPC request to an OpenTelemetry receiver configured with <code>azureauthextension</code>.</li>
<li>Attacker sets the <code>Authorization</code> header in the request to &ldquo;Bearer &quot; followed by the obtained Azure access token.</li>
<li>If exploiting the scope confusion variant, the attacker sets the <code>Host</code> header to match the Azure resource associated with the token (e.g., <code>vault.azure.net</code> for a Key Vault token).</li>
<li>The <code>azureauthextension</code>&rsquo;s <code>Authenticate</code> method extracts the <code>Authorization</code> and <code>Host</code> headers.</li>
<li>The <code>getTokenForHost</code> function uses the client-supplied <code>Host</code> header to request a token for the corresponding scope (e.g., <code>https://vault.azure.net/.default</code>).</li>
<li>The extension performs a string comparison between the client-supplied token and the server-minted token, which succeeds because both tokens are valid for the same service principal and scope.</li>
<li>The attacker successfully bypasses authentication and ingests arbitrary telemetry data (traces, metrics, and logs) into the OpenTelemetry collector.</li>
</ol>
<h2 id="impact">Impact</h2>
<p>Successful exploitation allows unauthenticated ingestion of arbitrary traces, metrics, and logs. This can lead to telemetry-backend poisoning, log injection (masking real attacker activity), metric manipulation to trigger or suppress alerts, cost-amplification against pay-per-datapoint backends, and adversarial traces that corrupt service-graph and incident-triage signals. Multi-workload Azure environments, deployments that forward <code>Authorization:</code> headers, and multi-tenant environments are most at risk. This vulnerability affects operators of <code>opentelemetry-collector-contrib</code> v0.124.0 through v0.150.0 who have configured <code>azureauthextension</code> on a receiver&rsquo;s <code>auth:</code> block.</p>
<h2 id="recommendation">Recommendation</h2>
<ul>
<li>As an immediate mitigation, remove <code>azure_auth</code> from any receiver <code>auth:</code> blocks. This prevents the vulnerable authentication mechanism from being used.</li>
<li>Deploy the Sigma rule <code>Detect OpenTelemetry Azure Auth Bypass Attempt</code> to detect attempts to exploit this vulnerability by monitoring for specific HTTP <code>Host</code> header values associated with Azure services.</li>
<li>Implement JWT validation using <code>oidcauthextension</code> pointed at the tenant discovery URL, with audience pinned from configuration, as described in the mitigation section.</li>
<li>Upgrade to a patched version of <code>opentelemetry-collector-contrib</code> once available.</li>
</ul>
]]></content:encoded><category domain="severity">high</category><category domain="type">advisory</category><category>authentication-bypass</category><category>opentelemetry</category><category>azure</category><category>jwt</category></item></channel></rss>