Security Advisory · Published 2026-05-21

cPanel Redis CVE-2026-48172 Self-Check

CVSS 10.0. Redis socket on your cPanel box can give an attacker root. This is the third critical cPanel CVE this year. If you also handled the April wave (CVE-2026-41940), check this one before assuming the server is safe. The verification takes about 10 minutes with SSH access.

What CVE-2026-48172 does

Short version: the Redis Unix socket on default cPanel installs has overly permissive access. Any local user, compromised PHP process, or adjacent container can talk to Redis, use CONFIG SET and SAVE to write arbitrary files as root, and drop an SSH key or cron job. Game over. Full root. No password needed.

This isn't a new attack concept. Redis socket abuse has been a thing for years on standalone setups. What makes this one nasty is that cPanel's own privilege boundary is supposed to prevent exactly this kind of cross-user escalation, and it doesn't. Every shared hosting box running Redis for WordPress caching is a potential target.

Who's affected

If you run cPanel/WHM and any of these are true, you're in scope:

• Redis is enabled (check WHM > Service Manager)
• Any WordPress site uses object caching (WP Redis, Redis Object Cache, LiteSpeed Cache with Redis)
• WooCommerce session storage uses Redis
• You enabled Redis manually for any application

If Redis isn't running on your box, you're not affected by this specific CVE. But keep reading anyway because step 5 covers post-41940 persistence that's still relevant.

Step 1: Check if Redis is running

SSH into your server as root and run:

systemctl status redis
# or on older setups:
ps aux | grep redis-server

If Redis isn't running, you can skip steps 2-3 and go straight to step 4. If it is, keep going.

Step 2: Check Redis socket permissions

ls -la /var/run/redis/redis.sock
# or wherever your socket lives:
find / -name "redis.sock" -o -name "redis-server.sock" 2>/dev/null

What you want to see: the socket owned by redis:redis with permissions srwxrwx--- (770) or tighter. What you don't want: srwxrwxrwx (777) or ownership by root. If it's world-writable, any local user can talk to it.

Step 3: Check for Redis-based persistence

This is where an attacker would leave traces:

# Check if Redis was used to write files outside its data dir
redis-cli CONFIG GET dir
redis-cli CONFIG GET dbfilename

# Look for suspicious cron entries
ls -la /var/spool/cron/
cat /var/spool/cron/root
for user in $(ls /var/spool/cron/); do echo "=== $user ==="; cat /var/spool/cron/$user; done

# Check for rogue SSH keys planted via Redis
cat /root/.ssh/authorized_keys
diff <(sort /root/.ssh/authorized_keys) <(sort /root/.ssh/authorized_keys.bak 2>/dev/null || echo "no backup")

Red flags: cron entries you don't recognize, SSH keys you didn't add, Redis dir pointing to /root/.ssh or /var/spool/cron instead of its normal data directory.

Step 4: Verify your cPanel version

/usr/local/cpanel/cpanel -V
cat /usr/local/cpanel/version

Make sure you're on the latest build. If you're behind, update now:

/usr/local/cpanel/scripts/upcp --force

Step 5: Cross-check with CVE-2026-41940 IOCs

Here's why this matters: if your server got popped during the April 41940 wave and the attacker left a low-privilege backdoor (webshell, compromised PHP user), they now have a local escalation path to root through this Redis bug. Old backdoor + new priv-esc = full root again.

# .sorry ransomware files
find / -name "*.sorry" 2>/dev/null | head -20

# Mr_Rot13 Filemanager backdoor (binds on 8000-9999)
ss -tlnp | awk '$4 ~ /:8[0-9]{'{3}'}$/ || $4 ~ /:9[0-9]{'{3}'}$/'

# Suspicious binaries
find /tmp /var/tmp /dev/shm -type f -executable 2>/dev/null

# C2 domains in DNS cache or connection logs
grep -r "wrned\.com\|wpsock\.com" /var/log/ 2>/dev/null | head

Step 6: Harden Redis

Even after patching, lock down Redis so this class of attack can't recur:

# /etc/redis/redis.conf (or /etc/redis.conf)

# Bind to localhost only
bind 127.0.0.1

# Set socket permissions tight
unixsocketperm 770

# Disable dangerous commands
rename-command CONFIG ""
rename-command SAVE ""
rename-command BGSAVE ""
rename-command DEBUG ""
rename-command FLUSHALL ""
rename-command FLUSHDB ""

# Require a password (generate a random one)
requirepass $(openssl rand -hex 32)

Restart Redis after changes: systemctl restart redis

The rename-command trick is the real defense here. Even if someone reaches the socket, they can't use CONFIG SET to redirect file writes if the command doesn't exist anymore. Apply this hardening before treating the Redis socket as safe.

What to do if you find something

• Rogue SSH key in /root/.ssh/authorized_keys: Remove it immediately. Check /home/*/.ssh/authorized_keys too.
• Suspicious cron entry: Remove it, then check if it recreates itself (persistence loop).
• Redis dir pointed somewhere weird: Reset it to /var/lib/redis and investigate what files were written.
• .sorry files or Mr_Rot13 traces: You've got a bigger problem. See our full recovery playbook.

If you're not comfortable doing this yourself, Ping7 can review the output and walk through the repair path.

References

• NVD — CVE-2026-48172
• Ping7 CVE Watch: CVE-2026-48172
• Ping7 CVE Watch: CVE-2026-41940 (related)
• CVE-2026-41940 self-check
• Full cPanel recovery playbook

Ping7 is not affiliated with cPanel L.L.C., WebPros, or any hosting provider. All trademarks belong to their owners. This page references public CVE data only.