CWE-294
AllowedAuthentication Bypass by Capture-replay
Abstraction: Base · Status: Incomplete
A capture-replay flaw exists when the design of the product makes it possible for a malicious user to sniff network traffic and bypass authentication by replaying it to the server in question to the same effect as the original message (or with minor changes).
342 vulnerabilities reference this CWE, most recent first.
GHSA-PFR7-2PH8-36R9
Vulnerability from github – Published: 2022-05-24 17:31 – Updated: 2022-05-24 17:31Netwrix Account Lockout Examiner before 5.1 allows remote attackers to capture the Net-NTLMv1/v2 authentication challenge hash of the Domain Administrator (that is configured within the product in its installation state) by generating a single Kerberos Pre-Authentication Failed (ID 4771) event on a Domain Controller.
{
"affected": [],
"aliases": [
"CVE-2020-15931"
],
"database_specific": {
"cwe_ids": [
"CWE-294"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-10-20T20:15:00Z",
"severity": "HIGH"
},
"details": "Netwrix Account Lockout Examiner before 5.1 allows remote attackers to capture the Net-NTLMv1/v2 authentication challenge hash of the Domain Administrator (that is configured within the product in its installation state) by generating a single Kerberos Pre-Authentication Failed (ID 4771) event on a Domain Controller.",
"id": "GHSA-pfr7-2ph8-36r9",
"modified": "2022-05-24T17:31:41Z",
"published": "2022-05-24T17:31:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-15931"
},
{
"type": "WEB",
"url": "https://www.netwrix.com/netwrix_reports_vulnerability_in_netwrix_account_lockout_examiner_4_1.html"
},
{
"type": "WEB",
"url": "https://www.optiv.com/explore-optiv-insights/source-zero/netwrix-account-lockout-examiner-41-disclosure-vulnerability"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-PHJF-69J5-93R8
Vulnerability from github – Published: 2022-11-10 12:01 – Updated: 2025-05-01 15:31The DDMP/ODMF module has a service hijacking vulnerability. Successful exploit of this vulnerability may cause services to be unavailable.
{
"affected": [],
"aliases": [
"CVE-2022-44555"
],
"database_specific": {
"cwe_ids": [
"CWE-294"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-11-09T21:15:00Z",
"severity": "HIGH"
},
"details": "The DDMP/ODMF module has a service hijacking vulnerability. Successful exploit of this vulnerability may cause services to be unavailable.",
"id": "GHSA-phjf-69j5-93r8",
"modified": "2025-05-01T15:31:29Z",
"published": "2022-11-10T12:01:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-44555"
},
{
"type": "WEB",
"url": "https://consumer.huawei.com/en/support/bulletin/2022/11"
},
{
"type": "WEB",
"url": "https://device.harmonyos.com/en/docs/security/update/security-bulletins-phones-202211-0000001441016433"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-PHP2-3GV6-62RW
Vulnerability from github – Published: 2023-09-14 15:31 – Updated: 2024-04-04 07:40A remote authentication bypass issue exists in some OneView APIs.
{
"affected": [],
"aliases": [
"CVE-2023-30909"
],
"database_specific": {
"cwe_ids": [
"CWE-288",
"CWE-294"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-09-14T15:15:08Z",
"severity": "CRITICAL"
},
"details": "A remote authentication bypass issue exists in some\nOneView APIs.\n\n\n\n\n\n\n\n",
"id": "GHSA-php2-3gv6-62rw",
"modified": "2024-04-04T07:40:20Z",
"published": "2023-09-14T15:31:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-30909"
},
{
"type": "WEB",
"url": "https://support.hpe.com/hpesc/public/docDisplay?docLocale=en_US\u0026docId=hpesbgn04538en_us"
}
],
"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:H",
"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-PPQH-5VMG-4XR4
Vulnerability from github – Published: 2026-04-08 18:34 – Updated: 2026-04-09 21:31OpenAirInterface v2.2.0 accepts Security Mode Complete without any integrity protection. Configuration has supported integrity NIA1 and NIA2. But if an UE sends initial registration request with only security capability IA0, OpenAirInterface accepts and proceeds. This downgrade security context can lead to the possibility of replay attack.
{
"affected": [],
"aliases": [
"CVE-2026-30080"
],
"database_specific": {
"cwe_ids": [
"CWE-294"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-08T17:21:18Z",
"severity": "HIGH"
},
"details": "OpenAirInterface v2.2.0 accepts Security Mode Complete without any integrity protection. Configuration has supported integrity NIA1 and NIA2. But if an UE sends initial registration request with only security capability IA0, OpenAirInterface accepts and proceeds. This downgrade security context can lead to the possibility of replay attack.",
"id": "GHSA-ppqh-5vmg-4xr4",
"modified": "2026-04-09T21:31:28Z",
"published": "2026-04-08T18:34:07Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-30080"
},
{
"type": "WEB",
"url": "https://gitlab.eurecom.fr/oai/cn5g/oai-cn5g-amf/-/issues/78"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-PQ93-2733-562X
Vulnerability from github – Published: 2021-12-16 00:02 – Updated: 2022-01-07 00:01An RF replay attack vulnerability in the SecuritasHome home alarm system, version HPGW-G 0.0.2.23F BG_U-ITR-F1-BD_BL.A30.20181117, allows an attacker to trigger arbitrary system functionality by replaying previously recorded signals. This lets an adversary, among other things, disarm an armed system.
{
"affected": [],
"aliases": [
"CVE-2021-40170"
],
"database_specific": {
"cwe_ids": [
"CWE-294"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-12-15T07:15:00Z",
"severity": "MODERATE"
},
"details": "An RF replay attack vulnerability in the SecuritasHome home alarm system, version HPGW-G 0.0.2.23F BG_U-ITR-F1-BD_BL.A30.20181117, allows an attacker to trigger arbitrary system functionality by replaying previously recorded signals. This lets an adversary, among other things, disarm an armed system.",
"id": "GHSA-pq93-2733-562x",
"modified": "2022-01-07T00:01:33Z",
"published": "2021-12-16T00:02:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-40170"
},
{
"type": "WEB",
"url": "https://www.diva-portal.org/smash/get/diva2:1600180/FULLTEXT04.pdf"
},
{
"type": "WEB",
"url": "https://www.securitashome.se/product.html/securitashome"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-PWFH-8XV9-VGC2
Vulnerability from github – Published: 2025-05-14 18:30 – Updated: 2025-05-19 15:30Authentication Bypass by Capture-replay vulnerability in Drupal Enterprise MFA - TFA for Drupal allows Remote Services with Stolen Credentials.This issue affects Enterprise MFA - TFA for Drupal: from 0.0.0 before 4.7.0, from 5.0.0 before 5.2.0.
{
"affected": [],
"aliases": [
"CVE-2025-47706"
],
"database_specific": {
"cwe_ids": [
"CWE-294"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-14T17:15:49Z",
"severity": "MODERATE"
},
"details": "Authentication Bypass by Capture-replay vulnerability in Drupal Enterprise MFA - TFA for Drupal allows Remote Services with Stolen Credentials.This issue affects Enterprise MFA - TFA for Drupal: from 0.0.0 before 4.7.0, from 5.0.0 before 5.2.0.",
"id": "GHSA-pwfh-8xv9-vgc2",
"modified": "2025-05-19T15:30:38Z",
"published": "2025-05-14T18:30:50Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-47706"
},
{
"type": "WEB",
"url": "https://www.drupal.org/sa-contrib-2025-052"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-Q7X5-RCGH-Q498
Vulnerability from github – Published: 2025-06-13 15:30 – Updated: 2025-06-13 15:30Use of fixed learning codes, one code to lock the car and the other code to unlock it, the Key Fob Transmitter in KIA-branded Aftermarket Generic Smart Keyless Entry System, primarily distributed in Ecuador, which allows a replay attack.
Manufacture is unknown at the time of release. CVE Record will be updated once this is clarified.
{
"affected": [],
"aliases": [
"CVE-2025-6029"
],
"database_specific": {
"cwe_ids": [
"CWE-294"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-06-13T15:15:21Z",
"severity": "CRITICAL"
},
"details": "Use of fixed learning codes, one code to lock the car and the other code to unlock it, the\u00a0Key Fob Transmitter in KIA-branded Aftermarket Generic Smart Keyless Entry System, primarily distributed in Ecuador, which allows a replay attack.\n\nManufacture is unknown at the time of release.\u00a0 CVE Record will be updated once this is clarified.",
"id": "GHSA-q7x5-rcgh-q498",
"modified": "2025-06-13T15:30:32Z",
"published": "2025-06-13T15:30:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-6029"
},
{
"type": "WEB",
"url": "https://asrg.io/security-advisories/cve-2025-6029-kia-branded-aftermarket-generic-smart-keyless-entry-system-replay-attack"
},
{
"type": "WEB",
"url": "https://revers3everything.com/unlocking-thousands-of-cars-by-exploiting-learning-codes-from-key-fobs"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:A/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/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:N/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-Q8W6-W55C-CCV5
Vulnerability from github – Published: 2026-05-11 14:42 – Updated: 2026-05-11 14:42CVE-2026-6420: Hardcoded attestation challenge nonce allows replay attacks
Impact
The CertificationParameters.generate_challenge() method in the push attestation protocol uses a hardcoded challenge nonce instead of generating a cryptographically random value. This removes the nonce-based replay protection from TPM quote attestation.
An attacker with root access on a monitored agent node can exploit this by stockpiling valid TPM quotes (using tpm2_quote with the known nonce) before compromising the system, then replaying them to evade detection by the verifier. The push attestation timeout (~10s) constrains the generation window, but TPM throughput allows stockpiling ~50-200 quotes, enabling approximately 8-33 minutes of undetected compromise with default settings.
The attack is limited to a single agent node (AK signature binding prevents cross-agent replay). The pull-mode (legacy) attestation path is not affected.
Affected versions: >= 7.14.0, <= 7.14.1
CVSS: 6.3 Medium (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:L)
| Metric | Value | Rationale |
|---|---|---|
| AV | Local | Exploitation requires local access to the agent machine (stop agent, access TPM, run replacement). The network transmission of quotes to the verifier is normal protocol operation. |
| AC | Low | Deterministic attack: publicly visible nonce, standard tpm2-tools, no race conditions. |
| PR | High | Root on a legitimate enrolled node is required. The vulnerability does not help gain access -- it only helps evade detection after root is obtained. No value against a machine the attacker already controls. |
| UI | None | Fully automated after initial setup. |
| S | Unchanged | AK signature binding confines impact to the single compromised agent. |
| C | High | Compromised node continues receiving bootstrap keys, payloads, and secrets intended for trusted nodes. |
| I | High | Verifier cannot distinguish a healthy system from a fully compromised one during the evasion window. |
| A | Low | Only the compromised agent's revocation and incident response are suppressed; the system as a whole remains operational. |
The base score does not fully capture the operational severity: Keylime exists to detect machine compromise, so 8-33 minutes of undetected compromise is operationally critical. The fix is a one-line change and should be applied immediately regardless of the base score.
Patches
The fix restores the original random nonce generation (one-line change in keylime/models/verifier/evidence.py):
# Before (vulnerable):
def generate_challenge(self, bit_length):
# self.challenge = Nonce.generate(bit_length)
self.challenge = bytes.fromhex("49beed365aac777dae23564f5ad0ec")
# After (fixed):
def generate_challenge(self, bit_length):
self.challenge = Nonce.generate(bit_length)
Users should upgrade to the version containing this fix (7.14.2).
Workarounds
There is no complete workaround. The following existing mechanisms provide partial mitigation and are already active by default (no configuration needed):
- TPM clock monotonicity check limits each distinct stockpiled quote to a single use, bounding the total evasion time.
- Push attestation timeout (default 10s) prevents the attacker from going silent and constrains the quote generation window.
Reducing quote_interval increases the attestation frequency but does not prevent the stockpiling attack.
References
- CWE-329: Generation of Predictable IV/Nonce (primary -- hardcoded nonce in cryptographic attestation protocol)
- CWE-547: Use of Hard-Coded, Security-relevant Constants (hardcoded constant left in production code)
- CWE-294: Authentication Bypass by Capture-replay (consequence -- enables replay attacks)
- CWE-1241: Use of Predictable Algorithm in Random Number Generator
- Introducing commit:
2bf91197via PR #1814 - TCG TPM 2.0 Library Specification, Part 1, Section 18.4 (TPM2_Quote)
- IETF RATS Architecture (RFC 9334), Section 8 (Freshness)
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 7.14.1"
},
"package": {
"ecosystem": "PyPI",
"name": "keylime"
},
"ranges": [
{
"events": [
{
"introduced": "7.14.0"
},
{
"fixed": "7.14.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-6420"
],
"database_specific": {
"cwe_ids": [
"CWE-1241",
"CWE-294",
"CWE-329",
"CWE-547"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-11T14:42:46Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "## CVE-2026-6420: Hardcoded attestation challenge nonce allows replay attacks\n\n### Impact\n\nThe `CertificationParameters.generate_challenge()` method in the push attestation protocol uses a hardcoded challenge nonce instead of generating a cryptographically random value. This removes the nonce-based replay protection from TPM quote attestation.\n\nAn attacker with root access on a monitored agent node can exploit this by stockpiling valid TPM quotes (using `tpm2_quote` with the known nonce) before compromising the system, then replaying them to evade detection by the verifier. The push attestation timeout (~10s) constrains the generation window, but TPM throughput allows stockpiling ~50-200 quotes, enabling approximately 8-33 minutes of undetected compromise with default settings.\n\nThe attack is limited to a single agent node (AK signature binding prevents cross-agent replay). The pull-mode (legacy) attestation path is not affected.\n\n**Affected versions:** \u003e= 7.14.0, \u003c= 7.14.1\n\n**CVSS:** 6.3 Medium (`CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:L`)\n\n| Metric | Value | Rationale |\n|---|---|---|\n| AV | Local | Exploitation requires local access to the agent machine (stop agent, access TPM, run replacement). The network transmission of quotes to the verifier is normal protocol operation. |\n| AC | Low | Deterministic attack: publicly visible nonce, standard `tpm2-tools`, no race conditions. |\n| PR | High | Root on a legitimate enrolled node is required. The vulnerability does not help gain access -- it only helps evade detection after root is obtained. No value against a machine the attacker already controls. |\n| UI | None | Fully automated after initial setup. |\n| S | Unchanged | AK signature binding confines impact to the single compromised agent. |\n| C | High | Compromised node continues receiving bootstrap keys, payloads, and secrets intended for trusted nodes. |\n| I | High | Verifier cannot distinguish a healthy system from a fully compromised one during the evasion window. |\n| A | Low | Only the compromised agent\u0027s revocation and incident response are suppressed; the system as a whole remains operational. |\n\nThe base score does not fully capture the operational severity: Keylime exists to detect machine compromise, so 8-33 minutes of undetected compromise is operationally critical. The fix is a one-line change and should be applied immediately regardless of the base score.\n\n### Patches\n\nThe fix restores the original random nonce generation (one-line change in `keylime/models/verifier/evidence.py`):\n\n```python\n# Before (vulnerable):\ndef generate_challenge(self, bit_length):\n # self.challenge = Nonce.generate(bit_length)\n self.challenge = bytes.fromhex(\"49beed365aac777dae23564f5ad0ec\")\n\n# After (fixed):\ndef generate_challenge(self, bit_length):\n self.challenge = Nonce.generate(bit_length)\n```\n\nUsers should upgrade to the version containing this fix (7.14.2).\n\n### Workarounds\n\nThere is no complete workaround. The following existing mechanisms provide partial mitigation and are already active by default (no configuration needed):\n\n1. **TPM clock monotonicity check** limits each distinct stockpiled quote to a single use, bounding the total evasion time.\n2. **Push attestation timeout** (default 10s) prevents the attacker from going silent and constrains the quote generation window.\n\nReducing `quote_interval` increases the attestation frequency but does not prevent the stockpiling attack.\n\n### References\n\n- CWE-329: Generation of Predictable IV/Nonce (primary -- hardcoded nonce in cryptographic attestation protocol)\n- CWE-547: Use of Hard-Coded, Security-relevant Constants (hardcoded constant left in production code)\n- CWE-294: Authentication Bypass by Capture-replay (consequence -- enables replay attacks)\n- CWE-1241: Use of Predictable Algorithm in Random Number Generator\n- Introducing commit: [`2bf91197`](https://github.com/keylime/keylime/commit/2bf91197) via [PR #1814](https://github.com/keylime/keylime/pull/1814)\n- TCG TPM 2.0 Library Specification, Part 1, Section 18.4 (TPM2_Quote)\n- IETF RATS Architecture (RFC 9334), Section 8 (Freshness)",
"id": "GHSA-q8w6-w55c-ccv5",
"modified": "2026-05-11T14:42:46Z",
"published": "2026-05-11T14:42:46Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/keylime/keylime/security/advisories/GHSA-q8w6-w55c-ccv5"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-6420"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2026-6420"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2458889"
},
{
"type": "PACKAGE",
"url": "https://github.com/keylime/keylime"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:L",
"type": "CVSS_V3"
}
],
"summary": "Keylime has a hardcoded attestation challenge nonce that allows replay attacks"
}
GHSA-QF8R-GMH3-Q7X2
Vulnerability from github – Published: 2024-06-26 18:30 – Updated: 2024-09-24 15:31There exists a vulnerability in Quickshare/Nearby where an attacker can bypass the accept file dialog on QuickShare Windows. Normally in QuickShare Windows app we can't send a file without the user accept from the receiving device if the visibility is set to everyone mode or contacts mode. We recommend upgrading to version 1.0.1724.0 of Quickshare or above
{
"affected": [],
"aliases": [
"CVE-2024-38272"
],
"database_specific": {
"cwe_ids": [
"CWE-294"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-06-26T16:15:11Z",
"severity": "HIGH"
},
"details": "There exists a vulnerability in Quickshare/Nearby where an attacker can bypass the accept file dialog on QuickShare Windows.\u00a0Normally in QuickShare Windows app we can\u0027t send a file without the user accept from the receiving device if the visibility is set to everyone mode or contacts mode.\u00a0We recommend upgrading to version 1.0.1724.0 of Quickshare or above",
"id": "GHSA-qf8r-gmh3-q7x2",
"modified": "2024-09-24T15:31:32Z",
"published": "2024-06-26T18:30:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38272"
},
{
"type": "WEB",
"url": "https://github.com/google/nearby/pull/2402"
},
{
"type": "WEB",
"url": "https://github.com/google/nearby/pull/2589"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:A/AC:H/AT:P/PR:L/UI:N/VC:H/VI:L/VA:L/SC:H/SI:L/SA:L/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"
}
]
}
Mitigation
Utilize some sequence or time stamping functionality along with a checksum which takes this into account in order to ensure that messages can be parsed only once.
Mitigation
Since any attacker who can listen to traffic can see sequence numbers, it is necessary to sign messages with some kind of cryptography to ensure that sequence numbers are not simply doctored along with content.
CAPEC-102: Session Sidejacking
Session sidejacking takes advantage of an unencrypted communication channel between a victim and target system. The attacker sniffs traffic on a network looking for session tokens in unencrypted traffic. Once a session token is captured, the attacker performs malicious actions by using the stolen token with the targeted application to impersonate the victim. This attack is a specific method of session hijacking, which is exploiting a valid session token to gain unauthorized access to a target system or information. Other methods to perform a session hijacking are session fixation, cross-site scripting, or compromising a user or server machine and stealing the session token.
CAPEC-509: Kerberoasting
Through the exploitation of how service accounts leverage Kerberos authentication with Service Principal Names (SPNs), the adversary obtains and subsequently cracks the hashed credentials of a service account target to exploit its privileges. The Kerberos authentication protocol centers around a ticketing system which is used to request/grant access to services and to then access the requested services. As an authenticated user, the adversary may request Active Directory and obtain a service ticket with portions encrypted via RC4 with the private key of the authenticated account. By extracting the local ticket and saving it disk, the adversary can brute force the hashed value to reveal the target account credentials.
CAPEC-555: Remote Services with Stolen Credentials
This pattern of attack involves an adversary that uses stolen credentials to leverage remote services such as RDP, telnet, SSH, and VNC to log into a system. Once access is gained, any number of malicious activities could be performed.
CAPEC-561: Windows Admin Shares with Stolen Credentials
An adversary guesses or obtains (i.e. steals or purchases) legitimate Windows administrator credentials (e.g. userID/password) to access Windows Admin Shares on a local machine or within a Windows domain.
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-644: Use of Captured Hashes (Pass The Hash)
An adversary obtains (i.e. steals or purchases) legitimate Windows domain credential hash values to access systems within the domain that leverage the Lan Man (LM) and/or NT Lan Man (NTLM) authentication protocols.
CAPEC-645: Use of Captured Tickets (Pass The Ticket)
An adversary uses stolen Kerberos tickets to access systems/resources that leverage the Kerberos authentication protocol. The Kerberos authentication protocol centers around a ticketing system which is used to request/grant access to services and to then access the requested services. An adversary can obtain any one of these tickets (e.g. Service Ticket, Ticket Granting Ticket, Silver Ticket, or Golden Ticket) to authenticate to a system/resource without needing the account's credentials. Depending on the ticket obtained, the adversary may be able to access a particular resource or generate TGTs for any account within an Active Directory Domain.
CAPEC-652: Use of Known Kerberos Credentials
An adversary obtains (i.e. steals or purchases) legitimate Kerberos credentials (e.g. Kerberos service account userID/password or Kerberos Tickets) with the goal of achieving authenticated access to additional systems, applications, or services within the domain.
CAPEC-701: Browser in the Middle (BiTM)
An adversary exploits the inherent functionalities of a web browser, in order to establish an unnoticed remote desktop connection in the victim's browser to the adversary's system. The adversary must deploy a web client with a remote desktop session that the victim can access.
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.