In this blog i will show you how i dissected redis source code in order to write a simple PoC for CVE-2023-28425. Furthermore some tips on how to read the source code of an open-source project in order to find vulnerabilities of known bugs are given. Finally i show you how i regularly use chatGPT to find more info about the target.



Redis is an open-source, in-memory data structure store that is widely used as a database, cache, and message broker. It was first released in 2009 and has since become one of the most popular NoSQL databases, thanks to its high performance, scalability, and flexibility. Overall, Redis is a powerful and versatile data store that has found widespread use in a wide range of applications and industries, from social media and e-commerce to finance and healthcare.


As described in the security advisory link, an authenticated users can use the MSETNX command to trigger a runtime assertion and termination of the Redis server process.

Of course the product owner does not want to expose further information regarding a vulnerability, as it should be. Our starting point will be the security advisor/cve bulletin. Assuming the security advisor is correct, we extract the following info:

  • affected versions >= 7.0.8
  • patch applied from version 7.0.10
  • the vulnerability is simple to trigger and only authenticated users can trigger it
  • after triggering the vulnerability it will be catched by a runtime assertion causing the redis servers to exit (DoS)
  • reporter who’ve discovered the vuln

info gathering

The first step should be called information gathering, and as the name suggest is the act of collecting knowledge. Of course you can directly go into the codebase, but personally i prefer spending more time on this part. The step is subdivided into:

  1. Search CVE on twitter/dorks/github/gitlab
  2. Look for keywords on github/gitlab issues and commits sections, in this case “MSETNX” could be a good candidate
  3. Follow social activities of the vuln reporter

During this phase i found: redis internals notes, CVE-2022-31144 POC.

code inspection

The step is subdivided in:

  1. Compare the patched version with the unpatched version that has the nearest version number to the patched one using git diff.
  2. Grep, do search by keywords
  3. Use a code navigation tool, for big projects use eclipse, otherwise vim+cscope is better (link)
  4. Ask chatGPT to be your assistant

Let’s do the first substep:

git diff 7.0.9 7.0.10

We try looking for the keyword “MSETNX”, and after inspecting the diff we find that a test case was added for “MSETNX with not existing keys - same key twice”, maybe that’s the vuln.

We ask about the MSETNX command and the vulnerability to chatGPT. To find good results we need to tell chatgpt to be our assistant. I do this like so: before making a question related to vulnerabilities, i prefix the following sentence: "As a <role> <adjective-role>, your are my assistant.", with <role> being for example as “Security code auditor, Security researcher, vulnerability researcher” and <adjective> “skilled, expert”, and so on. You can combine roles.

Now the question to chatGPT can’t be a simple “how to trigger CVE-2023-…”, (or isn’t it). Because in first place it will tell you that it does know nothing after Sept 2021 (like we believe it), and secondly the question could be labeled as a sensitive question and the answer will be restrictive or manipulated (e.g. tell me a joke about a man vs. tell me a joke about a woman).

I escape it like so: "I am analyzing <project-name> project which is hosted on github at <url>, and i have found the following vulnerability: "<vulnerability-description>". Can you explain it better and maybe give an example ?".

The final question used:

As security code auditor expert and skilled bug bounty hunter, your are my
assistant. I am analyzing redis project which is hosted on github here, and i have found the following vulnerability
"Authenticated users can use the MSETNX command to trigger a runtime assertion
and termination of the Redis server process.", can you explain better and maybe
give an example ?

build the test environemnt

# ubuntu 20.04 docker image
git clone
cd redis
git checkout 7.0.9
export CFLAGS="-g"
cd src

# run redis server
#gdb -ex "run" --args ./redis-server --port 7777
./redis-server --port 7777

# run client
./redis-cli -h -p 7777

Let’s try the poc given by chatgpt.

Let’s try the test case which was added on the patched version. Cool we found the vuln.

Vulnerability triaging (?)

Compile source code with “-g” symbol flag, then after triggering the program crash inspect function caller stack frame on gdb by up <#frame> and down <#frame> command. In our case we do up 4 and then we give context command to update gdb console view.

Cool we found where the runtime assertion happens. Let’s inspect the source code. In my case i am using cscope as follows:

# append this to bashrc or only for the current bash session
# Cscope config
export CSCOPE_EDITOR=`which vim`
alias cscope_cpp="find . -iname '*.cpp' -o -iname '*.c' -o -iname '*.h' -o -iname '*.hpp' -o -iname '*.cc' > cscope.files"
alias cscope_java="find . -iname '*.java' > cscope.files"
alias cscope_py="find . -iname '*.py' > cscope.files"
alias cscope_all="find . -iname '*.cpp' -o -iname '*.c' -o -iname '*.h' -o -iname '*.hpp' -o -iname '*.cc' -o -iname '*.java' -o -iname '*.py' > cscope.files"
alias cscope_database="cscope -q -R -b -i cscope.files"
alias cscope_Clean='rm cscope.po.out cscope.files cscope.out'

cd redis
cscope -d

We search on “Find this global definition” section, use “TAB” to move from/to query sections.

So back to dbAdd function. We conclude the assert happens because de != NULL is true.

