Cloudanix VulnDB

CVE-2026-92542

None

CVSS

—

EPSS

0.1%

Published

Oct 7, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A server software bug lets ordinary programs send fake network messages that get encrypted and accepted as if the system itself had sent them, risking interference with private container communications.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Low
Impact
Data Tampering
Component
Application
Class
Authorization Bypass
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

Firewall rules intended to mark only kernel-originated VXLAN datagrams for IPsec encryption also match and encrypt forged UDP/VXLAN packets originating from user-space processes in the host network namespace, allowing unauthorized injection into encrypted overlay networks.

Why it matters to the business

Attackers with local access can inject or disrupt traffic on container overlay networks, leading to data tampering, service outages, or unauthorized communication across cluster nodes until the underlying software is updated.

How an attack unfolds

An attacker with local shell access on a Linux Swarm node crafts UDP datagrams destined for the Swarm data-path port that begin with a valid VXLAN header for an encrypted VNI; the host firewall marks these forged packets for encryption using the overlay IPsec keys, allowing them to traverse or interfere with the encrypted overlay.

How to fix it

Upgrade the container runtime and networking stack to a version containing corrected firewall marking logic that distinguishes kernel-originated VXLAN traffic; until patches are available, restrict unprivileged user access to the host network namespace and consider disabling encrypted overlays where feasible.

How to confirm the fix worked

Review firewall rule definitions and packet marking logic in the networking component source or configuration; test by sending crafted user-space VXLAN datagrams and confirm they are no longer marked for encryption after the update.

Typical attack path

  1. Obtain local user access on a Swarm node host network namespace
  2. Craft UDP datagram with destination port matching Swarm data-path and valid VXLAN header for an encrypted VNI
  3. Transmit packet from user process
  4. Observe packet being encrypted and forwarded into the overlay network

How to detect it

Inspect host firewall logs and network captures for VXLAN datagrams originating from non-kernel processes; correlate with process accounting to identify user-space senders of matching UDP traffic on Swarm data-path ports.

What your security team should do

  • Prioritize patching container orchestration components on all Swarm nodes once fixed releases are published
  • Audit and restrict local user privileges on cluster hosts to limit namespace access
  • Monitor for unexpected VXLAN traffic patterns on data-path ports

The record

The firewall rules which mark VXLAN datagrams for encryption indiscriminately match both authentic VXLAN datagrams sent from the kernel and forged datagrams sent by user processes. Any packet sent from the host network namespace of a Linux Swarm node is encrypted with the overlay-network IPsec parameters which meets the following criteria: - UDP datagram - Destination port is the Swarm data-path port - Datagram starts with a VXLAN header for the VNI of an encrypted overlay network which any running container on the node is connected to

Affected packages

Ecosystem Package Introduced Fixed

Related vulnerabilities