Ray (GCS Redis credential handling / logging): When the Redis password is passed on the Ray command line it gets

Impact

When the Redis password is passed on the Ray command line it gets written into standard logs. Anyone who can read those logs - a log aggregator, a sidecar, a co-tenant with pod-log RBAC - recovers the password to the Global Control Store, which is the cluster's single source of truth for actor placement and job state. From there they can read or tamper with every tenant's workload metadata.

Who can reach it

A local or in-cluster reader of Ray's log output who also has network reach to the Redis instance. Requires that Redis auth is enabled and the password was supplied as an argument.

What to do

Upgrade Ray to 2.43.0 or later, then rotate the Redis password - the upgrade stops new leakage but does nothing about passwords already sitting in retained logs. Purge or re-key any log archives that captured the old value.

References

Related entries

• KServe ModelMesh: Group-writable `/etc/passwd` in the container imageCVE-2025-57852 · KServe ModelMeshMedium
• Jupyter Server: login `next` parameter allows redirect to an arbitrary external hostCVE-2025-61669 · Jupyter Server (LoginFormHandler redirect validation)Medium
• vLLM: video decoder limit bypass via sampler subclass shadowing exhausts unaccounted GPU memoryCVE-2026-100649 · vLLM (PyNvVideoCodec decoder allocation, sampler subclass accounting)Medium
• TrustyAI Service Operator: unauthenticated access to AI guardrail and orchestrator APIsCVE-2026-15044 · TrustyAI Service Operator (Red Hat OpenShift AI)Medium
• llama.cpp: oversized seq_id in a saved slot file leaks heap memory past the cells arrayCVE-2026-43630 · llama.cpp server (recurrent memory state slot-restore path)Medium
• vLLM: race in the prompt_embeds sparse-tensor guard reopens the CVE-2025-62164 crash pathCVE-2026-73557 · vLLM prompt_embeds loader (safe_load_prompt_embeds sparse-tensor guard)Medium