Redis CVE-2026-81934: Patch Matrix and DBA Remediation Runbook

DBA PARK may earn a commission from purchases through links in this article, at no extra cost to you.

Redis published an advisory on August 28, 2026 for CVE-2026-81934, a use-after-free vulnerability in TLS pending-data processing. Under specific conditions, an authenticated attacker may be able to trigger the flaw and potentially execute remote code. Redis updated the advisory on September 1, 2026 after the public CVE record was revised to a CVSS v4.0 score of 7.5 (High).

The operational response is straightforward: inventory every Redis endpoint, move each deployment to a fixed release, verify the running binary and topology after restart, and reduce the permissions and network paths available to application users. Disabling TLS is not an acceptable workaround.

What You’ll Learn: identify affected versions, select the correct fixed build, plan a low-risk upgrade for standalone, Sentinel, and Cluster deployments, verify the result, and apply compensating controls while patching is in progress.

1. What CVE-2026-81934 Means for Redis Administrators

The defect is in TLS pending-data processing. Redis states that exploitation requires authenticated access, broad permissions, coordinated TLS sessions, precise runtime conditions, and target-specific adaptation. Those requirements reduce exploitability, but they do not remove the need to patch. Successful exploitation could affect confidentiality, integrity, and availability.

Redis reported that it was not aware of active exploitation as of August 27, 2026. Treat that date precisely: it is not a guarantee about later activity. The September 1 scoring update also does not represent a new fix; it changes the severity assessment while the remediation remains the same.

Patch to a fixed release as soon as practical. Network isolation and ACL restrictions reduce exposure, but they do not repair the vulnerable code.

2. Fixed Versions

Redis lists the following fixed releases in its advisory.

Redis Cloud Essentials was already patched when the advisory was published. The August 28 advisory said remediation of Redis Cloud Pro subscriptions was underway, so Cloud Pro administrators should verify the current maintenance state in their account rather than assuming completion from the product name alone.

If your version family is not in the fixed-version table, do not assume that a numerically higher patch from an unsupported branch is safe. Move to a currently supported fixed branch using the vendor’s documented upgrade path.

3. Inventory the Running Version—not Just the Package Repository

Query every primary, replica, Sentinel-managed node, and Cluster node. The process that is actually serving traffic is the source of truth.

redis-cli -h redis01.example.internal -p 6379 INFO server \
  | sed -n 's/^redis_version://p' \
  | tr -d '\r'

For a TLS-only endpoint, use a trusted CA and your normal authenticated administrative connection. Do not place passwords directly on the command line or in shell history.

redis-cli --tls \
  --cacert /etc/redis/tls/ca.crt \
  -h redis01.example.internal -p 6380 \
  INFO server

Capture topology and persistence information before the change.

INFO replication
INFO persistence
ROLE
CLIENT LIST
ACL LIST

ACL LIST can expose password hashes and detailed access rules. Store the output as security-sensitive evidence and redact it before attaching it to an ordinary ticket.

For Redis Cluster, also capture:

CLUSTER INFO
CLUSTER NODES

Record the host, port, TLS/plaintext listener, version, role, shard, replica relationship, package or image identifier, and maintenance owner. A load balancer or Kubernetes Service can hide individual nodes, so inventory the backends rather than checking only the virtual endpoint.

4. Check a Version Against the Fixed Floor

The following local script checks the eight Redis Open Source release lines named in the advisory. It intentionally returns REVIEW for unlisted branches instead of guessing.

VERSION="$(redis-cli INFO server | sed -n 's/^redis_version://p' | tr -d '\r')"

python3 - "$VERSION" <<'PY'
import re
import sys

match = re.match(r"^(\d+)\.(\d+)\.(\d+)", sys.argv[1])
if not match:
    raise SystemExit("REVIEW: cannot parse the Redis version")

