Common Weakness Enumeration

CWE-287

Discouraged

Improper Authentication

Abstraction: Class · Status: Draft

When an actor claims to have a given identity, the product does not prove or insufficiently proves that the claim is correct.

5978 vulnerabilities reference this CWE, most recent first.

GHSA-PJMG-9MFX-VG44

Vulnerability from github – Published: 2022-05-05 00:28 – Updated: 2024-04-03 23:53
VLAI
Details

Authentication bypass vulnerability in the the web interface in Hunt CCTV, Capture CCTV, Hachi CCTV, NoVus CCTV, and Well-Vision Inc DVR systems allows a remote attacker to retrieve the device configuration.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2013-1391"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-10-30T21:15:00Z",
    "severity": "HIGH"
  },
  "details": "Authentication bypass vulnerability in the the web interface in Hunt CCTV, Capture CCTV, Hachi CCTV, NoVus CCTV, and Well-Vision Inc DVR systems allows a remote attacker to retrieve the device configuration.",
  "id": "GHSA-pjmg-9mfx-vg44",
  "modified": "2024-04-03T23:53:48Z",
  "published": "2022-05-05T00:28:55Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2013-1391"
    },
    {
      "type": "WEB",
      "url": "https://www.rapid7.com/db/modules/auxiliary/scanner/misc/dvr_config_disclosure"
    },
    {
      "type": "WEB",
      "url": "https://www.securityfocus.com/bid/57579/info"
    },
    {
      "type": "WEB",
      "url": "http://www.securitybydefault.com/2013/01/12000-grabadores-de-video-expuestos-en.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-PJP5-QQC6-2QCQ

Vulnerability from github – Published: 2023-09-27 15:30 – Updated: 2023-09-27 15:30
VLAI
Details

Sensitive information disclosure and manipulation due to improper authentication. The following products are affected: Acronis Cyber Protect 15 (Linux, macOS, Windows) before build 35979.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-44152"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287",
      "CWE-306"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-09-27T15:19:37Z",
    "severity": "MODERATE"
  },
  "details": "Sensitive information disclosure and manipulation due to improper authentication. The following products are affected: Acronis Cyber Protect 15 (Linux, macOS, Windows) before build 35979.",
  "id": "GHSA-pjp5-qqc6-2qcq",
  "modified": "2023-09-27T15:30:39Z",
  "published": "2023-09-27T15:30:39Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-44152"
    },
    {
      "type": "WEB",
      "url": "https://security-advisory.acronis.com/advisories/SEC-1908"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-PJQH-2JCC-5J84

Vulnerability from github – Published: 2022-05-13 01:12 – Updated: 2024-04-05 18:51
VLAI
Summary
Improper Authentication in Pivotal Spring-LDAP
Details

In Pivotal Spring-LDAP versions 1.3.0 - 2.3.1, when connected to some LDAP servers, when no additional attributes are bound, and when using LDAP BindAuthenticator with org.springframework.ldap.core.support.DefaultTlsDirContextAuthenticationStrategy as the authentication strategy, and setting userSearch, authentication is allowed with an arbitrary password when the username is correct. This occurs because some LDAP vendors require an explicit operation for the LDAP bind to take effect.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.3.1"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.springframework.ldap:spring-ldap-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.3.0"
            },
            {
              "fixed": "2.3.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2017-8028"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-06-30T21:14:06Z",
    "nvd_published_at": "2017-11-27T10:29:00Z",
    "severity": "HIGH"
  },
  "details": "In Pivotal Spring-LDAP versions 1.3.0 - 2.3.1, when connected to some LDAP servers, when no additional attributes are bound, and when using LDAP BindAuthenticator with org.springframework.ldap.core.support.DefaultTlsDirContextAuthenticationStrategy as the authentication strategy, and setting userSearch, authentication is allowed with an arbitrary password when the username is correct. This occurs because some LDAP vendors require an explicit operation for the LDAP bind to take effect.",
  "id": "GHSA-pjqh-2jcc-5j84",
  "modified": "2024-04-05T18:51:08Z",
  "published": "2022-05-13T01:12:09Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-8028"
    },
    {
      "type": "WEB",
      "url": "https://github.com/spring-projects/spring-ldap/commit/08e8ae289bbd1b581986c7238604a147119c1336"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2018:0319"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/spring-projects/spring-ldap"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2017/11/msg00026.html"
    },
    {
      "type": "WEB",
      "url": "https://pivotal.io/security/cve-2017-8028"
    },
    {
      "type": "WEB",
      "url": "https://www.debian.org/security/2017/dsa-4046"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpujan2021.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Improper Authentication in Pivotal Spring-LDAP"
}

GHSA-PJQQ-4XR8-43P8

Vulnerability from github – Published: 2022-05-24 19:08 – Updated: 2022-05-24 19:08
VLAI
Details

