1. Exposure first: list Redis/Valkey instances reachable from outside their app tier (port 6379 and any custom ports) and any with no requirepass or ACL users beyond default. CVE-2026-25243 needs a login with RESTORE rights, so open or shared-password instances are the ones at risk.
2. Command counters: on each instance run INFO commandstats and look for cmdstat_restore. Outside migration, cluster resharding (MIGRATE sends RESTORE to the target) and backup-restore tooling, most app workloads never call RESTORE, so a non-zero count on a cache or queue box is worth explaining. Also check cmdstat_flushall and cmdstat_eval/cmdstat_evalsha.
3. The Defused sequence: one client connecting, issuing a burst of about 26 key writes, a single RESTORE, a short Lua EVAL, then FLUSHALL, repeating on a timer. If you log commands (proxy logs, MONITOR captures, or the ACL log), search for RESTORE followed within seconds by FLUSHALL from the same client. Unexplained empty keyspaces or sudden key-count drops in your metrics are another clue.
4. Crash signal: heap corruption attempts can crash redis-server. Look for unexpected restarts, segfault/"crashed by signal" entries in Redis logs, or core dumps since mid-October.
5. Host follow-up: if you see the pattern, treat the host as possibly compromised. Look for new child processes of redis-server, outbound connections from it, and changed dir/dbfilename config (CONFIG GET dir).

Defused publishes the full IOCs on its Radar console (sign-up required), so they aren't reproduced here.