Ray's Own Software Told Me It Was Vulnerable

Some vulnerabilities need a careful chain of evidence to prove. This one announces itself. Start a Ray head node - the current latest release, 2.59.0, installed fresh today, not an old vulnerable version kept around to make a point - with no special configuration, and read what it prints before you've sent it a single request:

WARNING authentication_token_setup.py:73 -- Token authentication is disabled
for this Ray cluster. Anyone with network access to the cluster can run
arbitrary code and access its data. To enable token authentication,
generate a token with `ray get-auth-token --generate` or set
RAY_AUTH_MODE=token.

That's not a third-party security researcher's characterization of the risk. That's the vendor's own software, unprompted, describing CVE-2025-62593 - CVSS 9.4, CISA Known Exploited Vulnerabilities catalog as of August 2026 - in its own startup banner, every single time someone starts a cluster without opting into the fix.

Proving the banner isn't just a disclaimer

A warning is cheap. I wanted to see the actual request succeed or fail.

$ curl -s -X POST http://127.0.0.1:8265/api/jobs/ \
    -H "Content-Type: application/json" \
    -d '{"entrypoint": "echo UNAUTHENTICATED-JOB-PROBE ran as $(whoami) on $(hostname)"}'
{"job_id": "raysubmit_EgMVgPxC1JhUy11d", "submission_id": "raysubmit_EgMVgPxC1JhUy11d"}

No API key. No bearer token. No login step anywhere in that request. Checking what actually happened:

$ curl -s http://127.0.0.1:8265/api/jobs/raysubmit_EgMVgPxC1JhUy11d/logs
UNAUTHENTICATED-JOB-PROBE ran as [redacted] on [redacted]

It ran. A real shell command, with real output, including the real username and hostname of the machine it ran on - redacted here before publishing anything, but printed in full on the actual run. One HTTP POST, zero credentials, arbitrary code execution, on the version of Ray anyone installs today if they run pip install ray without reading the fine print.

This is specifically what CVE-2025-62593 escalates past the earlier, disputed CVE-2023-48022 ("ShadowRay") - Anyscale's original position on that one was "this is a design decision, not a bug, just don't expose Ray to the internet." The 2025 version proves that advice doesn't hold: a malicious website, opened in an ordinary browser, can reach a Ray cluster that was never exposed to the internet at all, via DNS rebinding and a spoofed User-Agent header, because the only thing standing between a browser request and the Jobs API was a check for whether the request looked like a browser. I didn't rebuild that specific delivery mechanism for this piece - that's attack infrastructure, not the point being proven. The point is what's underneath it: there was never any real authentication to bypass in the first place.

The fix isn't a version number

Here's the part that makes this a different shape of problem than most CVEs: there's no patched release that closes this by default. The fix is a configuration flag you have to know to set, RAY_AUTH_MODE=token, plus generating a token before the cluster will even start in that mode.

$ curl -s -X POST http://127.0.0.1:8265/api/jobs/ \
    -H "Authorization: Bearer $(cat ~/.ray/auth_token)" \
    -H "Content-Type: application/json" \
    -d '{"entrypoint": "echo test"}'
{"job_id": "raysubmit_mVQacnXgjaNh4TqK", "submission_id": "raysubmit_mVQacnXgjaNh4TqK"}

Same cluster version. Same endpoint. Same request shape. The only thing that changed is whether anyone opted into the control that already exists. Without it:

$ curl -s -X POST http://127.0.0.1:8265/api/jobs/ \
    -H "Content-Type: application/json" \
    -d '{"entrypoint": "echo test"}'
Unauthorized: Missing authentication token

That's the real fix working, confirmed live, not described.

A nuance worth knowing if you're actually running this

Ray doesn't always start wide open. If a token was ever generated on a given machine, Ray detects the leftover token file on the next start and quietly enables auth, even without the environment variable set. Found this by accident, building a repeatable test for it - my first "vulnerable" test run came back clean, because an earlier manual test had left a token file sitting in ~/.ray. The actual vulnerable state is specifically the fresh-install default: a machine that has never once generated a token. Worth knowing in both directions - it means a cluster you've protected once stays protected across restarts without re-flagging it, and it means never checking whether you've opted in at all is the one condition that's actually dangerous.

GhostInThePrompt.com // The vendor's own warning said it plainly. I just checked whether it was telling the truth.