CVE-2025-30472 is a critical (CVSS 9.0) stack-based buffer overflow in Corosync through version 3.1.9. It needs encryption to be disabled or the key known, and a large UDP packet. Check the linked issue and your distribution advisory for the fixed release.
What's affected
The record says Corosync through 3.1.9 is affected. The flaw is in orf_token_endian_convert in exec/totemsrp.c and is reached with a large UDP packet.
The condition matters: it applies if encryption is disabled, or if the attacker knows the encryption key. A cluster with encryption on and a secret key is therefore harder to attack.
The Corosync project page lists 3.1.10 as the latest stable release. I could not confirm from the project which release carries the fix for this CVE, so check the issue linked below and your distribution's advisory. A Debian LTS announcement is referenced in the record, though I could not read it. The record does not flag the CVE as known exploited.
How to check if you're exposed
Corosync is a cluster engine used for high availability, often together with Pacemaker.
- Run corosync -v on each node to read the version.
- On Debian or Ubuntu, run dpkg -l corosync. On RPM based systems, run rpm -q corosync, and compare with your distribution's security advisory.
- Read corosync.conf and check whether crypto settings are enabled. Look for the crypto_cipher and crypto_hash options in the totem section.
Also check which networks carry the cluster traffic and who can send UDP packets to the cluster ports.
What to do now
- List all nodes that run Corosync and note the version and whether encryption is enabled.
- Install your distribution's fixed package, or upgrade beyond 3.1.9, after confirming the fix in the advisory or issue.
- Turn on encryption for the cluster network and protect the key like any other secret.
- Put the cluster traffic on a private network that untrusted hosts cannot reach.
- Update nodes in a rolling way, following your cluster vendor's guidance, so that services stay available.
Why it matters
The record maps the flaw to CWE-121 (Stack-based Buffer Overflow) and CWE-787 (Out-of-bounds Write). A conversion routine for a cluster protocol message copies data using a size that the sender can influence, and a large packet writes past the space reserved on the stack.
Stack overflows are serious because the stack holds return addresses, though modern protections make exploitation harder. At minimum, a crash of a cluster node can cause failover or loss of quorum, which is a real outage for a high availability setup.
The conditions in the record, encryption off or key known, show why cluster traffic should be encrypted and kept on private networks. They also explain the 9.0 score rather than a higher one. If an attacker is already on your cluster network, a missing key is the only barrier left.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Does encryption protect me?
The record says the flaw applies if encryption is disabled or the attacker knows the key. Encryption with a secret key raises the bar, but still patch.
Which release fixes it?
I could not confirm this from the project pages. Check the linked issue and your distribution advisory.
Sources
Last reviewed: 19 October 2026.
