CVE-2026-68300 Overview
CVE-2026-68300 is an authentication bypass vulnerability in the Linux kernel's Stream Control Transmission Protocol (SCTP) implementation. The flaw resides in the sctp_auth_chunk_verify() function, which unconditionally returns true when chunk->auth_chunk is NULL. This behavior silently skips authentication for SCTP chunks under specific conditions, allowing unauthenticated peers to bypass required chunk authentication. Remote attackers can reach the code path over the network without prior authentication or user interaction.
Critical Impact
Remote attackers can bypass SCTP chunk authentication over the network, compromising confidentiality, integrity, and availability of affected Linux kernel hosts.
Affected Products
- Linux kernel (SCTP subsystem) — versions prior to the fixing commits listed in the kernel git history
- Linux distributions shipping vulnerable stable kernel branches
- Systems using SCTP with AUTH extension (RFC 4895) for chunk authentication
Discovery Timeline
- 2026-08-10 - CVE-2026-68300 published to NVD
- 2026-08-13 - Last updated in NVD database
Technical Details for CVE-2026-68300
Vulnerability Analysis
SCTP AUTH (RFC 4895) requires certain chunk types to be preceded by an AUTH chunk that cryptographically authenticates the following payload. The kernel enforces this in sctp_auth_chunk_verify(), which is expected to validate that authentication has occurred for chunks the endpoint marks as requiring AUTH. The vulnerable implementation returns true unconditionally whenever chunk->auth_chunk is NULL, treating the absence of an AUTH chunk as a successful verification.
Two conditions trigger the bypass. First, when skb_clone() fails in the bottom-half receive path, auth_chunk is left NULL. In sctp_endpoint_bh_rcv() the association pointer asoc is NULL for new connections, so the early sctp_auth_recv_cid() check cannot catch the missing authentication. Second, when no AUTH chunk precedes a COOKIE-ECHO, skb_clone() is never invoked and auth_chunk remains NULL, again passing verification silently.
Root Cause
The root cause is missing negative-path validation. The verification routine conflates two states — "authentication succeeded" and "no authentication data present" — into the same return value. The fix checks sctp_auth_recv_cid() when auth_chunk is NULL: if authentication is required for the chunk type, the function returns false and the chunk is dropped; otherwise processing continues normally.
Attack Vector
An unauthenticated remote attacker sends crafted SCTP traffic to a listening endpoint that enforces AUTH. By omitting the AUTH chunk before a protected chunk such as COOKIE-ECHO, or by triggering conditions that induce skb_clone() failure, the attacker bypasses chunk authentication. This enables spoofed association establishment and injection of chunks that should have been rejected, undermining the security guarantees SCTP AUTH is meant to provide.
No verified public proof-of-concept is available at the time of publication. See the upstream fix commits referenced in the Linux Kernel Commit 18957373 and Linux Kernel Commit ec2e157f for the exact code changes.
Detection Methods for CVE-2026-68300
Indicators of Compromise
- Unexpected SCTP associations established with peers that should require AUTH but where no AUTH chunk was observed on the wire.
- COOKIE-ECHO chunks accepted without a preceding AUTH chunk in packet captures on hosts configured to require chunk authentication.
- Kernel log anomalies or memory pressure events correlating with skb_clone() allocation failures during SCTP receive processing.
Detection Strategies
- Deploy network monitoring on SCTP-enabled interfaces to alert on association setup where required AUTH chunks are absent.
- Compare running kernel versions against the fixed commit hashes on all Linux hosts exposing SCTP services such as telecom signaling gateways and Diameter/M3UA endpoints.
- Correlate SCTP protocol events with process and socket telemetry to identify anomalous new associations from unexpected sources.
Monitoring Recommendations
- Enable SCTP protocol logging and forward events to a central analytics platform for retention and correlation.
- Track kernel version and patch level as an asset attribute so unpatched hosts running SCTP workloads surface in vulnerability queries.
- Alert on new SCTP listeners appearing on hosts that historically did not accept SCTP traffic.
How to Mitigate CVE-2026-68300
Immediate Actions Required
- Inventory all Linux hosts exposing SCTP services and identify those relying on SCTP AUTH for chunk authentication.
- Apply the upstream stable kernel updates that include the sctp_auth_chunk_verify() fix and reboot into the patched kernel.
- Restrict SCTP traffic at network boundaries so only trusted peers can reach protected endpoints until patches are deployed.
Patch Information
The fix is available in the upstream Linux kernel stable tree. Refer to Linux Kernel Commit 18957373, Linux Kernel Commit 28c5fdce, Linux Kernel Commit 83f5031f, Linux Kernel Commit 8e04823c, and Linux Kernel Commit ec2e157f. Distribution vendors are backporting the patch to supported kernel branches; consult your distribution's security tracker for the corresponding package versions.
Workarounds
- Where SCTP is not required, unload the sctp kernel module and blacklist it to eliminate the attack surface entirely.
- Filter inbound SCTP traffic (IP protocol 132) at perimeter and host firewalls, permitting only known signaling peers.
- If SCTP AUTH is enforced application-side, review whether the application can reject associations that lack expected AUTH chunks before kernel patches are applied.
# Disable the SCTP kernel module if SCTP is not needed
echo "install sctp /bin/true" | sudo tee /etc/modprobe.d/disable-sctp.conf
sudo rmmod sctp 2>/dev/null || true
# Restrict inbound SCTP traffic to trusted peers (example using nftables)
sudo nft add rule inet filter input meta l4proto sctp ip saddr != { 192.0.2.10, 192.0.2.11 } drop
# Verify running kernel version against distribution advisory
uname -r
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

