CVE-2026-54609: QTI Neon UDP Relay DoS Vulnerability

CVE-2026-54609 Overview

CVE-2026-54609 is a denial-of-service vulnerability in QTI Neon, a minimal, game-agnostic, relay-based UDP multiplayer protocol library. Version 1.0.0 contains an unbounded packet-forwarding flaw in the handleReconnectRequest function of the relay component. The relay forwards RECONNECT_REQUEST packets to the host without any rate limiting or validation, enabling relay-to-host amplification. An unauthenticated remote attacker can flood the host with reconnect requests, exhausting host resources and disrupting multiplayer service availability. The issue is classified under [CWE-400] Uncontrolled Resource Consumption. No fixed version is available as of this review.

Critical Impact
Unauthenticated remote attackers can drive relay-to-host UDP amplification, causing denial of service on any host relying on QTI Neon 1.0.0.

Affected Products

QTI Neon (Quiet Terminal Interactive)
QTI Neon version 1.0.0
Relay component (handleReconnectRequest)

Discovery Timeline

2026-07-28 - CVE-2026-54609 published to NVD
2026-07-28 - Last updated in NVD database

Technical Details for CVE-2026-54609

Vulnerability Analysis

QTI Neon is a UDP-based multiplayer relay library that brokers traffic between clients and a game host. The relay processes control-plane packets, including RECONNECT_REQUEST messages that clients use to re-establish sessions. In version 1.0.0, the handleReconnectRequest routine forwards every incoming reconnect packet directly to the host without applying per-source rate limits, authentication checks, or aggregate bounds.

This design allows a single unauthenticated client to convert modest inbound traffic into a sustained outbound stream aimed at the host. Because UDP is connectionless and the relay does not validate source identity, attackers can also spoof source addresses to amplify the effect. The resulting resource exhaustion on the host degrades or halts multiplayer service.

Root Cause

The root cause is missing input rate control and packet accounting in handleReconnectRequest. The relay trusts client-supplied RECONNECT_REQUEST traffic and forwards it unconditionally. There is no cap on packets per second, per source, or per session, and no state check to confirm that a legitimate reconnect is in progress.

Attack Vector

The vulnerability is exploitable over the network with no privileges or user interaction. An attacker sends a high volume of RECONNECT_REQUEST UDP packets to the relay's listening port. The relay forwards each packet to the configured host, amplifying the attacker's traffic and exhausting host CPU, socket buffers, or bandwidth. The scope is changed because the vulnerable relay impacts a separate host component.

See the GitHub Security Advisory GHSA-85rg-p3fr-xc2f for maintainer-provided technical details.

Detection Methods for CVE-2026-54609

Indicators of Compromise

- High volumes of UDP RECONNECT_REQUEST packets arriving at the QTI Neon relay from a single or small set of source addresses.
- Sudden spikes in relay-to-host UDP traffic that do not correlate with legitimate client session activity.
- Host process instability, dropped packets, or elevated CPU usage on the game host paired with relay forwarding bursts.

Detection Strategies

- Instrument the relay to log RECONNECT_REQUEST counts per source IP and alert on rates exceeding legitimate reconnect patterns.
- Deploy network flow monitoring (NetFlow, IPFIX, or eBPF) between relay and host to baseline normal UDP traffic and flag amplification ratios.
- Correlate relay ingress and egress packet counts; a widening egress-to-ingress ratio on control packets indicates abuse.

Monitoring Recommendations

- Forward relay and host logs to a centralized SIEM or data lake and build detections for anomalous RECONNECT_REQUEST bursts.
- Monitor UDP socket buffer errors and packet drop counters on the host operating system.
- Track EPSS movement for CVE-2026-54609 and adjust detection priority as exploit likelihood changes.

How to Mitigate CVE-2026-54609

Immediate Actions Required

- Restrict relay exposure by placing the QTI Neon relay behind a firewall or ACL that limits inbound UDP to known client ranges where feasible.
- Apply upstream UDP rate limiting on network devices for the relay's listening port to cap RECONNECT_REQUEST throughput.
- Isolate the host from untrusted networks and require the relay to be the only path to host UDP services.
- Audit application logs for prior signs of reconnect flooding and validate host stability.

Patch Information

No fixed version is available as of this review. Track the QTI Neon GitHub Security Advisory GHSA-85rg-p3fr-xc2f for a patched release. When a fix is published, upgrade beyond version 1.0.0 and validate that handleReconnectRequest enforces per-source and aggregate bounds.

Workarounds

- Implement an application-layer rate limiter in front of the relay that caps RECONNECT_REQUEST packets per source IP and per second.
- Drop or throttle unauthenticated reconnect traffic at the network edge using stateful UDP filtering.
- Temporarily disable the relay reconnect path if operationally acceptable, forcing clients to establish new sessions instead.
- Deploy the relay on infrastructure with UDP flood protection provided by the hosting network.

bash

# Example: iptables rate limit for RECONNECT_REQUEST UDP traffic on relay port
# Replace <RELAY_PORT> with the QTI Neon relay UDP port
iptables -A INPUT -p udp --dport <RELAY_PORT> \
  -m hashlimit --hashlimit-name qtineon_reconnect \
  --hashlimit-above 20/second --hashlimit-mode srcip \
  -j DROP