To decide whether an inference server CVE is exploitable in your deployment, ask five questions: do you run an affected version, do you use the affected feature, can an attacker reach it on the network, does it require authentication, and what could an attacker do with the process's access. Two or more "no" answers usually lower urgency.
The five questions
1. Is the version affected? Compare your deployed version, from the image or lockfile, with the advisory range. Not the version you intended to deploy.
2. Is the feature on? Many serving runtimes have optional features: dynamic adapter loading, built in code interpreters, tool servers, multimodal URL fetching, development endpoints. The vLLM security guide, for example, says dynamic adapter loading is disabled by default, that dev mode endpoints should never be enabled in production, and that tool servers and the code interpreter should stay off unless reviewed. If the advisory involves a feature you never enabled, say so in writing.
3. Can an attacker reach it? Internal cluster ports, dashboards, and control channels often assume a trusted network. Ray's documentation states that anyone who can reach its dashboard, jobs, or client ports can run arbitrary code on the cluster, which is why it asks for network isolation. If those ports are not reachable except from trusted hosts, remote exploitation is much harder.
4. Does authentication stand in the way? Check which routes your key or proxy actually covers. The vLLM guide notes its API key applies to specific path prefixes only.
5. What is the blast radius? If exploited, what does the process hold: cloud credentials, customer data, GPU nodes, other tenants? A runtime with a broad role turns a medium flaw into a serious one.
Score it
| Answers | Suggested action |
|---|---|
| All five point to exposure | Treat as urgent, patch or mitigate now |
| Reachable and unauthenticated | Mitigate at the network first, patch next |
| Feature off, not reachable | Schedule the update, record why |
Add outside signals. A listing in the CISA Known Exploited Vulnerabilities catalog, which CISA says should feed vulnerability prioritisation, should override a comfortable local analysis until you have verified it.
Do not confuse reachable with exploitable
Reachable code is not always exploitable, and unreachable code today may be reachable after a refactor. See reachable does not mean exploitable.
Try it yourself
Open the exploitability check demo and walk one finding through its questions. Notice which answer moves the priority most.
Click through it at your own pace, or open it full screen.
A short note on Safeguard
Safeguard offers reachability analysis and dependency scanning to help rank findings. Try a free scan at gold.safeguard.sh/scan.
Quick check
If the feature is off, can I skip the patch?
You can lower urgency, but still schedule it. Configuration drifts and features get switched on.
Who should write the exploitability decision down?
The service owner, with a date. Customers and auditors ask for it later.
Sources
Last reviewed: 19 October 2026.
