A critical security risk was discovered in the PHP-Memcached extension up to version 2.2.. This vulnerability, assigned CVE-2022-26635, stems from improper NULL termination in the way PHP-Memcached handles certain input. This flaw can be exploited by attackers to execute CLRF (Carriage Return Line Feed) Injection Attacks, potentially allowing them to tamper with memcached commands, disrupt data, or even take over certain application behaviors.

Let's break down what this vulnerability is, how it works, and how attackers can exploit it — using practical examples and easy wording.

About PHP-Memcached

PHP-Memcached is a popular PHP extension to interact with memcached — a high-performance, distributed memory object caching system, often used for speeding up dynamic web applications.

What Happened?

Older versions of PHP-Memcached did NOT properly terminate input strings with a NULL byte (\). In C and C++, strings are arrays terminated by a special \ character. If this termination is missing, other data can 'leak' into the variable, or extra bytes can be processed — _but not sanitized!_

This makes it possible for attackers to smuggle \r\n (carriage return + line feed, or CRLF), the key characters to start a new line in various network protocols. This kind of bug is the root of CLRF injection.

Why Is CLRF Injection Bad?

Most network protocols, including the memcached protocol, depend on \r\n to separate commands and data. If an attacker can insert these into a data stream, they can trick the server:

Exploitation Example

Let’s see this with a real-life scenario using PHP-Memcached.

Imagine the following Insecure Code

<?php
// Insecure: Directly setting a user-controlled key
$key = $_GET['id']; // Example: user passes ?id=foo123
$value = "This is a cached value.";
$memcached->set($key, $value);
?>

Problem: If a malicious user submits a specially crafted value as the key, like

foo\r\nset hacked_key   10\r\nmaliciousdata

If $key is not properly NULL-terminated, PHP-Memcached will send

set foo\r\nset hacked_key   10\r\nmaliciousdata  21\r\nThis is a cached value.\r\n

set hacked_key   10 and a new 10-byte value (maliciousdata)


Result: The attacker adds a new entry (hacked_key) with their own content, _in addition_ to whatever the application intended.

A minimal PHP code to illustrate

<?php
$memcached = new Memcached();
$memcached->addServer('127...1', 11211);

$malicious_key = "foo\r\nset injected   4\r\ntest\r\n";
$memcached->set($malicious_key, 'dummy');

// Now the 'injected' key exists in memcached, set via CLRF injection!
$value = $memcached->get('injected');
echo "Injected value: $value\n";
?>

If affected, "Injected value: test" will appear — showing the attacker managed to set a new key by abusing improper NULL termination.

Real Attack Vector

Attackers can use specially crafted HTTP parameters (think URLs or form submissions). If app code EVER takes untrusted input for memcached key/value and directly passes it to $memcached->set(), the vulnerability can be triggered.

Exploitation Steps

1. Discover user input passed into memcached key/value.

References and Resources

- NIST NVD: CVE-2022-26635 Details
- PHP-Memcached Github Issue
- Exploit-db Writeup
- Oasis Open: NULL termination
- memcached Protocol Text

Mitigation & Fix

- Update: Upgrade to PHP-Memcached v3.1. or later, where proper NULL termination is enforced for all input.
- Input validation: Filter and sanitize keys/values, strip or encode any CR (\r) and LF (\n) before passing to the memcached API.
- Audit: Search for any code that sets memcached keys/values with user-controlled input.

Summary Table

| Version            | Vulnerable? | Fix?              |
|--------------------|-------------|-------------------|
| <=2.2.            | YES         | Upgrade required  |
| >=3.1.            | NO          | Safe              |

Conclusion

CVE-2022-26635 is a classic example of how a simple mistake in string handling can open the door to protocol-level attacks, here using CLRF injection. These vulnerabilities can have a big impact — especially in apps relying heavily on caching layers exposed to user input.

If you use PHP-Memcached, make sure you are updated to the latest version, and never pass unsanitized, user-controlled strings as memcached keys or values.

Timeline

Published on: 04/05/2022 17:15:00 UTC
Last modified on: 04/18/2022 10:13:00 UTC