Valkey 8.0 added hide-user-data-from-log, on by default, and many teams read that as "our Valkey logs are clean". The release notes say otherwise. Error replies still copied keys and values into the server log until 9.1.3, 9.0.7, 8.1.11 and 8.0.12 (late October 2026). On every GA release, a rejected AUTH, HELLO or MIGRATE shows its password in clear text to MONITOR; only the 9.2 release candidate redacts it. CONFIG GET primaryauth returns the replication password to anyone allowed to run CONFIG, and core files, RDB and AOF files and plain replication links carry the dataset itself. This post maps each path: what leaks, which version fixes it, and the control that closes it.
- Run 9.1.3, 9.0.7, 8.1.11 or 8.0.12 or later before you ship Valkey logs to a shared system. Valkey 7.2 has no
hide-user-data-from-logsetting. hide-user-data-from-logcovers the server log and crash report only.MONITOR,COMMANDLOG,SLOWLOG,CLIENT LISTandACL LOGignore it.- A malformed or rejected
AUTH,HELLOorMIGRATEleaks its password toMONITORon every GA release; 9.2.0-rc2 fixes it (#5180). A well-formedAUTHwith a wrong password is already redacted. CONFIG GETreturnsrequirepass,primaryauthand TLS key passphrases in plain text in 9.1.3 and 9.2.0-rc2. Keep@adminaway from application and monitoring users.
Scope and review date: November 2026. This post covers Valkey 7.2 to 9.1.3 GA and the 9.2.0-rc2 release candidate of 4 November 2026. Behaviour was checked on 10 November 2026 against the Valkey release notes, the valkey.io documentation, and the 9.1.3 and 9.2.0-rc2 source. The commands were not run in a lab, so rehearse them on staging.
Where can Valkey data and credentials leave the server?
Through eight paths: the server log and crash report, the MONITOR stream, the command log, CONFIG GET, the introspection commands, core files, persistence files and the replication link. Each has its own fix version and control. The card compares a default 9.1.3 install with a hardened one; each row has a section below.
Valkey 9.1.3 leak surface, default and hardened
Switch panels to see what each path exposes before and after the controls
9.1.3 defaults
| Path | What it exposes |
|---|---|
| Server log and crash report | User data hidden; client IP addresses still logged |
MONITOR | Every non-admin command with arguments; rejected AUTH passwords in clear |
COMMANDLOG and SLOWLOG | Arguments of any request over 1 MB or command over 10 ms |
CONFIG GET | requirepass, primaryauth and TLS key passphrases in plain text |
CLIENT LIST and ACL LOG | Client addresses, names and usernames, unredacted |
| Core dumps | Allowed by the OS limit; a core holds the dataset |
| RDB and AOF files | Full dataset, unencrypted |
| Replication and cluster bus | Plain TCP: the replica's AUTH and every write |
Hardened 9.1.3
| Path | What it exposes |
|---|---|
| Server log and crash report | User data hidden; client IP addresses still logged |
MONITOR | Denied to every user except a named operator account |
COMMANDLOG and SLOWLOG | Operator account only; large-request log off |
CONFIG GET | Denied to service users |
CLIENT LIST and ACL LOG | Operator account only |
| Core dumps | LimitCORE=0 |
| RDB and AOF files | Mode 0600 on an encrypted volume |
| Replication and cluster bus | TLS |
Unchanged row: no setting removes client IP addresses from the server log. If your policy treats IP addresses as personal data, handle that in the log pipeline, not in Valkey.
Record the exact version on every node first.
valkey-cli --user ops --askpass INFO server | grep -E '^(valkey_version|redis_version):'Interpretation: compare valkey_version with the tables below. redis_version is a fixed compatibility value, not the Valkey patch.
What does hide-user-data-from-log hide, and since which version?
The setting arrived in Valkey 8.0.0 (released 15 September 2024; added in 8.0.0-rc2 by PR #877) with a default of yes. The 9.1.3 valkey.conf describes it this way: "User data, including keys, values, client names, and ACL usernames, can be logged as part of assertions and other error cases." With the setting on, that data is hidden from the server log file. Valkey 7.2 does not have the setting. Later patches closed gaps in it:
| Fixed in | What still leaked before the fix |
|---|---|
| 8.1.0 (#1889) | Protocol-error log lines sampled the client's input buffer, which can hold user data |
| 8.0.10, 8.1.8, 9.0.5, 9.1.1 (#3872) | Key names and user data in RDB, networking, debug and hash log messages |
| 8.0.12, 8.1.11, 9.0.7, 9.1.3 (#4815) | The full error text a replica, primary, AOF-loading client or slot migration link received, such as an "unknown command" error echoing up to 128 bytes of arguments |
| 9.2.0-rc2 only (#5185) | A Lua server.log() message with line breaks could forge a log record that looks like a server line |
The #4815 fix is in the 9.1.3 release notes (26 October 2026), 9.0.7 (27 October), and 8.1.11 and 8.0.12 (26 October). The Lua fix matters for the default log-format legacy; logfmt and json already neutralised line breaks.
valkey-cli --user ops --askpass CONFIG GET hide-user-data-from-log
valkey-cli --user ops --askpass CONFIG GET log-formatInterpretation: the first must return yes; a no left over from an incident means every later assertion logs arguments and key names. The second shows legacy, logfmt (8.1) or json (9.1.0).
With the setting on, the 9.1.3 source still logs client IP addresses and ports, lib-name and command names. Only the logging code reads it, so it has no effect on MONITOR, COMMANDLOG, CLIENT LIST or ACL LOG.
If you turn it off to read a failing command, treat the log written in that window as customer data, and switch it back in the same change.
What do Valkey crash reports and core dumps expose?
On an assertion or fatal signal, Valkey writes a crash report to the server log (crash-log-enabled defaults to yes). It includes INFO OUTPUT, CLIENT LIST OUTPUT, the current client, the stack trace and registers. With hide-user-data-from-log yes, the 9.1.3 debug.c logs only each argument's byte length, writes key '*redacted*', redacts client names and users, and skips raw stack content. With it off, argument values and key names are printed, though the dump stops at an AUTH token.
# Illustrative shape of a 9.1.3 crash report with hide-user-data-from-log yes
------ CURRENT CLIENT INFO ------
id=1842 addr=10.0.1.15:51234 laddr=10.0.1.10:6379 fd=11 name=*redacted* ... cmd=hset user=*redacted* ...
argc: 4
argv[0]: "hset"
argv[1]: 9 bytes
argv[2]: 5 bytes
argv[3]: 17 bytes
key '*redacted*' found in DB containing the following object:Interpretation: the command name, argument sizes and client address survive. That is usually enough to match a known bug in the release notes.
Core files contain the dataset
The Valkey debugging guide asks for a core file when a crash report is not enough, and warns that a core "happens to contain all the data that was inside the Valkey instance at the time of the crash". After the report, Valkey re-sends the fatal signal to itself, so the kernel writes a core whenever the process's core limit allows one.
# Effective core limit of the running server, and where the kernel sends cores
grep -i 'core file size' /proc/$(pidof valkey-server)/limits
sysctl kernel.core_patternInterpretation: a soft limit of 0 means no core. Anything else means a crash can write the process memory to core_pattern; a pattern starting with | hands it to a handler such as systemd-coredump, which by default stores it under /var/lib/systemd/coredump/.
# /etc/systemd/system/valkey.service.d/no-core.conf
[Service]
LimitCORE=0
# /etc/systemd/coredump.conf.d/no-store.conf (host-wide)
[Coredump]
Storage=none
ProcessSizeMax=0Interpretation: LimitCORE=0 stops cores for the unit. Per the coredump.conf manual, Storage=none alone still writes the core to disk briefly unless ProcessSizeMax=0 is set. If one investigation needs a core, enable it on one node and delete the file afterwards.
Can MONITOR show passwords on Valkey?
Yes, in one case on every GA release. MONITOR streams every command with its arguments, so it shows customer data by design, and it needs @admin. Admin commands such as CONFIG SET requirepass never appear. AUTH, HELLO ... AUTH and MIGRATE ... AUTH appear with credentials replaced by "(redacted)", even when the password is wrong, because AUTH redacts before it checks it.
The gap is commands rejected before redaction runs. PR #5180 lists them: AUTH user pass extra, HELLO 4 AUTH user pass (unsupported protocol), a HELLO with a bad option before AUTH, and a MIGRATE with an unknown option before AUTH. call() feeds MONITOR and the command log even for failed commands, and the PR says every Valkey release is affected. The fix is in the 9.2.0-rc2 release notes, not 9.1.3, so on GA versions the control is ACL.
MONITOR and CONFIG GET on Valkey 9.1.3
Illustrative output: a well-formed AUTH is redacted, rejected AUTH and HELLO are not, and CONFIG GET returns the secret
What changes in 9.2: the two bold MONITOR lines show "(redacted)" from 9.2.0-rc2 (#5180). The CONFIG GET reply is the same in 9.1.3 and 9.2.0-rc2. Line formats follow the 9.1.3 source and the PR's examples; the values are invented.
# Prove that application and exporter users cannot open a MONITOR stream
valkey-cli --user ops --askpass ACL DRYRUN app MONITOR
valkey-cli --user ops --askpass ACL DRYRUN exporter MONITORInterpretation: you want User app has no permissions to run the 'monitor' command. OK means that user can watch every value. ACL DRYRUN checks without running the command. (The MONITOR page says both that AUTH "is excluded" and that it is "included"; the source includes it, redacted.)
Passwords on the client side
valkey-cli -a puts the password in the process list and shell history; use --askpass or VALKEYCLI_AUTH. Since 8.0.0, interactive valkey-cli keeps AUTH, ACL SETUSER and password CONFIG SET lines out of ~/.valkeycli_history.
What do COMMANDLOG and SLOWLOG keep about your data?
Per the 9.1.3 commandlog.c, each entry keeps the command and up to 32 arguments of 128 bytes each, plus the client address and name. COMMANDLOG arrived in 8.1.0; SLOWLOG reads the same slow log. hide-user-data-from-log does not apply. In the 9.1.3 valkey.conf, commandlog-execution-slower-than is 10000 microseconds, and the request and reply thresholds are 1048576 bytes, with 128 entries per log. Any request over 1 MB, such as a large SET, therefore stores its key and the first 128 bytes of its value in the large-request log, and any slow HSET stores its field values.
9.1.2 fixed redaction leaking between commands in a MULTI and missing for script commands (#4323, 9.1.2 release notes, listed for the 9.1 branch only). The #5180 leak reaches the command log too when an entry crosses a threshold.
# What is in the large-request log right now?
valkey-cli --user ops --askpass COMMANDLOG GET 5 large-requestInterpretation: each entry is an ID, timestamp, size, argument array, client address and client name (COMMANDLOG GET). If arguments hold emails or tokens, anything that scrapes this log handles customer data.
# Keep the slow log, stop capturing large writes, clear what is already there
valkey-cli --user ops --askpass CONFIG SET commandlog-request-larger-than -1
valkey-cli --user ops --askpass COMMANDLOG RESET large-requestInterpretation: -1 disables the large-request log; a higher threshold keeps it for outliers. Persist the choice in valkey.conf.
CLIENT LIST and ACL LOG
CLIENT LIST shows the last command's name, not its arguments, plus unredacted addr, name and user. ACL LOG keeps 128 entries by default, each with an unredacted client-info string. Both need @admin.
Does CONFIG GET return Valkey passwords in plain text?
Yes. In the 9.1.3 config.c, requirepass, primaryauth (alias masterauth), primaryuser, tls-key-file-pass and tls-client-key-file-pass carry a "sensitive" flag. That flag only redacts CONFIG SET arguments from logs, MONITOR and the command log. CONFIG GET, including CONFIG GET *, returns the stored value as is, and 9.2.0-rc2 behaves the same. The replica must send primaryauth, so it stays in plain text; the control is who can run CONFIG. The valkey-ldap module marks ldap.search_bind_passwd sensitive and hidden, so wildcards skip it; we did not test an exact-name CONFIG GET.
Where the replication password travels
Follow the numbers: steps 2 and 3 expose the password; step 4 shows it redacted
Two exposures, two controls: deny CONFIG to every user except operators for step 3, and set tls-replication yes for step 2. Nothing in Valkey hashes primaryauth.
valkey-cli --user ops --askpass ACL DRYRUN exporter CONFIG GET primaryauthInterpretation: expect User exporter has no permissions to run the 'config|get' command. If your exporter needs CONFIG GET for maxmemory, reconfigure it rather than grant +config|get.
For client passwords, avoid requirepass and define users in an ACL file. ACL SAVE and the ACL documentation's #<hash> rule store a SHA-256 hash instead of the password.
# /etc/valkey/users.acl (hash made with: read -rs P; printf '%s' "$P" | sha256sum)
user default off
user app on #<sha256-hex-of-app-password> ~app:* resetchannels +@all -@admin -@dangerous
user ops on #<sha256-hex-of-ops-password> ~* &* +@allInterpretation: removing @admin and @dangerous takes MONITOR, CONFIG, COMMANDLOG, CLIENT and ACL from app. Replace each placeholder with the 64-character hex hash. Our Valkey security hardening guide covers the full ACL user design.
Who can read Valkey RDB and AOF files and backups?
Anyone who can read the files can read the dataset. The 9.1.3 valkey.conf has no setting to encrypt RDB or AOF files, and they go to dir (./ in the shipped file). The upstream example systemd unit sets UMask=0077; packages and images choose their own, so check the result.
valkey-cli --user ops --askpass CONFIG GET dir
sudo stat -c '%a %U:%G %n' /var/lib/valkey /var/lib/valkey/* /var/lib/valkey/appendonlydir/*Interpretation: you want 700 on the directory and 600 on the RDB and AOF files, owned by the service user. A 644 file is readable by every local account.
Replicas default to repl-diskless-load disabled, so they write the sync RDB to disk; rdb-del-sync-files yes removes it only when RDB and AOF persistence are both off. Backups in object storage are full extracts too, so review their encryption and access policy.
Encryption at rest has to come from the volume: LUKS, encrypted cloud block storage or an encrypted storage class. That also covers sync files and stray cores.
Is Valkey replication traffic encrypted?
Not by default. In the 9.1.3 valkey.conf, "a replica does not attempt to establish a TLS connection with its primary", and "the cluster bus uses a plain TCP connection". Both tls-replication and tls-cluster default to no. A connecting replica sends AUTH with primaryauth, then receives the RDB and the live command stream, so a packet capture yields the password and every write. The Valkey security page says the same about client connections: AUTH "is sent unencrypted unless TLS is enabled".
# valkey.conf on every node (requires a build with TLS support)
port 0
tls-port 6379
tls-cert-file /etc/valkey/tls/valkey.crt
tls-key-file /etc/valkey/tls/valkey.key
tls-ca-cert-file /etc/valkey/tls/ca.crt
tls-replication yes
tls-cluster yesInterpretation: port 0 closes the plain-text port. Roll it out replicas first, and confirm master_link_status:up in INFO replication after each node.
How do you close each Valkey leak path, in order?
Patch first, because several leaks are code fixes. ACLs then close MONITOR, CONFIG GET, the command log and introspection in one change. OS and network controls come last.
Data-exposure hardening for Valkey 9.1.3
Nine steps; only step 9 needs a rolling restart
-
Reach the patch floor
9.1.3, 9.0.7, 8.1.11 or 8.0.12 carry the log redaction fix #4815. Plan 7.2 nodes onto 8.0 or later, because 7.2 has no redaction setting.
valkey-cli INFO server | grep valkey_version -
Confirm log redaction is on
It must return yes on every node, and valkey.conf must not set it to no.
valkey-cli CONFIG GET hide-user-data-from-log -
Remove @admin from service users
Applications, exporters and Sentinel get only the commands they call. One named operator account keeps @admin.
ACL SETUSER app -@admin -@dangerous ACL SAVE -
Prove it with ACL DRYRUN
Each line must return a "has no permissions" message, not OK.
ACL DRYRUN app MONITOR ACL DRYRUN exporter CONFIG GET primaryauth -
Retire requirepass
Move client passwords to hashed ACL file users, then turn the default user off.
-
Limit what the command log captures
Disable or raise the large-request threshold and clear old entries.
CONFIG SET commandlog-request-larger-than -1 COMMANDLOG RESET large-request -
Stop core dumps
Add LimitCORE=0 to the unit, and Storage=none with ProcessSizeMax=0 in coredump.conf.
sudo systemctl edit valkey sudo systemctl daemon-reload -
Lock down data files
Mode 0700 on dir and 0600 on RDB and AOF files, on an encrypted volume.
sudo chmod 700 /var/lib/valkey sudo chmod -R go-rwx /var/lib/valkey -
Turn on TLS for replication and the bus
Rolling restartReplicas first, then fail over and change the old primary. Check the replication link after each node.
tls-replication yes tls-cluster yes
Main risk: step 3 can break an exporter or Sentinel that relied on @admin. Run step 4 and read ACL LOG before you remove the old rules everywhere.
Record what remains: client IP addresses in the server log, and what the operator account can see through MONITOR.
Frequently asked questions
Does hide-user-data-from-log redact MONITOR and SLOWLOG in Valkey?
No. The setting only affects the server log and the crash report. MONITOR, COMMANDLOG, SLOWLOG, CLIENT LIST and ACL LOG return arguments, client names and usernames regardless of it. Passwords in AUTH, HELLO and MIGRATE are redacted separately in MONITOR and the command log, except when the command is rejected early, which 9.2.0-rc2 fixes.
Which Valkey version stops keys and values leaking into the server log?
Use 9.1.3, 9.0.7, 8.1.11 or 8.0.12 or later, with hide-user-data-from-log set to yes. Those October 2026 patches redact error reply text that could echo command arguments (#4815). Earlier patches closed other gaps. Valkey 7.2 has no redaction setting, so its logs can contain arguments and key names.
Can CONFIG GET show the Valkey replication password?
Yes. In 9.1.3 and 9.2.0-rc2, CONFIG GET returns primaryauth, requirepass and TLS key passphrases in plain text. The sensitive flag only hides them from CONFIG SET arguments in logs and MONITOR. Deny CONFIG to every account except operators, and check application and exporter users with ACL DRYRUN.
Does a failed AUTH show the password in Valkey MONITOR?
A well-formed AUTH with a wrong password is redacted. A malformed or rejected one, such as AUTH with an extra argument or HELLO with an unsupported protocol version, shows the password in clear text on every GA release up to 9.1.3. The fix is in the 9.2.0-rc2 release candidate. Until then, deny MONITOR to everyone except operators.
Should I disable core dumps for Valkey in production?
For most teams, yes. The Valkey debugging guide warns that a core file contains all the data in the instance. Set LimitCORE=0 for the service, and set Storage=none with ProcessSizeMax=0 for systemd-coredump. Enable cores on one node only for a specific investigation, and delete them afterwards.
Key takeaways
- Run at least 9.1.3, 9.0.7, 8.1.11 or 8.0.12 with
hide-user-data-from-log yesbefore logs leave the host, and move 7.2 nodes off a branch that has no redaction. - That setting does not cover
MONITOR, the command log,CLIENT LISTorACL LOG. ACLs that deny@adminto service users close all of them. - Rejected
AUTH,HELLOandMIGRATEcommands leak passwords toMONITORuntil 9.2 (release candidate today), andCONFIG GETreturns secrets in plain text on every version. - Core files, RDB files, AOF files and backups are full copies of the data. Disable cores, use 0600 files on encrypted volumes, and review backup storage.
- Set
tls-replication yesandtls-cluster yes, because the replica'sAUTHand every write travel in clear text otherwise.
Review your Valkey data exposure with JusDB
JusDB's Valkey support team can review where your servers send logs, which users can run MONITOR, CONFIG and COMMANDLOG, how crash evidence and core files are handled, and whether replication runs over TLS. We can also help you plan the patch and ACL changes in an order that does not break exporters or Sentinel.
Bring your versions, valkey.conf and ACL file with the secrets removed, and your log shipping setup. Your team approves every production change.