dbcve.org
Openshift Container PlatformApplication · Redhat

CVE-2025-5351

MEDIUM · 6.5 CVSS v3.1 Published 2025-07-04
Fix available
A fix is available. Upgrade to 0.11.2 or later.
See remediation →
71/100
Remediation priority · Elevated
Remotely reachable Zero-click

Official description Straight from the sourceThe vendor's or NVD's own wording, published unedited. Authoritative, but often terse — it says what broke, rarely what to do.

NVD · unedited
A flaw was found in the key export functionality of libssh. The issue occurs in the internal function responsible for converting cryptographic keys into serialized formats. During error handling, a memory structure is freed but not cleared, leading to a potential double free issue if an additional failure occurs later in the function. This condition may result in heap corruption or application instability in low-memory scenarios, posing a risk to system reliability where key export operations are performed.

Technical summary Written by usOur analysis, written from the advisory, the CVSS vector and the affected-version data. It adds context the advisory leaves out, and never invents facts that are not in the source.

dbcve analysis · moderate confidence

A double-free vulnerability exists in libssh's key export functionality. During error handling, a memory structure is freed but the pointer is not cleared. If another failure occurs subsequently, the same memory is freed again, causing heap corruption. This is exploitable in low-memory scenarios where multiple error conditions may arise during key export operations.

MitigationApply the vendor patch when available; in the interim, avoid performing key export operations under low-memory conditions and monitor for application instability. The fix typically involves setting pointers to NULL after freeing or restructuring error-handling code paths.

Verify against the referenced sources before acting — the references below are authoritative for this CVE, this summary is not.

Affected products & versions What the vendor confirmedThe version ranges the vendor confirmed as vulnerable. If your version sits inside a range here, treat yourself as exposed until you have upgraded.

NVD · CPE data
Openshift Container PlatformApplication
Affected:= 4.0
Enterprise LinuxOperating system
Affected:= 6.0= 7.0= 8.0= 9.0= 10.0
LibsshApplication
Affected:>= 0.10.0, < 0.11.2

CVSS breakdown How the score is builtThe industry scoring standard. It rates how the flaw is reached, what it takes to exploit, and what an attacker gains — the score is derived from those, not the other way round.

From the vector
Attack vector
Network
Complexity
Low
Privileges
Low
User interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Am I affected? How to checkSteps we derive from the advisory and the affected-version data, so you can decide whether this CVE reaches your setup. They are a guide, not a scan — your own configuration is the authority.

dbcve checks

Work through these to decide whether this CVE applies to you.

  1. Identify libssh library version
    Run 'ssh -V' or check the shared library version with 'ldd --version' or inspect the libssh package: 'rpm -qa | grep libssh' on RHEL systems, or check the library file directly with 'strings /path/to/libssh.so | grep version'
    Affected if The installed version is >= 0.10.0 and < 0.11.2
  2. Confirm key export operations are performed
    Review application logs, code, or configuration to determine whether SSH key export or key generation functions from libssh are being called by your application
    Affected if Your application or service uses libssh to export or generate SSH keys
  3. Identify low-memory execution context
    Check application runtime environment: review container memory limits ('kubectl get pod -o jsonpath={.spec.containers[*].resources.limits.memory}'), systemd memory limits, or application configuration for memory-constrained settings
    Affected if The application runs with memory limits below typical operational requirements or in environments prone to memory pressure
  4. Inspect for heap corruption indicators
    Run application under memory debugging tools such as Valgrind or AddressSanitizer if safe to do so, or check system logs (/var/log/messages, dmesg) for heap corruption warnings or segmentation faults related to libssh
    Affected if Heap corruption errors, crashes, or memory allocation failures occur during or after key export operations
  5. Verify OpenSSH or derivative product usage
    Check if a Red Hat OpenShift Container Platform version 4.0 or Red Hat Enterprise Linux version 6.0-10.0 is deployed, as these include vulnerable libssh versions: 'oc version' or 'cat /etc/redhat-release'
    Affected if Running the specified Red Hat products that ship the affected libssh version

You are affected if your environment uses libssh version 0.10.0 through 0.11.1 and performs SSH key export operations, particularly under memory-constrained conditions where multiple error conditions can occur.

Generated from the published advisory. Verify against your own configuration.

Check your environment

Paste your version and any relevant configuration and it will be compared against the affected criteria above. Do not include secrets or credentials.

AI-assisted, checked against the advisory. Informational, not a guarantee.

Remediation Closing itWhat it takes to close this. Where a vendor fix exists we point at it; where none exists we say so plainly, and can build one. Effort estimates are scoped from the advisory, not from your codebase.

dbcve · scoped
Upgrade available Upgrade to 0.11.2 or later
Fixed in 0.11.2
Interim mitigation

Apply the vendor patch when available; in the interim, avoid performing key export operations under low-memory conditions and monitor for application instability. The fix typically involves setting pointers to NULL after freeing or restructuring error-handling code paths.

Recommended fix High confidence

libssh version 0.11.2 or later; for RHEL/CentOS systems, apply the vendor security advisory RHSA for this CVE

  1. Identify all applications and services that depend on libssh in your environment
  2. Update the libssh package to version 0.11.2 or later using your system's package manager (e.g., yum update libssh or dnf update libssh)
  3. For Red Hat Enterprise Linux systems, run: yum update libssh (or dnf update libssh) to pull in the fixed package
  4. Restart any services or applications that use libssh to ensure the updated library is loaded
  5. Verify the installed libssh version matches or exceeds 0.11.2 using: rpm -q libssh or ssh -V
Caveat Review application compatibility with libssh 0.11.x before production deployment; minor API changes may exist between 0.10.x and 0.11.x

Generated from the published advisory — verify against the referenced sources before acting.

Fix this in Openshift Container Platform Scoped from the published advisory
  • Consultation4.0 h
  • Implementation8.0 h
  • Testing6.0 h
  • Review / QA3.0 h
21.0 hours of engineering $3,680
Get the upgrade done

An estimate, not a bill — we confirm scope with you before any work starts. Need it this week? Rush from $5,888.

Scan for this in your stack

Free · runs locally
dbcve dependency scanner

Check whether your project pulls in CVE-2025-5351 — or any other known-vulnerable package — straight from your lock files. Free and open source; it runs locally and uploads nothing.

Get it on GitHub Scan in the browser

References Go to the primary sourcePrimary sources — vendor advisories, patches and trackers. Where our summary and a reference disagree, the reference wins.

Primary sources

Practitioner notes

Contributed

Peer-ranked notes from engineers who’ve handled CVE-2025-5351 in production — separate from our analysis above.

No notes yet

Be the first to add a field note for this CVE — a mitigation you’ve verified, a version caveat, or a link to a working fix. Sign in above to contribute.

What this is

A place for practitioners to share what actually worked: a mitigation you’ve tested, a configuration change, a version- or environment-specific caveat, or a link to a verified patch. The most useful notes rise to the top as peers upvote them, so the signal stays high.

What belongs here
  • Verified mitigations, workarounds, and config changes
  • Version or environment caveats, and links to real fixes
  • No weaponised exploit code, or anything meant to cause harm
  • No spam, self-promotion, credentials, or personal data