Is the Redis Docker Image Safe? What Our Scanner Found

What we found scanning redis:7-alpine

We exported both images with docker save and scanned them with ScanRook, which matches every installed package against OSV, NVD, and vendor advisory data:

ScanRook v1.14.2, warm-cache scan, 2026-07-04. Counts change as new advisories publish.

Redis is unusual in this series in that its leanest tag is also its most common production choice. The Alpine build still isn't zero-risk — it inherits BusyBox and OpenSSL from its base — but at 299 findings it is close to the floor you can expect from any actively maintained Alpine image.

The CVEs worth knowing about

The top critical findings in redis:7-alpine come from two packages inherited from the Alpine base, not from Redis itself:

• busybox-binsh — CVE-2021-42377, CVE-2022-48174, CVE-2016-2148. BusyBox provides the minimal shell and coreutils Alpine uses in place of a full GNU userland. These advisories affect BusyBox applet parsing and shell handling; whether they are reachable depends on whether anything in your entrypoint or healthcheck actually invokes a shell inside the container.
• libcrypto3 — CVE-2021-3711, CVE-2022-2274.libcrypto3 is OpenSSL's cryptography library, used for TLS if you enable Redis's encrypted connections. Both CVEs are buffer-overflow issues in specific OpenSSL code paths; check whether your deployed OpenSSL build post-dates the fix before treating either as exploitable.

Neither package is part of the Redis server binary. Our guide to installed-state scanning vs. advisory matching explains why scanners flag base-image packages like these even when the application never touches them directly.

Which tag should you use?

Use redis:7-alpine unless you have a concrete reason not to. It is the same Redis release as the Debian-based tag, with roughly 79% fewer findings and about a fifth of the container size. For the wider tradeoffs between Alpine, Debian, and distroless base families, see Alpine vs Debian vs Distroless.

Stick with redis:7 if you build custom Redis modules linked against glibc, or your infrastructure standardizes on Debian images for debugging and tooling parity across services. Automate the scan comparison in CI so the decision is data-driven rather than a one-time judgment call — see how to scan Docker images in GitHub Actions.

Hardening checklist

• Set a strong requirepass or use Redis ACLs — never expose Redis without authentication.
• Bind Redis to an internal network only; never publish port 6379 to the public internet.
• Pin the image by digest (redis@sha256:…) so deploys are reproducible.
• Disable dangerous commands (FLUSHALL, CONFIG) in production via rename-command or ACLs.
• Enable TLS for Redis connections that cross a network boundary you don't fully trust.
• Rebuild and redeploy on a schedule so BusyBox and OpenSSL patches actually reach you.
• Scan every build in CI so a base image regression is caught before it ships.

Scan it yourself

Counts drift as new advisories publish, so verify against the exact tag and digest you deploy:

curl -fsSL https://scanrook.io/install.sh | sh
docker save redis:7-alpine -o redis.tar
scanrook scan redis.tar

The full CLI reference, including JSON output and severity gating for CI, is in the docs.

Frequently asked questions