Monthly
Catalyst::Plugin::Authentication versions through 0.10024 for Perl is susceptible to timing attacks. These versions use Perl's built-in eq comparison. Discrepencies in timing could be used to guess the underlying hash or password.
Timing side-channel exposure in Netatalk's DES-ECB authentication allows a remote unauthenticated attacker to conduct a cryptographic timing oracle attack against the AFP server, potentially recovering authentication secrets or credentials through statistical analysis of server response latency. Affected versions span 1.5.0 through 4.4.2 - a broad range covering multiple major releases - and the issue is rooted in non-constant-time operations during DES-ECB auth processing (CWE-208). No public exploit has been identified at time of analysis, and this CVE is not listed in the CISA KEV catalog; Netatalk 4.5.0 resolves the issue per the vendor advisory.
Timing side-channel in the Perl module Crypt::SaltedHash through version 0.09 allows remote attackers to recover stored password hashes by measuring response-time discrepancies during hash validation. The flaw stems from use of Perl's short-circuiting `eq` operator inside the `validate()` routine, enabling byte-by-byte hash inference. EPSS is very low (0.02%) and there is no public exploit identified at time of analysis, but the upstream maintainer has shipped a fix in version 0.10 replacing the comparison with a constant-time routine.
Timing side-channel in memcached versions prior to 1.6.42 allows remote attackers to recover SASL authentication credentials by measuring response times during password comparison. The flaw stems from the use of the non-constant-time memcmp() function within sasl_server_userdb_checkpass, enabling byte-by-byte inference of stored passwords. No public exploit identified at time of analysis, but the upstream fix has been published.
Observable timing discrepancy in memcached prior to version 1.6.42 enables remote attackers to enumerate valid SASL authentication usernames by measuring response time differences. The vulnerable sasl_server_userdb_checkpass function exits its credential-file loop early upon matching a valid username, producing measurable timing variance between known and unknown accounts. No public exploit identified at time of analysis, and the issue is not listed in CISA KEV.
Timing attack vulnerability in RELATE's authentication module allows remote unauthenticated attackers to infer valid sign-in keys through response time analysis. The CWE-208 timing side-channel in course/auth.py's check_sign_in_key() function enables attackers to distinguish between valid and invalid authentication tokens by measuring server response latencies. While attack complexity is high (AC:H) due to the precise timing measurements required, successful exploitation grants full authentication bypass with cross-scope impact. Patched in commit 2f68e16. No public exploit identified at time of analysis. EPSS data not provided, CVSS 9.0 (Critical) reflects potential for complete system compromise via side-channel cryptanalysis.
Sync-in Server is a secure, open-source platform for file storage, sharing, collaboration, and syncing. Prior to version 2.2.0, the /api/auth/login endpoint contains a logic flaw that allows unauthenticated remote attackers to enumerate valid usernames by measuring the application's response time. This issue has been patched in version 2.2.0.
The `mul_mod` function implements multiplication via a binary expansion loop whose execution time depends on the Hamming weight of the second operand (the exponent). An attacker who can measure the time of secret‑sharing operations (e.g., via a remote service) could progressively recover the values of shares, ultimately leading to secret reconstruction. https://github.com/svvqt/pyquorum/releases/tag/v0.2.1
{ 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`: ```go 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. 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: ```yaml 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] ``` 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. 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. **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. 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: ```yaml extensions: oidc: issuer_url: https://login.microsoftonline.com/<tenant-id>/v2.0 audience: <expected-api-audience> ``` - PR introducing the vulnerable server-side path: [#39178](https://github.com/open-telemetry/opentelemetry-collector-contrib/pull/39178) - Affected versions: v0.124.0 - v0.150.0 Assisted-by: Opus 4.7
Timing attack against mod_auth_digest in Apache HTTP Server 2.4.66 allows remote unauthenticated attackers to bypass Digest authentication with high attack complexity. The vulnerability exploits measurable timing differences in digest credential validation, enabling credential compromise without valid authentication. Apache has released patched version 2.4.67; no active exploitation has been confirmed, but CISA SSVC framework indicates automatable exploitation is not feasible due to the timing attack's sensitivity requirements.
Catalyst::Plugin::Authentication versions through 0.10024 for Perl is susceptible to timing attacks. These versions use Perl's built-in eq comparison. Discrepencies in timing could be used to guess the underlying hash or password.
Timing side-channel exposure in Netatalk's DES-ECB authentication allows a remote unauthenticated attacker to conduct a cryptographic timing oracle attack against the AFP server, potentially recovering authentication secrets or credentials through statistical analysis of server response latency. Affected versions span 1.5.0 through 4.4.2 - a broad range covering multiple major releases - and the issue is rooted in non-constant-time operations during DES-ECB auth processing (CWE-208). No public exploit has been identified at time of analysis, and this CVE is not listed in the CISA KEV catalog; Netatalk 4.5.0 resolves the issue per the vendor advisory.
Timing side-channel in the Perl module Crypt::SaltedHash through version 0.09 allows remote attackers to recover stored password hashes by measuring response-time discrepancies during hash validation. The flaw stems from use of Perl's short-circuiting `eq` operator inside the `validate()` routine, enabling byte-by-byte hash inference. EPSS is very low (0.02%) and there is no public exploit identified at time of analysis, but the upstream maintainer has shipped a fix in version 0.10 replacing the comparison with a constant-time routine.
Timing side-channel in memcached versions prior to 1.6.42 allows remote attackers to recover SASL authentication credentials by measuring response times during password comparison. The flaw stems from the use of the non-constant-time memcmp() function within sasl_server_userdb_checkpass, enabling byte-by-byte inference of stored passwords. No public exploit identified at time of analysis, but the upstream fix has been published.
Observable timing discrepancy in memcached prior to version 1.6.42 enables remote attackers to enumerate valid SASL authentication usernames by measuring response time differences. The vulnerable sasl_server_userdb_checkpass function exits its credential-file loop early upon matching a valid username, producing measurable timing variance between known and unknown accounts. No public exploit identified at time of analysis, and the issue is not listed in CISA KEV.
Timing attack vulnerability in RELATE's authentication module allows remote unauthenticated attackers to infer valid sign-in keys through response time analysis. The CWE-208 timing side-channel in course/auth.py's check_sign_in_key() function enables attackers to distinguish between valid and invalid authentication tokens by measuring server response latencies. While attack complexity is high (AC:H) due to the precise timing measurements required, successful exploitation grants full authentication bypass with cross-scope impact. Patched in commit 2f68e16. No public exploit identified at time of analysis. EPSS data not provided, CVSS 9.0 (Critical) reflects potential for complete system compromise via side-channel cryptanalysis.
Sync-in Server is a secure, open-source platform for file storage, sharing, collaboration, and syncing. Prior to version 2.2.0, the /api/auth/login endpoint contains a logic flaw that allows unauthenticated remote attackers to enumerate valid usernames by measuring the application's response time. This issue has been patched in version 2.2.0.
The `mul_mod` function implements multiplication via a binary expansion loop whose execution time depends on the Hamming weight of the second operand (the exponent). An attacker who can measure the time of secret‑sharing operations (e.g., via a remote service) could progressively recover the values of shares, ultimately leading to secret reconstruction. https://github.com/svvqt/pyquorum/releases/tag/v0.2.1
{ 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`: ```go 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. 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: ```yaml 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] ``` 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. 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. **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. 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: ```yaml extensions: oidc: issuer_url: https://login.microsoftonline.com/<tenant-id>/v2.0 audience: <expected-api-audience> ``` - PR introducing the vulnerable server-side path: [#39178](https://github.com/open-telemetry/opentelemetry-collector-contrib/pull/39178) - Affected versions: v0.124.0 - v0.150.0 Assisted-by: Opus 4.7
Timing attack against mod_auth_digest in Apache HTTP Server 2.4.66 allows remote unauthenticated attackers to bypass Digest authentication with high attack complexity. The vulnerability exploits measurable timing differences in digest credential validation, enabling credential compromise without valid authentication. Apache has released patched version 2.4.67; no active exploitation has been confirmed, but CISA SSVC framework indicates automatable exploitation is not feasible due to the timing attack's sensitivity requirements.