CVE-2025-5372: Red Hat Enterprise Linux 8 · Incorrect Calculation
Affects Red Hat Enterprise Linux 8Source CVE Database V5
Not known to be exploited · CVSS 5.0 Medium.
Data as of 26 Oct 2026, 10:12 UTC
- EPSS
- 0.5% chance of exploitation in 30 days – higher than 42% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:LExploitation evidence
Disclosed: evidence found.
CVE published 4 Jul 2025
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
European organizations should prioritize upgrading OpenSSL to version 3.0 or later to ensure consistent return value semantics with libssh. If upgrading OpenSSL is not immediately feasible, applying patches or updates to libssh that correctly handle the return values from OpenSSL is essential. Organizations should audit their Red Hat Enterprise Linux 8 systems to identify those running vulnerable libssh and OpenSSL versions. Network segmentation and strict access controls can limit exposure by restricting SSH access to trusted hosts and users. Monitoring SSH session logs for anomalies and implementing intrusion detection systems capable of identifying unusual SSH behavior can help detect exploitation attempts. Additionally, organizations should enforce multi-factor authentication for SSH access to reduce the risk of unauthorized use. Regularly reviewing and updating cryptographic libraries and dependencies as part of patch management processes will help prevent similar issues.
Description
A flaw was found in libssh versions built with OpenSSL versions older than 3.0, specifically in the ssh_kdf() function responsible for key derivation. Due to inconsistent interpretation of return values where OpenSSL uses 0 to indicate failure and libssh uses 0 for success—the function may mistakenly return a success status even when key derivation fails. This results in uninitialized cryptographic key buffers being used in subsequent communication, potentially compromising SSH sessions' confidentiality, integrity, and availability.