CVE-2026-54609: 
JavaScript vulnerability analysis and mitigation

CVE-2026-54609 is a denial-of-service vulnerability in QTI Neon (QTINeon), a minimal relay-based UDP multiplayer protocol library developed by Quiet-Terminal-Interactive. The flaw exists in version 1.0.0 across all three implementations (Java, Python, TypeScript) of the NeonRelay component. An unauthenticated attacker can exploit unbounded RECONNECT_REQUEST forwarding to conduct relay-to-host amplification attacks, causing denial of service against the game host. It was first published on June 7, 2026 by KohanMathers and added to the GitHub Advisory Database on July 28, 2026. The vulnerability carries a CVSS v3.1 base score of 8.6 (High) (GitHub Advisory, Security Advisory).

The root cause is the handleReconnectRequest function in NeonRelay, which forwards every incoming RECONNECT_REQUEST packet to the host without enforcing a size cap on the pendingReconnects map — a guard (maxPendingConnections) that exists in the connect flow but was omitted from the reconnect flow (CWE-770, CWE-400, CWE-406). An attacker who knows a valid session ID can send RECONNECT_REQUEST packets from many spoofed source addresses; because the per-source rate limiter allocates a fresh token bucket for each new IP, it provides no protection against IP spoofing-based amplification. A secondary issue compounds the problem: once the number of spoofed IPs exceeds maxRateLimiters, performCleanup calls rateLimiters.clear(), resetting rate-limit state for all sources — including legitimate ones — effectively disabling the rate limiter entirely (Security Advisory, GitHub Advisory).

Successful exploitation causes a high-availability impact on the game host by flooding it with forwarded reconnect attempts, effectively denying service to legitimate players. Because the relay acts as an amplification vector and the host's real IP address is never exposed to clients by design, this amplification path represents the primary viable denial-of-service vector against the host. There is no confidentiality or integrity impact; the vulnerability is purely an availability concern with a changed scope, meaning the host (a component outside the relay's security boundary) is the entity harmed (GitHub Advisory).

1. Reconnaissance: Identify a publicly accessible QTINeon relay server (version 1.0.0) and obtain a valid session ID, which may be observable through normal client participation in a game session.
2. Craft spoofed UDP packets: Prepare a large number of RECONNECT_REQUEST UDP packets, each with a different spoofed source IP address but containing the same valid session ID.
3. Flood the relay: Send the spoofed RECONNECT_REQUEST packets to the relay at high volume. Each packet that passes the session lookup is forwarded to the host as a distinct reconnect attempt, since no deduplication or pendingReconnects size cap is enforced.
4. Exhaust rate limiter state: Once the number of unique spoofed IPs exceeds maxRateLimiters, the relay's performCleanup function calls rateLimiters.clear(), resetting all rate-limit state and removing any remaining protection for legitimate sources.
5. Achieve DoS on host: The host receives one forwarded packet per spoofed source per cleanup cycle, overwhelming it with reconnect attempts and causing denial of service — without the attacker ever learning the host's real IP address (Security Advisory).

• Network: Sudden spike in UDP traffic directed at the QTINeon relay on its listening port, originating from a large number of distinct source IPs (indicative of IP spoofing); unusually high volume of RECONNECT_REQUEST packets for a single session ID from many different source addresses.
• Logs: Relay logs showing repeated reconnect forwarding events for the same session ID from hundreds or thousands of unique source IPs within a short time window; log entries indicating rateLimiters.clear() being triggered frequently (signaling maxRateLimiters threshold being exceeded).
• Process/Resource: Abnormal memory growth in the relay process due to unbounded expansion of the pendingReconnects map; host-side logs showing a flood of reconnect validation requests from the relay (Security Advisory).

No patched version of QTINeon is currently available for any of the three package ecosystems (Maven com.quietterminal:qti-neon, pip qti-neon, npm qti-neon). The advisory describes the required fix as three changes to handleReconnectRequest: (1) reject requests when pendingReconnects.size() >= maxPendingConnections, (2) only forward to the host if the sessionId:clientId key is not already present in pendingReconnects, and (3) evict throttled entries in performCleanup before falling back to rateLimiters.clear(). As an interim workaround, operators should deploy the relay behind a network-level filter enforcing BCP38/uRPF to drop packets with spoofed source addresses, which eliminates the amplification path in most environments but does not address the missing size cap or rate-limiter reset issues (GitHub Advisory, Security Advisory).