VALKEY-SECURITY(7)

🌸 NAME 🌸

okay so bestie, this page is valkey-security — it's from the Valkey manual (manual name is VALKEY-SECURITY, section 7, if you're keeping track) and it's literally all about security. pull up a chair 💅

---

✨ DESCRIPTION ✨

so this doc is your lil intro to the whole security vibe from Valkey's point of view 👑 it covers the access control Valkey gives you, code security stuff to worry about, attacks that randos can trigger from the outside by feeding in malicious inputs, and other similar topics. the whole menu, basically 🍓

for security-related contacts? open an issue on GitHub, or when you feel it is really important to preserve the security of the communication, use the GPG key at the end of this document 🔐 (yes it's at the end, go scroll, iykyk)

🛡️ Security model

so here's the tea: Valkey is designed to be accessed by trusted clients inside trusted environments. which means... usually it is not a good idea to expose your Valkey instance directly to the internet 😭 or, like, in general to any environment where untrusted clients can directly access the Valkey TCP port or UNIX socket. do not do that. that's the vibe check failing fr fr.

for instance — and this is the classic scenario — in the common context of a web app that uses Valkey as a database, cache, or messaging system, the clients inside the front-end (the web side) of the app will query Valkey to generate pages or to perform operations requested or triggered by the web application user. normal! fine! that's the intended use 💖

in this case, the web application is the one mediating access between Valkey and the untrusted clients (aka the user browsers accessing the web app). the web app is your bodyguard 🫶

in general, untrusted access to Valkey should always be mediated by a layer implementing ACLs, validating user input, and deciding what operations to perform against the Valkey instance. always. no exceptions. periodt.

🌐 Network security

access to the Valkey port should be denied to everybody but trusted clients in the network — so the servers running Valkey should be directly accessible only by the computers implementing the application using Valkey. keep the circle small bestie 💅

in the common case of a single computer directly exposed to the internet, like a virtualized Linux instance (Linode, EC2, ...), the Valkey port should be firewalled to prevent access from the outside. clients will still be able to access Valkey using the loopback interface though, so you're not locked out ✨

and note that it is possible to bind Valkey to a single interface by adding a line like the following to the valkey.conf file:

bind 127.0.0.1

failing to protect the Valkey port from the outside can have a big security impact because of the nature of Valkey. like, for instance, a single FLUSHALL command can be used by an external attacker to delete the whole data set 💀 whole. entire. dataset. gone. not me crying.

🙈 Protected mode

unfortunately — and this is the sad part — many users fail to protect Valkey instances from being accessed from external networks 😭 many instances are simply left exposed on the internet with public IPs. girl. anyway.

Valkey enters a special mode called protected mode when it is executed with the default configuration (binding all the interfaces) and without any password in order to access it. in this mode, Valkey only replies to queries from the loopback interfaces, and it replies to clients connecting from other addresses with an error that explains the problem and how to configure Valkey properly 🎀

we expect protected mode to seriously decrease the security issues caused by unprotected Valkey instances executed without proper administration. however, the system administrator can still ignore the error given by Valkey and disable protected mode or manually bind all the interfaces 🫠 (sir. why.)

🔑 Authentication

Valkey provides two ways to authenticate clients:

1. the recommended authentication method is via Access Control Lists, allowing named users to be created and assigned fine-grained permissions. read more about Access Control Lists in valkey-acl(7) — here. go read it 💖
2. the legacy authentication method, enabled by editing the valkey.conf file, and providing a database password using the requirepass setting. this password is then used by all clients.

when the requirepass setting is enabled, Valkey will refuse any query by unauthenticated clients. a client can authenticate itself by sending the AUTH command followed by the password 👑

the password is set by the system administrator in clear text inside the valkey.conf file. it should be long enough to prevent brute force attacks, for two reasons:

• Valkey is very fast at serving queries. many passwords per second can be tested by an external client. ⚡
• the Valkey password is stored in the valkey.conf file and inside the client configuration. since the system administrator does not need to remember it, the password can be very long. 🐘

the goal of the authentication layer is to optionally provide a layer of redundancy. if firewalling or any other system implemented to protect Valkey from external attackers fail, an external client will still not be able to access the Valkey instance without knowledge of the authentication password. it's the backup plan 🫶

since the AUTH command, like every other Valkey command, is sent unencrypted, it does not protect against an attacker that has enough access to the network to perform eavesdropping. 👀 no cap, keep that in mind.

🔒 TLS support

Valkey has optional support for TLS on all communication channels, including client connections, replication links, and the Valkey Cluster bus protocol 🌈 all of them. every channel. slay.

💥 Attacks triggered by malicious inputs from external clients

there is a class of attacks that an attacker can trigger from the outside even without external access to the instance 😭 like, for example, an attacker might insert data into Valkey that triggers pathological (worst case) algorithm complexity on data structures implemented inside Valkey internals.

an attacker could supply, via a web form, a set of strings that are known to hash to the same bucket in a hash table in order to turn the O(1) expected time (the average time) to the O(N) worst case. this can consume more CPU than expected and ultimately cause a Denial of Service 💀

to prevent this specific attack, Valkey uses a per-execution, pseudo-random seed to the hash function 🎲

Valkey implements the SORT command using the qsort algorithm. currently, the algorithm is not randomized, so it is possible to trigger a quadratic worst-case behavior by carefully selecting the right set of inputs. (noted. be careful with those inputs bestie 🙈)

🧚 String escaping and NoSQL injection

the Valkey protocol has no concept of string escaping, so injection is impossible under normal circumstances using a normal client library 🎀 the protocol uses prefixed-length strings and is completely binary safe. iconic.

since Lua scripts executed by the EVAL and EVALSHA commands follow the same rules, those commands are also safe ✨

while it would be a strange use case, the application should avoid composing the body of the Lua script from strings obtained from untrusted sources 🫠 just don't.

🛡️ Code security

internally, Valkey uses all the well-known practices for writing secure code to prevent buffer overflows, format bugs, and other memory corruption issues 💪

Valkey does not require root privileges to run. it is recommended to run it as an unprivileged valkey user that is only used for this purpose 👑

---

okay that's the whole page bestie, go be safe out there 💖🦋

— with love, from the Valkey manual, version 9.0.0, dated 2025-10-21 🌸⭐