Summary
KeyDB's source contains two security vulnerabilities that were silently fixed in Redis upstream (no CVE, no GHSA — discovered via commit log analysis). The fixes have not been ported to KeyDB.
Issue 1: Use-After-Free in RM_RegisterClusterMessageReceiver
Severity: HIGH (UAF, module-triggered)
Location: src/module.cpp line 6225
Redis fix: commit 303667a40cdf5032b1044e94dfc6860a15414e03 (Apr 23 2026)
When a module unregisters a cluster message receiver (callback = NULL), removing the head node updates the wrong pointer:
// src/module.cpp:6222-6225 (vulnerable)
if (prev)
prev->next = r->next;
else
clusterReceivers[type]->next = r->next; // BUG
zfree(r);
After zfree(r), clusterReceivers[type] still points to freed memory. Any subsequent traversal dereferences a dangling pointer.
Fix: Change clusterReceivers[type]->next = r->next; to clusterReceivers[type] = r->next;
Issue 2: Sentinel Config Injection via SENTINEL SET
Severity: HIGH (Code execution via config injection on Sentinel restart)
Location: src/sentinel.cpp sentinelSetCommand() line ~4001, especially auth-pass (4084-4089), auth-user (4090-4095), notification-script (4055-4063), client-reconfig-script (4064-4083)
Redis fix: commit 3e1afec688dc3f9354277ce6ad522996ebe4f2a6 (May 5 2026)
Type: CWE-93 → CWE-94
KeyDB's SENTINEL SET handler accepts arbitrary control characters (including \r\n) in user-controlled string fields and persists them to the Sentinel config file without escaping. An authenticated attacker with SENTINEL SET access can inject arbitrary config directives:
SENTINEL SET mymaster auth-pass "secret\\r\\nnotification-script /tmp/evil.sh"
On next Sentinel restart, the persisted config contains an injected notification-script line, which executes during failover events.
Fix path (from Redis):
- Add
sentinelStringContainsControlChars() — reject 0x00-0x1F and 0x7F at SENTINEL SET / MONITOR / CONFIG SET entry points
- Add
sentinelSdscatConfigArg() — use sdscatrepr when a value needs escaping (defense in depth)
References
Note: Reporting on GitHub since KeyDB has no SECURITY.md. Please advise if private channel preferred.
Summary
KeyDB's source contains two security vulnerabilities that were silently fixed in Redis upstream (no CVE, no GHSA — discovered via commit log analysis). The fixes have not been ported to KeyDB.
Issue 1: Use-After-Free in RM_RegisterClusterMessageReceiver
Severity: HIGH (UAF, module-triggered)
Location:
src/module.cppline 6225Redis fix: commit
303667a40cdf5032b1044e94dfc6860a15414e03(Apr 23 2026)When a module unregisters a cluster message receiver (callback = NULL), removing the head node updates the wrong pointer:
After
zfree(r),clusterReceivers[type]still points to freed memory. Any subsequent traversal dereferences a dangling pointer.Fix: Change
clusterReceivers[type]->next = r->next;toclusterReceivers[type] = r->next;Issue 2: Sentinel Config Injection via SENTINEL SET
Severity: HIGH (Code execution via config injection on Sentinel restart)
Location:
src/sentinel.cppsentinelSetCommand()line ~4001, especially auth-pass (4084-4089), auth-user (4090-4095), notification-script (4055-4063), client-reconfig-script (4064-4083)Redis fix: commit
3e1afec688dc3f9354277ce6ad522996ebe4f2a6(May 5 2026)Type: CWE-93 → CWE-94
KeyDB's SENTINEL SET handler accepts arbitrary control characters (including
\r\n) in user-controlled string fields and persists them to the Sentinel config file without escaping. An authenticated attacker with SENTINEL SET access can inject arbitrary config directives:On next Sentinel restart, the persisted config contains an injected
notification-scriptline, which executes during failover events.Fix path (from Redis):
sentinelStringContainsControlChars()— reject 0x00-0x1F and 0x7F at SENTINEL SET / MONITOR / CONFIG SET entry pointssentinelSdscatConfigArg()— usesdscatreprwhen a value needs escaping (defense in depth)References
Note: Reporting on GitHub since KeyDB has no SECURITY.md. Please advise if private channel preferred.