S4E just found a high top 10 tcp port service scan
critical·Product Based Network Vulnerabilities·Updated Oct 7, 2025

CVE-2025-49844 Scanner

CVE-2025-49844 Scanner - Remote Code Execution vulnerability in Redis

Est. Time~10 seconds
Scan TypeSingle Scan
Targetsdomain, subdomain, ipv4
CostFree
31
Times Used
by S4E users
25
Assets Scanned
domains & IPs
25
Vulnerabilities Found
confirmed findings
CVECVE-2025-49844
10.0
CVSScritical
Exploitable remotely over the internet · low-privilege account sufficient.

Redis is an open source, in-memory database that persists on disk. Versions 8.2.1 and below allow an authenticated user to use a specially crafted Lua script to manipulate the garbage collector, trigger a use-after-free and potentially lead to remote code execution. The problem exists in all versions of Redis with Lua scripting. This issue is fixed in version 8.2.2. To workaround this issue 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.

Attack Vector
Network
Privileges Req.
Low
User Interaction
None
Affected
redisby redis
< 8.2.2
Updated Aug 19, 2026View on NVD →
Detail

Redis is an open-source, in-memory data store widely used as a cache, message broker, and key-value database across cloud and on-premise environments. It powers session stores, job queues, real-time analytics, and pub/sub workflows for applications ranging from startups to large enterprises, and is commonly deployed in containers, VMs, and managed services. Built for low latency and high throughput, Redis provides persistence, replication, and clustering features that make it integral to performance-sensitive stacks. Its embedded Lua scripting capability is used to run complex, atomic operations directly on the server, improving efficiency but expanding the runtime surface that must be secured. Because Redis often holds runtime secrets, session data, and ephemeral credentials, any flaw in its execution paths can have outsized operational and security consequences. For these reasons, careful control of scripting privileges and network exposure is essential in production deployments.

This issue stems from unsafe memory handling inside Redis’s embedded Lua interpreter, specifically where parser behavior and garbage collection interact in a way that can leave live references dangling. An attacker who can submit scripts to the server can intentionally provoke garbage collection at precise points during script parsing, producing a use-after-free condition. That memory corruption can be shaped by the attacker to corrupt interpreter internals or function pointers, enabling execution of native code from within the Redis process. Because the attack leverages the scripting surface (EVAL/EVALSHA) rather than an external protocol parsing bug, the presence and permissiveness of scripting controls are the key operational risk factors. The scanner therefore focuses on detecting runnable scripting surfaces and runtime indicators consistent with exploitable behavior instead of relying solely on reported version strings. Environments that allow unauthenticated or overly permissive script execution are particularly exposed to this class of attack.

At a technical level, the unsafe interaction occurs when the parser handles the script “chunk name” without guaranteeing that the name remains anchored on the Lua stack while lexical analysis and GC can run. If the chunk name is reclaimed by the garbage collector while still referenced, subsequent accesses touch freed memory (use-after-free). Repeatedly loading scripts, forcing GC cycles, and feeding controlled chunk/name data lets an attacker turn that dangling reference into controlled memory corruption. With carefully crafted payloads the attacker can overwrite internal structures or return addresses and chain that corruption into arbitrary machine code execution. Because exploitation leverages script execution primitives available inside Redis, the critical mitigations are reducing scripting exposure and enforcing least-privilege ACLs in addition to applying the upstream fix.

Successful exploitation permits the attacker to break out of the Lua sandbox and run arbitrary code in the context of the Redis process, potentially resulting in full host compromise. Consequences include installation of persistent backdoors or miners, theft of in-memory secrets and credentials, destruction or tampering of cached data, and pivoting to other systems in the environment. In cloud deployments, stolen tokens or keys may enable lateral movement and privilege escalation across services. Attack surface is amplified where Redis is exposed to untrusted networks or where ACLs and authentication are weak or absent. Rapid detection, containment, disabling of scripting for untrusted users, and application of the upstream corrective patch are the highest-priority responses.

REFERENCES

Solution Advice
  • Upgrade Redis to version 8.2.2 or later to resolve the memory corruption issue in the Lua scripting engine.
  • Disable Lua scripting in environments where it is not required by removing EVAL and EVALSHA command permissions through ACL configuration.
  • Restrict Redis access to internal networks and ensure that port 6379 is not publicly exposed to the internet.
  • Enforce authentication using strong passwords and role-based access controls to limit script execution privileges.
  • Operate Redis under non-root users and apply OS-level sandboxing to reduce the impact of potential exploitation.
  • Enable comprehensive monitoring and logging to detect unusual script execution patterns or unexpected memory crashes.
  • Regularly audit Redis deployments for default configurations and tighten ACL rules to follow the least privilege principle.

Get AI-powered remediation steps tailored to your asset.

Try AI Solutions →

Check your infrastructure.
Right now.

11,000+ scanners. Free to start. No credit card required.