Kronosnet ACL Bypass Flaw (CVE-2026-15812) Lets Attackers Spoof Link IDs Remotely

A newly disclosed vulnerability in Kronosnet, the network transport layer underpinning high-availability Linux clustering, allows unauthenticated remote attackers to bypass access control checks by spoofing link identifiers, but only when administrators run the software in an insecure, non-default configuration.

Tracked as CVE-2026-15812, the issue resides in kronosnet’s internal Access Control List subsystem, which is meant to validate the origin of network frames flowing between cluster nodes.

The bug surfaces specifically when kronosnet is configured to accept “dynamic links” connections from any arbitrary IP address without enabling payload encryption.

In that state, the validation logic implicitly trusts whatever link ID is embedded in an incoming packet rather than independently verifying it, letting an attacker forge a legitimate link ID inside a crafted frame and slip malicious data straight past the ACL into the application layer.

Kronosnet ACL Bypass Flaw

The weakness is cataloged under CWE-290, Authentication Bypass by Spoofing, a class of flaw where a system substitutes weak identity checks for real authentication and ends up trusting attacker-controlled input. Fabio Di Nitto is credited with reporting the issue through Red Hat Bugzilla tracking ID 2500851.

Despite enabling a full ACL bypass, Red Hat assigns this flaw a CVSS v3.1 base score of 4.8, with a vector reflecting a network attack vector, high attack complexity, no privileges or user interaction required, and low integrity and availability impact with no confidentiality loss.

The muted score hinges on one critical caveat: exploitation demands a non-production setup where dynamic links are active, and encryption is deliberately disabled a combination Red Hat does not ship by default in any supported product.

Red Hat has confirmed that its own layered products, including RHEL High Availability, are not affected because default configurations enforce network encryption, which independently neutralizes the attack’s prerequisites. Even so, the kronosnet package itself remains listed across multiple platforms pending a code-level fix.

Product	Component	Status	Errata
Red Hat Enterprise Linux 8	kronosnet	Fix deferred	None
Red Hat Enterprise Linux 9	kronosnet	Fix deferred	None
Red Hat Enterprise Linux 10	kronosnet	Fix deferred	None
OpenShift Container Platform 4	rhcos	Fix deferred	None

A “fix deferred” status means Red Hat has assessed the issue but has not yet scheduled a patch release, typically because the risk in default deployments is negligible.

Organizations running kronosnet-based clustering outside Red Hat’s hardened defaults, for instance in custom Corosync or Pacemaker deployments, should treat this disclosure as a configuration audit trigger rather than an emergency patch scenario.

Confirm network traffic encryption (crypto_cipher and crypto_hash) is enabled on every kronosnet link, not left at “none”.
Avoid dynamic link configurations that accept connections from unrestricted IP ranges unless strictly necessary for the deployment.
Segment cluster interconnect traffic on isolated, trusted VLANs to reduce exposure even if encryption is temporarily unavailable.
Monitor for anomalous link ID reuse or unexpected packet sources in kronosnet logs as an early warning sign of spoofing attempts.

The core lesson from CVE-2026-15812 is that implicit trust in packet-supplied identifiers, even inside purpose-built cluster transport protocols, remains a recurring architectural blind spot.

Security teams evaluating high-availability infrastructure should treat encryption as a mandatory control for any interconnect accepting traffic from dynamic or untrusted network segments, not an optional hardening step.