Return of the Living Dead: Swoole's SDS Integer Overflow

There is a special place in security hell for bundled dependencies. You know the drill: a developer finds a cool library (in this case, hiredis and its Simple Dynamic Strings, or SDS), copies the files into their thirdparty/ directory, and then completely forgets about them for a decade.

CVE-2026-24814 is exactly that story. In 2021, Redis fixed a critical heap overflow (CVE-2021-41099) in their SDS implementation. It was a big deal. Everyone patched. Well, everyone except the folks who had copy-pasted that code into their own projects and stopped tracking upstream changes.

Swoole, the high-performance coroutine-based PHP framework, was sitting on this time bomb until version 6.0.2. Because Swoole acts as an application server (unlike standard ephemeral PHP-FPM scripts), a successful exploit here doesn't just crash a request; it compromises the entire persistent process, giving an attacker a foothold that doesn't disappear when the HTTP connection closes.

The vulnerability lives in sdsMakeRoomFor, a function responsible for ensuring a string buffer has enough space to append more data. It sounds simple: take current length, add the new length, and reallocate.

Here is the logic that doomed us:

// len is current length
// addlen is what we want to append
newlen = (len + addlen);
// ...
newsh = s_realloc(sh, hdrlen + newlen + 1);

The problem is size_t wrapping. In C, if you add two large unsigned integers and they exceed the maximum value the type can hold (SIZE_MAX), they wrap around to a small number (modulo arithmetic).

If an attacker provides an addlen such that len + addlen wraps around to, say, 20, the s_realloc call will happily allocate a tiny chunk of memory (header + 20 bytes). However, the subsequent memcpy or append operation doesn't know about the wrap-around. It attempts to copy the full, massive addlen payload into that tiny 20-byte buffer. The result? A catastrophic heap overflow that overwrites adjacent memory chunks, metadata, and pointers.

The fix is embarrassingly simple, which makes the presence of the bug even more painful. The patch introduces a sanity check to ensure the addition won't overflow SIZE_MAX.

Here is the diff from the remediation:

 sds sdsMakeRoomFor(sds s, size_t addlen) {
     // ...
     len = sdslen(s);
     sh = (char*)s-sdsHdrSize(oldtype);
-    newlen = (len+addlen);
+
+    /* The Fix: Check for overflow before it happens */
+    if (addlen > SIZE_MAX - len) return NULL;
+    newlen = len + addlen;
     
     // ...
     hdrlen = sdsHdrSize(type);
-    if (oldtype==type) {
-        newsh = s_realloc(sh, hdrlen+newlen+1);
+    
+    /* The Fix: Ensure the header overhead doesn't cause overflow either */
+    if (hdrlen + newlen + 1 < newlen) return NULL;
+
+    if (oldtype == type) {
+        newsh = s_realloc(sh, hdrlen + newlen + 1);

Notice the explicit check: if (addlen > SIZE_MAX - len). Without this, the CPU blindly executes the wrap-around, and the allocator is tricked into handing out a thimble when we asked for a bucket.

Exploiting this on a modern allocator (like glibc's ptmalloc) is an exercise in "Heap Feng Shui." Since we control the size of the allocation (via the wrap-around) and the data being written (our payload), we have a powerful primitive.

The Attack Chain:

1. Grooming: The attacker sends several requests to Swoole to align the heap, placing a target object (like a function pointer or a PHP object representation) immediately after the chunk we are about to overflow.
2. The Trigger: We send a payload with a length calculated to wrap newlen to a small value (e.g., matching a specific tcache bin size).
3. The Smash: The allocator reserves the small chunk. The copy loop runs, blasting past the end of the chunk.
4. The Override: We overwrite the metadata of the next chunk. If we overwrite a zval (PHP variable) or a Zend Engine structure, we can fake an object type, leading to arbitrary code execution when the engine tries to destruct or access that variable.

Because Swoole runs as a daemon, we don't just crash a thread; we own the process memory. This allows for stealthy persistence and data exfiltration from other concurrent user requests.

It is rare to see a solid 10.0 CVSS score these days, but CVE-2026-24814 earns it.

Confidentiality: We can read memory (via heap manipulation) containing other users' session tokens, database credentials, or source code. Integrity: We can modify application state or inject backdoors into the running PHP process. Availability: At the very least, this is a trivial DoS. Send one packet, crash the server.

Since Swoole is often used for high-concurrency microservices and WebSockets, a single unauthenticated request from the internet can take down the core infrastructure or turn it into a botnet node. The lack of authentication requirements and the complexity of the attack (low, once the offset is known) makes this a "drop everything and patch" situation.

The only reliable fix is to upgrade swoole-src to version 6.0.2 or higher. This version includes the integer overflow checks in sds.c.

If you cannot upgrade immediately, you are in a tight spot. WAF rules might help if you can block request bodies larger than a certain size, but be warned: the overflow depends on len + addlen. An attacker could potentially build up len slowly with valid requests and then trigger the overflow with a smaller addlen that pushes it over the edge, evading simple "large body" detection rules.

Lesson Learned: If your project vendors third-party libraries, audit them. Don't assume code written 5 years ago is safe today.