Exposed with no password
The configuration behind essentially every public Redis compromise
bind 0.0.0.0 protected-mode no port 6379
Paste a redis.conf and get the problems that cause real incidents, in severity order. Each finding says what breaks, not merely that a setting differs from a default.
Or drop a file anywhere on this panel. Nothing is uploaded: the analysis runs in this tab.
The answer appears here
Paste on the left and press Lint. Nothing leaves this tab.
Nothing else to flag.
No formatting problems, and nothing the rules object to. Worth remembering what that covers: this reads the file you pasted, not the account or cluster it will be applied to.
No finding matches that filter.
Real input you can load into the tool above. Each one shows a different thing going wrong, because that is what the tool is for.
The configuration behind essentially every public Redis compromise
bind 0.0.0.0 protected-mode no port 6379
noeviction is the default, so this arrives by omission rather than by choice
requirepass hunter2 maxmemory 2gb
A restart loses everything, which is fine for a cache and not stated anywhere
requirepass hunter2 maxmemory 2gb maxmemory-policy allkeys-lru appendonly no save ""
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
protected-mode only refuses outside connections while there is no password and no bind. Adding a bind removes that guard, and an unauthenticated Redis on a network is remote code execution, not just a data leak.
Instead:Set requirepass or ACL users before changing bind or protected-mode.
noeviction is the default and refuses writes at the limit while reads keep working. For a cache that is an outage arriving by omission.
Instead:allkeys-lru or allkeys-lfu for a cache. Keep noeviction only where the data must not be dropped.
Those policies only evict keys that have a TTL. With no TTLs there is nothing eligible, so they behave exactly like noeviction and the failure looks like a broken policy.
Instead:Confirm keys actually get a TTL, or use the allkeys- variant.
Redis ships with defaults chosen for a developer laptop, not for a server. Most production problems come from a small number of them being left alone.
protected-mode refuses outside connections while there is no password and no bind, which contains a default install. Adding a bind line or turning protected-mode off removes that guard, and an unauthenticated Redis reachable from a network is remote code execution rather than merely a data leak: CONFIG SET dir plus SAVE writes a file anywhere the process can write.
With no limit Redis grows until the kernel's OOM killer terminates the process, losing everything not persisted. A limit turns that into either eviction or a clear OOM error to the client. Set it to roughly 60 to 70 percent of the host, because replication buffers, client output buffers and the fork that BGSAVE performs all live outside the limit.
noeviction is the default, and at the limit it refuses writes while reads keep working. For a datastore that is correct. For a cache it is an outage, and because it is the default it arrives by omission rather than by decision. The volatile- policies have a sharper version of the same trap: if no key has a TTL there is nothing eligible to evict, so they behave exactly like noeviction.
appendonly defaults to no, and save "" disables snapshots. Together they mean a restart loses everything. That is a reasonable choice for a cache and a serious one for anything else, and the file should say which it is.
It reads one file. It cannot see included files, command line arguments, runtime CONFIG SET changes, your network topology, or whether the port is actually reachable from anywhere dangerous. A clean result here means these particular rules found nothing, not that the deployment is safe.