CVE-2024-45244: Hyperledger Fabric · Authentication Bypass by Capture-replay
Source CVE Database V5
Not known to be exploited · CVSS 5.3 Medium.
Data as of 26 Oct 2026, 16:39 UTC
- EPSS
- 0.5% chance of exploitation in 30 days – higher than 47% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:NExploitation evidence
Disclosed: evidence found.
CVE published 25 Aug 2024
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.
What to do
AI-suggested
To mitigate CVE-2024-45244, organizations should first identify all deployments running affected versions of Hyperledger Fabric (up to 3.0.0 and 2.5.x through 2.5.9). In the interim, administrators can implement custom validation logic or middleware to enforce strict timestamp checks on incoming requests, ensuring they fall within an acceptable time window relative to the system clock. Network-level controls such as rate limiting and anomaly detection can help identify and block replay attempts. Additionally, organizations should review and tighten blockchain network policies, including endorsement and validation policies, to reduce the risk of unauthorized transaction acceptance. Logging and monitoring should be enhanced to detect suspicious transaction patterns or repeated requests with stale timestamps. Finally, organizations should plan for timely upgrades to patched versions once available and conduct thorough testing to ensure the integrity of blockchain operations is restored.
Description
Hyperledger Fabric through 3.0.0 and 2.5.x through 2.5.9 do not verify that a request has a timestamp within the expected time window.