TL;DR There are new versions of Redis available on Compose, 4.0.10 and 3.2.12, which addresses security vulnerabilities in Redis. We recommend all users upgrade to these versions as soon as possible. In future weeks, Compose will be looking to move deployments with older versions onto these new versions.

Background: Redis includes a powerful Lua scripting feature, introduced in Redis 2.6 in 2013, which had a number of extensions added to it - cmsgpack and struct - to make life easier for Lua script writers. Apple recently informed Redis's creator that there were issues with these extensions which, when abused, could cause the server to corrupt memory and crash or potentially take control of the Redis process. Yesterday, an announcement was made that there were new, patched versions of Redis available which fixed these vulnerabilities.

Exposure: For a third-party attacker to exploit this vulnerability, they would require access to the Redis instance. At Compose, all our Redis deployments are password protected and access can be controlled through a whitelist. Furthermore, we now have TLS/SSL connection support to protect against third party interception of traffic.

Action: We consider the risk to Compose deployments low due to these mitigations and the lack of any known exploitation of the vulnerabilities in the five years they have been in the wild. We do, though, consider it important the users upgrade their Redis deployments as soon as possible to ensure that they are not running an exposed version of Redis.

• Users of Redis 3.x should upgrade to Redis 3.2.12 or Redis 4.0.10.
• Users of Redis 4.x should upgrade to Redis 4.0.10.

As no update is available for older 2.x versions of Redis, we are moving to end-of-life 2.x Redis on the Compose platform.

Also, Redis 4.0.10 has become the preferred version of Redis for new deployments. Customers who automate deployments and do not override the default version should allow for this in their processes.

Future Action: Users who do not upgrade their deployments within the next 4 weeks should expect automated upgrades to take place on their deployment at some point after that time as part of regular maintenance work. This is in line with our current Database Life Cycle Policy.

attribution Igor Starkov