The open-source Ray distributed computing framework is used worldwide—from research to production AI—and features Redis as its backend data store. But if you are running a version of Ray earlier than 2.43., you may be exposing your Redis passwords… directly into your log files!

In this post, we’ll break down CVE-2025-1979, demonstrate how the leak happens (with code), lay out the exploitation conditions, and tell you how to fix and recover from this bug. This is an original, easy-to-follow explanation with practical security advice.

What Is CVE-2025-1979?

CVE-2025-1979 affects the Ray package (Python) before version 2.43.. If you use password-protected Redis with Ray, and logging is turned on, your Redis password can get written in plain, clear text to log files.

This puts secrets at risk—especially if those log files are backed up insecurely, shipped to monitoring tools, or left readable by others. An attacker with access to your logs could then connect to your Redis backend and mess with your cluster.

Redis instance is password-protected (has requirepass foo set or equivalent).

3. Password is passed via command/args/env when launching Ray, not via secure file loading or secrets manager.
4. Your log files are accessible (via shared machines, open file shares, log aggregation/SIEM systems, etc).

If you run Ray on your laptop at home with local Redis and never share logs, you’re less at risk. But in production and cloud setups (Kubernetes, clusters, CI/CD), this is a big deal.

Let’s look at how Ray used to initialize Redis in old versions (before 2.43.)

# Vulnerable simplified Ray code (before v2.43.)
import logging

def start_redis(redis_password):
    logger = logging.getLogger("ray")
    logger.info(f"Starting Redis with password: {redis_password}")
    # Start the Redis process
    # ... (more startup)

When invoked (e.g. via CLI or Python API) like this

ray start --head --redis-password s3cr3tpa55

or programmatically

import ray
ray.init(redis_password="s3cr3tpa55")

The logs will contain lines like

INFO ray Starting Redis with password: s3cr3tpa55

This means anyone with log access sees the credentials, which defeats the whole point of securing your Redis.

Set up Vulnerable Ray

Run Ray With Logging Enabled

Find the Credentials in Logs


Look for logs in /tmp/ray/session_latest/logs/ or equivalent (raylet.err, redis-server.out, etc):

`

grep password /tmp/ray/session_latest/logs/*

`

/tmp/ray/session_latest/logs/raylet.err:INFO ray Starting Redis with password: hiddensecret

Extract the password

- Connect (redis-cli -a hiddensecret) and escalate attacks (read, write, or even execute dangerous commands on Redis, depending on configuration)

Upgrade to Ray version 2.43. or newer

pip install --upgrade ray

Or specify in your requirements.txt or dependencies (for Docker, CI/CD, pipenv, etc).

Release Notes / Fixes:
- Ray Release info: https://docs.ray.io/en/latest/release-notes.html
- Fix commit: PR #XXXXX (replace with actual PR link if available)

2. Rotate Your Redis Password

Even after upgrading, rotate your existing Redis password to prevent misuse by anyone who saw the old one (maliciously or accidentally):

3. Scrub Logs

Remove old log files containing your previous password. If you ship logs off-site, scrub them there as well.

4. Harden Log Access

Restrict permissions on all log files and directories, and minimize logging of secrets everywhere.

More on This Issue

Official Advisory:
- GitHub Security Advisory for ray (search for CVE-2025-1979)

CVE Details:
- NVD entry (if available)

Discussion & Community Fixes:
- Issue on GitHub Ray repo (search for “redis password log”)

Practice least privilege with logs and secrets.

If you’re using Ray with Redis authentication and logging, update and rotate now. Don’t let passwords leak where you least expect them.


*Stay safe, and always treat your logs like gold!*

References and Further Reading

- Ray Documentation
- Ray GitHub
- How Not to Log Credentials

*(Please check release and advisory links regularly for the latest updates.)*

Timeline

Published on: 03/06/2025 05:15:16 UTC
Last modified on: 03/06/2025 16:15:54 UTC