A stack buffer overflow in Redis (CVE-2025-62507, CVSS 8.8) allows remote code execution through the XACKDEL command introduced in version 8.2. While the initial advisory suggested authentication mitigates the risk, JFrog researchers demonstrated that full RCE is achievable, and many Redis deployments run without authentication enabled.
Vulnerability overview
| Attribute | Value |
|---|---|
| CVE | CVE-2025-62507 |
| CVSS v3 score | 8.8 (High) |
| CVSSv4 score | 7.7 (High) |
| Type | Stack Buffer Overflow |
| Affected command | XACKDEL |
| Exploit complexity | Low |
| Authentication | Required (but often absent) |
| Fixed versions | Redis 8.2.3, 8.3.2 |
Discovery by Google Big Sleep
CVE-2025-62507 was discovered by Google Big Sleep, an AI security agent jointly developed by Google DeepMind and Project Zero. Big Sleep acts as an automated security researcher to find and report unknown security vulnerabilities in software.
| Attribute | Details |
|---|---|
| Discoverer | Google Big Sleep |
| Organizations | Google DeepMind + Project Zero |
| Type | AI-powered vulnerability research |
| Significance | Notable AI-discovered vulnerability with practical exploit chain |
This represents one of the more significant AI-discovered vulnerabilities with a demonstrated practical exploitation path.
Technical details
The XACKDEL command was added in Redis 8.2 to simplify stream cleanup by combining acknowledge and delete operations.
Root cause
| Element | Description |
|---|---|
| Vulnerable function | XACKDEL implementation |
| Buffer type | Fixed-size stack array (static_ids) |
| Flaw | No verification that ID count fits within array |
| Trigger | Supplying more IDs than STREAMID_STATIC_VECTOR_LEN |
| Memory failure | No reallocation when count exceeds limit |
The implementation allocates a fixed-size array on the stack to store parsed message IDs but fails to verify the number of IDs provided by the client fits within this array. Redis identified that the flaw occurs when the XACKDEL implementation fails to properly reallocate memory for a large number of stream IDs.
Overflow mechanics
| Step | Description |
|---|---|
| 1 | Attacker sends XACKDEL with excessive stream IDs |
| 2 | Code skips reallocation when count exceeds STREAMID_STATIC_VECTOR_LEN |
| 3 | Write operation exceeds buffer boundary |
| 4 | Stack contents overwritten, including return address |
When more IDs are supplied than the array can hold, the function writes past the buffer boundary. Because parsed stream IDs consist of two attacker-controlled numeric values, an attacker can precisely control what gets written to the stack.
Single-command exploitation
| Factor | Detail |
|---|---|
| Trigger method | Single XACKDEL command |
| Default config | Exploitable without configuration changes |
| Authentication default | Redis does not enforce authentication by default |
| Result | Unauthenticated remote code execution |
In affected versions, this condition can be triggered remotely in the default Redis configuration by sending a single XACKDEL command containing a sufficiently large number of message IDs.
JFrog RCE demonstration
The initial CVSS scoring assumed “Privileges Required,” suggesting authentication would limit exploitability. JFrog’s security research team investigated further.
JFrog findings
| Finding | Implication |
|---|---|
| Overflow allows overwriting saved registers | Control flow hijacking possible |
| Return addresses can be overwritten | Code execution achievable |
| Stream ID structure enables precise memory control | Reliable exploitation |
| Full RCE demonstrated | Critical urgency warranted |
“Since the parsed stream IDs are fully attacker controlled, the overflow does not merely corrupt adjacent data; it allows an attacker to overwrite sensitive stack contents, including saved registers and the function’s return address. The structure of stream IDs, which are parsed as two independent numeric values, makes it possible to precisely control the overwritten memory and successfully get Remote Code Execution.” — JFrog Security Research
Why authentication doesn’t mitigate the risk
| Reality | Impact |
|---|---|
| Redis defaults to no authentication | Direct exploitation possible |
| Many deployments run without authentication | Standard practice in dev/internal |
| Authenticated users may include untrusted code | Applications can trigger vulnerability |
| Internal network access often treated as trusted | Lateral movement enables exploitation |
| Cloud/container deployments may expose Redis | Internet-accessible instances |
Shachar Menashe, VP of Security Research at JFrog, noted that cybersecurity teams should deploy firewalls to protect older Redis versions if immediate upgrade isn’t possible.
Compilation security
JFrog also noted that developers should ensure security mitigations are enabled during compilation:
| Mitigation | Implementation |
|---|---|
| Stack canary protection | Add -fstack-protector flag with gcc |
| ASLR | Enabled by default on modern systems |
| DEP/NX | Prevents execution of stack memory |
These mitigations can make exploitation more difficult but do not eliminate the vulnerability—patching remains essential.
Affected versions
| Version range | Status |
|---|---|
| Redis < 8.2.0 | Not affected (XACKDEL didn’t exist) |
| Redis 8.2.0 - 8.2.2 | Vulnerable |
| Redis 8.2.3 | Fixed |
| Redis 8.3.0 - 8.3.1 | Vulnerable |
| Redis 8.3.2+ | Fixed |
Mitigation options
Primary recommendation
Upgrade to Redis 8.2.3 or 8.3.2 as soon as possible.
If immediate upgrade isn’t feasible
| Mitigation | Implementation |
|---|---|
| Restrict XACKDEL via ACL | ACL SETUSER default -XACKDEL |
| Enable authentication | Require auth for all connections |
| Network segmentation | Isolate Redis from untrusted networks |
| Firewall protection | Limit access to Redis ports |
ACL configuration example
ACL SETUSER default -XACKDELThis prevents users from executing the XACKDEL operation without requiring a full upgrade.
Deployment context
Redis is one of the most widely deployed in-memory data stores, used for:
| Use case | Risk level |
|---|---|
| Caching | Moderate (often internal) |
| Session management | High (contains auth data) |
| Message queuing | Moderate |
| Real-time analytics | Moderate |
| Development environments | High (often no auth) |
Common misconfigurations
| Issue | Prevalence |
|---|---|
| No authentication enabled | Very common in dev/internal |
| Exposed to internal network | Standard practice |
| Accessible from application servers | By design |
| Internet-exposed (cloud misconfig) | Less common but exists |
Production deployment statistics
Redis powers millions of applications globally, making this vulnerability high-impact:
| Factor | Scale |
|---|---|
| Global deployments | Millions |
| Cloud provider managed instances | High |
| Container/Kubernetes deployments | Growing |
| Legacy unpatched instances | Common |
Redis security best practices
| Practice | Implementation |
|---|---|
| Always enable authentication | requirepass or ACLs |
| Bind to specific interfaces | Not 0.0.0.0 |
| Use TLS for connections | tls-port configuration |
| Apply ACLs for least privilege | Restrict command access |
| Network isolation | Firewall and segmentation |
| Regular patching | Monitor Redis security advisories |
| Disable dangerous commands | rename-command or ACLs |
Timeline
| Date | Event |
|---|---|
| Late 2025 | Google Big Sleep discovers vulnerability |
| December 2025 | Redis notified |
| January 2026 | CVE-2025-62507 published |
| January 2026 | JFrog demonstrates full RCE |
| January 2026 | Redis 8.2.3 and 8.3.2 released with fix |
Recommendations
For Redis operators
| Priority | Action |
|---|---|
| Critical | Upgrade to Redis 8.2.3 or 8.3.2 |
| Critical | If upgrade delayed, apply ACL restriction |
| High | Audit authentication configuration |
| High | Review network exposure |
| Medium | Implement monitoring for anomalous commands |
| Medium | Verify compilation security flags |
For security teams
| Priority | Action |
|---|---|
| High | Inventory all Redis deployments |
| High | Verify version and patch status |
| Medium | Review Redis access patterns |
| Ongoing | Monitor for exploitation attempts |
Detection opportunities
| Indicator | Detection method |
|---|---|
| Large XACKDEL commands | Command auditing |
| Unusual stream operations | Behavioral monitoring |
| Crash/restart patterns | Process monitoring |
| Memory corruption signs | Core dump analysis |
Context
The assumption that “authentication required” meaningfully reduces risk doesn’t hold when:
- Many deployments run without authentication
- Authenticated users may include untrusted application code
- Internal network access is often treated as trusted
- Cloud misconfigurations can expose services
| Risk factor | Status |
|---|---|
| Default configuration exploitable | Yes |
| Single command trigger | Yes |
| Precise memory control | Yes |
| Full RCE demonstrated | Yes |
| Authentication default | None |
Organizations should treat CVE-2025-62507 as a critical priority regardless of authentication status. The JFrog RCE demonstration confirms this is not a theoretical risk but a practical, exploitable vulnerability.
The Google Big Sleep discovery also highlights the emerging role of AI in vulnerability research—security teams should anticipate that AI-assisted vulnerability discovery will accelerate the pace of zero-day disclosure across the software ecosystem.