What is the CVSS score of CVE-2026-64551?

CVE-2026-64551 has a contested CVSS base score of 9.1 from a third party (e.g. CISA-ADP), while the vendor rates it Critical. vuln.today uses the vendor rating as authoritative.

Which versions of Linux Kernel are affected by CVE-2026-64551?

The Linux kernel SCTP stack contains a critical memory disclosure vulnerability (CVE-2026-64551) capable of exposing encryption keys and credentials to remote attackers.. A patch is available.

How to fix or mitigate CVE-2026-64551?

Within 24 hours, identify systems with SCTP enabled in your environment, assess which are exposed to untrusted network traffic, and prioritize systems processing sensitive data. Within 7 days, obtain and thoroughly test the available vendor patch in a staging environment, then begin deployment to production systems starting with high-priority applications. Within 30 days, ensure all affected systems have been patched, validate remediation through automated vulnerability scanning, and update your kernel patching procedures to accelerate deployment of future critical vulnerabilities.

Linux Kernel CVE-2026-64551

EUVD-2026-49602 CRITICAL

2026-07-27 Linux

GHSA-m58p-8fjh-3whj

Information Disclosure Linux

Critical

Disputed · 9.1 Vendor: Linux

Severity by source

Sources disagree (Medium–Critical)

Vendor (Linux) PRIMARY

9.1 CRITICAL

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

vuln.today AI

6.5 MEDIUM

Unauthenticated peer/local raw-socket reach gives AV:N/AC:L/PR:N, but the leak is a small uninitialized value (C:L) with only a possible OOB-read crash (A:L), not full compromise.

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

4.0 AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:L/SC:N/SI:N/SA:N

SUSE

CRITICAL

qualitative

Red Hat

7.0 MEDIUM

qualitative

vuln.today treats the vendor’s rating as authoritative. A higher third-party CVSS (e.g. CISA-ADP) is shown for transparency but does not drive the headline severity.

CVSS VectorVendor: Linux

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

None

Availability

High

Lifecycle Timeline

Analysis Generated

Jul 30, 2026 - 06:53 vuln.today

CVSS changed

Jul 30, 2026 - 06:37 NVD

9.1 (CRITICAL)

Patch available

Jul 27, 2026 - 21:17 EUVD

CVE Published

Jul 27, 2026 - 20:10 cve.org

UNKNOWN (no severity yet)

CVE Published

Jul 27, 2026 - 20:10 cve.org

CRITICAL 9.1

DescriptionCVE.org

In the Linux kernel, the following vulnerability has been resolved:

sctp: validate STALE_COOKIE cause length before reading staleness

When an ERROR chunk with a STALE_COOKIE cause is received in the COOKIE_ECHOED state, sctp_sf_do_5_2_6_stale() reads the 4-byte Measure of Staleness that follows the cause header:

err = (struct sctp_errhdr *)(chunk->skb->data); stale = ntohl(*(__be32 *)((u8 *)err + sizeof(*err)));

err is the first cause in the chunk, not the STALE_COOKIE cause that caused the dispatch, and nothing guarantees the staleness field is present. sctp_walk_errors() only requires a cause to be as long as the 4-byte header, so for a STALE_COOKIE cause of length 4 the read runs past the cause, and for a minimal ERROR chunk past skb->tail. The value is echoed to the peer in the Cookie Preservative of the reply INIT, leaking uninitialized memory.

sctp_sf_cookie_echoed_err() already walks to the STALE_COOKIE cause, so check its length there and pass it to sctp_sf_do_5_2_6_stale(), which reads that cause instead of the first one. A STALE_COOKIE cause too short to hold the staleness field is discarded.

The read is reachable by any peer that can drive an association into COOKIE_ECHOED, including an unprivileged process using a raw SCTP socket in a user and network namespace.

AnalysisAI

Uninitialized kernel memory disclosure in the Linux kernel SCTP stack allows a remote peer to leak stale kernel heap/stack bytes by sending a malformed ERROR chunk carrying a STALE_COOKIE cause. When an association is in the COOKIE_ECHOED state, sctp_sf_do_5_2_6_stale() reads a 4-byte 'Measure of Staleness' from the first cause in the chunk without verifying that the field is actually present, and echoes that value back to the peer in the Cookie Preservative of the reply INIT. It is reachable by any peer - including an unprivileged local process using a raw SCTP socket inside a user+network namespace - and there is no public exploit identified at time of analysis (EPSS 0.18%, not in CISA KEV).

