CWE-290
AllowedAuthentication Bypass by Spoofing
Abstraction: Base · Status: Incomplete
This attack-focused weakness is caused by incorrectly implemented authentication schemes that are subject to spoofing attacks.
925 vulnerabilities reference this CWE, most recent first.
GHSA-PH67-FVRF-JCVP
Vulnerability from github – Published: 2025-08-05 18:30 – Updated: 2025-08-05 21:31An Authentication Bypass vulnerability in Blue Access' Cobalt X1 thru 02.000.187 allows an unauthorized attacker to log into the application as an administrator without valid credentials.
{
"affected": [],
"aliases": [
"CVE-2025-50454"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-08-05T18:15:31Z",
"severity": "MODERATE"
},
"details": "An Authentication Bypass vulnerability in Blue Access\u0027 Cobalt X1 thru 02.000.187 allows an unauthorized attacker to log into the application as an administrator without valid credentials.",
"id": "GHSA-ph67-fvrf-jcvp",
"modified": "2025-08-05T21:31:37Z",
"published": "2025-08-05T18:30:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-50454"
},
{
"type": "WEB",
"url": "https://blueaccesstech.com/collections/software/products/cobalt-x1-software"
},
{
"type": "WEB",
"url": "https://snakemacready.github.io/cve/2025/08/01/CVE-2025-50454.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-PH86-P8F6-F9R2
Vulnerability from github – Published: 2026-05-27 16:50 – Updated: 2026-05-27 16:50Description
X509Authenticator implements client-certificate (mTLS) authentication: the web server validates the client's certificate against a trusted CA, then passes the certificate's Subject DN (Distinguished Name: a string like CN=Alice,O=Example,emailAddress=alice@example.com) to Symfony via $_SERVER['SSL_CLIENT_S_DN']. Symfony extracts the user identifier from that string.
The extraction uses an unanchored regex that matches emailAddress= anywhere in the DN string: including inside the value of a different RDN (Relative Distinguished Name: one key=value component of the DN), such as CN. An attacker who can obtain a certificate from a trusted CA with a free-text CN can smuggle emailAddress=victim@target inside the CN value and be authenticated as the victim.
Resolution
The X509Authenticator now uses a regex that anchors the match to an RDN boundary (start of string, or following a , / / separator).
The patch for this issue is available here for branch 5.4.
Credits
Symfony would like to thank Claude Mythos Preview (via Project Glasswing) for reporting the issue and providing the fix.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "symfony/security-http"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.4.52"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "symfony/security-http"
},
"ranges": [
{
"events": [
{
"introduced": "6.0.0-BETA1"
},
{
"fixed": "6.4.40"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "symfony/security-http"
},
"ranges": [
{
"events": [
{
"introduced": "7.0.0-BETA1"
},
{
"fixed": "7.4.12"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "symfony/security-http"
},
"ranges": [
{
"events": [
{
"introduced": "8.0.0-BETA1"
},
{
"fixed": "8.0.12"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "symfony/symfony"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.4.52"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "symfony/symfony"
},
"ranges": [
{
"events": [
{
"introduced": "6.0.0-BETA1"
},
{
"fixed": "6.4.40"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "symfony/symfony"
},
"ranges": [
{
"events": [
{
"introduced": "7.0.0-BETA1"
},
{
"fixed": "7.4.12"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "symfony/symfony"
},
"ranges": [
{
"events": [
{
"introduced": "8.0.0-BETA1"
},
{
"fixed": "8.0.12"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-45063"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-27T16:50:42Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Description\n\n`X509Authenticator` implements client-certificate (mTLS) authentication: the web server validates the client\u0027s certificate against a trusted CA, then passes the certificate\u0027s Subject DN (Distinguished Name: a string like `CN=Alice,O=Example,emailAddress=alice@example.com`) to Symfony via `$_SERVER[\u0027SSL_CLIENT_S_DN\u0027]`. Symfony extracts the user identifier from that string.\n\nThe extraction uses an **unanchored** regex that matches `emailAddress=` anywhere in the DN string: including inside the *value* of a different RDN (Relative Distinguished Name: one `key=value` component of the DN), such as `CN`. An attacker who can obtain a certificate from a trusted CA with a free-text `CN` can smuggle `emailAddress=victim@target` inside the CN value and be authenticated as the victim.\n\n### Resolution\n\nThe `X509Authenticator` now uses a regex that anchors the match to an RDN boundary (start of string, or following a `,` / `/` separator).\n\nThe patch for this issue is available [here](https://github.com/symfony/symfony/commit/ccb3f724c7ff55670a6fe3521c7bf1514cceb478) for branch 5.4.\n\n### Credits\n\nSymfony would like to thank Claude Mythos Preview (via Project Glasswing) for reporting the issue and providing the fix.",
"id": "GHSA-ph86-p8f6-f9r2",
"modified": "2026-05-27T16:50:42Z",
"published": "2026-05-27T16:50:42Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/symfony/symfony/security/advisories/GHSA-ph86-p8f6-f9r2"
},
{
"type": "WEB",
"url": "https://github.com/symfony/symfony/commit/ccb3f724c7ff55670a6fe3521c7bf1514cceb478"
},
{
"type": "WEB",
"url": "https://github.com/FriendsOfPHP/security-advisories/blob/master/symfony/security-http/CVE-2026-45063.yaml"
},
{
"type": "WEB",
"url": "https://github.com/FriendsOfPHP/security-advisories/blob/master/symfony/symfony/CVE-2026-45063.yaml"
},
{
"type": "PACKAGE",
"url": "https://github.com/symfony/symfony"
},
{
"type": "WEB",
"url": "https://symfony.com/cve-2026-45063"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Symfony Vulnerable to Identity Spoofing via Unanchored DN Regex in X509Authenticator"
}
GHSA-PH8H-4MQ7-VW5V
Vulnerability from github – Published: 2024-09-12 21:32 – Updated: 2024-09-12 21:32An issue was discovered in GitLab CE/EE affecting all versions starting from 8.14 prior to 17.1.7, starting from 17.2 prior to 17.2.5, and starting from 17.3 prior to 17.3.2, which allows an attacker to trigger a pipeline as an arbitrary user under certain circumstances.
{
"affected": [],
"aliases": [
"CVE-2024-6678"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-09-12T19:15:04Z",
"severity": "CRITICAL"
},
"details": "An issue was discovered in GitLab CE/EE affecting all versions starting from 8.14 prior to 17.1.7, starting from 17.2 prior to 17.2.5, and starting from 17.3 prior to 17.3.2, which allows an attacker to trigger a pipeline as an arbitrary user under certain circumstances.",
"id": "GHSA-ph8h-4mq7-vw5v",
"modified": "2024-09-12T21:32:02Z",
"published": "2024-09-12T21:32:02Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-6678"
},
{
"type": "WEB",
"url": "https://hackerone.com/reports/2595495"
},
{
"type": "WEB",
"url": "https://gitlab.com/gitlab-org/gitlab/-/issues/471923"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-PHF4-W5J6-499Q
Vulnerability from github – Published: 2024-12-13 15:30 – Updated: 2026-04-28 21:35Authentication Bypass by Spoofing vulnerability in Michal Novák Secure Admin IP allows Functionality Bypass.This issue affects Secure Admin IP: from n/a through 2.0.
{
"affected": [],
"aliases": [
"CVE-2023-41133"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-12-13T15:15:22Z",
"severity": "MODERATE"
},
"details": "Authentication Bypass by Spoofing vulnerability in Michal Nov\u00e1k Secure Admin IP allows Functionality Bypass.This issue affects Secure Admin IP: from n/a through 2.0.",
"id": "GHSA-phf4-w5j6-499q",
"modified": "2026-04-28T21:35:25Z",
"published": "2024-12-13T15:30:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-41133"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/plugin/secure-admin-ip/vulnerability/wordpress-secure-admin-ip-plugin-2-0-ip-spoofing-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-PJV4-3C63-699F
Vulnerability from github – Published: 2026-05-06 22:32 – Updated: 2026-05-14 20:42Summary
A server-side authentication bypass in azureauthextension allows any party who holds a single valid Azure access token for any scope the collector's configured identity can mint for to authenticate to any OpenTelemetry receiver that uses auth: azure_auth. The extension's Authenticate method does not validate incoming bearer tokens as JWTs. Instead, it calls its own configured credential to obtain an access token and compares the client's token to the result with string equality — and the scope for that server-side token request is taken from the client-supplied Host header. As a result, a token minted for any Azure resource the service principal has ever been issued a token for (ARM, Graph, Key Vault, Storage, etc.) will authenticate to the collector if the attacker picks a matching Host. Tokens are replayable for the full issued lifetime (commonly several hours for managed identity tokens).
Severity: High (CVSS 8.1). See "Threat model" below for the preconditions that inform that score.
Root cause
The extension implements both extensionauth.HTTPClient (outbound: "attach my identity to requests I send") and extensionauth.Server (inbound: "validate a credential someone presented to me"). Those two interfaces look symmetric but are not: holding a credential to present says nothing about the ability to validate a credential someone else presents. The outbound path only requires credential.GetToken(); the inbound path requires JWT signature verification against the issuer's JWKS, issuer/audience/exp/nbf checks, and an algorithm allowlist — none of which the extension does.
PR #39178 ("Implement extensionauth.HTTPClient and extensionauth.Server interface functions") added the Server path in v0.124.0 by reusing the same credential object and comparing strings. That server-side path is present in every release through v0.150.0. The outbound HTTPClient path (used by Azure exporters) is unaffected.
Details
Vulnerable code — extension/azureauthextension/extension.go:208–235:
func (a *authenticator) Authenticate(ctx context.Context, headers map[string][]string) (context.Context, error) {
auth, err := getHeaderValue("Authorization", headers)
if err != nil { return ctx, err }
host, err := getHeaderValue("Host", headers)
if err != nil { return ctx, err }
authFormat := strings.Split(auth, " ")
if len(authFormat) != 2 { /* ... */ }
if authFormat[0] != "Bearer" { /* ... */ }
token, err := a.getTokenForHost(ctx, host) // asks the collector's own identity
if err != nil { return ctx, err }
if authFormat[1] != token { // string comparison, not JWT validation
return ctx, errors.New("unauthorized: invalid token")
}
return ctx, nil
}
And getTokenForHost at extension.go:187–206:
options := policy.TokenRequestOptions{
Scopes: []string{
fmt.Sprintf("https://%s/.default", host), // client-supplied Host chooses scope
},
}
Two independent problems compose here:
1. No JWT validation. Real Entra ID bearer validation requires verifying the JWT signature against the tenant JWKS and checking iss, aud, exp, nbf, plus an algorithm allowlist. The extension does none of this. The "expected" value is a token the server mints from its own credential, not a signature to verify. Any party that already holds a valid token for the collector's identity — a co-tenant pod that shares the managed identity, any peer authenticated with the same service principal, any component that retained an Authorization: header — can replay it directly.
2. Attacker-controlled audience. The scope used to mint the "expected" token comes from the client-supplied Host header: https://<Host>/.default. The azcore credential returns a consistent token per (identity, scope) pair within the cache window, so an attacker can pick any scope the SP has been issued a token for and match it by setting Host accordingly. This is the sharper of the two flaws: it means a token leaked from an unrelated Azure integration — ARM, Graph, Key Vault, a different Storage account — authenticates to the collector.
The correct primitive is a real JWT validator — e.g. github.com/coreos/go-oidc/v3 pointed at the tenant's discovery endpoint, with audience and issuer pinned server-side from configuration, never derived from request headers.
Proof of concept
Both variants assume a collector running with azureauthextension v0.124.0–v0.150.0, configured with any credential mode and referenced from a receiver's auth: block:
extensions:
azure_auth:
managed_identity:
client_id: ${CLIENT_ID}
receivers:
otlp:
protocols:
http:
endpoint: 0.0.0.0:4318
auth:
authenticator: azure_auth
service:
extensions: [azure_auth]
pipelines:
traces:
receivers: [otlp]
exporters: [debug]
Variant A — Replay (same scope)
The attacker controls a workload that shares the collector's managed identity (common in AKS when multiple pods bind the same UAMI). Both workloads query IMDS for https://management.azure.com/.default and receive the same cached token. The attacker replays:
POST /v1/traces HTTP/1.1
Host: management.azure.com
Authorization: Bearer eyJ... # token minted for management.azure.com
Content-Type: application/json
{"resourceSpans":[...]}
Authenticate calls getTokenForHost(ctx, "management.azure.com"), receives the identical cached token, and the string comparison passes.
Variant B — Scope confusion (the stronger case)
The attacker holds a token for the SP issued for a different Azure resource — say Key Vault, obtained from an entirely unrelated integration. The collector was never intended to accept Key Vault tokens. The attacker sets Host to match:
POST /v1/traces HTTP/1.1
Host: vault.azure.net
Authorization: Bearer eyJ... # token minted for vault.azure.net
Content-Type: application/json
{"resourceSpans":[...]}
Authenticate calls getTokenForHost(ctx, "vault.azure.net"). The collector's credential mints (or returns cached) a token for https://vault.azure.net/.default — the same token the attacker holds, because both come from the same SP issued for the same scope by the same IdP. Comparison passes. The collector accepts telemetry gated on "proof of identity to Key Vault."
In a correct implementation, the JWT's aud would be pinned server-side to a value unrelated to Host, and Variant B would fail regardless of what the attacker put in the Host header.
A small Go reproducer can be built around the extension's own test harness: the existing TestAuthenticate in extension_test.go is effectively a demonstration of the broken behavior — it passes when the client-supplied token equals the server-side token for the given Host, which is exactly what an attacker arranges.
Impact
Vulnerability class: Improper Authentication (CWE-287), with contributing CWE-347 (Improper Verification of Cryptographic Signature — no JWT validation), CWE-294 (Authentication Bypass by Capture-replay — tokens replayable for full TTL), and CWE-290 (Authentication Bypass by Spoofing — client Host header chooses the expected scope).
Threat model / precondition. The attacker needs to already hold (or be able to obtain) a valid Azure access token issued to the collector's SP for any scope. In practice this is satisfied by: (a) controlling another workload that binds the same managed identity, (b) compromising any peer authenticated with the same SP, or (c) observing an Authorization: header from any prior legitimate request for the SP. This is what drives the 8.1 score — the precondition is non-trivial but is routine in multi-workload Azure environments.
Who is impacted. Any operator of opentelemetry-collector-contrib v0.124.0 through v0.150.0 who configured azureauthextension on a receiver's auth: block. This applies to both HTTP and gRPC receivers — gRPC receivers surface :authority as Host through the collector's header handling, so the same exploit path applies there.
Deployments most at risk:
- Multi-workload Azure environments where the collector shares a managed identity with other workloads (any such workload can authenticate as an arbitrary telemetry source).
- Deployments that forward Authorization: headers through proxies, service meshes, or logging pipelines (one leaked token is enough, and persists for the token TTL — typically several hours for MI tokens, not the 60-minute user-token window).
- Multi-tenant environments where different customers' telemetry converges at a collector protected by this extension.
Consequences. Unauthenticated (from the collector's perspective) ingest of arbitrary traces, metrics, and logs. Downstream effects depend on the collector's exporters and include telemetry-backend poisoning, log injection (masking real attacker activity in SIEMs), 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.
Not impacted. The extension's outbound extensionauth.HTTPClient path, used by Azure exporters, is unaffected. Operators who use azureauthextension only on exporters can continue doing so.
Mitigation
Until a patched release is available, remove azure_auth from any receiver auth: blocks. For genuine Entra ID JWT validation on OTLP receivers, use oidcauthextension pointed at the tenant discovery URL, with audience pinned from configuration:
extensions:
oidc:
issuer_url: https://login.microsoftonline.com/<tenant-id>/v2.0
audience: <expected-api-audience>
Resources
- PR introducing the vulnerable server-side path: #39178
- Affected versions: v0.124.0 – v0.150.0
Assisted-by: Opus 4.7
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/open-telemetry/opentelemetry-collector-contrib/extension/azureauthextension"
},
"ranges": [
{
"events": [
{
"introduced": "0.124.0"
},
{
"last_affected": "0.150.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-42602"
],
"database_specific": {
"cwe_ids": [
"CWE-208",
"CWE-287",
"CWE-290",
"CWE-294",
"CWE-347"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-06T22:32:43Z",
"nvd_published_at": "2026-05-13T21:16:47Z",
"severity": "HIGH"
},
"details": "### Summary\n\nA server-side authentication bypass in `azureauthextension` allows any party who holds a single valid Azure access token for *any scope the collector\u0027s configured identity can mint for* to authenticate to any OpenTelemetry receiver that uses `auth: azure_auth`. The extension\u0027s `Authenticate` method does not validate incoming bearer tokens as JWTs. Instead, it calls its own configured credential to obtain an access token and compares the client\u0027s token to the result with string equality \u2014 and the scope for that server-side token request is taken from the client-supplied `Host` header. As a result, a token minted for any Azure resource the service principal has ever been issued a token for (ARM, Graph, Key Vault, Storage, etc.) will authenticate to the collector if the attacker picks a matching `Host`. Tokens are replayable for the full issued lifetime (commonly several hours for managed identity tokens).\n\nSeverity: High (CVSS 8.1). See \"Threat model\" below for the preconditions that inform that score.\n\n### Root cause\n\nThe extension implements both `extensionauth.HTTPClient` (outbound: \"attach my identity to requests I send\") and `extensionauth.Server` (inbound: \"validate a credential someone presented to me\"). Those two interfaces look symmetric but are not: holding a credential to present says nothing about the ability to validate a credential someone else presents. The outbound path only requires `credential.GetToken()`; the inbound path requires JWT signature verification against the issuer\u0027s JWKS, issuer/audience/exp/nbf checks, and an algorithm allowlist \u2014 none of which the extension does.\n\nPR #39178 (\"Implement extensionauth.HTTPClient and extensionauth.Server interface functions\") added the `Server` path in v0.124.0 by reusing the same credential object and comparing strings. That server-side path is present in every release through v0.150.0. The outbound `HTTPClient` path (used by Azure exporters) is unaffected.\n\n### Details\n\nVulnerable code \u2014 `extension/azureauthextension/extension.go:208\u2013235`:\n\n```go\nfunc (a *authenticator) Authenticate(ctx context.Context, headers map[string][]string) (context.Context, error) {\n auth, err := getHeaderValue(\"Authorization\", headers)\n if err != nil { return ctx, err }\n host, err := getHeaderValue(\"Host\", headers)\n if err != nil { return ctx, err }\n\n authFormat := strings.Split(auth, \" \")\n if len(authFormat) != 2 { /* ... */ }\n if authFormat[0] != \"Bearer\" { /* ... */ }\n\n token, err := a.getTokenForHost(ctx, host) // asks the collector\u0027s own identity\n if err != nil { return ctx, err }\n if authFormat[1] != token { // string comparison, not JWT validation\n return ctx, errors.New(\"unauthorized: invalid token\")\n }\n return ctx, nil\n}\n```\n\nAnd `getTokenForHost` at `extension.go:187\u2013206`:\n\n```go\noptions := policy.TokenRequestOptions{\n Scopes: []string{\n fmt.Sprintf(\"https://%s/.default\", host), // client-supplied Host chooses scope\n },\n}\n```\n\nTwo independent problems compose here:\n\n**1. No JWT validation.** Real Entra ID bearer validation requires verifying the JWT signature against the tenant JWKS and checking `iss`, `aud`, `exp`, `nbf`, plus an algorithm allowlist. The extension does none of this. The \"expected\" value is a token the server mints from its own credential, not a signature to verify. Any party that already holds a valid token for the collector\u0027s identity \u2014 a co-tenant pod that shares the managed identity, any peer authenticated with the same service principal, any component that retained an `Authorization:` header \u2014 can replay it directly.\n\n**2. Attacker-controlled audience.** The scope used to mint the \"expected\" token comes from the client-supplied `Host` header: `https://\u003cHost\u003e/.default`. The `azcore` credential returns a consistent token per (identity, scope) pair within the cache window, so an attacker can pick any scope the SP has been issued a token for and match it by setting `Host` accordingly. This is the sharper of the two flaws: it means a token leaked from an unrelated Azure integration \u2014 ARM, Graph, Key Vault, a different Storage account \u2014 authenticates to the collector.\n\nThe correct primitive is a real JWT validator \u2014 e.g. `github.com/coreos/go-oidc/v3` pointed at the tenant\u0027s discovery endpoint, with audience and issuer pinned *server-side from configuration*, never derived from request headers.\n\n### Proof of concept\n\nBoth variants assume a collector running with `azureauthextension` v0.124.0\u2013v0.150.0, configured with any credential mode and referenced from a receiver\u0027s `auth:` block:\n\n```yaml\nextensions:\n azure_auth:\n managed_identity:\n client_id: ${CLIENT_ID}\n\nreceivers:\n otlp:\n protocols:\n http:\n endpoint: 0.0.0.0:4318\n auth:\n authenticator: azure_auth\n\nservice:\n extensions: [azure_auth]\n pipelines:\n traces:\n receivers: [otlp]\n exporters: [debug]\n```\n\n#### Variant A \u2014 Replay (same scope)\n\nThe attacker controls a workload that shares the collector\u0027s managed identity (common in AKS when multiple pods bind the same UAMI). Both workloads query IMDS for `https://management.azure.com/.default` and receive the same cached token. The attacker replays:\n\n```\nPOST /v1/traces HTTP/1.1\nHost: management.azure.com\nAuthorization: Bearer eyJ... # token minted for management.azure.com\nContent-Type: application/json\n\n{\"resourceSpans\":[...]}\n```\n\n`Authenticate` calls `getTokenForHost(ctx, \"management.azure.com\")`, receives the identical cached token, and the string comparison passes.\n\n#### Variant B \u2014 Scope confusion (the stronger case)\n\nThe attacker holds a token for the SP issued for a *different* Azure resource \u2014 say Key Vault, obtained from an entirely unrelated integration. The collector was never intended to accept Key Vault tokens. The attacker sets `Host` to match:\n\n```\nPOST /v1/traces HTTP/1.1\nHost: vault.azure.net\nAuthorization: Bearer eyJ... # token minted for vault.azure.net\nContent-Type: application/json\n\n{\"resourceSpans\":[...]}\n```\n\n`Authenticate` calls `getTokenForHost(ctx, \"vault.azure.net\")`. The collector\u0027s credential mints (or returns cached) a token for `https://vault.azure.net/.default` \u2014 the same token the attacker holds, because both come from the same SP issued for the same scope by the same IdP. Comparison passes. The collector accepts telemetry gated on \"proof of identity to Key Vault.\"\n\nIn a correct implementation, the JWT\u0027s `aud` would be pinned server-side to a value unrelated to `Host`, and Variant B would fail regardless of what the attacker put in the `Host` header.\n\nA small Go reproducer can be built around the extension\u0027s own test harness: the existing `TestAuthenticate` in `extension_test.go` is effectively a demonstration of the broken behavior \u2014 it passes when the client-supplied token equals the server-side token for the given `Host`, which is exactly what an attacker arranges.\n\n### Impact\n\n**Vulnerability class:** Improper Authentication (CWE-287), with contributing CWE-347 (Improper Verification of Cryptographic Signature \u2014 no JWT validation), CWE-294 (Authentication Bypass by Capture-replay \u2014 tokens replayable for full TTL), and CWE-290 (Authentication Bypass by Spoofing \u2014 client `Host` header chooses the expected scope).\n\n**Threat model / precondition.** The attacker needs to already hold (or be able to obtain) a valid Azure access token issued to the collector\u0027s SP for any scope. In practice this is satisfied by: (a) controlling another workload that binds the same managed identity, (b) compromising any peer authenticated with the same SP, or (c) observing an `Authorization:` header from any prior legitimate request for the SP. This is what drives the 8.1 score \u2014 the precondition is non-trivial but is routine in multi-workload Azure environments.\n\n**Who is impacted.** Any operator of `opentelemetry-collector-contrib` v0.124.0 through v0.150.0 who configured `azureauthextension` on a receiver\u0027s `auth:` block. This applies to both HTTP and gRPC receivers \u2014 gRPC receivers surface `:authority` as `Host` through the collector\u0027s header handling, so the same exploit path applies there.\n\n**Deployments most at risk:**\n- Multi-workload Azure environments where the collector shares a managed identity with other workloads (any such workload can authenticate as an arbitrary telemetry source).\n- Deployments that forward `Authorization:` headers through proxies, service meshes, or logging pipelines (one leaked token is enough, and persists for the token TTL \u2014 typically several hours for MI tokens, not the 60-minute user-token window).\n- Multi-tenant environments where different customers\u0027 telemetry converges at a collector protected by this extension.\n\n**Consequences.** Unauthenticated (from the collector\u0027s perspective) ingest of arbitrary traces, metrics, and logs. Downstream effects depend on the collector\u0027s exporters and include telemetry-backend poisoning, log injection (masking real attacker activity in SIEMs), 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.\n\n**Not impacted.** The extension\u0027s outbound `extensionauth.HTTPClient` path, used by Azure exporters, is unaffected. Operators who use `azureauthextension` only on exporters can continue doing so.\n\n### Mitigation\n\nUntil a patched release is available, remove `azure_auth` from any receiver `auth:` blocks. For genuine Entra ID JWT validation on OTLP receivers, use `oidcauthextension` pointed at the tenant discovery URL, with audience pinned from configuration:\n\n```yaml\nextensions:\n oidc:\n issuer_url: https://login.microsoftonline.com/\u003ctenant-id\u003e/v2.0\n audience: \u003cexpected-api-audience\u003e\n```\n\n### Resources\n\n- PR introducing the vulnerable server-side path: [#39178](https://github.com/open-telemetry/opentelemetry-collector-contrib/pull/39178)\n- Affected versions: v0.124.0 \u2013 v0.150.0\n\nAssisted-by: Opus 4.7",
"id": "GHSA-pjv4-3c63-699f",
"modified": "2026-05-14T20:42:40Z",
"published": "2026-05-06T22:32:43Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/open-telemetry/opentelemetry-collector-contrib/security/advisories/GHSA-pjv4-3c63-699f"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42602"
},
{
"type": "PACKAGE",
"url": "https://github.com/open-telemetry/opentelemetry-collector-contrib"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "opentelemetry-collector-contrib\u0027s azureauthextension Authenticate method does not validate bearer tokens, allowing auth bypass via replay"
}
GHSA-PMXQ-PJ47-J8J4
Vulnerability from github – Published: 2023-09-08 12:19 – Updated: 2023-09-08 12:19Impact
The proxy mode of WireMock, can be protected by the network restrictions configuration, as documented in Preventing proxying to and recording from specific target addresses. These restrictions can be configured using the domain names, and in such a case the configuration is vulnerable to the DNS rebinding attacks. A similar patch was applied in WireMock 3.0.0-beta-15 for the WireMock Webhook Extensions.
The root cause of the attack is a defect in the logic which allows for a race condition triggered by a DNS server whose address expires in between the initial validation and the outbound network request that might go to a domain that was supposed to be prohibited. Control over a DNS service is required to exploit this attack, so it has high execution complexity and limited impact.
Affected versions
- WireMock 3,x until 3.0.3 (security patch), on default settings in environments with access to the network
- WireMock 2.x until 2.35.1 (security patch), on default settings in environments with access to the network
- Python WireMock until 2.6.1
- WireMock Studio - all versions, this proprietary product was discontinued in 2022
Patches
- WireMock 3.0.3 + the 3.0.3-1 Docker image
- WireMock 2.35.1 + the 2.35.1-1 Docker image - backport to WireMock 2.x
- Python WireMock 2.6.1
Workarounds
For WireMock:
- Option 1: Configure WireMock to use IP addresses instead of the domain names in the outbound URLs subject to DNS rebinding
- Option 2: Use external firewall rules to define the list of permitted destinations
For WireMock Studio: N/A. Switch to another distribution, there will be no fix provided. The vendor of former WireMock Studio recommends migration to WireMock Cloud
References
- CVE-2023-41327 - Related issue in the WireMock Webhooks Extension
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.wiremock:wiremock-standalone"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.0.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.wiremock:wiremock"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.0.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "com.github.tomakehurst:wiremock-jre8"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.35.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "com.github.tomakehurst:wiremock-jre8-standalone"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.35.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "wiremock"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.6.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-41329"
],
"database_specific": {
"cwe_ids": [
"CWE-290",
"CWE-350"
],
"github_reviewed": true,
"github_reviewed_at": "2023-09-08T12:19:49Z",
"nvd_published_at": "2023-09-06T21:15:14Z",
"severity": "LOW"
},
"details": "### Impact\n\nThe proxy mode of WireMock, can be protected by the network restrictions configuration, as documented in [Preventing proxying to and recording from specific target addresses](https://wiremock.org/docs/configuration/#preventing-proxying-to-and-recording-from-specific-target-addresses). These restrictions can be configured using the domain names, and in such a case the configuration is vulnerable to the DNS rebinding attacks. A similar patch was applied in WireMock 3.0.0-beta-15 for the WireMock Webhook Extensions.\n\nThe root cause of the attack is a defect in the logic which allows for a race condition triggered by a DNS server whose address expires in between the initial validation and the outbound network request that might go to a domain that was supposed to be prohibited. Control over a DNS service is required to exploit this attack, so it has high execution complexity and limited impact.\n\n### Affected versions\n\n- WireMock 3,x until 3.0.3 (security patch), on default settings in environments with access to the network\n- WireMock 2.x until 2.35.1 (security patch), on default settings in environments with access to the network\n- Python WireMock until 2.6.1\n- WireMock Studio - all versions, this proprietary product was discontinued in 2022\n\n\n### Patches\n\n- WireMock 3.0.3 + the 3.0.3-1 Docker image\n- WireMock 2.35.1 + the 2.35.1-1 Docker image - backport to WireMock 2.x\n- Python WireMock 2.6.1\n\n### Workarounds\n\nFor WireMock:\n\n- Option 1: Configure WireMock to use IP addresses instead of the domain names in the outbound URLs subject to DNS rebinding\n- Option 2: Use external firewall rules to define the list of permitted destinations\n\nFor WireMock Studio: N/A. Switch to another distribution, there will be no fix provided. The vendor of former WireMock Studio recommends migration to [WireMock Cloud](https://www.wiremock.io/product)\n\n### References\n\n- CVE-2023-41327 - Related issue in the WireMock Webhooks Extension\n",
"id": "GHSA-pmxq-pj47-j8j4",
"modified": "2023-09-08T12:19:49Z",
"published": "2023-09-08T12:19:49Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/wiremock/wiremock/security/advisories/GHSA-pmxq-pj47-j8j4"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-41329"
},
{
"type": "PACKAGE",
"url": "https://github.com/wiremock/wiremock"
},
{
"type": "WEB",
"url": "https://wiremock.org/docs/configuration/#preventing-proxying-to-and-recording-from-specific-target-addresses"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:H/PR:H/UI:N/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
}
],
"summary": "Domain restrictions bypass via DNS Rebinding in WireMock and WireMock Studio webhooks, proxy and recorder modes"
}
GHSA-PPP4-P6WJ-8GP8
Vulnerability from github – Published: 2025-03-04 06:30 – Updated: 2025-03-04 15:31The Admin and Site Enhancements (ASE) WordPress plugin before 7.6.10 retrieves client IP addresses from potentially untrusted headers, allowing an attacker to manipulate their value to bypass the login limit feature in the Admin and Site Enhancements (ASE) WordPress plugin before 7.6.10.
{
"affected": [],
"aliases": [
"CVE-2024-13685"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-03-04T06:15:27Z",
"severity": "MODERATE"
},
"details": "The Admin and Site Enhancements (ASE) WordPress plugin before 7.6.10 retrieves client IP addresses from potentially untrusted headers, allowing an attacker to manipulate their value to bypass the login limit feature in the Admin and Site Enhancements (ASE) WordPress plugin before 7.6.10.",
"id": "GHSA-ppp4-p6wj-8gp8",
"modified": "2025-03-04T15:31:48Z",
"published": "2025-03-04T06:30:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-13685"
},
{
"type": "WEB",
"url": "https://wpscan.com/vulnerability/72c61904-253d-42d1-9edd-7ea2162a2f85"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-PR8C-F372-64CH
Vulnerability from github – Published: 2024-06-24 00:34 – Updated: 2024-11-21 21:33Click Studios Passwordstate Core before 9.8 build 9858 allows Authentication Bypass.
{
"affected": [],
"aliases": [
"CVE-2024-39337"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-06-24T00:15:09Z",
"severity": "MODERATE"
},
"details": "Click Studios Passwordstate Core before 9.8 build 9858 allows Authentication Bypass.",
"id": "GHSA-pr8c-f372-64ch",
"modified": "2024-11-21T21:33:30Z",
"published": "2024-06-24T00:34:02Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39337"
},
{
"type": "WEB",
"url": "https://www.clickstudios.com.au/passwordstate-changelog.aspx"
},
{
"type": "WEB",
"url": "https://www.clickstudios.com.au/security/advisories"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-PW24-QQC3-7VPX
Vulnerability from github – Published: 2025-01-30 00:31 – Updated: 2025-01-30 00:31Authentication bypass by spoofing in Azure AI Face Service allows an authorized attacker to elevate privileges over a network.
{
"affected": [],
"aliases": [
"CVE-2025-21415"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-29T23:15:33Z",
"severity": "CRITICAL"
},
"details": "Authentication bypass by spoofing in Azure AI Face Service allows an authorized attacker to elevate privileges over a network.",
"id": "GHSA-pw24-qqc3-7vpx",
"modified": "2025-01-30T00:31:04Z",
"published": "2025-01-30T00:31:04Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21415"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-21415"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-PW26-HVCP-W6VJ
Vulnerability from github – Published: 2026-06-19 15:33 – Updated: 2026-06-23 15:32Authentication Bypass by Spoofing vulnerability in Apache APISIX.
The attacker can completely bypass authentication capitalising on certain configurations of jwt-auth plugin. This issue affects Apache APISIX: from v2.2 through v3.16.0.
Users are recommended to upgrade to version v3.17.0, which fixes the issue.
{
"affected": [],
"aliases": [
"CVE-2026-39999"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-19T14:16:21Z",
"severity": "HIGH"
},
"details": "Authentication Bypass by Spoofing vulnerability in Apache APISIX.\n\nThe attacker can completely bypass authentication capitalising on certain configurations of jwt-auth plugin.\nThis issue affects Apache APISIX: from v2.2 through v3.16.0.\n\nUsers are recommended to upgrade to version v3.17.0, which fixes the issue.",
"id": "GHSA-pw26-hvcp-w6vj",
"modified": "2026-06-23T15:32:30Z",
"published": "2026-06-19T15:33:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-39999"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread/nfopt8cnxd3k0rs1oxtr7lzxrdw4mojq"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2026/06/19/5"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
No mitigation information available for this CWE.
CAPEC-21: Exploitation of Trusted Identifiers
An adversary guesses, obtains, or "rides" a trusted identifier (e.g. session ID, resource ID, cookie, etc.) to perform authorized actions under the guise of an authenticated user or service.
CAPEC-22: Exploiting Trust in Client
An attack of this type exploits vulnerabilities in client/server communication channel authentication and data integrity. It leverages the implicit trust a server places in the client, or more importantly, that which the server believes is the client. An attacker executes this type of attack by communicating directly with the server where the server believes it is communicating only with a valid client. There are numerous variations of this type of attack.
CAPEC-459: Creating a Rogue Certification Authority Certificate
An adversary exploits a weakness resulting from using a hashing algorithm with weak collision resistance to generate certificate signing requests (CSR) that contain collision blocks in their "to be signed" parts. The adversary submits one CSR to be signed by a trusted certificate authority then uses the signed blob to make a second certificate appear signed by said certificate authority. Due to the hash collision, both certificates, though different, hash to the same value and so the signed blob works just as well in the second certificate. The net effect is that the adversary's second X.509 certificate, which the Certification Authority has never seen, is now signed and validated by that Certification Authority.
CAPEC-461: Web Services API Signature Forgery Leveraging Hash Function Extension Weakness
An adversary utilizes a hash function extension/padding weakness, to modify the parameters passed to the web service requesting authentication by generating their own call in order to generate a legitimate signature hash (as described in the notes), without knowledge of the secret token sometimes provided by the web service.
CAPEC-473: Signature Spoof
An attacker generates a message or datablock that causes the recipient to believe that the message or datablock was generated and cryptographically signed by an authoritative or reputable source, misleading a victim or victim operating system into performing malicious actions.
CAPEC-476: Signature Spoofing by Misrepresentation
An attacker exploits a weakness in the parsing or display code of the recipient software to generate a data blob containing a supposedly valid signature, but the signer's identity is falsely represented, which can lead to the attacker manipulating the recipient software or its victim user to perform compromising actions.
CAPEC-59: Session Credential Falsification through Prediction
This attack targets predictable session ID in order to gain privileges. The attacker can predict the session ID used during a transaction to perform spoofing and session hijacking.
CAPEC-60: Reusing Session IDs (aka Session Replay)
This attack targets the reuse of valid session ID to spoof the target system in order to gain privileges. The attacker tries to reuse a stolen session ID used previously during a transaction to perform spoofing and session hijacking. Another name for this type of attack is Session Replay.
CAPEC-667: Bluetooth Impersonation AttackS (BIAS)
An adversary disguises the MAC address of their Bluetooth enabled device to one for which there exists an active and trusted connection and authenticates successfully. The adversary can then perform malicious actions on the target Bluetooth device depending on the target’s capabilities.
CAPEC-94: Adversary in the Middle (AiTM)
An adversary targets the communication between two components (typically client and server), in order to alter or obtain data from transactions. A general approach entails the adversary placing themself within the communication channel between the two components.