We're very public and open about our infrastructure at Report URI, having written many blog posts about how we process billions of telemetry events every single week. As a result, it's no secret that we use Redis quite heavily across our infrastructure, and some have asked how the recent security vulnerability discovered in Redis has impacted us.

TLDR;

The short answer is that CVE-2025-49844 hasn't impacted us at all, largely because of our strict stance on security and existing measures that we already had in place. That said, any time something big happens in the industry that might have affected us, we take a look at how we might improve even further.

Immediate response

This advisory from Redis (GHSA-4789-qfc9-5f9q) is the first visibility I had into the issue and the specified workaround was to use the ACL feature in Redis to restrict access to the commands that might be abused.

An additional workaround to mitigate the problem without patching the redis-server executable is to prevent users from executing Lua scripts. This can be done using ACL to restrict EVAL and EVALSHA commands.

This is an easy protection to implement and I know we don't use the EVAL or EVALSHA commands, so we could get this in place immediately and deploy it across the fleet via Ansible.

# Disable use of the EVAL and EVALSHA commands
redis-cli ACL SETUSER {user} -EVAL -EVALSHA
# Persist the change to config so it survives restarts
redis-cli CONFIG REWRITE

With that in place, we can take a little more time to investigate the issue and plan for the upgrade from Redis 8.2.1 to 8.2.2 to properly resolve the problem.

Upgrading Redis

As fate would have it, ~2 months ago I published this blog post: We're going High Availability with Redis Sentinel! In that blog post, I described our new High Availability setup using Redis Sentinel to give us failover capabilities between our new Primary and Replica caches. I also explained how one of the major benefits of the upgrade would be that updating our Redis server binary becomes a whole lot easier, and here we are!

Our Redis Sentinels fronting our Primary and Replica caches

With our new HA setup, it's simply a case of updating and upgrading the Replica cache, promoting it to Primary, and then updating what previously was the Primary cache but is now a Replica. Done!

redis-cli info
# Server
redis_version:8.2.2
redis_git_sha1:00000000
redis_git_dirty:1
redis_build_id:8ade872ac64c6931
redis_mode:standalone
...

Existing protections and investigations

Our Redis caches reside on a private network and are not at any time accessible from the public Internet. Further to that, we have firewall rules in place to only allow known IP addresses on our private network to have access to the Redis caches. Just to go the extra distance, we then only allow our application servers with the appropriate roles to have access to the appropriate Redis caches that they require to fulfil that role! Our network access is already locked down as tight as we can get it and there is no anomalous network activity in our logs.

Looking at the Redis caches themselves, we can use commandstats to get per-command counters on how many times each command has been called against the cache since the server started. To reset the counters it would require access to restart redis-server or call CONFIG RESETSTAT, and the command counters all look aligned with typical volumes before the update. Running the command, we can see no indication of the counts being reset, and there are no instances of EVAL or EVALSHA being called on the servers.

Further Hardening

With some quick research looking at other powerful commands, I could see that we currently don't require the use of the SCRIPT or FUNCTION commands, so they presented themselves as another good opportunity to further reduce the commands available.

# Disable use of the SCRIPT and FUNCTION commands
redis-cli ACL SETUSER {user} -SCRIPT -FUNCTION
# Persist the change to config so it survives restarts
redis-cli CONFIG REWRITE

There are some other commands that I want to restrict, but they require further investigation to ensure there are no adverse effects. To wrap things up and make sure that all of these restrictions are working as intended, we can try to run some of the commands that should now be blocked.

redis-cli EVAL "return 1" 0
(error) NOPERM User default has no permissions to run the 'eval' command
redis-cli ACL LOG 1
1)  1) "count"
    2) (integer) 1
    3) "reason"
    4) "command"
    5) "context"
    6) "toplevel"
    7) "object"
    8) "eval"
    9) "username"
   10) "default"
   11) "age-seconds"
   12) "54.578"
   13) "client-info"
   14) "id=49 addr=*snip*:59092 laddr=*snip*:6379 fd=32 name= age=0 idle=0 flags=N db=0 sub=0 psub=0 ssub=0 multi=-1 watch=0 qbuf=35 qbuf-free=20439 argv-mem=13 multi-mem=0 rbs=16384 rbp=16384 obl=0 oll=0 omem=0 tot-mem=37797 events=r cmd=eval user=default redir=-1 resp=2 lib-name= lib-ver= io-thread=0 tot-net-in=35 tot-net-out=0 tot-cmds=0"
   15) "entry-id"
   16) (integer) 0
   17) "timestamp-created"
   18) (integer) 1760018943783
   19) "timestamp-last-updated"
   20) (integer) 1760018943783

The EVAL command was blocked as expected and the ACL LOG now has an entry to show that the block happened, which makes it easier to track the attempted usage of blocked commands in the future too.

With the fleet now updated to Redis 8.2.2, the additional protections in place, and no indication that we (or anyone else) were affected, I'm happy to consider this resolved!

That's a lot of data!

If you're curious just how much data we process, you can see my recent blog post Trillion with a T: Surpassing 2 Trillion Events Processed!🚀🚀 which covers the details. That blog post also announced the launch of our public dashboard that provides a live insight into our telemetry volumes, along with heaps of other interesting data, so check that out here too: Public Dashboard