Redis Unauthenticated Exposure in Bug Bounty Programs

Redis Unauthenticated Exposure in Bug Bounty Programs

Redis speaks a simple protocol and forgives mistakes. Bind to 0.0.0.0, skip requirepass, forget protected-mode, and the internet gets a cache that may hold sessions, job payloads, or MFA state.

Your job is to prove reachability and impact without wiping the instance.

Detect and fingerprint

From an allowed network path (often public cloud IP space, sometimes SSRF to an internal host):

redis-cli -h target PING

PONG without auth is the headline. Follow with INFO server for version and OS hints, CONFIG GET requirepass only if policy permits config reads, and DBSIZE for scale.

Avoid KEYS * on large stores; it blocks Redis. Prefer SCAN with a small count if you must sample key names. Look for prefixes like sess:, sidekiq, bull:, or app-specific canaries you planted through the product.

Cloud security groups and "redis on a private VPC" stories fail when a managed instance got a public endpoint checkbox. Managed Redis with auth tokens still counts if the token is empty, default, or leaked beside the host in a config gist.

Protected mode should reject remote unauthenticated clients on stock builds. If you still get PONG from the internet, someone disabled it or bound the service in a way that bypasses the safeguard. Mention that explicitly; it shows you understand Redis defaults rather than cargo-culting scanner output.

Port 6379 on a shared bastion jump box is still Redis. Do not assume only dedicated cache hosts matter—developers leave local redis containers published during demos more often than anyone admits.

Impact without vandalism

Strong proofs:

• Read a session key belonging to your own account after you log in
• Show a queue payload containing a URL or token you triggered
• Write a unique key bugflare:<random> and read it back, then DEL it
• Demonstrate SLAVEOF is possible only on a disposable lab—describe replication abuse on production instead of executing it

Never FLUSHALL, never CONFIG SET dir toward web roots on customer hosts, never start miners. Those stunts destroy trust and sometimes the only copy of cache-backed data.

SSRF-to-Redis deserves a clear diagram: HTTP gopher/raw TCP quirks vary, and many modern SSRF filters block it. If you only get PONG through an app feature, document the exact request.

Module-loaded Redis (RedisJSON, RediSearch, and friends) can change which commands matter. Stick to boring proofs unless a module endpoint is clearly in scope and safer than CONFIG tricks.

Reporting tone

Explain what the exposed DB number held in your sample, whether writes worked, and which app feature consumes those keys. Recommend requirepass or ACL users, protected-mode yes, binding to private interfaces, TLS where supported, and renaming dangerous commands on older versions.

If the instance is used only as an ephemeral cache with no secrets, keep severity tempered but still report exposure—session fixation and cache poisoning remain on the table when writes succeed.

Redis security management docs cover ACL and protected mode. Pair that with your PONG transcript and triage usually moves fast.