In May 2026, Redis patched CVE-2026-23479, a use-after-free vulnerability affecting its blocking client processing logic. Under specific conditions, an authenticated attacker may be able to trigger remote code execution (RCE) on the host system running the Redis server.
CVE-2026-23479 remained in stable Redis releases for nearly two years after being introduced in Redis 7.2.0 and persisted until the release of Redis 8.6.3. The vulnerability gained attention because it was discovered during the validation process of an autonomous AI security tool. While it is not an unauthenticated vulnerability, environments where Redis is exposed to the internet or where application accounts possess excessive privileges may still present a practical attack surface.
This article examines the technical root cause of CVE-2026-23479 and explores how Criminal IP can be used to identify internet-exposed Redis assets and potentially vulnerable instances.
CVE-2026-23479 Vulnerability Overview
| Category | Description |
|---|---|
| Vulnerability ID | CVE-2026-23479 |
| Affected Product | Redis / redis-server |
| Affected Version | Redis 7.2.0 through 8.6.2 |
| Vulnerability Type | Use-After-Free |
| Attack Requirements | Authenticated attacker |
| CVSS Score | NVD CVSS 3.1: 8.8 High / Redis CVSS 4.0: 7.7 High |
| Patched Version | 7.2.14, 7.4.9, 8.2.6, 8.4.3, 8.6.3 |
The vulnerability affects Redis versions 7.2.0 and later, but earlier than 8.6.3. Rather than checking for a specific version alone, organizations should verify whether their deployed Redis branch has been upgraded to one of the recommended patched releases.
Technical Root Cause: Unblock Client Flow and Use-After-Free
Redis allows certain commands to place clients into a temporary blocked state. For example, operations involving lists, streams, or sorted sets may pause execution until required data becomes available. Once conditions are met, the blocked client is returned to the normal execution flow. CVE-2026-23479 occurs during this resumption process. Redis’s unblock client flow invokes ‘processCommandAndResetClient( )’ when handling previously blocked clients. Under specific conditions, however, a client object may be freed while an existing pointer continues to reference it, resulting in a use-after-free condition.
A use-after-free vulnerability occurs when software continues to access memory that has already been released. In this case, attackers may manipulate Redis blocking command workflows to create abnormal memory reuse conditions and potentially execute code with the privileges of the Redis process. The core issue is that the client object’s state is not always accurately reflected during the transition between being released and being reprocessed. As a result, actual risk depends not only on the Redis version but also on factors such as command permissions and data-write privileges assigned to Redis accounts.
Why the Vulnerability Remained Hidden for Two Years
According to public analysis, the bug was difficult to identify during code review because the return value of the ‘processCommandAndResetClient( )’ function was typically used in contexts where explicit validation was not considered necessary. The vulnerability only manifests when multiple conditions align simultaneously, including specific memory pressure scenarios, such as exceeding the maxmemory-clients limit, and precise timing involving blocking commands. As a result, it is difficult to reproduce through conventional functional testing or routine code reviews.
The discovery of this vulnerability by Xint Code is considered a notable example of how autonomous AI security tools can effectively analyze complex chains of conditions across large codebases and uncover vulnerabilities that may remain hidden from traditional review methodologies.
Attack Flow: From Internet-Exposed Redis to Remote Code Execution
CVE-2026-23479 requires an authenticated attacker. However, real-world attack conditions can emerge when externally exposed Redis instances are combined with weak credentials, shared accounts, excessive ACL permissions, or outdated software versions.
A potential attack scenario may proceed as follows:
- An attacker identifies internet-exposed Redis instances through large-scale scanning.
- Potential targets are selected based on banner information, open ports, version details, and authentication requirements.
- The attacker gains access using leaked credentials, weak passwords, shared accounts, or overly privileged application accounts.
- Blocking commands such as XREAD BLOCK are combined with MULTI/EXEC operations to manipulate eviction timing and trigger a use-after-free condition within ‘unblockClientOnKey’.
- The attacker attempts to execute code with the privileges of the Redis process.
- Session data, cached information, internal service details, and application connection information may then be collected, or the attacker may pivot to other services on the same host.
The most important factor is often not the vulnerability itself, but the environment in which Redis operates. If Redis is tightly integrated with internal services and shares infrastructure with exposed management interfaces or web services, the impact of a compromise can expand significantly.
Redis Exposure Analysis Through Criminal IP
Using Criminal IP Asset Search, organizations can identify internet-exposed Redis assets and evaluate risk based on service ports, banners, version information, and vulnerability mappings. This visibility allows security teams to prioritize exposed Redis instances, determine whether vulnerable versions are present, and identify environments where excessive permissions or external accessibility may increase the likelihood of successful exploitation.
Criminal IP Search Query: product: Redis
Using the Redis product filter in Criminal IP, approximately 74,000 Redis-related assets were identified as of June 2026. This demonstrates that Redis services continue to be widely discoverable across the public internet. Redis typically operates on port 6379. If Redis is publicly accessible on port 6379, or if services such as SSH, web management interfaces, databases, or monitoring tools are exposed on the same IP address, the environment should be considered a compound risk rather than a single-vulnerability concern.
Identifying Assets Potentially Affected by CVE-2026-23479
To identify Redis assets associated with CVE-2026-23479, the following query can be used.
Criminal IP Search Query: cve_id: CVE-2026-23479
Using the cve_id filter in Criminal IP Asset Search, approximately 16,090 potentially vulnerable assets associated with CVE-2026-23479 were identified as of June 2026. This allows organizations to prioritize externally exposed Redis instances that may be affected by the vulnerability.
The top country distribution was as follows:
- Japan: 4,772 assets
- United States: 2,970 assets
- China: 1,886 assets
- France: 1,134 assets
- Germany: 873 assets
These findings suggest that potentially vulnerable Redis instances are not concentrated in a single region but are distributed across major cloud and hosting infrastructures worldwide.
Because CVE-based search results depend on factors such as banner information, version identification, and vulnerability database mappings, the results should be treated as a prioritized list of potentially affected assets. Organizations should validate findings against their internal asset inventories and confirm actual Redis versions deployed in production.
Identifying Vulnerable Redis Versions
CVE-2026-23479 affects Redis versions 7.2.0 through 8.6.2. Among these, Redis 8.6.2 represents the final vulnerable release in the 8.6.x branch prior to the security fix and can be considered a representative affected version.
Criminal IP Search Query: redis_version:8.6.2
Criminal IP provides a redis_version filter that can be used to identify assets running specific Redis versions.
Search results identified 2,166 assets running Redis 8.6.2. Because these assets fall within the affected version range of CVE-2026-23479, organizations operating externally exposed Redis instances on this version should prioritize upgrading to Redis 8.6.3 or later, or to the appropriate patched release within their respective Redis branch.
The recommended patched versions for each Redis branch are as follows:
| Redis Branch | Affected Versions | Recommended Patched Version |
|---|---|---|
| 7.2.x | 7.2.0 ~ 7.2.13 | 7.2.14 or later |
| 7.4.x | 7.4.0 ~ 7.4.8 | 7.4.9 or later |
| 8.2.x | 8.2.0 ~ 8.2.5 | 8.2.6 or later |
| 8.4.x | 8.4.0 ~ 8.4.2 | 8.4.3 or later |
| 8.6.x | 8.6.0 ~ 8.6.2 | 8.6.3 or later |
IP Report: Understanding the Compound Risks of Redis Assets
Criminal IP’s IP Report provides a comprehensive view of a Redis asset, including open ports, service banners, vulnerabilities, risk scores, and hosting information.
In one example asset, the Inbound Risk Score was rated Dangerous (80.0%), with 12 open ports and 18 identified vulnerabilities. In addition to Redis’s default port 6379, services running on SSH, HTTP/HTTPS, ports in the 3000, 5000, 8000, and 9000 ranges were also exposed, indicating a broader attack surface beyond a standalone Redis deployment. The vulnerability list included not only CVE-2026-23479 but also RediShell (CVE-2025-49844), a Redis RCE vulnerability disclosed in 2025. This demonstrates that internet-exposed Redis assets may accumulate multiple vulnerabilities over time rather than being affected by a single newly disclosed CVE.
For this reason, Redis security assessments should not stop at determining whether port 6379 is exposed. Organizations should also evaluate co-hosted services, accumulated CVEs, hosting environments, and remote accessibility to accurately assess the overall attack surface.
Recommended Mitigation Measures
- Apply Redis Security Updates
The highest-priority mitigation is to upgrade Redis to a patched version. Organizations should verify that their Redis deployments have been updated to the recommended fixed releases for their respective branches: 7.2.14, 7.4.9, 8.2.6, 8.4.3, or 8.6.3 and later. For Redis Cloud customers, patches may have already been applied through managed service updates. However, it is recommended to confirm the update status with the cloud provider. - Restrict External Redis Exposure
Redis generally does not need to be directly accessible from the public internet. Organizations should review firewalls, security groups, and network ACLs to ensure that port 6379 is not reachable from public IP addresses. Redis instances that do not require external access should be restricted to internal networks, VPNs, or private subnets. - Review Redis ACLs and Command Permissions
Because CVE-2026-23479 requires an authenticated attacker, account permissions play a critical role in the overall risk. If application accounts have access to commands such as XREAD BLOCK, BLPOP, BRPOP, CONFIG, or EVAL, along with broad read/write privileges, exploitation conditions may be easier to satisfy. Organizations should apply the principle of least privilege, granting service accounts only the permissions they require and separating administrative accounts from application accounts. - Audit Credentials and Default Accounts
Even when authentication is enabled, weak passwords or long-shared credentials can increase the likelihood of compromise. Organizations should review:- Use of default accounts
- Reuse of previously leaked passwords
- Legacy employee or contractor accounts
- Shared service credentials
- Continuously Monitor Redis Assets
Even after patching, Redis assets may become exposed again due to operational changes, cloud security group misconfigurations, or forgotten test environments. Using Criminal IP Asset Search filters such as product, cve_id, and redis_version, organizations can continuously identify:- Internet-exposed Redis assets
- Vulnerability-mapped Redis instances
- Assets running specific vulnerable Redis versions
FAQ
Q1. Is CVE-2026-23479 an unauthenticated RCE vulnerability?
No. CVE-2026-23479 requires an authenticated attacker. However, environments with weak credentials, shared accounts, or excessive ACL permissions may unintentionally satisfy the attack prerequisites.
Q2. Is Redis 8.6.2 the only vulnerable version?
No. Redis 8.6.2 is simply a representative vulnerable release. The affected range includes Redis 7.2.0 through 8.6.2. Organizations should verify that their deployments have been upgraded to the recommended patched versions for their respective branches.
Q3. If Criminal IP does not return any CVE results, does that mean the system is safe?
No. CVE-based search results depend on banner visibility, version identification, and vulnerability mappings. A system may still be running an affected Redis version even if no CVE mapping appears in search results. Organizations should compare Criminal IP findings with internal asset inventories and verify Redis versions directly using commands such as:
‘redis-cli INFO server | grep redis_version’
Conclusion
CVE-2026-23479 is a use-after-free vulnerability within Redis’s blocked-client processing workflow. While the issue originates from what appears to be a relatively small logic flaw involving the handling of ‘processCommandAndResetClient (c)’ return values, exploitation requires a complex combination of memory pressure conditions and blocking-command timing, making it difficult to discover through traditional testing and code review.
More important than the vulnerability itself is how Redis is deployed and used within production environments. Redis often sits at the intersection of application accounts, session storage, caching layers, and internal service communication. As a result, compromise of a single Redis instance can become the starting point for broader attacks against internal systems.
Organizations should combine patch management with reviews of externally exposed Redis assets, excessive ACL permissions, shared accounts, and co-exposed management services. In cloud environments particularly, configuration drift and forgotten test deployments can reintroduce exposure over time, making continuous external attack-surface monitoring an essential part of Redis security management.
In relation to this, you can refer to RediShell RCE Alert: Over 8,000 Redis Instances — Immediate Update Recommended
You can subscribe to Criminal IP (criminalip.io/register) and start detecting vulnerable assets right away. You can also request a demo using the button below and explore Criminal IP’s threat intelligence (TI) analysis of externally exposed assets at the enterprise level.
This report is based on data from Criminal IP, a Cyber Threat Intelligence search engine. Sign up for a free Criminal IP account today to explore the search results mentioned in the report and delve into comprehensive threat intelligence.
Source: Criminal IP(https://www.criminalip.io), The Hacker News(https://thehackernews.com/2026/06/autonomous-ai-tool-finds-2-year-old-rce.html)
Related article: https://www.criminalip.io/knowledge-hub/blog/30489