CVE-2026-28707: Ray local privilege escalation flaw

CISO Take

LLM-on-Ray before version 1.0 ships with a protection mechanism failure (CWE-693) that lets a low-privileged local process escalate to a privileged context within the application, with confidentiality, integrity and availability of the affected component all rated high. This isn't remotely exploitable — it needs local access plus passive interaction from a higher-privileged user — and the exploitation math backs a measured response: EPSS sits at just 0.12%, there's no public exploit or Nuclei template, and it's absent from CISA KEV, so this is not a break-glass item. It matters more for multi-tenant or shared ML infrastructure — think a Ray cluster serving LLM-on-Ray workloads for several teams or customers — where an unprivileged user with a foothold could pivot into another tenant's model-serving context. With 620 downstream dependents and an OpenSSF Scorecard of 5.8/10 for the package, and no patched version yet published by the vendor, security teams should inventory any LLM-on-Ray deployments, restrict local shell/container access to the hosts running it, and watch the upstream Intel repo for a 1.0 release that closes this gap.

Sources: NVD EPSS OpenSSF

What is the risk?

Medium severity is appropriate given the access model: exploitation requires local access and a passive interaction from a privileged user, which rules out opportunistic remote attackers and narrows the realistic threat actor to an insider, a compromised co-tenant process, or an attacker who has already achieved initial local access via another vector (e.g., a malicious notebook, container escape, or supply-chain package). EPSS (0.12%) and the absence of any public exploit code or scanner signature both indicate low near-term exploitation likelihood. However, the CIA impact on the affected component is rated high across all three axes, so if the local-access precondition is met, the consequence is severe — full compromise of the LLM-on-Ray process's confidentiality, integrity and availability. Treat this as 'low likelihood, high consequence if the precondition is already met' rather than an internet-facing emergency.

How does the attack unfold?

Local foothold

Adversary obtains low-privileged local access to a host or container running LLM-on-Ray, e.g. via a malicious notebook dependency or shared multi-tenant cluster access.

AML.T0037

Trigger condition

A privileged user (admin, ML engineer) performs a normal action against LLM-on-Ray, satisfying the passive user-interaction requirement for the exploit.

Privilege escalation

The failed protection mechanism (CWE-693) allows the adversary's low-privileged process to gain elevated rights within the LLM-on-Ray application context.

Impact

Adversary gains high-confidentiality, -integrity and -availability impact over the LLM-on-Ray component, potentially exposing models, training data or other tenants' workloads.

AML.T0007

Local foothold

Adversary obtains low-privileged local access to a host or container running LLM-on-Ray, e.g. via a malicious notebook dependency or shared multi-tenant cluster access.

AML.T0037

Trigger condition

A privileged user (admin, ML engineer) performs a normal action against LLM-on-Ray, satisfying the passive user-interaction requirement for the exploit.

Privilege escalation

The failed protection mechanism (CWE-693) allows the adversary's low-privileged process to gain elevated rights within the LLM-on-Ray application context.

Impact

Adversary gains high-confidentiality, -integrity and -availability impact over the LLM-on-Ray component, potentially exposing models, training data or other tenants' workloads.

AML.T0007

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
Ray	pip	—	No patch
43.9K OpenSSF 5.8 638 dependents Pushed 6d ago 68% patched ~148d to patch Full package profile →

Do you use Ray? You're affected.

How severe is it?

CVSS 3.1

N/A

EPSS

0.2%

chance of exploitation in 30 days

Higher than 5% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Moderate

What should I do?

1 step

No patched version number is published yet in the advisory data, so prioritize compensating controls: (1) inventory every host/container running LLM-on-Ray and confirm it's pre-1.0; (2) restrict local access to those hosts to trusted operators only — no shared shells, no untrusted job submission on the same node; (3) if the deployment is multi-tenant, enforce hard isolation (separate namespaces/nodes per tenant) until a fix ships; (4) monitor Intel's LLM-on-Ray GitHub repo and the referenced Intel security advisory for the 1.0 release and changelog describing the fix; (5) audit local file/IPC permissions used by the LLM-on-Ray process as a detection heuristic for the underlying protection-mechanism gap; (6) log and alert on unexpected privilege transitions or process spawns from the LLM-on-Ray service account.

