Skip to content
HackIndex.io

Memcached Key Dump with stats cachedump

5 min read Created Feb 25, 2026 Last updated Feb 25, 2026

stats cachedump is the old-school slab-based key dump. It works against memcached servers that have not explicitly disabled it. Most production deployments either run a version where it is still enabled or have never changed the default.

Memcached organizes memory into slabs. Each slab class holds items of a similar size range. To enumerate keys, you first identify which slab classes are in use, then request a key listing per slab. This differs from lru_crawler metadump, which bypasses slab boundaries and dumps all keys in one pass.

Use stats cachedump when lru_crawler metadump returns nothing or is unavailable on the target version. It is useful in lab environments and older deployments running memcached below 1.4.31. No authentication is required by default, so unauthenticated access is the common case.

Notice

stats cachedump is treated as a last-resort debugging command in the memcached ecosystem. Prefer lru_crawler metadump when available.

Get active slab IDs

┌──(kali㉿kali)-[~]
└─$ printf "stats items\r\nquit\r\n" | nc -nv -w 3 $TARGET_IP ${PORT:-11211} | grep -Eo 'items:[0-9]+' | cut -d: -f2 | sort -nu

The output lists slab class IDs that currently hold at least one item. A slab with a high item count is worth targeting first. If multiple slabs are active, run cachedump against each one. Slab IDs are not predictable across deployments, so never skip any.

The count argument in the cachedump command caps results per request. Set it to 200 or higher to return as many keys as possible per slab. A value of 0 requests all items, but large slabs can time out or return truncated output on busy servers. 200 is a safe starting point.

Dump keys from a slab

Pick a slab ID from the previous output.

┌──(kali㉿kali)-[~]
└─$ SLAB_ID=1
┌──(kali㉿kali)-[~]
└─$ printf "stats cachedump $SLAB_ID 200\r\nquit\r\n" | nc -nv -w 3 $TARGET_IP ${PORT:-11211} 
ITEM session:9f3c... [248 b; 1700000000 s]
ITEM csrf:... [64 b; 1700000000 s]
END

Each ITEM line shows the key name, value size in bytes, and expiry as a Unix timestamp. A timestamp of 0 means the item never expires. High timestamps indicate long-lived keys. Those are your priority. They are more likely to hold session tokens, API keys, or config values that are actively in use.

Key name prefixes reveal the application's caching strategy:

  • session:, auth:, token: hold authentication material

  • config:, db: hold application configuration and credentials

  • cache:, view: contain rendered HTML or query results (low value)

Focus on authentication and config keys first.

Byte size gives a rough indication of content type. Keys under 100 bytes likely hold tokens, hashes, or flags. Larger entries hold serialized objects or blobs. Fetch the small keys first. They parse quickly and often contain credentials directly.

Pull values for dumped keys

Extract keys from cachedump output and fetch values:

┌──(kali㉿kali)-[~]
└─$ SLAB_ID=1
┌──(kali㉿kali)-[~]
└─$ KEYS=$(printf "stats cachedump $SLAB_ID 200\r\nquit\r\n" | nc -w 3 $TARGET_IP ${PORT:-11211} | awk '/^ITEM /{print $2}' | tr '\n' ' ')
┌──(kali㉿kali)-[~]
└─$ printf "get $KEYS\r\nquit\r\n" | nc -nv -w 3 $TARGET_IP ${PORT:-11211}

Common failure modes

Cachedump is disabled

When stats cachedump is disabled, the server returns an error line instead of ITEM entries. The response typically reads CLIENT_ERROR or ERROR. Some versions return an empty response followed by END with no items in between. Either way, you get no key names and the command is not usable on this server.

Cachedump does not return everything

Even when it works, it is not a complete dump. Memcached does not guarantee reliable key enumeration via this mechanism. The count argument limits results per slab, and slabs can contain more items than the cap. Run cachedump on every active slab ID, not just the first one. A slab may hold thousands of items. The command briefly locks the slab during enumeration, so busy servers may return fewer results in practice.

Memcached can also evict items between your stats items call and the stats cachedump call. Items that appeared in the first call may already be gone. This is more likely on high-traffic servers with small memory allocations. If a key shows in the dump but the subsequent get returns nothing, the item was evicted. Move on rather than retrying.

After collecting keys and values, check for serialized PHP objects, JSON blobs with credentials, or base64-encoded strings. Decode and deserialize before concluding there is nothing useful. Applications often store user objects, privilege flags, or session state in a format that does not read as plaintext at first glance.

If the target allows unauthenticated writes, consider whether cached values could be replaced to hijack sessions or escalate privileges. That crosses into exploitation. For this enumeration phase, focus on collecting what the cache exposes and noting key patterns that point to sensitive data.

References