/* Add the key to the DB. It's up to the caller to increment the reference
 * counter of the value if needed.
 * The program is aborted if the key already exists. */
void dbAdd(redisDb *db, robj *key, robj *val) {
    sds copy = sdsdup(key->ptr);
    dictEntry *de = dictAddRaw(db->dict, copy, NULL);
    serverAssertWithInfo(NULL, key, de != NULL);
    dictSetVal(db->dict, de, val);
    signalKeyAsReady(db, key, val->type);
    if (server.cluster_enabled) slotToKeyAddEntry(de, db);

Let’s inspect dictAddRaw function. With gdb we find that if ((index = _dictKeyIndex(d, key, dictHashKey(d,key), existing)) == -1) is true, which means the key is already present on the dictionary and so NULL is returned, which will trigger the assert condition explained before.

/* Low level add or find:
 * This function adds the entry but instead of setting a value returns the
 * dictEntry structure to the user, that will make sure to fill the value
 * field as they wish.
 * This function is also directly exposed to the user API to be called
 * mainly in order to store non-pointers inside the hash value, example:
 * entry = dictAddRaw(dict,mykey,NULL);
 * if (entry != NULL) dictSetSignedIntegerVal(entry,1000);
 * Return values:
 * If key already exists NULL is returned, and "*existing" is populated
 * with the existing entry if existing is not NULL.
 * If key was added, the hash entry is returned to be manipulated by the caller.
dictEntry *dictAddRaw(dict *d, void *key, dictEntry **existing)
    long index;
    dictEntry *entry;
    int htidx;

    if (dictIsRehashing(d)) _dictRehashStep(d);

    /* Get the index of the new element, or -1 if
     * the element already exists. */
    if ((index = _dictKeyIndex(d, key, dictHashKey(d,key), existing)) == -1)
        return NULL;

    /* Allocate the memory and store the new entry.
     * Insert the element in top, with the assumption that in a database
     * system it is more likely that recently added entries are accessed
     * more frequently. */
    htidx = dictIsRehashing(d) ? 1 : 0;
    size_t metasize = dictMetadataSize(d);
    entry = zmalloc(sizeof(*entry) + metasize);
    if (metasize > 0) {
        memset(dictMetadata(entry), 0, metasize);
    entry->next = d->ht_table[htidx][index];
    d->ht_table[htidx][index] = entry;

    /* Set the hash entry fields. */
    dictSetKey(d, entry, key);
    return entry;


In the end the vulnerability is caused by declaring a new key twice on the same MSETNX command executed. In particular the vuln is present on msetGenericCommand function which is called while parsing MSETNX k1 val1 k1 val2 command. Because nx is not equal to 0, and because none of the keys declared by the command is present on the db, then setkey_flags |= SETKEY_DOESNT_EXIST; happens. Then we loop on each key declared and we use the same setkey_flags, setKey(c, c->db, c->argv[j], c->argv[j + 1], setkey_flags);. Which is correct for the first declaration k1 val1, but wrong for k1 val2 as k1 was alredy declared and should not have SETKEY_DOESNT_EXIST bit set on setkey_flags.

void msetGenericCommand(client *c, int nx) {
    int j;
    int setkey_flags = 0;

    if ((c->argc % 2) == 0) {

    /* Handle the NX flag. The MSETNX semantic is to return zero and don't
     * set anything if at least one key already exists. */
    if (nx) {                                                               // [0]
        for (j = 1; j < c->argc; j += 2) {
            if (lookupKeyWrite(c->db,c->argv[j]) != NULL) {
                addReply(c, shared.czero);
        setkey_flags |= SETKEY_DOESNT_EXIST;                                // [1]

    for (j = 1; j < c->argc; j += 2) {
        c->argv[j+1] = tryObjectEncoding(c->argv[j+1]);
        setKey(c, c->db, c->argv[j], c->argv[j + 1], setkey_flags);         // [2]
    server.dirty += (c->argc-1)/2;
    addReply(c, nx ? shared.cone : shared.ok);

Diff patch:

diff --git a/src/t_string.c b/src/t_string.c
index af58d7d54..4659e1861 100644
--- a/src/t_string.c
+++ b/src/t_string.c
@@ -561,7 +561,6 @@ void mgetCommand(client *c) {

 void msetGenericCommand(client *c, int nx) {
     int j;
-    int setkey_flags = 0;

     if ((c->argc % 2) == 0) {
@@ -577,12 +576,11 @@ void msetGenericCommand(client *c, int nx) {
-        setkey_flags |= SETKEY_DOESNT_EXIST;

     for (j = 1; j < c->argc; j += 2) {
         c->argv[j+1] = tryObjectEncoding(c->argv[j+1]);
-        setKey(c, c->db, c->argv[j], c->argv[j + 1], setkey_flags);
+        setKey(c, c->db, c->argv[j], c->argv[j + 1], 0);
     server.dirty += (c->argc-1)/2;

What’s next

Where can i learn more? no prob i got you. Here you can follow some path to enhance your knowledge on vuln research and code auditing:

Hope you enjoyed and see you soon.