CWE-385
AllowedCovert Timing Channel
Abstraction: Base · Status: Incomplete
Covert timing channels convey information by modulating some aspect of system behavior over time, so that the program receiving the information can observe system behavior and infer protected information.
80 vulnerabilities reference this CWE, most recent first.
GHSA-JQR3-3JM7-R6CM
Vulnerability from github – Published: 2025-06-17 00:30 – Updated: 2025-06-26 18:31OpenSSL 3.0.0 through 3.3.2 on the PowerPC architecture is vulnerable to a Minerva attack, exploitable by measuring the time of signing of random messages using the EVP_DigestSign API, and then using the private key to extract the K value (nonce) from the signatures. Next, based on the bit size of the extracted nonce, one can compare the signing time of full-sized nonces to signatures that used smaller nonces, via statistical tests. There is a side-channel in the P-364 curve that allows private key extraction (also, there is a dependency between the bit size of K and the size of the side channel). NOTE: This CVE is disputed because the OpenSSL security policy explicitly notes that any side channels which require same physical system to be detected are outside of the threat model for the software. The timing signal is so small that it is infeasible to be detected without having the attacking process running on the same physical system.
{
"affected": [],
"aliases": [
"CVE-2025-27587"
],
"database_specific": {
"cwe_ids": [
"CWE-385"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-06-16T22:15:44Z",
"severity": "MODERATE"
},
"details": "OpenSSL 3.0.0 through 3.3.2 on the PowerPC architecture is vulnerable to a Minerva attack, exploitable by measuring the time of signing of random messages using the EVP_DigestSign API, and then using the private key to extract the K value (nonce) from the signatures. Next, based on the bit size of the extracted nonce, one can compare the signing time of full-sized nonces to signatures that used smaller nonces, via statistical tests. There is a side-channel in the P-364 curve that allows private key extraction (also, there is a dependency between the bit size of K and the size of the side channel). NOTE: This CVE is disputed because the OpenSSL security policy explicitly notes that any side channels which require same physical system to be detected are outside of the threat model for the software. The timing signal is so small that it is infeasible to be detected without having the attacking process running on the same physical system.",
"id": "GHSA-jqr3-3jm7-r6cm",
"modified": "2025-06-26T18:31:19Z",
"published": "2025-06-17T00:30:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-27587"
},
{
"type": "WEB",
"url": "https://github.com/openssl/openssl/issues/24253"
},
{
"type": "WEB",
"url": "https://minerva.crocs.fi.muni.cz"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-M5PX-2Q2G-HXC2
Vulnerability from github – Published: 2022-05-13 01:14 – Updated: 2022-05-13 01:14It was found that the GnuTLS implementation of HMAC-SHA-384 was vulnerable to a Lucky thirteen style attack. Remote attackers could use this flaw to conduct distinguishing attacks and plain text recovery attacks via statistical analysis of timing data using crafted packets.
{
"affected": [],
"aliases": [
"CVE-2018-10845"
],
"database_specific": {
"cwe_ids": [
"CWE-327",
"CWE-385"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-08-22T13:29:00Z",
"severity": "MODERATE"
},
"details": "It was found that the GnuTLS implementation of HMAC-SHA-384 was vulnerable to a Lucky thirteen style attack. Remote attackers could use this flaw to conduct distinguishing attacks and plain text recovery attacks via statistical analysis of timing data using crafted packets.",
"id": "GHSA-m5px-2q2g-hxc2",
"modified": "2022-05-13T01:14:22Z",
"published": "2022-05-13T01:14:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-10845"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2018:3050"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2018:3505"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2018-10845"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=1582572"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2018-10845"
},
{
"type": "WEB",
"url": "https://eprint.iacr.org/2018/747"
},
{
"type": "WEB",
"url": "https://gitlab.com/gnutls/gnutls/merge_requests/657"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2018/10/msg00022.html"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/ILMOWPKMTZAIMK5F32TUMO34XCABUCFJ"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/WDYY3R4F5CUTFAMXH2C5NKYFVDEJLTT7"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/ILMOWPKMTZAIMK5F32TUMO34XCABUCFJ"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/WDYY3R4F5CUTFAMXH2C5NKYFVDEJLTT7"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/3999-1"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/105138"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-P93R-85WP-75V3
Vulnerability from github – Published: 2026-04-17 18:31 – Updated: 2026-06-19 15:20Covert timing channel vulnerability in Legion of the Bouncy Castle Inc. BC-JAVA core on all (core modules). This vulnerability is associated with program files FrodoEngine.Java.
This issue only affects users of the FrodoKEM algorithm involved in the decryption of encapsulations.
This issue affects BC-JAVA: from 1.71 to 1.80.1, 1.81, 1.82 to 1.83.
Fixed versions: 1.80.2, 1.81.1, 1.84
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.bouncycastle:bcprov-jdk15to18"
},
"ranges": [
{
"events": [
{
"introduced": "1.71"
},
{
"fixed": "1.80.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.bouncycastle:bcprov-jdk14"
},
"ranges": [
{
"events": [
{
"introduced": "1.81"
},
{
"fixed": "1.81.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.bouncycastle:bcprov-jdk18on"
},
"ranges": [
{
"events": [
{
"introduced": "1.82"
},
{
"fixed": "1.84"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-5598"
],
"database_specific": {
"cwe_ids": [
"CWE-385"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-25T23:25:24Z",
"nvd_published_at": "2026-04-15T10:16:49Z",
"severity": "HIGH"
},
"details": "Covert timing channel vulnerability in Legion of the Bouncy Castle Inc. BC-JAVA core on all (core modules). This vulnerability is associated with program files FrodoEngine.Java.\n\nThis issue only affects users of the FrodoKEM algorithm involved in the decryption of encapsulations.\n\nThis issue affects BC-JAVA: from 1.71 to 1.80.1, 1.81, 1.82 to 1.83.\n\nFixed versions: 1.80.2, 1.81.1, 1.84",
"id": "GHSA-p93r-85wp-75v3",
"modified": "2026-06-19T15:20:41Z",
"published": "2026-04-17T18:31:50Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-5598"
},
{
"type": "WEB",
"url": "https://github.com/bcgit/bc-java/commit/8692e6b2b191fc4aafa32545c7a78bdb9bf110c5"
},
{
"type": "WEB",
"url": "https://github.com/bcgit/bc-java/commit/94abbd56413dfdac651fd878bc60253871ef5e87"
},
{
"type": "PACKAGE",
"url": "https://github.com/bcgit/bc-java"
},
{
"type": "WEB",
"url": "https://github.com/bcgit/bc-java/wiki/CVE%E2%80%902026%E2%80%905598"
},
{
"type": "WEB",
"url": "https://github.com/bcgit/bc-java/wiki/CVE-2026-5598"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:H/SI:H/SA:N/E:U/S:P/AU:Y/U:Red",
"type": "CVSS_V4"
}
],
"summary": "Bouncy Castle Has Covert Timing Channel Vulnerability"
}
GHSA-Q65W-FG65-79F4
Vulnerability from github – Published: 2025-03-14 19:55 – Updated: 2025-03-19 15:28Description:
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.
This advisory formalizes the timing side-channel vulnerabilities already documented in the library's "Known Security Vulnerabilities" section. 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.
Impact:
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.
References:
- File:
feldman_vss.py - Function:
_find_secure_pivot - Function:
_secure_matrix_solve - Function:
constant_time_compare - Timing Attacks on Implementations of Diffie-Hellman, RSA, DSS, and Other Systems (1996) - A seminal paper on timing attacks.
- Side-Channel Attacks - Wikipedia article on side-channel attacks.
Remediation:
As acknowledged in the library's documentation, these vulnerabilities cannot be adequately addressed in pure Python. The advisory recommends:
-
SHORT TERM: Consider using this library only in environments where timing measurements by attackers are infeasible.
-
MEDIUM TERM: Implement your own wrappers around critical operations using constant-time libraries in languages like Rust, Go, or C.
-
LONG TERM: Wait for the planned Rust implementation mentioned in the library documentation that will properly address these issues.
Note that the usage of random.Random() identified in the _refresh_shares_additive function is intentional and secure as documented in the "False-Positive Vulnerabilities" section of the code, and should not be considered part of this vulnerability.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "PostQuantum-Feldman-VSS"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "0.8.0b2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-29780"
],
"database_specific": {
"cwe_ids": [
"CWE-203",
"CWE-208",
"CWE-385"
],
"github_reviewed": true,
"github_reviewed_at": "2025-03-14T19:55:10Z",
"nvd_published_at": "2025-03-14T18:15:32Z",
"severity": "MODERATE"
},
"details": "**Description:**\n\nThe `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\u0027s 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.\n\nThe `_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 \u003c min_value:` has execution time that depends on the value of `matrix[row][col]`. This timing difference can be exploited by an attacker.\n\nThe `constant_time_compare` function in this file also does not provide a constant-time guarantee.\n\nThis advisory formalizes the timing side-channel vulnerabilities already documented in the library\u0027s \"Known Security Vulnerabilities\" section. 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.\n\nAn 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.\n\n**Impact:**\n\nSuccessful 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.\n\n**References:**\n\n* File: `feldman_vss.py`\n* Function: `_find_secure_pivot`\n* Function: `_secure_matrix_solve`\n* Function: `constant_time_compare`\n* [Timing Attacks on Implementations of Diffie-Hellman, RSA, DSS, and Other Systems (1996)](https://www.rambus.com/wp-content/uploads/2015/08/TimingAttacks.pdf) - A seminal paper on timing attacks.\n* [Side-Channel Attacks](https://en.wikipedia.org/wiki/Side-channel_attack) - Wikipedia article on side-channel attacks.\n\n**Remediation:**\n\nAs acknowledged in the library\u0027s documentation, these vulnerabilities cannot be adequately addressed in pure Python. The advisory recommends:\n\n1. SHORT TERM: Consider using this library only in environments where timing measurements by attackers are infeasible.\n\n2. MEDIUM TERM: Implement your own wrappers around critical operations using constant-time libraries in languages like Rust, Go, or C.\n\n3. LONG TERM: Wait for the planned Rust implementation mentioned in the library documentation that will properly address these issues.\n\nNote that the usage of random.Random() identified in the _refresh_shares_additive function is intentional and secure as documented in the \"False-Positive Vulnerabilities\" section of the code, and should not be considered part of this vulnerability.",
"id": "GHSA-q65w-fg65-79f4",
"modified": "2025-03-19T15:28:08Z",
"published": "2025-03-14T19:55:10Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/DavidOsipov/PostQuantum-Feldman-VSS/security/advisories/GHSA-q65w-fg65-79f4"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-29780"
},
{
"type": "WEB",
"url": "https://en.wikipedia.org/wiki/Side-channel_attack"
},
{
"type": "PACKAGE",
"url": "https://github.com/DavidOsipov/PostQuantum-Feldman-VSS"
},
{
"type": "WEB",
"url": "https://www.rambus.com/wp-content/uploads/2015/08/TimingAttacks.pdf"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:L/AC:H/AT:P/PR:L/UI:N/VC:H/VI:L/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Post-Quantum Secure Feldman\u0027s Verifiable Secret Sharing has Timing Side-Channels in Matrix Operations"
}
GHSA-Q97C-8QH3-FPC6
Vulnerability from github – Published: 2026-09-08 21:24 – Updated: 2026-09-08 21:24The pure-PHP X25519 scalar multiplication in phpseclib is not constant-time. Field addition and subtraction each perform a data-dependent conditional modular reduction, so the cost of each Montgomery-ladder step is a linear function of that step's reduction count which is a quantity determined by the secret scalar's prefix.
An observer with per-ladder-step resolution recovers the 251-bit clamped private scalar. This is a per-step leak, not an aggregate one: an instrumented code proof-of-concept recovers 20/20 test keys from 32 observed operations, and an observer that counts libgmp calls instead of timing them recovers a key from a single operation.
This is not a low-order-input issue. Recovery works with the RFC 7748 base point u = 9, with no attacker-chosen input at all. Rejecting low-order public values does not close it.
2. Affected component
Confirmed on phpseclib 3.0.56 (338 files under phpseclib/,sha256(sorted(relpath NUL file_sha256 LF)) = cc7250b611f520e809131aab0931503457c44d8cbfb10d535251c6fec5f62a2b).
The code appears unchanged across the 3.0 series wherever Curve25519 is supported, please confirm the affected range.
| file:line | role |
|---|---|
Math/PrimeField/Integer.php:189 |
add() — conditional subtract($modulo) when the sum ≥ p |
Math/PrimeField/Integer.php:207 |
subtract() — conditional add($modulo) when the result is negative |
Crypt/EC/BaseCurves/Montgomery.php:229–234 |
ladder branch on the secret bit, selecting argument order of doubleAndAddPoint |
Crypt/EC/Formats/Keys/MontgomeryPrivate.php:66 |
multiplyPoint(getBasePoint(), dA) — no engine check of any kind |
Crypt/EC/Formats/Keys/PKCS8.php:194–200 |
the same derivation, correctly gated on ext-sodium — the pattern MontgomeryPrivate is missing |
3. Technical description
Operation counts in the ladder are already constant — 10 field multiplications, 4 additions and 4 subtractions per step, 2560 multiplications per 256-step ladder. Operand values are not. Each PrimeField\Integer::add() / subtract() takes a data-dependent branch costing ~0.85–1.0 µs on the GMP engine, against a ~32 µs step period, so per-step cost is α + β·c where c is that step's conditional-reduction count. Measured across 20 keys: R² = 0.91–0.98, β = 838–920 ns.
c depends on the whole scalar prefix, not on the current bit, so per-step thresholding is useless — it saturates at ~93% per bit for u = p−1 and at chance for u = 9, and recovers 0/20 keys either way, because the bit string is a prefix-XOR in which one flipped step inverts the entire tail. Conditioning on the prefix removes the ambiguity: a beam search replays both branches from each candidate ladder state, reads off the exact c for each, and scores against the observation. The victim's public key adjudicates the small residual search.
Two facts bound the problem and are worth stating precisely, because they determine whether a fix is needed at all:
- Aggregate observation is provably useless. The adjacent-bit transition count
T(k)has exact entropyH(T) = 4.0357bits over clamped scalars, so a noiseless transition-count oracle still leaves ~2^247 candidates. The summed reduction countΣcis richer (~6.6–6.9 bits) and still leaves ~2^244. Any measurement that collapses the call to one number is safe. Per-step measurement is not. - The libgmp call counts are exactly determined. Per ladder step,
__gmpz_add = 4 + csub,__gmpz_sub = 4 + cadd,__gmpz_mul = __gmpz_mod = 10. Verified by differencing gdb breakpoint counts against phpseclib's owndoubleAndAddPoint— 27/27 steps exact, extended independently to 64/64 and 38/38 by our two reviewers. An observer that only counts these calls needs no timing, no calibration and no repetition.
Results, 20 keys × 3 sampling seeds, 800 traces per path collected from 800 distinct PHP processes (so the observations are cross-process, as real requests would be):
| observer | path | observations needed | exact 251-bit recovery |
|---|---|---|---|
| timing | key load, u = 9 |
32 | 20/20 keys, 95% CI [83.9%, 100%] |
| timing | ECDH, u = p−1 |
32 | 18/20 keys, 95% CI [69.9%, 96.8%] |
| timing | either | 8 | 18–23% of trials |
| libgmp call counts | either | 1 | 20/20 keys; tolerates 20–30% of per-step counts being wrong |
The model underlying the decoder is validated against the pinned implementation: 254/254 (key, peer) outputs match the real DH::computeSecret, and all four RFC 7748 §6.1 vectors match both phpseclib and the published constants.
Negative controls are clean — wrong public key, shuffled trace, wrong peer value, foreign key: 0/20 in every case. Nothing derived from the private key reaches the decoder; its inputs are the observation vector, the peer value, the victim's public key, and the public clamping constants.
5. Impact
In the instrumented, local model, recovery of the clamped scalar gives a permanent compromise of the X25519 private key. Clamping is applied on every call, so the recovered value is what every past and future operation with that key uses.
6. Restrictions
Required for exploitation:
- A reused / long-lived X25519 private key. Ephemeral X25519 — the normal TLS and SSH case — defeats this outright. phpseclib's own SSH path generates a fresh scalar per exchange and is not affected.
- Knowledge of the victim's public key. It adjudicates the decoder's residual search; without it no candidate can be selected. This is normally public, but it is a precondition, not a convenience.
- The pure-PHP path must actually run. Measured across four extension configurations:
EC::loadFormat('MontgomeryPrivate', $raw32)runs the ladder in every configuration — but the format declaresIS_INVISIBLE(MontgomeryPrivate.php:40), soPublicKeyLoader::loadskips it and nothing inside phpseclib calls it. An application must name the format explicitly.PKCS8/PublicKeyLoader::load/EC::createKeyrun the ladder only when ext-sodium is absent —PKCS8.php:194gates onsodium_crypto_box_publickey_from_secretkey. OpenSSL does not help here.DH::computeSecretruns the ladder only underEC::forceEngine('PHP'), or when bothopenssl_pkey_derive(DH.php:325) andsodium_crypto_scalarmult(EC/PrivateKey.php:75) are unavailable. ext-sodium is bundled and enabled by default in PHP 7.2+, so the reachable configurations are a minority — thoughdisable_functionshardening and--disable-sodiumbuilds do occur, particularly in shared hosting.- An observer with per-ladder-step resolution, i.e. one that can distinguish ~0.9 µs within a ~32 µs step, or count libgmp entry-point calls. In practice that means local co-residency (e.g. a Flush+Reload spy on the shared
libgmp.somapping —__gmpz_add/__gmpz_subare the correct targets;__gmpn_*are not, being size-dispatched internals).
7. Suggested remediation
- Constant-time, fixed-width field arithmetic, or delegate to a vetted native provider. This is the actual fix. Removing the ladder's bit branch is not sufficient while
Integer.php:189and:207remain operand-dependent. - Gate
MontgomeryPrivate.php:66the wayPKCS8.php:194–200already is. That is a one-block change and it closes the only entry point that is un-gated in every configuration. Keep the$curve instanceof Curve25519guard —MontgomeryPrivatealso accepts Curve448 keys. - Consider an OpenSSL arm alongside the sodium arm in
PKCS8::loadECDH, or fail closed, so stacks without ext-sodium do not fall through to the ladder. - Separately, and unrelated to this channel: the pure-PHP path returns an all-zero 32-byte shared secret for low-order peer inputs. Rejecting the full canonicalised low-order set and adding a constant-time all-zero check is correct hygiene for contributory behaviour — but it does not mitigate the timing channel, since recovery works with
u = 9.
Contact
George Stergiopoulos Assistant Professor of cybersecurity Athens University of Economics and Business, Greece E: geostergiop@aueb.gr | s: https://www.aueb.gr/en/faculty_page/stergiopoulos-georgios
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "phpseclib"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.0.57"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "phpseclib"
},
"ranges": [
{
"events": [
{
"introduced": "4.0.0"
},
{
"fixed": "4.0.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-84308"
],
"database_specific": {
"cwe_ids": [
"CWE-208",
"CWE-385"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-08T21:24:29Z",
"nvd_published_at": "2026-09-01T20:17:24Z",
"severity": "MODERATE"
},
"details": "The pure-PHP X25519 scalar multiplication in phpseclib is not constant-time. Field addition and subtraction each perform a **data-dependent conditional modular reduction**, so the cost of each Montgomery-ladder step is a linear function of that step\u0027s reduction count which is a quantity determined by the secret scalar\u0027s *prefix*.\n\nAn observer with per-ladder-step resolution recovers the 251-bit clamped private scalar. This is a per-step leak, not an aggregate one: an instrumented code proof-of-concept recovers 20/20 test keys from 32 observed operations, and an observer that counts libgmp calls instead of timing them recovers a key from a **single** operation.\n\nThis is **not** a low-order-input issue. Recovery works with the RFC 7748 base point `u = 9`, with no attacker-chosen input at all. Rejecting low-order public values does not close it.\n\n## 2. Affected component\n\nConfirmed on **phpseclib 3.0.56** (338 files under `phpseclib/`,`sha256(sorted(relpath NUL file_sha256 LF)) = cc7250b611f520e809131aab0931503457c44d8cbfb10d535251c6fec5f62a2b`).\nThe code appears unchanged across the 3.0 series wherever Curve25519 is supported, please confirm the affected range.\n\n| file:line | role |\n|---|---|\n| `Math/PrimeField/Integer.php:189` | `add()` \u2014 conditional `subtract($modulo)` when the sum \u2265 p |\n| `Math/PrimeField/Integer.php:207` | `subtract()` \u2014 conditional `add($modulo)` when the result is negative |\n| `Crypt/EC/BaseCurves/Montgomery.php:229\u2013234` | ladder branch on the secret bit, selecting argument order of `doubleAndAddPoint` |\n| `Crypt/EC/Formats/Keys/MontgomeryPrivate.php:66` | `multiplyPoint(getBasePoint(), dA)` \u2014 **no engine check of any kind** |\n| `Crypt/EC/Formats/Keys/PKCS8.php:194\u2013200` | the same derivation, correctly gated on ext-sodium \u2014 the pattern `MontgomeryPrivate` is missing |\n\n## 3. Technical description\n\nOperation *counts* in the ladder are already constant \u2014 10 field multiplications, 4 additions and 4 subtractions per step, 2560 multiplications per 256-step ladder. Operand *values* are not. Each `PrimeField\\Integer::add()` / `subtract()` takes a data-dependent branch costing ~0.85\u20131.0 \u00b5s on the GMP engine, against a ~32 \u00b5s step period, so per-step cost is `\u03b1 + \u03b2\u00b7c` where `c` is that step\u0027s conditional-reduction count. Measured across 20 keys: R\u00b2 = 0.91\u20130.98, \u03b2 = 838\u2013920 ns.\n\n`c` depends on the whole scalar prefix, not on the current bit, so per-step thresholding is useless \u2014 it saturates at ~93% per bit for `u = p\u22121` and at **chance** for `u = 9`, and recovers 0/20 keys either way, because the bit string is a prefix-XOR in which one flipped step inverts the entire tail. Conditioning on the prefix removes the ambiguity: a beam search replays both branches from each candidate ladder state, reads off the exact `c` for each, and scores against the observation. The victim\u0027s public key adjudicates the small residual search.\n\nTwo facts bound the problem and are worth stating precisely, because they determine whether a fix is needed at all:\n\n- **Aggregate observation is provably useless.** The adjacent-bit transition count `T(k)` has exact entropy `H(T) = 4.0357` bits over clamped scalars, so a noiseless transition-count oracle still leaves ~2^247 candidates. The summed reduction count `\u03a3c` is richer (~6.6\u20136.9 bits) and still leaves ~2^244. Any measurement that collapses the call to one number is safe. Per-step measurement is not.\n- **The libgmp call counts are exactly determined.** Per ladder step, `__gmpz_add = 4 + csub`, `__gmpz_sub = 4 + cadd`, `__gmpz_mul = __gmpz_mod = 10`. Verified by differencing gdb breakpoint counts against phpseclib\u0027s own `doubleAndAddPoint` \u2014 27/27 steps exact, extended independently to 64/64 and 38/38 by our two reviewers. An observer that only *counts* these calls needs no timing, no calibration and no repetition.\n\nResults, 20 keys \u00d7 3 sampling seeds, 800 traces per path collected from **800 distinct PHP processes** (so the observations are cross-process, as real requests would be):\n\n| observer | path | observations needed | exact 251-bit recovery |\n|---|---|---|---|\n| timing | key load, `u = 9` | 32 | **20/20 keys**, 95% CI [83.9%, 100%] |\n| timing | ECDH, `u = p\u22121` | 32 | **18/20 keys**, 95% CI [69.9%, 96.8%] |\n| timing | either | 8 | 18\u201323% of trials |\n| libgmp call counts | either | **1** | 20/20 keys; tolerates 20\u201330% of per-step counts being wrong |\n\nThe model underlying the decoder is validated against the pinned implementation: 254/254 (key, peer) outputs match the real `DH::computeSecret`, and all four RFC 7748 \u00a76.1 vectors match both phpseclib and the published constants.\n\nNegative controls are clean \u2014 wrong public key, shuffled trace, wrong peer value, foreign key: 0/20 in every case. Nothing derived from the private key reaches the decoder; its inputs are the observation vector, the peer value, the victim\u0027s public key, and the public clamping constants.\n\n## 5. Impact\n\nIn the instrumented, local model, recovery of the clamped scalar gives a permanent compromise of the X25519 private key. Clamping is applied on every call, so the recovered value is what every past and future operation with that key uses.\n\n## 6. Restrictions\n\n**Required for exploitation:**\n\n1. **A reused / long-lived X25519 private key.** Ephemeral X25519 \u2014 the normal TLS and SSH case \u2014 defeats this outright. phpseclib\u0027s own SSH path generates a fresh scalar per exchange and is not affected.\n2. **Knowledge of the victim\u0027s public key.** It adjudicates the decoder\u0027s residual search; without it no candidate can be selected. This is normally public, but it is a precondition, not a convenience.\n3. **The pure-PHP path must actually run.** Measured across four extension configurations:\n - `EC::loadFormat(\u0027MontgomeryPrivate\u0027, $raw32)` runs the ladder in **every**\n configuration \u2014 but the format declares `IS_INVISIBLE` (`MontgomeryPrivate.php:40`),\n so `PublicKeyLoader::load` skips it and nothing inside phpseclib calls it. An\n application must name the format explicitly.\n - `PKCS8` / `PublicKeyLoader::load` / `EC::createKey` run the ladder **only when ext-sodium is absent** \u2014 `PKCS8.php:194` gates on `sodium_crypto_box_publickey_from_secretkey`. OpenSSL does not help here.\n - `DH::computeSecret` runs the ladder only under `EC::forceEngine(\u0027PHP\u0027)`, or when *both* `openssl_pkey_derive` (`DH.php:325`) and `sodium_crypto_scalarmult` (`EC/PrivateKey.php:75`) are unavailable. ext-sodium is bundled and enabled by default in PHP 7.2+, so the reachable configurations are a minority \u2014 though `disable_functions` hardening and `--disable-sodium` builds do occur, particularly in shared hosting.\n4. **An observer with per-ladder-step resolution**, i.e. one that can distinguish ~0.9 \u00b5s within a ~32 \u00b5s step, or count libgmp entry-point calls. In practice that means local co-residency (e.g. a Flush+Reload spy on the shared `libgmp.so` mapping \u2014 `__gmpz_add` / `__gmpz_sub` are the correct targets; `__gmpn_*` are not, being size-dispatched internals).\n\n## 7. Suggested remediation\n\n1. **Constant-time, fixed-width field arithmetic, or delegate to a vetted native provider.** This is the actual fix. Removing the ladder\u0027s bit branch is *not* sufficient while `Integer.php:189` and `:207` remain operand-dependent.\n2. **Gate `MontgomeryPrivate.php:66` the way `PKCS8.php:194\u2013200` already is.** That is a one-block change and it closes the only entry point that is un-gated in every configuration. Keep the `$curve instanceof Curve25519` guard \u2014 `MontgomeryPrivate` also accepts Curve448 keys.\n3. **Consider an OpenSSL arm alongside the sodium arm in `PKCS8::loadECDH`**, or fail closed, so stacks without ext-sodium do not fall through to the ladder.\n4. Separately, and unrelated to this channel: the pure-PHP path returns an all-zero 32-byte shared secret for low-order peer inputs. Rejecting the full canonicalised low-order set and adding a constant-time all-zero check is correct hygiene for contributory behaviour \u2014 but it does **not** mitigate the timing channel, since recovery works with `u = 9`.\n\n## Contact\nGeorge Stergiopoulos\nAssistant Professor of cybersecurity\nAthens University of Economics and Business, Greece\nE: geostergiop@aueb.gr | s: https://www.aueb.gr/en/faculty_page/stergiopoulos-georgios",
"id": "GHSA-q97c-8qh3-fpc6",
"modified": "2026-09-08T21:24:29Z",
"published": "2026-09-08T21:24:29Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/phpseclib/phpseclib/security/advisories/GHSA-q97c-8qh3-fpc6"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-84308"
},
{
"type": "WEB",
"url": "https://github.com/phpseclib/phpseclib/commit/fb56bc5bb9009b54a6c26b31aeec8ed944f17373"
},
{
"type": "PACKAGE",
"url": "https://github.com/phpseclib/phpseclib"
},
{
"type": "WEB",
"url": "https://github.com/phpseclib/phpseclib/releases/tag/3.0.57"
},
{
"type": "WEB",
"url": "https://github.com/phpseclib/phpseclib/releases/tag/4.0.1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "phpseclib \u2014 non-constant-time X25519 scalar multiplication permits full private-key recovery"
}
GHSA-QC2P-Q7X9-V64P
Vulnerability from github – Published: 2022-05-13 01:09 – Updated: 2023-12-21 23:03The OAuth2 Hawk and JOSE MAC Validation code in Apache CXF prior to 3.0.13 and 3.1.x prior to 3.1.10 is not using a constant time MAC signature comparison algorithm which may be exploited by sophisticated timing attacks.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.0.12"
},
"package": {
"ecosystem": "Maven",
"name": "org.apache.cxf.karaf:apache-cxf"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.0.13"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.1.9"
},
"package": {
"ecosystem": "Maven",
"name": "org.apache.cxf.karaf:apache-cxf"
},
"ranges": [
{
"events": [
{
"introduced": "3.1.0"
},
{
"fixed": "3.1.10"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2017-3156"
],
"database_specific": {
"cwe_ids": [
"CWE-385"
],
"github_reviewed": true,
"github_reviewed_at": "2022-07-01T17:33:35Z",
"nvd_published_at": "2017-08-10T18:29:00Z",
"severity": "HIGH"
},
"details": "The OAuth2 Hawk and JOSE MAC Validation code in Apache CXF prior to 3.0.13 and 3.1.x prior to 3.1.10 is not using a constant time MAC signature comparison algorithm which may be exploited by sophisticated timing attacks.",
"id": "GHSA-qc2p-q7x9-v64p",
"modified": "2023-12-21T23:03:29Z",
"published": "2022-05-13T01:09:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-3156"
},
{
"type": "WEB",
"url": "https://github.com/apache/cxf/commit/1338469"
},
{
"type": "WEB",
"url": "https://github.com/apache/cxf/commit/555843f"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2017:1832"
},
{
"type": "WEB",
"url": "https://github.com/apache/cxf"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r36e44ffc1a9b365327df62cdfaabe85b9a5637de102cea07d79b2dbf@%3Ccommits.cxf.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rc774278135816e7afc943dc9fc78eb0764f2c84a2b96470a0187315c@%3Ccommits.cxf.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rd49aabd984ed540c8ff7916d4d79405f3fa311d2fdbcf9ed307839a6@%3Ccommits.cxf.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rec7160382badd3ef4ad017a22f64a266c7188b9ba71394f0d321e2d4@%3Ccommits.cxf.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rfb87e0bf3995e7d560afeed750fac9329ff5f1ad49da365129b7f89e@%3Ccommits.cxf.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rff42cfa5e7d75b7c1af0e37589140a8f1999e578a75738740b244bd4@%3Ccommits.cxf.apache.org%3E"
},
{
"type": "WEB",
"url": "http://cxf.apache.org/security-advisories.data/CVE-2017-3156.txt.asc"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Covert Timing Channel in Apache CXF"
}
GHSA-QGHG-5FPH-Q28C
Vulnerability from github – Published: 2024-01-31 06:30 – Updated: 2024-04-25 18:30A 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.
{
"affected": [],
"aliases": [
"CVE-2024-0914"
],
"database_specific": {
"cwe_ids": [
"CWE-203",
"CWE-385"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-01-31T05:15:08Z",
"severity": "MODERATE"
},
"details": "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.",
"id": "GHSA-qghg-5fph-q28c",
"modified": "2024-04-25T18:30:38Z",
"published": "2024-01-31T06:30:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-0914"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2024:1239"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2024:1411"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2024:1608"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2024:1856"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2024:1992"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2024-0914"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2260407"
},
{
"type": "WEB",
"url": "https://people.redhat.com/~hkario/marvin"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-QGW6-CGVX-VW2G
Vulnerability from github – Published: 2022-05-13 01:14 – Updated: 2022-05-13 01:14A cache-based side channel in GnuTLS implementation that leads to plain text recovery in cross-VM attack setting was found. An attacker could use a combination of "Just in Time" Prime+probe attack in combination with Lucky-13 attack to recover plain text using crafted packets.
{
"affected": [],
"aliases": [
"CVE-2018-10846"
],
"database_specific": {
"cwe_ids": [
"CWE-327",
"CWE-385"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-08-22T13:29:00Z",
"severity": "MODERATE"
},
"details": "A cache-based side channel in GnuTLS implementation that leads to plain text recovery in cross-VM attack setting was found. An attacker could use a combination of \"Just in Time\" Prime+probe attack in combination with Lucky-13 attack to recover plain text using crafted packets.",
"id": "GHSA-qgw6-cgvx-vw2g",
"modified": "2022-05-13T01:14:22Z",
"published": "2022-05-13T01:14:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-10846"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2018:3050"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2018:3505"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2018-10846"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=1582574"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2018-10846"
},
{
"type": "WEB",
"url": "https://eprint.iacr.org/2018/747"
},
{
"type": "WEB",
"url": "https://gitlab.com/gnutls/gnutls/merge_requests/657"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2018/10/msg00022.html"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/ILMOWPKMTZAIMK5F32TUMO34XCABUCFJ"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/WDYY3R4F5CUTFAMXH2C5NKYFVDEJLTT7"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/ILMOWPKMTZAIMK5F32TUMO34XCABUCFJ"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/WDYY3R4F5CUTFAMXH2C5NKYFVDEJLTT7"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/3999-1"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/105138"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-R6V6-V5R9-3GGH
Vulnerability from github – Published: 2026-05-14 15:31 – Updated: 2026-08-25 15:32Covert timing channel in comparison of MD5-hashed password in PostgreSQL authentication allows an attacker to recover user credentials sufficient to authenticate. This does not affect scram-sha-256 passwords, the default in all supported releases. However, current databases may have MD5-hashed passwords originating in upgrades from PostgreSQL 13 or earlier. Versions before PostgreSQL 18.4, 17.10, 16.14, 15.18, and 14.23 are affected.
{
"affected": [],
"aliases": [
"CVE-2026-6478"
],
"database_specific": {
"cwe_ids": [
"CWE-385"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-14T14:16:25Z",
"severity": "MODERATE"
},
"details": "Covert timing channel in comparison of MD5-hashed password in PostgreSQL authentication allows an attacker to recover user credentials sufficient to authenticate. This does not affect scram-sha-256 passwords, the default in all supported releases. However, current databases may have MD5-hashed passwords originating in upgrades from PostgreSQL 13 or earlier. Versions before PostgreSQL 18.4, 17.10, 16.14, 15.18, and 14.23 are affected.",
"id": "GHSA-r6v6-v5r9-3ggh",
"modified": "2026-08-25T15:32:24Z",
"published": "2026-05-14T15:31:58Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-6478"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:21182"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:29953"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:32983"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:32994"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:33441"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:33497"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:34043"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:34362"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:34363"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:35880"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:42555"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:44420"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:44481"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:49521"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:58981"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2026-6478"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2477447"
},
{
"type": "WEB",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-6478.json"
},
{
"type": "WEB",
"url": "https://www.postgresql.org/support/security/CVE-2026-6478"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:22878"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:26181"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:26203"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:26204"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:26524"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:26525"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:26561"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:27718"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:27738"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:27741"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:27742"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:27743"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:28037"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:28143"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:28208"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:28999"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:29212"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:29815"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:29904"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-R9FV-H47R-823F
Vulnerability from github – Published: 2025-01-20 15:31 – Updated: 2025-11-03 21:32Issue summary: A timing side-channel which could potentially allow recovering the private key exists in the ECDSA signature computation.
Impact summary: A timing side-channel in ECDSA signature computations could allow recovering the private key by an attacker. However, measuring the timing would require either local access to the signing application or a very fast network connection with low latency.
There is a timing signal of around 300 nanoseconds when the top word of the inverted ECDSA nonce value is zero. This can happen with significant probability only for some of the supported elliptic curves. In particular the NIST P-521 curve is affected. To be able to measure this leak, the attacker process must either be located in the same physical computer or must have a very fast network connection with low latency. For that reason the severity of this vulnerability is Low.
{
"affected": [],
"aliases": [
"CVE-2024-13176"
],
"database_specific": {
"cwe_ids": [
"CWE-385"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-20T14:15:26Z",
"severity": "MODERATE"
},
"details": "Issue summary: A timing side-channel which could potentially allow recovering\nthe private key exists in the ECDSA signature computation.\n\nImpact summary: A timing side-channel in ECDSA signature computations\ncould allow recovering the private key by an attacker. However, measuring\nthe timing would require either local access to the signing application or\na very fast network connection with low latency.\n\nThere is a timing signal of around 300 nanoseconds when the top word of\nthe inverted ECDSA nonce value is zero. This can happen with significant\nprobability only for some of the supported elliptic curves. In particular\nthe NIST P-521 curve is affected. To be able to measure this leak, the attacker\nprocess must either be located in the same physical computer or must\nhave a very fast network connection with low latency. For that reason\nthe severity of this vulnerability is Low.",
"id": "GHSA-r9fv-h47r-823f",
"modified": "2025-11-03T21:32:14Z",
"published": "2025-01-20T15:31:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-13176"
},
{
"type": "WEB",
"url": "https://github.com/openssl/openssl/commit/07272b05b04836a762b4baa874958af51d513844"
},
{
"type": "WEB",
"url": "https://github.com/openssl/openssl/commit/2af62e74fb59bc469506bc37eb2990ea408d9467"
},
{
"type": "WEB",
"url": "https://github.com/openssl/openssl/commit/392dcb336405a0c94486aa6655057f59fd3a0902"
},
{
"type": "WEB",
"url": "https://github.com/openssl/openssl/commit/4b1cb94a734a7d4ec363ac0a215a25c181e11f65"
},
{
"type": "WEB",
"url": "https://github.com/openssl/openssl/commit/77c608f4c8857e63e98e66444e2e761c9627916f"
},
{
"type": "WEB",
"url": "https://github.openssl.org/openssl/extended-releases/commit/0d5fd1ab987f7571e2c955d8d8b638fc0fb54ded"
},
{
"type": "WEB",
"url": "https://github.openssl.org/openssl/extended-releases/commit/a2639000db19878d5d89586ae7b725080592ae86"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/05/msg00028.html"
},
{
"type": "WEB",
"url": "https://openssl-library.org/news/secadv/20250120.txt"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20250124-0005"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20250418-0010"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20250502-0006"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2025/01/20/2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:P/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
}
]
}
Mitigation
Whenever possible, specify implementation strategies that do not introduce time variances in operations.
Mitigation
Often one can artificially manipulate the time which operations take or -- when operations occur -- can remove information from the attacker.
Mitigation
It is reasonable to add artificial or random delays so that the amount of CPU time consumed is independent of the action being taken by the application.
CAPEC-462: Cross-Domain Search Timing
An attacker initiates cross domain HTTP / GET requests and times the server responses. The timing of these responses may leak important information on what is happening on the server. Browser's same origin policy prevents the attacker from directly reading the server responses (in the absence of any other weaknesses), but does not prevent the attacker from timing the responses to requests that the attacker issued cross domain.