CVE-2026-93561: 
Memcached vulnerability analysis and mitigation

CVE-2026-93561 is a signed/unsigned integer type mismatch vulnerability in the io.netty/netty-codec-memcache library that causes frame desynchronization and response smuggling in the Memcache binary protocol codec. A malicious Memcache server can exploit this flaw by sending specially crafted responses that exploit the type mismatch, potentially exposing one client's data to another client's response stream in proxy or cache environments. The vulnerability affects io.netty:netty-codec-memcache versions >= 4.2.0.Final through <= 4.2.17.Final and <= 4.1.137.Final, and was disclosed on September 18, 2026. It carries a CVSS v3.1 base score of 6.5 (Medium) (GitHub Advisory, Red Hat Bugzilla).

The root cause is an integer signedness error: BinaryMemcacheRequestDecoder.java reads keyLength using readShort() (signed, range -32768..32767) and extrasLength using readByte() (signed, range -128..127), whereas the Memcache binary protocol specifies these fields as unsigned uint16 and uint8 respectively. When a malicious server sends extras_length = 0x80 (128 unsigned, interpreted as -128 signed), the condition extrasLength > 0 evaluates to false, so the extras bytes are not consumed from the wire buffer. Subsequently, the valueLength calculation (totalBodyLength - keyLength - extrasLength) produces an inflated result, causing the decoder to read 128 extra bytes from the next frame, permanently desynchronizing frame boundaries. All subsequent responses are then misinterpreted, enabling response smuggling where one client's data bleeds into another's response stream (Red Hat Bugzilla, GitHub Advisory). The suggested fix is to use readUnsignedByte() and readUnsignedShort() and store values in int fields.

Successful exploitation allows a malicious Memcache server to desynchronize frame parsing in the Netty codec, leading to response smuggling where data intended for one client may be inadvertently exposed to another client's response stream. This primarily affects confidentiality (partial data exposure) and integrity (injection of malicious or incorrect responses) in proxy or caching environments that use Netty's Memcache binary codec. Availability is not directly impacted, but the frame desynchronization can corrupt all subsequent responses in the affected connection, potentially disrupting application functionality (GitHub Advisory, Red Hat Bugzilla).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation as of the disclosure date (GitHub Advisory). The EPSS score is 0.0, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog. Exploitation requires the attacker to control or compromise a Memcache server that communicates with a vulnerable Netty-based client, making opportunistic mass exploitation less likely. The attack is automatable (no user interaction required) and requires no authentication, but the threat model is constrained to environments where a malicious or compromised Memcache backend is reachable (Feedly).

1. Identify target: Locate a proxy or caching application that uses io.netty:netty-codec-memcache (versions <= 4.1.137.Final or 4.2.0.Final–4.2.17.Final) to communicate with a Memcache backend using the binary protocol.
2. Control or compromise the Memcache server: Position as a malicious Memcache server (e.g., via DNS poisoning, BGP hijacking, or direct compromise of the backend) that the vulnerable Netty client connects to.
3. Craft a malicious response: Construct a Memcache binary protocol response with extras_length set to 0x80 (128 unsigned). The Netty codec will interpret this as -128 (signed), causing the extras bytes to not be consumed from the buffer.
4. Trigger frame desynchronization: The valueLength calculation will add 128 extra bytes to the read length, consuming bytes from the next frame. All subsequent frames are now misaligned.
5. Achieve response smuggling: In a multi-client proxy scenario, the desynchronized frames cause one client's response data to be delivered to a different client, exposing sensitive data or injecting attacker-controlled content into another client's response stream (Red Hat Bugzilla).

• Network: Unexpected or malformed Memcache binary protocol responses from backend servers, particularly responses with extras_length values of 0x80 or higher; anomalous response sizes inconsistent with request parameters.
• Logs: Application errors or exceptions in Netty-based services related to Memcache frame parsing, such as IndexOutOfBoundsException or buffer underflow errors in AbstractBinaryMemcacheDecoder; unexpected data appearing in client responses that does not match the original request.
• Application Behavior: Clients receiving responses intended for other clients (data leakage between sessions); corrupted or garbled Memcache responses following a specific response in a connection; sudden increase in Memcache decode errors or connection resets (Red Hat Bugzilla).

Apply the patch referenced in the GitHub Security Advisory (GHSA-wxrh-4rgq-pjcg / GHSA-7p33-hhxj-4qcr), which fixes the issue by replacing readShort()/readByte() with readUnsignedShort()/readUnsignedByte() in the affected decoder classes. Affected versions are io.netty:netty-codec-memcache >= 4.2.0.Final through <= 4.2.17.Final and <= 4.1.137.Final; upgrade to a fixed version once available. As a workaround, restrict network access to Memcache services so that only trusted, controlled servers can communicate with Netty-based clients, reducing the risk of a malicious server exploiting this flaw (GitHub Advisory, Red Hat Bugzilla).

Red Hat has acknowledged the vulnerability and opened a security response bug (Bug 2536949) with high priority and severity, involving a broad CC list of 37 engineers across multiple product teams including JBoss EAP and Red Hat build of Apache Camel (Red Hat Bugzilla). The GitHub Advisory Database has published the advisory (GHSA-7p33-hhxj-4qcr) with a Moderate severity rating. No significant public researcher commentary or social media discussion has been identified at this time.