| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Quiet is an alternative to team chat apps like Slack, Discord, and Element that does not require trusting a central server or running one's own. In versions 6.1.0-alpha.4 and below, Quiet's API for backend/frontend communication was using an insecure, not constant-time comparison function for token verification. This allowed for a potential timing attack where an attacker would try different token values and observe tiny differences in the response time (wrong characters fail faster) to guess the whole token one character at a time. This is fixed in version 6.0.1. |
| Post-Quantum Secure Feldman's Verifiable Secret Sharing provides a Python implementation of Feldman's Verifiable Secret Sharing (VSS) scheme. In versions 0.8.0b2 and prior, the `feldman_vss` library contains timing side-channel vulnerabilities in its matrix operations, specifically within the `_find_secure_pivot` function and potentially other parts of `_secure_matrix_solve`. These vulnerabilities are due to Python's execution model, which does not guarantee constant-time execution. An attacker with the ability to measure the execution time of these functions (e.g., through repeated calls with carefully crafted inputs) could potentially recover secret information used in the Verifiable Secret Sharing (VSS) scheme. The `_find_secure_pivot` function, used during Gaussian elimination in `_secure_matrix_solve`, attempts to find a non-zero pivot element. However, the conditional statement `if matrix[row][col] != 0 and row_random < min_value:` has execution time that depends on the value of `matrix[row][col]`. This timing difference can be exploited by an attacker. The `constant_time_compare` function in this file also does not provide a constant-time guarantee. The Python implementation of matrix operations in the _find_secure_pivot and _secure_matrix_solve functions cannot guarantee constant-time execution, potentially leaking information about secret polynomial coefficients. An attacker with the ability to make precise timing measurements of these operations could potentially extract secret information through statistical analysis of execution times, though practical exploitation would require significant expertise and controlled execution environments. Successful exploitation of these timing side-channels could allow an attacker to recover secret keys or other sensitive information protected by the VSS scheme. This could lead to a complete compromise of the shared secret. As of time of publication, no patched versions of Post-Quantum Secure Feldman's Verifiable Secret Sharing exist, but other mitigations are available. As acknowledged in the library's documentation, these vulnerabilities cannot be adequately addressed in pure Python. In the short term, consider using this library only in environments where timing measurements by attackers are infeasible. In the medium term, implement your own wrappers around critical operations using constant-time libraries in languages like Rust, Go, or C. In the long term, wait for the planned Rust implementation mentioned in the library documentation that will properly address these issues. |
| SCRAM (Salted Challenge Response Authentication Mechanism) is part of the family of Simple Authentication and Security Layer (SASL, RFC 4422) authentication mechanisms. Prior to version 3.2, a timing attack vulnerability exists in the SCRAM Java implementation. The issue arises because Arrays.equals was used to compare secret values such as client proofs and server signatures. Since Arrays.equals performs a short-circuit comparison, the execution time varies depending on how many leading bytes match. This behavior could allow an attacker to perform a timing side-channel attack and potentially infer sensitive authentication material. All users relying on SCRAM authentication are impacted. This vulnerability has been patched in version 3.1 by replacing Arrays.equals with MessageDigest.isEqual, which ensures constant-time comparison. |
| Padding oracle attack vulnerability in Oberon microsystem AG’s Oberon PSA Crypto library in all versions since 1.0.0 and prior to 1.5.1 allows an attacker to recover plaintexts via timing measurements of AES-CBC PKCS#7 decrypt operations. |
| Observable Timing Discrepancy (CWE-208) in HBUS devices may allow an attacker with physical access to the device to extract device-specific keys, potentially compromising further site security.
This issue affects Command Centre Server:
9.30 prior to vCR9.30.251028a (distributed in 9.30.2881 (MR3)), 9.20 prior to vCR9.20.251028a (distributed in 9.20.3265 (MR5)), 9.10 prior to vCR9.10.251028a (distributed in 9.10.4135 (MR8)), all versions of 9.00 and prior. |
| The fix applied in CVE-2025-22228 inadvertently broke the timing attack mitigation implemented in DaoAuthenticationProvider. This can allow attackers to infer valid usernames or other authentication behavior via response-time differences under certain configurations. |
| A timing-based side-channel flaw was found in libgcrypt's RSA implementation. This issue may allow a remote attacker to initiate a Bleichenbacher-style attack, which can lead to the decryption of RSA ciphertexts. |
| Observable timing discrepancy in firmware for some Intel(R) CSME and Intel(R) SPS may allow a privileged user to potentially enable information disclosure via local access. |
| A flaw in Node.js HMAC verification uses a non-constant-time comparison when validating user-provided signatures, potentially leaking timing information proportional to the number of matching bytes. Under certain threat models where high-resolution timing measurements are possible, this behavior could be exploited as a timing oracle to infer HMAC values.
Node.js already provides timing-safe comparison primitives used elsewhere in the codebase, indicating this is an oversight rather than an intentional design decision.
This vulnerability affects **20.x, 22.x, 24.x, and 25.x**. |
| A vulnerability was found that the response times to malformed ciphertexts in RSA-PSK ClientKeyExchange differ from response times of ciphertexts with correct PKCS#1 v1.5 padding. |
| H3 is a minimal H(TTP) framework. Versions 2.0.1-beta.0 through 2.0.0-rc.8 contain a Timing Side-Channel vulnerability in the requireBasicAuth function due to the use of unsafe string comparison (!==). This allows an attacker to deduce the valid password character-by-character by measuring the server's response time, effectively bypassing password complexity protections. This issue is fixed in version 2.0.1-rc.9. |
| Traefik is an HTTP reverse proxy and load balancer. Versions 2.11.40 and below, 3.0.0-beta1 through 3.6.11, and 3.7.0-ea.1 comtain BasicAuth middleware that allows username enumeration via a timing attack. When a submitted username exists, the middleware performs a bcrypt password comparison taking ~166ms. When the username does not exist, the response returns immediately in ~0.6ms. This ~298x timing difference is observable over the network and allows an unauthenticated attacker to reliably distinguish valid from invalid usernames. This issue is patched in versions 2.11.41, 3.6.11 and 3.7.0-ea.2. |
| A timing side-channel vulnerability has been discovered in the opencryptoki package while processing RSA PKCS#1 v1.5 padded ciphertexts. This flaw could potentially enable unauthorized RSA ciphertext decryption or signing, even without access to the corresponding private key. |
| A flaw was found in the python-cryptography package. This issue may allow a remote attacker to decrypt captured messages in TLS servers that use RSA key exchanges, which may lead to exposure of confidential or sensitive data. |
| Cleanuparr is a tool for automating the cleanup of unwanted or blocked files in Sonarr, Radarr, and supported download clients like qBittorrent. From 2.7.0 to 2.8.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. It appears that the hashing function, which is the most time-consuming part of the process by design, occurs as part of the VerifyPassword function. With the short circuits occurring before the hashing function, a timing differential is introduced that exposes validity to the actor. This vulnerability is fixed in 2.8.1. |
| A security vulnerability has been identified in the cryptlib cryptographic library when cryptlib is compiled with the support for RSA key exchange ciphersuites in TLS (by setting the USE_RSA_SUITES define), it will be vulnerable to the timing variant of the Bleichenbacher attack. An attacker that is able to perform a large number of connections to the server will be able to decrypt RSA ciphertexts or forge signatures using server's certificate. THIS CVE ID IS CURRENTLY DISPUTED - MAINTAINER NOTE: There are only two situations where it's enabled, one is for fuzz-testing to exercise code paths that wouldn't otherwise be available, the other is for static source code analysis with tools like Coverity and Prefast, again to open up code paths that otherwise wouldn't be available. It can also be enabled manually in two specific test builds just to make sure the code still compiles OK, to avoid bit rot and verify that the fuzz-testing build will compile without errors. |
| An observable timing discrepancy in @perfood/couch-auth v0.26.0 allows attackers to access sensitive information via a timing side-channel. |
| In drawLayersInternal of SkiaRenderEngine.cpp, there is a possible way to access the GPU cache due to side channel information disclosure. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation. |
| FastAPI Api Key provides a backend-agnostic library that provides an API key system. Version 1.1.0 has a timing side-channel vulnerability in verify_key(). The method applied a random delay only on verification failures, allowing an attacker to statistically distinguish valid from invalid API keys by measuring response latencies. With enough repeated requests, an adversary could infer whether a key_id corresponds to a valid key, potentially accelerating brute-force or enumeration attacks. All users relying on verify_key() for API key authentication prior to the fix are affected. Users should upgrade to version 1.1.0 to receive a patch. The patch applies a uniform random delay (min_delay to max_delay) to all responses regardless of outcome, eliminating the timing correlation. Some workarounds are available. Add an application-level fixed delay or random jitter to all authentication responses (success and failure) before the fix is applied and/or use rate limiting to reduce the feasibility of statistical timing attacks. |
| Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: JSSE). Supported versions that are affected are Oracle Java SE:8u441, 8u441-perf, 11.0.26, 17.0.14, 21.0.6, 24; Oracle GraalVM for JDK:17.0.14, 21.0.6, 24; Oracle GraalVM Enterprise Edition:20.3.17 and 21.3.13. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition. Successful attacks of this vulnerability can result in unauthorized creation, deletion or modification access to critical data or all Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data as well as unauthorized access to critical data or complete access to all Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 7.4 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N). |