Basix NEX-Forms through 7.8.7 allows authentication bypass for Excel report generation.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-34676"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-07-19T17:15:00Z",
    "severity": "HIGH"
  },
  "details": "Basix NEX-Forms through 7.8.7 allows authentication bypass for Excel report generation.",
  "id": "GHSA-pjqq-4xr8-43p8",
  "modified": "2022-05-24T19:08:21Z",
  "published": "2022-05-24T19:08:21Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-34676"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rauschecker/CVEs/tree/main/CVE-2021-34676"
    },
    {
      "type": "WEB",
      "url": "http://basixonline.net/nex-forms-wordpress-form-builder-demo/change-log"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-PJQR-F9GR-WM84

Vulnerability from github – Published: 2022-05-13 01:51 – Updated: 2024-03-21 03:33
VLAI
Details

** DISPUTED ** An issue was discovered in BMC PATROL Agent through 11.3.01. It was found that the PatrolCli application can allow for lateral movement and escalation of privilege inside a Windows Active Directory environment. It was found that by default the PatrolCli / PATROL Agent application only verifies if the password provided for the given username is correct; it does not verify the permissions of the user on the network. This means if you have PATROL Agent installed on a high value target (domain controller), you can use a low privileged domain user to authenticate with PatrolCli and then connect to the domain controller and run commands as SYSTEM. This means any user on a domain can escalate to domain admin through PATROL Agent. NOTE: the vendor disputes this because they believe it is adequate to prevent this escalation by means of a custom, non-default configuration.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2018-20735"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-01-17T20:29:00Z",
    "severity": "HIGH"
  },
  "details": "** DISPUTED ** An issue was discovered in BMC PATROL Agent through 11.3.01. It was found that the PatrolCli application can allow for lateral movement and escalation of privilege inside a Windows Active Directory environment. It was found that by default the PatrolCli / PATROL Agent application only verifies if the password provided for the given username is correct; it does not verify the permissions of the user on the network. This means if you have PATROL Agent installed on a high value target (domain controller), you can use a low privileged domain user to authenticate with PatrolCli and then connect to the domain controller and run commands as SYSTEM. This means any user on a domain can escalate to domain admin through PATROL Agent. NOTE: the vendor disputes this because they believe it is adequate to prevent this escalation by means of a custom, non-default configuration.",
  "id": "GHSA-pjqr-f9gr-wm84",
  "modified": "2024-03-21T03:33:32Z",
  "published": "2022-05-13T01:51:07Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-20735"
    },
    {
      "type": "WEB",
      "url": "https://www.exploit-db.com/exploits/46556"
    },
    {
      "type": "WEB",
      "url": "https://www.securifera.com/blog/2018/12/17/bmc-patrol-agent-domain-user-to-domain-admin"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-PJRX-5R6Q-MC9X

Vulnerability from github – Published: 2022-05-01 17:58 – Updated: 2022-05-01 17:58
VLAI
Details

Session fixation vulnerability in onelook obo Shop allows remote attackers to hijack web sessions by setting a PHPSESSID cookie.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2007-1951"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2007-04-11T01:19:00Z",
    "severity": "HIGH"
  },
  "details": "Session fixation vulnerability in onelook obo Shop allows remote attackers to hijack web sessions by setting a PHPSESSID cookie.",
  "id": "GHSA-pjrx-5r6q-mc9x",
  "modified": "2022-05-01T17:58:32Z",
  "published": "2022-05-01T17:58:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2007-1951"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/33500"
    },
    {
      "type": "WEB",
      "url": "http://www.majorsecurity.de/index_2.php?major_rls=major_rls40"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/archive/1/464886/100/0/threaded"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-PJRX-65PG-8JMF

Vulnerability from github – Published: 2022-05-17 05:12 – Updated: 2022-05-17 05:12
VLAI
Details

importbuddy.php in the BackupBuddy plugin 1.3.4, 2.1.4, 2.2.25, 2.2.28, and 2.2.4 for WordPress allows remote attackers to bypass authentication via a crafted integer in the step parameter.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2013-2743"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2013-04-02T12:09:00Z",
    "severity": "HIGH"
  },
  "details": "importbuddy.php in the BackupBuddy plugin 1.3.4, 2.1.4, 2.2.25, 2.2.28, and 2.2.4 for WordPress allows remote attackers to bypass authentication via a crafted integer in the step parameter.",
  "id": "GHSA-pjrx-65pg-8jmf",
  "modified": "2022-05-17T05:12:25Z",
  "published": "2022-05-17T05:12:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2013-2743"
    },
    {
      "type": "WEB",
      "url": "http://archives.neohapsis.com/archives/fulldisclosure/2013-03/0205.html"
    },
    {
      "type": "WEB",
      "url": "http://packetstormsecurity.com/files/120923"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-PJV4-3C63-699F

Vulnerability from github – Published: 2026-05-06 22:32 – Updated: 2026-05-14 20:42
VLAI
Summary
opentelemetry-collector-contrib's azureauthextension Authenticate method does not validate bearer tokens, allowing auth bypass via replay
Details

Summary

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

Show details on source website

{
  "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-PM46-RMC8-J8J3

Vulnerability from github – Published: 2022-05-24 19:21 – Updated: 2022-05-24 19:21
VLAI
Details

A vulnerability in specific versions of Zyxel NBG6818, NBG7815, WSQ20, WSQ50, WSQ60, and WSR30 firmware with pre-configured password management could allow an attacker to obtain root access of the device, if the local attacker dismantles the device and uses a USB-to-UART cable to connect the device, or if the remote assistance feature had been enabled by an authenticated user.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-35033"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287",
      "CWE-522"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-11-23T22:15:00Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability in specific versions of Zyxel NBG6818, NBG7815, WSQ20, WSQ50, WSQ60, and WSR30 firmware with pre-configured password management could allow an attacker to obtain root access of the device, if the local attacker dismantles the device and uses a USB-to-UART cable to connect the device, or if the remote assistance feature had been enabled by an authenticated user.",
  "id": "GHSA-pm46-rmc8-j8j3",
  "modified": "2022-05-24T19:21:12Z",
  "published": "2022-05-24T19:21:12Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-35033"
    },
    {
      "type": "WEB",
      "url": "https://www.tenable.com/security/research/tra-2022-06"
    },
    {
      "type": "WEB",
      "url": "https://www.zyxel.com/support/Zyxel_security_advisory_for_pre-configured_password_management_vulnerability_of_home_routers_and_WiFi_systems.shtml"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-PM4R-RCGW-H79R

Vulnerability from github – Published: 2022-05-17 01:17 – Updated: 2025-04-20 03:34
VLAI
Details

Authentication bypass by assumed-immutable data vulnerability in Intel Security VirusScan Enterprise Linux (VSEL) 2.0.3 (and earlier) allows remote unauthenticated attacker to bypass server authentication via a crafted authentication cookie.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2016-8023"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-03-14T22:59:00Z",
    "severity": "HIGH"
  },
  "details": "Authentication bypass by assumed-immutable data vulnerability in Intel Security VirusScan Enterprise Linux (VSEL) 2.0.3 (and earlier) allows remote unauthenticated attacker to bypass server authentication via a crafted authentication cookie.",
  "id": "GHSA-pm4r-rcgw-h79r",
  "modified": "2025-04-20T03:34:04Z",
  "published": "2022-05-17T01:17:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2016-8023"
    },
    {
      "type": "WEB",
      "url": "https://kc.mcafee.com/corporate/index?page=content\u0026id=SB10181"
    },
    {
      "type": "WEB",
      "url": "https://www.exploit-db.com/exploits/40911"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/94823"
    },
    {
      "type": "WEB",
      "url": "http://www.securitytracker.com/id/1037433"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

Mitigation
Architecture and Design

Strategy: Libraries or Frameworks

Use an authentication framework or library such as the OWASP ESAPI Authentication feature.

CAPEC-114: Authentication Abuse

An attacker obtains unauthorized access to an application, service or device either through knowledge of the inherent weaknesses of an authentication mechanism, or by exploiting a flaw in the authentication scheme's implementation. In such an attack an authentication mechanism is functioning but a carefully controlled sequence of events causes the mechanism to grant access to the attacker.

CAPEC-115: Authentication Bypass

An attacker gains access to application, service, or device with the privileges of an authorized or privileged user by evading or circumventing an authentication mechanism. The attacker is therefore able to access protected data without authentication ever having taken place.

CAPEC-151: Identity Spoofing

Identity Spoofing refers to the action of assuming (i.e., taking on) the identity of some other entity (human or non-human) and then using that identity to accomplish a goal. An adversary may craft messages that appear to come from a different principle or use stolen / spoofed authentication credentials.

CAPEC-194: Fake the Source of Data

An adversary takes advantage of improper authentication to provide data or services under a falsified identity. The purpose of using the falsified identity may be to prevent traceability of the provided data or to assume the rights granted to another individual. One of the simplest forms of this attack would be the creation of an email message with a modified "From" field in order to appear that the message was sent from someone other than the actual sender. The root of the attack (in this case the email system) fails to properly authenticate the source and this results in the reader incorrectly performing the instructed action. Results of the attack vary depending on the details of the attack, but common results include privilege escalation, obfuscation of other attacks, and data corruption/manipulation.

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-57: Utilizing REST's Trust in the System Resource to Obtain Sensitive Data

This attack utilizes a REST(REpresentational State Transfer)-style applications' trust in the system resources and environment to obtain sensitive data once SSL is terminated.

CAPEC-593: Session Hijacking

This type of attack involves an adversary that exploits weaknesses in an application's use of sessions in performing authentication. The adversary is able to steal or manipulate an active session and use it to gain unathorized access to the application.

CAPEC-633: Token Impersonation

An adversary exploits a weakness in authentication to create an access token (or equivalent) that impersonates a different entity, and then associates a process/thread to that that impersonated token. This action causes a downstream user to make a decision or take action that is based on the assumed identity, and not the response that blocks the adversary.

CAPEC-650: Upload a Web Shell to a Web Server

By exploiting insufficient permissions, it is possible to upload a web shell to a web server in such a way that it can be executed remotely. This shell can have various capabilities, thereby acting as a "gateway" to the underlying web server. The shell might execute at the higher permission level of the web server, providing the ability the execute malicious code at elevated levels.

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.