How is it classified?

Auth Bypass Privacy Violation Inference Training Data AML.T0007 - Discover AI Artifacts AML.T0044 - Full AI Model Access

Which compliance frameworks are affected?

This CVE is relevant to:

ISO 42001

A.6.2.6 - AI system operation and monitoring

NIST AI RMF

MANAGE-1.1 - AI system risks are managed based on assessments and other analytical output

Frequently Asked Questions

What is CVE-2026-28707?

LLM-on-Ray before version 1.0 ships with a protection mechanism failure (CWE-693) that lets a low-privileged local process escalate to a privileged context within the application, with confidentiality, integrity and availability of the affected component all rated high. This isn't remotely exploitable — it needs local access plus passive interaction from a higher-privileged user — and the exploitation math backs a measured response: EPSS sits at just 0.12%, there's no public exploit or Nuclei template, and it's absent from CISA KEV, so this is not a break-glass item. It matters more for multi-tenant or shared ML infrastructure — think a Ray cluster serving LLM-on-Ray workloads for several teams or customers — where an unprivileged user with a foothold could pivot into another tenant's model-serving context. With 620 downstream dependents and an OpenSSF Scorecard of 5.8/10 for the package, and no patched version yet published by the vendor, security teams should inventory any LLM-on-Ray deployments, restrict local shell/container access to the hosts running it, and watch the upstream Intel repo for a 1.0 release that closes this gap.

Is CVE-2026-28707 actively exploited?

No confirmed active exploitation of CVE-2026-28707 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-28707?

No patched version number is published yet in the advisory data, so prioritize compensating controls: (1) inventory every host/container running LLM-on-Ray and confirm it's pre-1.0; (2) restrict local access to those hosts to trusted operators only — no shared shells, no untrusted job submission on the same node; (3) if the deployment is multi-tenant, enforce hard isolation (separate namespaces/nodes per tenant) until a fix ships; (4) monitor Intel's LLM-on-Ray GitHub repo and the referenced Intel security advisory for the 1.0 release and changelog describing the fix; (5) audit local file/IPC permissions used by the LLM-on-Ray process as a detection heuristic for the underlying protection-mechanism gap; (6) log and alert on unexpected privilege transitions or process spawns from the LLM-on-Ray service account.

What systems are affected by CVE-2026-28707?

This vulnerability affects the following AI/ML architecture patterns: model serving, training pipelines, multi-tenant ML infrastructure.

What is the CVSS score for CVE-2026-28707?

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

model servingtraining pipelinesmulti-tenant ML infrastructure

MITRE ATLAS Techniques

AML.T0007 Discover AI Artifacts

AML.T0044 Full AI Model Access

Compliance Controls Affected

ISO 42001: A.6.2.6

NIST AI RMF: MANAGE-1.1

What are the technical details?

Original Advisory

Protection mechanism failure for some LLM-on-Ray before version 1.0 within Ring 3: User Applications may allow an escalation of privilege. Unprivileged software adversary with a privileged user combined with a low complexity attack may enable escalation of privilege. This result may potentially occur via local access when attack requirements are present without special internal knowledge and requires passive user interaction. The potential vulnerability may impact the confidentiality (high), integrity (high) and availability (high) of the vulnerable system, resulting in subsequent system confidentiality (none), integrity (none) and availability (none) impacts.

Exploitation Scenario

An adversary with a low-privileged foothold on a shared ML training/serving host — for example, via a malicious dependency pulled into a data science notebook, or as a legitimate but restricted user on a shared Ray cluster — waits for or induces a privileged user (an ML engineer or admin) to trigger a routine action against LLM-on-Ray. Because the protection mechanism separating privilege levels fails, the adversary's process silently gains elevated rights within the LLM-on-Ray application, giving it read/write access to models, training data, or configuration it should never touch, and the ability to disrupt the service (availability impact) for other users of the same cluster.

Weaknesses (CWE)

CWE-693 Protection Mechanism Failure

CWE-693 — Protection Mechanism Failure: The product does not use or incorrectly uses a protection mechanism that provides sufficient defense against directed attacks against the product.

Source: MITRE CWE corpus.