Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
☕
☕ Maven📦 npm🐍 PyPI
Not in CISA KEV
HIGH severity

CVE-2026-54609 — qti-neon

HIGH

CVE-2026-54609 is a high-severity (CVSS 8.6) Uncontrolled Resource Consumption vulnerability in com.quietterminal:qti-neon. No vendor fix is recorded yet; mitigation options are listed below.

QTINeon has unauthenticated relay-to-host amplification via unbounded RECONNECT_REQUEST forwarding

Also known asGHSA-85rg-p3fr-xc2fPYSEC-2026-3615
Published
Updated
Affected
3 pkgs
Patched
None yet
Exploits
None indexed
Exploitation data as of Oct 26, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

No confirmed exploitation observed yet

  • CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
  • CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.

Exploitation and automatability from CISA’s SSVC triage for CVE-2026-54609.

EPSS Exploitation Probability

via FIRST.org ↗
0.5%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs40th percentile — riskier than 40% of all scored CVEsHighest risk
0.00%0.32%0.64%0.96%0.3%0.3%0.5%0.5%Aug 26Oct 26Oct 26

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

How urgent is this, really

CVE-2026-54609 by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.

Where this sits among everything scored

Of 396,257 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.

Real-World Exposure

3 pkgs affected

How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.

0other npm packages depend on this — each one inherits the vulnerability until it's patched upstream
qti-neonnpm
6downloads / week

Description

Impact

The relay's reconnect handler forwards every RECONNECT_REQUEST to the host without deduplication or a size cap on the pendingReconnects map, unlike the connect flow which guards against this with maxPendingConnections. An unauthenticated attacker who knows a valid session ID can send RECONNECT_REQUEST packets from many spoofed source addresses; each packet that passes the session lookup is forwarded to the host as a new reconnect attempt. Because the per-source rate limiter assigns a fresh token bucket to each spoofed IP, it provides no protection. The host receives one forwarded packet per spoofed source per cleanup cycle, making the relay an amplification vector for denial-of-service against the host. The host's real address is never exposed to clients by design, so this is the primary viable DoS path against it. A secondary issue: once more than maxRateLimiters spoofed IPs are seen, performCleanup calls rateLimiters.clear(), resetting rate limit state for all sources including legitimate ones.

Affected: NeonRelay in all three implementations (Java, Python, TypeScript).

Patches

Not yet patched. Fix consists of three changes to handleReconnectRequest in each implementation:

  1. Reject the request if pendingReconnects.size() >= maxPendingConnections (mirrors the existing connect-flow guard)
  2. Only forward to the host if the sessionId:clientId key is not already present in pendingReconnects — the map entry can still be updated with the new source address, but the host only needs to validate once per slot
  3. In performCleanup, evict throttled entries before falling back to rateLimiters.clear() to avoid resetting legitimate sources' rate limit state

Workarounds

Operators can partially mitigate by placing the relay behind a network-level filter that drops packets with spoofed source addresses (BCP38/uRPF). This does not address the missing pendingReconnects size cap or the rateLimiters.clear() issue but eliminates the amplification path in most deployment environments.

References

  • PROTOCOL.md — reconnect flow
  • ARCHITECTURE.md — reconnect handshake detail (step 4 describes the unbounded put)

Affected Packages

3 total
EcosystemPackageVulnerable rangeFix
☕Mavencom.quietterminal:qti-neonall versionsNo fix
📦npmqti-neonall versionsNo fix
🐍PyPIqti-neonall versionsNo fix

Detection & mitigation playbook

Open-source dependency

  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for com.quietterminal:qti-neon, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Remediation status

    No patched version of com.quietterminal:qti-neon has shipped for CVE-2026-54609 yet. Where your build allows, override or pin the dependency away from the vulnerable range, and apply any maintainer-recommended mitigation.

  3. Mitigate without a patch

    Cap what an attacker can consume: apply request size, rate and timeout limits in front of the affected component, and run it with memory and CPU limits so exhaustion degrades one worker rather than the whole service.

Frequently Asked Questions

### Impact The relay's reconnect handler forwards every `RECONNECT_REQUEST` to the host without deduplication or a size cap on the `pendingReconnects` map, unlike the connect flow which guards against this with `maxPendingConnections`. An unauthenticated attacker who knows a valid session ID can send `RECONNECT_REQUEST` packets from many spoofed source addresses; each packet that passes the session lookup is forwarded to the host as a new reconnect attempt. Because the per-source rate limiter assigns a fresh token bucket to each spoofed IP, it provides no protection. The host receives one forw
O3 Security · Impact-Aware SCA

Is CVE-2026-54609 in your dependencies?

Find it across Maven, npm, PyPI, including transitive dependencies.

Scan my dependencies How O3 SCA works
CVE-2026-54609: qti-neon DoS (High 8.6)