All Products
Document Center

[Vulnerability notice] Unauthorized access vulnerability in Redis

Last Updated: May 09, 2018


Redis is subject to unauthorized access because of improper configuration, which may be exploited by attackers.

Under certain conditions, if Redis runs with the root account, hackers can write an SSH public key file to the root account, directly logging on to the victim server through SSH. This may allow hackers to gain server privileges and delete or steal data, or even lead to an encryption extortion, critically endangering normal business services.

Once a Redis server is invaded, attackers may directly add an account for remote logon to control the server through SSH. This will impose security risks to users’ Redis environment and Linux hosts and lead to deletion or leakage of important data, or even extortion.

Affected versions

To check whether a client is subject to this vulnerability, try to log on to Redis on a client without an account:

  1. root@kali:~# redis-cli -h
  2. redis> keys *
  3. 1) "1"`

From the result, this Redis service is open to the Internet and has not enabled authentication.


At network layer

  • Specify the NIC used by the Redis service

    Redis listens to by default. Make sure the listener is local if you only need local communications.

    Note: This approach can alleviate the risk to Redis to some extent. If an attacker has a webshell, and Redis runs with the root account, the attacker can still use the Redis to activate a reverse shell and achieve permission elevation.

    Locate # bind in the redis.conf file, uncomment it, and then save the changes.


    • After the change, only local machines can access Redis. However, you can also specify the IP addresses allowed to access Redis.
      1. bind
    • You must restart Redis for the settings to take effect.
  • Set the firewall policy

    If the Redis service in a normal business needs to be accessed by other servers, you can set the iptables policy to only allow specified IP addresses to access the Redis service.

    1. iptables -A INPUT -s x.x.x.x -p tcp --dport 6379 -j ACCEPT

Account and authentication

  • Set the access password

    Locate the requirepass field in the redis.conf file and enter a password at the end. The Redis client also needs this password to access the Redis service.

    For example, open /etc/redis/redis.conf and create the password !QE%^E3323BDWEwwwe1839:

    1. requirepass !QE%^E3323BDWEwwwe1839

    Make sure the password is complex enough. Restart the service after the configuration to bring the changes into effect.

Least privilege

  • Change the account running the Redis service

    Run the Redis service with an account with only necessary permissions and disable the logon permission for this account.

    The following command creates a general-permission account with no home directory and cannot be logged on to:

    1. useradd -M -s /sbin/nologin [username]
  • Refine service authorization

    Redis does not support permission separation. So, no difference is found between the administrator and general account. As a result, attackers may log on to the database and perform any operation.

    Therefore, we recommend that you disable the following important commands: FLUSHDB, FLUSHALL, KEYS,PEXPIRE, DEL, CONFIG, SHUTDOWN, BGREWRITEAOF, BGSAVE, SAVE, SPOP, SREM, RENAME,DEBUG and EVAL.

    In addition, Redis 2.8.1 and Redis 3.x series (earlier than v3.0.2) may have an EVAL sandbox escape vulnerability that can be exploited to run any Lua code.

    The following configuration sets config/flushdb/flushall to empty, that is, disables the command. You can also give the command a name that is hard for attackers to decrypt.

    1. rename-command CONFIG ""
    2. rename-command flushall ""
    3. rename-command flushdb ""
    4. rename-command shutdown shotdown_test

    Save the changes and run /etc/init.d/redis-server restart to restart the database.

Install security patches

Pay attention to the latest security patches and upgrade Redis to the latest version to prevent new vulnerabilities from being exploited.