Technical ContextAI

The flaw lives in the kernel's SCTP (Stream Control Transmission Protocol, RFC 4960) state machine. During the four-way SCTP handshake, a server may reply to a COOKIE_ECHO with an ERROR chunk containing a STALE_COOKIE cause (type 3) whose body holds a 4-byte staleness value used by the peer to build the Cookie Preservative parameter of a retried INIT. The bug is a length-validation gap: sctp_walk_errors() only guarantees a cause is at least as long as its 4-byte header, but sctp_sf_do_5_2_6_stale() casts past that header (stale = ntohl(*(__be32 *)((u8 *)err + sizeof(*err)))) against the FIRST cause in the chunk rather than the STALE_COOKIE cause that triggered the dispatch. For a STALE_COOKIE cause of length 4, or a minimal ERROR chunk, the read runs past the cause and even past skb->tail. CWE is listed as N/A by NVD, but the root cause maps to CWE-125 (Out-of-Bounds Read) combined with CWE-908 (Use of Uninitialized Resource), since the leaked bytes are then transmitted to the peer. The fix makes sctp_sf_cookie_echoed_err() validate the STALE_COOKIE cause length and pass that specific cause to sctp_sf_do_5_2_6_stale(), discarding any STALE_COOKIE cause too short to hold the staleness field. Affected code is CONFIG_IP_SCTP; systems without the SCTP module loaded are not exposed. CPE data only generically identifies 'linux:linux' (the kernel).

RemediationAI

Vendor-released patch: upgrade to a fixed stable kernel - 6.18.40, 6.12.97, 6.6.145, 6.1.178, 5.15.212, or 5.10.261 (or 7.1.5 / 7.2-rc4 on newer trees) - or apply your distribution's backported update referencing CVE-2026-64551; the upstream fixes are the kernel.org stable commits (e.g., https://git.kernel.org/stable/c/588706ebaf8cdb4a4161602949eba365514b1db1). Where immediate patching is not possible, the most effective compensating control is to remove the attack surface: blacklist/unload the SCTP module (e.g., 'install sctp /bin/true' in modprobe.d) on hosts that do not require SCTP - side effect: breaks any legitimate SCTP applications such as certain telecom/Diameter/SS7-over-IP or clustering stacks. Additionally, restrict unprivileged user-namespace creation (sysctl kernel.unprivileged_userns_clone=0 or user.max_user_namespaces=0) to close the local raw-SCTP-socket path - trade-off: may break container runtimes and sandboxes that rely on unprivileged user namespaces. Where SCTP is needed, filter/deny untrusted SCTP (IP protocol 132) at the network boundary to limit which peers can drive associations into COOKIE_ECHOED.

Same technique Information Disclosure

View all

CVE-2019-2725 CRITICAL POC

9.8

CVE-2021-34523 CRITICAL POC

9.0

CVE-2013-2251 CRITICAL POC

9.8

CVE-2017-5638 CRITICAL POC

9.8

CVE-2025-24813 CRITICAL POC

9.8

CVE-2015-1701 HIGH POC

7.8

CVE-2017-0147 HIGH POC

7.5

CVE-2014-6324 HIGH POC

8.8

Vendor StatusVendor

SUSE

Severity: Critical

Product	Status
SUSE Linux Enterprise Desktop 15 SP7	Affected
SUSE Linux Enterprise Desktop 15 SP7	Affected
SUSE Linux Enterprise High Availability Extension 15 SP7	Affected
SUSE Linux Enterprise High Availability Extension 15 SP7	Affected
SUSE Linux Enterprise High Availability Extension 16.0	Affected

CVE-2026-64551 vulnerability details – vuln.today

Back

Linux Kernel CVE-2026-64551

Severity by source

CVSS VectorVendor: Linux

Lifecycle Timeline

DescriptionCVE.org

AnalysisAI

Technical ContextAI

RemediationAI

Same technique Information Disclosure

Vendor StatusVendor

SUSE

Share

External POC / Exploit Code