version = tuple(map(int, match.groups()))
fixed = {
    (8, 10): (8, 10, 1),
    (8, 8): (8, 8, 2),
    (8, 6): (8, 6, 6),
    (8, 4): (8, 4, 6),
    (8, 2): (8, 2, 9),
    (7, 4): (7, 4, 11),
    (7, 2): (7, 2, 16),
    (6, 2): (6, 2, 24),
}

floor = fixed.get(version[:2])
if floor is None:
    print(f"REVIEW: {version} is not on a release line listed in the advisory")
elif version >= floor:
    print(f"PASS: {version} is at or above fixed release {floor}")
else:
    print(f"PATCH: {version} is below fixed release {floor}")
PY

This is an inventory aid, not a substitute for a package or image provenance check. Confirm that the installed artifact came from a trusted vendor source and that the restarted process is using it.

5. Prioritize by Reachability and Privilege

Patch all affected deployments, but use the following factors to decide the order:

• TLS is enabled on a client, replication, or Cluster bus path.
• Affected endpoints are reachable from broad application networks, shared Kubernetes namespaces, partner networks, or the internet.
• Application users can run CLIENT KILL, Lua scripting commands, Pub/Sub commands, or access broad key/channel patterns.
• The deployment uses a shared or default user with +@all.
• Multiple tenants or less-trusted workloads share the same Redis service.
• The service holds authentication sessions, queues, payment state, secrets, or other high-impact data.

Redis should not be directly exposed to the internet. The official security guidance recommends allowing access only from trusted clients and using ACLs to mediate untrusted access.

6. Prepare a Safe Upgrade

Before touching production, complete these checks in a representative non-production environment:

1. Install the fixed build from the same package, container, or managed-service channel used in production.
2. Verify startup with the current configuration, modules, ACL file, TLS certificates, persistence files, and client libraries.
3. Run application smoke tests through the TLS endpoint.
4. Exercise failover and reconnection behavior if Sentinel or Cluster is used.
5. Confirm backup recoverability according to your existing Redis backup procedure.
6. Define a stop condition for replication lag, error rate, latency, or cluster health.

Do not rely on an image tag that can move. Record the immutable image digest or package checksum approved for the rollout.

7. Patch by Topology

Standalone Redis

Schedule a maintenance window unless the application can tolerate a restart. Confirm that the latest RDB snapshot or AOF state is healthy, stop writes according to the application runbook, replace the binary or image, restart Redis, and verify the new running version before reopening traffic.

Primary and Replica with Sentinel

Patch a replica first. Wait until master_link_status:up and the replication offset has caught up, then perform a controlled failover using the team’s established Sentinel procedure. Patch the former primary after it has rejoined as a replica. Do not restart the primary and its only healthy replica at the same time.

Redis Cluster

Patch one replica in each failure domain first, allow it to rejoin, and verify cluster_state:ok. Then roll masters one shard at a time using the platform’s supported failover mechanism. Maintain at least one healthy copy of every hash-slot range throughout the change. Cluster orchestration differs by package, operator, and managed service, so follow the vendor-specific procedure for promotion and replacement rather than improvising node-removal commands during an incident.

8. Apply Compensating Controls While Patching

The advisory recommends restricting network access, enforcing strong authentication and least-privilege ACLs, and removing unnecessary access to CLIENT KILL, Lua scripting, Pub/Sub, and associated keys or channels.

First, review the active users and connected clients.

ACL LIST
CLIENT LIST TYPE NORMAL
CLIENT LIST TYPE PUBSUB
ACL LOG 100

Avoid a blanket +@all policy for application users. Where the application does not require the relevant commands, remove them from its ACL. The exact rule must preserve the application’s required key and channel patterns.

ACL SETUSER app -client|kill -eval -evalsha -eval_ro -evalsha_ro -fcall -fcall_ro -publish -subscribe -psubscribe -ssubscribe -spublish

Test a proposed rule before rollout. ACL DRYRUN simulates authorization without executing the command.

