Invalid Memory Access in Redis RESTORE Command

This repository is a compact exploit package for CVE-2026-25243, containing one Python PoC (exploit.py) plus README and a detailed technical writeup. The exploit is not part of a common framework. Its purpose is to achieve DEBUG-free remote code execution against vulnerable Redis by abusing a crafted RESTORE payload that triggers a silent jemalloc double-free during zipmap-to-listpack conversion. Repository structure: README.md gives scope, caveats, affected/fixed versions, and usage; WRITEUP.md explains the vulnerability, heap grooming, arbitrary-read primitive, deterministic offsets, and final control-flow redirection; exploit.py is the operational PoC using only Python stdlib. The Python script includes a build-specific PROFILE with offsets for luaRedisCallCommand, free@GOT, libc free/system, and two exploit-specific heap-relative offsets (OFF_FK and OFF_BLOBROBJ). It implements CRC64 and RDB payload generation for a valid RESTORE object, a minimal RESP client, retry logic, and the full exploit chain. Main exploit capability: remote command execution as the Redis process. The chain is: trigger double-free with RESTORE; groom allocator state so two class-64 allocations alias the same chunk; forge a set dictionary to create an arbitrary-read primitive via SMEMBERS; leak a Lua closure pointer using EVAL; derive PIE from clo+33, derive libc/system from free@GOT+1, and derive blob_base from blob_robj+11; place a fake dictType structure containing hashFunction=system into a large Redis blob; then forge a hash object's dict->type pointer so HGET h2 <cmd> becomes system(<cmd>). The exploit supports arbitrary shell commands via --cmd and retries multiple times because the author notes roughly 50-75% success per attempt. Fingerprintable targets/endpoints are primarily Redis network access on host:port (default 127.0.0.1:6379) and Redis command endpoints rather than HTTP URLs. The exploit requires command reachability to RESTORE, EVAL, SMEMBERS, HGET, CONFIG SET, SETRANGE, SADD, and SET. No external C2, download URL, or hardcoded remote IP/domain is present. The only explicit filesystem path observed is /tmp/pwned in the writeup as an example command redirection target. Overall, this is a real exploit PoC rather than a detector. It is operational but build-sensitive: the README explicitly warns that OFF_BLOBROBJ may require recalibration for the exact target build and allocation sequence. Despite that caveat, the code and documentation clearly implement an end-to-end Redis RCE technique for vulnerable pre-patch versions.

Repository contains a full exploit research package for CVE-2026-25243, a Redis RESTORE deserialization flaw in legacy zipmap handling that yields a heap over-read and a Redis-only double-free. The repo is not just documentation: it includes multiple Python PoCs covering the full progression from crash/DoS (`exploits/poc_dos_overread.py`), to double-free trigger (`exploits/poc_doublefree.py`), to silent heap overlap/type confusion (`exploits/poc_typeconfusion.py`), and finally several remote code execution variants (`exploits/poc_rce_aslr.py`, `poc_rce_aslr_nodebug.py`, `poc_rce_aslr_off.py`, `poc_rce_aslr_pie_rop.py`, `poc_rce_aslr_selfcal.py`). Core capability: the exploit sends crafted Redis RESP commands over TCP, especially `RESTORE key 0 <payload>`, where the payload is a malformed but CRC-valid serialized `RDB_TYPE_HASH_ZIPMAP` object. The malformed zipmap uses an overlong 5-byte length encoding that passes validation but causes `zipmapNext()` to mis-stride, leading to an over-read and, in Redis, a double-free in the hash zipmap loader. Under default jemalloc this double-free is silent, enabling deterministic heap overlap. The exploit then forges internal Redis dictionary structures to obtain arbitrary heap read and ultimately code execution. The main RCE paths are: (1) a `system()` path that forges `dict->type->hashFunction = system` and triggers execution via `HGET hd <cmd>`, keeping the worker alive; and (2) a more self-contained PIE/JOP/ROP path in `poc_rce_aslr_pie_rop.py` that avoids libc offsets entirely, leaks runtime addresses via `EVAL 'return tostring(redis.call)'` and heap over-read, derives PIE base from leaked pointers, pivots the stack through a forged dictType, and calls `execve@plt` with `/bin/sh -c <cmd>`. The latter is the most advanced exploit in the repo and targets default Redis with DEBUG disabled and ASLR enabled. Repository structure: `Dockerfile` builds a vulnerable Redis lab environment from a specific upstream commit and also produces an ASan build for crash demonstrations. `demo.sh` launches Redis and demonstrates that the bug is not DoS-only by proving heap overlap. `README.md` and `WRITEUP.md` provide detailed vulnerability and exploitation analysis, affected versions, mitigations, and reliability notes. `evidence/` and `screenshots/` contain proof logs showing ASan traces, overlap confirmation, ASLR-on RCE success, and repeated reliability runs. Fingerprintable targets and behaviors are centered on Redis TCP port 6379 and Redis commands such as RESTORE, EVAL, DEBUG OBJECT, SETRANGE, SMEMBERS, HSET, SADD, HGET, and CONFIG SET. Default proof commands write to `/tmp/pwned*` files. Overall, this is a genuine operational exploit repository demonstrating remote code execution against vulnerable Redis instances, not merely a detector or theoretical PoC.