CVE-2026-27623: 
Valkey vulnerability analysis and mitigation

CVE-2026-27623 is a pre-authentication denial-of-service vulnerability in Valkey, a distributed key-value database, caused by improper networking state reset after processing empty requests. Affecting versions 9.0.0 through 9.0.2, a remote unauthenticated attacker can send a specially crafted RESP (REdis Serialization Protocol) request that triggers a server-side assertion, causing the Valkey process to abort and shut down. The vulnerability was reported by NVIDIA Networking Security researchers Daniel Bransky and Eliya Cohen, and publicly disclosed on February 23, 2026. It carries a CVSS v3.1 base score of 7.5 (High) (GitHub Advisory, Red Hat Bugzilla).

The root cause is classified as CWE-20 (Improper Input Validation) and CWE-617 (Reachable Assertion): Valkey fails to properly reset its internal networking state after processing an empty request, leaving the server in an inconsistent state. When a subsequent malformed RESP request is received, the server incorrectly evaluates it as violating server-side invariants and triggers an assertion failure, resulting in process termination. The attack requires only network access — no authentication, privileges, or user interaction — and has low attack complexity, making it trivially exploitable against any exposed Valkey 9.0.x instance (GitHub Advisory).

Successful exploitation results in a complete denial of service: the Valkey server process aborts and becomes unavailable, impacting all applications and services that depend on it for data operations. There is no confidentiality or integrity impact — the vulnerability is purely an availability issue. In environments where Valkey serves as a critical caching or data layer, a crash can cascade to dependent services, causing broader application outages (GitHub Advisory, Percona Blog).

As of the time of disclosure, there is no public proof-of-concept exploit and no evidence of in-the-wild exploitation (Feedly). The EPSS score is approximately 0.136%, reflecting a low but non-negligible probability of exploitation in the near term. The vulnerability is not currently listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. No threat actor attribution has been reported. Detection coverage exists via Nessus (plugins 299876 and 301434) and Qualys (Feedly).

1. Reconnaissance: Identify internet-facing or network-accessible Valkey instances running versions 9.0.0–9.0.2 using network scanners (e.g., Shodan, Censys, or nmap targeting the default Valkey port 6379).
2. Establish connection: Open a TCP connection to the Valkey server on its listening port (default: 6379) without any authentication credentials.
3. Send empty request: Transmit an empty or zero-length RESP request to the server, causing Valkey to process it without properly resetting its internal networking state.
4. Send malformed RESP request: Immediately follow with a specially crafted malformed RESP request that the server, now in an inconsistent networking state, incorrectly identifies as violating server-side invariants.
5. Trigger assertion and crash: The server triggers an internal assertion failure and aborts, resulting in a complete denial of service for all connected clients and dependent applications (GitHub Advisory).

• Network: Unexpected TCP connections to Valkey port (default 6379) from untrusted or external IP addresses; connections sending zero-length or malformed RESP frames followed by abrupt disconnection.
• Logs: Valkey server logs showing assertion failure messages (e.g., Assertion failed) immediately before process termination; repeated server restart events in system logs (e.g., systemd or supervisord restart entries for the Valkey service).
• Process: Unexpected termination of the valkey-server process with a non-zero exit code or core dump generation; process monitoring alerts for the Valkey service going down.
• File System: Core dump files generated in the Valkey working directory following an assertion-triggered abort (GitHub Advisory, Red Hat Bugzilla).

The primary remediation is to upgrade Valkey to version 9.0.3 or later, which fixes the improper networking state reset (GitHub Advisory). As an interim workaround, isolate Valkey deployments using network-level access controls (firewalls, security groups, or VPC rules) to restrict access exclusively to trusted hosts and users. Organizations should also review Valkey's bind configuration to prevent exposure on public interfaces (Red Hat Bugzilla, Percona Blog).

Percona published a security advisory covering this and related Valkey CVEs, recommending immediate upgrades (Percona Blog). The vulnerability received brief coverage on social platforms including Mastodon and Bluesky shortly after disclosure. Microsoft's Security Response Center also catalogued the CVE (MSRC). Community reaction was measured, consistent with a high-severity but availability-only vulnerability with no public exploit code.