CVE-2026-35091: Corosync Denial of Service Vulnerability

CVE-2026-35091 Overview

A flaw in Corosync allows a remote unauthenticated attacker to trigger an out-of-bounds read in the membership commit token sanity check. The vulnerability stems from an incorrect return value check [CWE-253] that can be exploited by sending a specially crafted User Datagram Protocol (UDP) packet. Successful exploitation causes a denial of service (DoS) condition and may disclose limited memory contents from the affected process. Corosync underpins cluster membership and messaging in high-availability deployments, so disruption can cascade across clustered services. The flaw affects upstream Corosync and is shipped in multiple Red Hat Enterprise Linux versions and Red Hat OpenShift.

Critical Impact
A single crafted UDP packet from an unauthenticated remote attacker can crash Corosync cluster nodes and leak limited memory, breaking high-availability clusters.

Affected Products

Corosync (upstream)
Red Hat Enterprise Linux 7, 8, 9, and 10
Red Hat OpenShift 4.0

Discovery Timeline

2026-04-01 - CVE-2026-35091 published to the National Vulnerability Database (NVD)
2026-05-13 - Last updated in NVD database

Technical Details for CVE-2026-35091

Vulnerability Analysis

Corosync is the cluster engine that provides totem-based membership and reliable ordered messaging for high-availability stacks such as Pacemaker. Cluster nodes exchange membership commit tokens over UDP to agree on ring state. The sanity check guarding the commit token parser returns an incorrect value when input validation fails, allowing parsing to continue against attacker-controlled data. The downstream code then reads memory past the bounds of the receive buffer, producing an out-of-bounds read.

Because Corosync processes these packets before authenticating cluster membership at the application layer, a remote attacker who can reach the totem UDP port can trigger the condition without credentials. The result is process termination on the affected daemon and possible disclosure of small amounts of adjacent process memory in error paths or replies.

Root Cause

The root cause is an Incorrect Check of Function Return Value [CWE-253] in the membership commit token sanity routine. The caller treats a failure path as success, allowing malformed token fields to flow into a length-controlled read. The condition aligns with Common Weakness Enumeration class CWE-125 (Out-of-Bounds Read) as the observable effect.

Attack Vector

Exploitation requires only network reachability to a Corosync node's totem UDP port. The attacker crafts a UDP datagram that mimics a membership commit token with manipulated length or offset fields. No authentication, user interaction, or prior access to the cluster is required. In typical deployments Corosync traffic is intended to remain on a private cluster interconnect, so exposure depends on network segmentation. Where the interconnect is shared with general networks or misconfigured, the attack surface is directly reachable.

No verified public proof-of-concept code is available. The vulnerability mechanism is described in the Red Hat CVE Report CVE-2026-35091 and the associated Red Hat Bug Report #2453169.

Detection Methods for CVE-2026-35091

Indicators of Compromise

Unexpected corosync process crashes or repeated restarts logged in /var/log/cluster/corosync.log or journalctl -u corosync.
Cluster membership churn, ring recovery messages, or Retransmit List entries appearing without a corresponding network event.
Inbound UDP traffic to the Corosync totem ports (default 5404/5405) from hosts outside the defined cluster ring address list.

Detection Strategies

Alert on Corosync daemon termination signals and segmentation faults via systemd journal or audit subsystem.
Inspect packet captures on cluster interconnect interfaces for malformed totem commit tokens or oversized membership payloads.
Correlate Pacemaker fencing or quorum-loss events with simultaneous Corosync exits across multiple nodes, which is consistent with a remote DoS attempt.

Monitoring Recommendations

Forward corosync and pacemaker logs to a centralized logging or SIEM platform and create rules for repeated crash signatures.
Monitor network flows for non-cluster source addresses sending UDP to totem ports and treat them as policy violations.
Track cluster quorum and node-state metrics with thresholds that page on rapid membership transitions.

How to Mitigate CVE-2026-35091

Immediate Actions Required

Apply vendor updates to the corosync package on every cluster node and restart the service in a rolling fashion to preserve quorum.
Restrict UDP 5404/5405 (or the configured totem ports) at the host firewall to known cluster member IP addresses only.
Validate that cluster interconnects are on isolated VLANs or dedicated interfaces, not exposed to client or management networks.

Patch Information

Red Hat has shipped fixes across multiple advisories covering Red Hat Enterprise Linux 7, 8, 9, 10, and Red Hat OpenShift 4. Refer to RHSA-2026:13644, RHSA-2026:13657, RHSA-2026:13673, RHSA-2026:14205, RHSA-2026:14210, RHSA-2026:14211, RHSA-2026:14212, RHSA-2026:14213, RHSA-2026:14214, RHSA-2026:14215, and RHSA-2026:14216 for the package versions applicable to your distribution.

Workarounds

Enforce Corosync cryptographic authentication and encryption by setting secauth: on and configuring a strong authkey so off-ring datagrams are dropped earlier in processing.
Use host-based firewalling (nftables, firewalld, or security groups) to permit totem traffic only between cluster members.
Where possible, bind Corosync to a dedicated, non-routable interconnect interface to reduce network exposure until patches are deployed.

bash

# Example: restrict Corosync totem ports to cluster members with firewalld
firewall-cmd --permanent --zone=trusted --add-source=10.10.0.11/32
firewall-cmd --permanent --zone=trusted --add-source=10.10.0.12/32
firewall-cmd --permanent --zone=trusted --add-source=10.10.0.13/32
firewall-cmd --permanent --zone=trusted --add-port=5404/udp
firewall-cmd --permanent --zone=trusted --add-port=5405/udp
firewall-cmd --reload