azure-token-replay-opentelemetry-auth-bypass

Azure token replay in azureauthextension lets unauthenticated auth bypass in OpenTelemetry, a clear information security headache

What happened

The sticky bit here is simple, and alarming: the azureauthextension Authenticate method does not validate incoming bearer tokens as JWTs, so any valid Azure access token for any scope the service principal has ever been issued will authenticate, if an attacker picks a matching Host header. That means tokens intended for ARM, Graph, Key Vault, Storage or similar could be replayed against OpenTelemetry receivers using auth: azure_auth.

According to the advisory, the flaw affects azureauthextension versions 0.124.0 through 0.150.0 and was reported about 9 hours ago. It’s a server-side authentication bypass in the Azure Authenticator Extension, and tokens are replayable for their full issued lifetime, commonly several hours for managed identity tokens. Who discovered it and whether a patch is already published was not disclosed in the alert, so check your vendor channels first.

Why this matters to businesses

OpenTelemetry collectors are not just plumbing, they sit at the throat of monitoring, security telemetry and performance data. When collectors accept data from unauthenticated sources, your logs and metrics can be poisoned, alerting can be disabled by noise, and forensic trails can be muddied.

That hits customers, operations teams and the SOC, and it drags in partners and suppliers who rely on your telemetry for SLAs or audits. Given that tokens can be replayed for hours, you’re looking at potential hours of unauthorised access unless you act fast. And yes, treating token validation as optional or trusting network perimeter alone, that habit will bite you now.

If you’ve got the same weakness, here’s what happens next

If you run an affected azureauthextension version, an attacker who obtains any Azure access token your service principal can mint can authenticate to your OpenTelemetry receiver, by choosing the right Host header. That’s quiet persistence, effectively, for the life of the token.

In practice that can mean injected telemetry to mask attacks, false alarms that swamp responders, or malicious payloads in logs that trick analytic tooling. Recovery is administrative and forensic work, not instant. You’ll spend hours or days chasing what was trusted and what wasn’t.

What to do on Monday morning

1. Inventory first: find every OpenTelemetry receiver and every instance using azureauthextension, note versions and where auth: azure_auth is enabled.

2. Check vendor channels for a patch, and apply it immediately if available. If no patch exists, plan compensating controls now.

3. Limit network exposure to collectors: put receivers behind allowlisted IPs, private endpoints or TLS client auth so public token replay can’t reach them.

4. Harden token acceptance: where possible, require validated JWTs, check token audience and scope, and reject tokens if the Host header is not an expected value.

5. Rotate any long-lived credentials associated with the service principal and review role assignments to reduce token scopes.

6. Search logs for unusual authentication attempts and unexpected Host headers over the past token lifetime window, and preserve those logs for incident response.

7. Update alerting and playbooks so SOC and engineering teams know to treat OpenTelemetry endpoints as high-risk when auth is in question.

Where ISO standards fit, without the sales pitch

An ISO-aligned information security management system helps here in three simple ways. First, an ISO 27001 approach forces you to inventory and control who and what can authenticate to critical services, and that reduces chances of a blind dependency, see this for practical alignment: https://synergosconsultancy.co.uk/iso27001/.

Second, when collectors form part of operational resilience, mapping continuity and recovery to standards matters, so treat continuity planning as part of the fix and look at business continuity guidance here: https://synergosconsultancy.co.uk/iso-22301-business-continuity-management-system-bcms/.

Third, baseline technical controls and supplier checks stop simple misconfigurations from becoming breaches; practical certification and baseline work can be found here: https://synergosconsultancy.co.uk/iasme-certifications/.

Put bluntly, ISO-style control objectives make you ask the obvious question early, like who can mint tokens that we accept, and why are collectors trusting Host headers to decide scope.

Acting on those questions saves hours of crisis calls later.