ACL DRYRUN app CLIENT KILL TYPE NORMAL
ACL DRYRUN app EVAL "return 1" 0
ACL DRYRUN app PUBLISH security-test value

Apply only restrictions that match the real application contract. If the service legitimately uses Lua or Pub/Sub, isolate it to specific users, key patterns, channel patterns, and network paths instead of disabling functionality blindly.

Network controls should allow Redis ports only from explicit clients, replication peers, Sentinels, management hosts, and required health-check sources. Keep TLS enabled, verify certificate validation, and eliminate unused plaintext listeners when the application is ready.

9. Verify the Patch

Immediately after each node restarts, run the following checks through the same path used by applications:

PING
INFO server
INFO replication
INFO persistence
ROLE

For Redis Cluster, add:

CLUSTER INFO
CLUSTER NODES

Confirm all of the following:

• redis_version is at or above the fixed release for that branch.
• The node has the expected primary or replica role.
• Replication is connected and lag is within the normal range.
• cluster_state is ok and all expected slot ranges are covered.
• RDB or AOF status is healthy and no unexpected recovery occurred.
• TLS clients complete the handshake and authenticate successfully.
• Application reads, writes, expiration, Pub/Sub, streams, scripting, and modules behave as required.
• Latency, error rate, connection churn, memory, and CPU remain within the rollout stop conditions.

Retain the before-and-after version output, package or image digest, change time, node list, health checks, and approver as patch evidence.

10. Rollback Without Reintroducing the Vulnerability

Do not roll back to the vulnerable binary. If the selected fixed build causes a regression, keep the data and configuration at their known-good state while moving to another vendor-supported fixed build in the same compatible release family, or engage Redis support. Test downgrade compatibility before any emergency rollback because persistence formats, modules, and configuration defaults can change across release lines.

Restoring data from backup is not a security fix. A restored RDB or AOF file can recover data, but the running server remains vulnerable until the binary is patched.

11. Common Questions

Is a plaintext-only Redis endpoint affected?

The reported defect is in TLS pending-data processing, so TLS-enabled communication paths are the direct concern. Do not treat a plaintext-only observation as permission to defer indefinitely: verify every client, replication, and Cluster bus listener, and upgrade to a fixed build. Disabling TLS would trade one security problem for another.

Is authentication enough protection?

No. The advisory explicitly describes an authenticated attacker. Strong authentication remains necessary, but the response also requires patching, network restriction, and least privilege.

Should we disable Lua and Pub/Sub everywhere?

No. Remove only permissions the user does not need. Create separate users for separate workloads, restrict key and channel patterns, and test the result with ACL DRYRUN and application smoke tests.

Does the CVSS change reduce the urgency?

The public score was revised to 7.5 (High), but the impact can still include remote code execution under specific conditions. The fixed-version matrix and Redis’s advice to upgrade as soon as practical did not change.

Summary

CVE-2026-81934 is a high-severity Redis vulnerability in TLS pending-data processing. The durable response is to identify every running Redis version, upgrade to the fixed release for that branch, roll the change through replicas before primaries, verify the actual process and topology, and reduce network and ACL exposure. Compensating controls help during rollout, but only a fixed binary removes the vulnerable code.

Continue learning: After completing the remediation, you can build a broader Redis foundation: browse Udemy and search for Redis courses with exercises on data structures, persistence, and replication. To build a foundation in NoSQL data models and key-value databases, explore DataCamp.

Related DBA park Guides

• Best Database for RAG in 2026: SQL Server vs PostgreSQL vs MongoDB vs Redis vs DuckDB
• Essential Workflow for Software Troubleshooting

Official References

• Redis Security Advisory: CVE-2026-81934
• Redis security guidance
• Redis Open Source upgrade guidance
• Redis INFO command
• Redis ACL LIST command
• Redis ACL DRYRUN command
• Redis CLIENT LIST command