CVE-2026-15044: NeMo Guardrails missing auth

CISO Take

The TrustyAI Service Operator ships gorch (its guardrails orchestrator) and NemoGuardrails integrations without enforcing mutual authentication by default, so any workload that reaches these services on the cluster network — no credentials, no user interaction — can talk to them as if it were a trusted caller. This matters because these components sit in the control path between applications and the LLM: an unauthenticated caller with adjacent network access can read sensitive orchestration traffic (confidentiality impact high) and push limited configuration changes to the guardrails/model behavior (integrity impact low). There's no CISA KEV listing, no EPSS score, and no public exploit code or Nuclei template as of this writing, so this reads as a real but not currently weaponized risk — the CVSS 6.3 (adjacent network, low complexity, low privileges) reflects that it's easy to trigger once inside the cluster, but hard to reach from outside it. Enable the required mutual-TLS/identity-verification setting on TrustyAI gorch and NemoGuardrails deployments immediately, and in the meantime restrict east-west traffic to these services with NetworkPolicies so only authorized pods can reach the orchestrator's ports.

Sources: NVD access.redhat.com ATLAS

What is the risk?

Medium severity (CVSS 6.3) with a narrow but real exposure window: exploitation requires adjacent network access to the Kubernetes cluster (AV:A) plus low privileges (PR:L, e.g., a compromised or malicious pod/service already inside the cluster), but once that foothold exists, exploitation itself is trivial — no user interaction, low complexity. The confidentiality impact is high (full read access to guardrails/orchestrator communications) while integrity impact is limited (partial model/config changes) and availability is unaffected. No CISA KEV entry, no EPSS data, and no public PoC lower the near-term exploitation likelihood, but this is exactly the kind of lateral-movement-friendly misconfiguration that gets weaponized in multi-tenant or shared Kubernetes environments once an attacker has any initial foothold (e.g., via a separate unrelated CVE, leaked service account, or supply-chain compromise of an adjacent workload).

How does the attack unfold?

Cluster foothold

Attacker obtains adjacent network access within the Kubernetes cluster, e.g., by compromising a separate lower-privilege workload or service account.

Service discovery

Attacker enumerates internal services and identifies the TrustyAI gorch orchestrator or NemoGuardrails endpoint lacking identity verification.

AML.T0075

Unauthenticated access

Attacker connects directly to the exposed communication channel without proving identity, gaining access equivalent to a trusted internal caller.

AML.T0040

Information exposure and limited model tampering

Attacker reads sensitive guardrails/orchestrator traffic and, in some configurations, makes limited unauthorized changes to AI model behavior or guardrail policies.

AML.T0018

Cluster foothold

Attacker obtains adjacent network access within the Kubernetes cluster, e.g., by compromising a separate lower-privilege workload or service account.

Service discovery

Attacker enumerates internal services and identifies the TrustyAI gorch orchestrator or NemoGuardrails endpoint lacking identity verification.

AML.T0075

Unauthenticated access

Attacker connects directly to the exposed communication channel without proving identity, gaining access equivalent to a trusted internal caller.

AML.T0040

Information exposure and limited model tampering

Attacker reads sensitive guardrails/orchestrator traffic and, in some configurations, makes limited unauthorized changes to AI model behavior or guardrail policies.

AML.T0018

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
NeMo Guardrails	pip	—	No patch
7.0K 9 dependents Pushed 4d ago 0% patched Full package profile →

Do you use NeMo Guardrails? You're affected.

How severe is it?

CVSS 3.1

6.3 / 10

EPSS

0.3%

chance of exploitation in 30 days

Higher than 18% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Moderate

What is the attack surface?

AV Adjacent

AC Low

PR Low

UI None

S Unchanged

C High

I Low

A None

What should I do?

1 step

1) Enable the security setting that requires identity verification on gorch and NemoGuardrails communication channels — check the TrustyAI Service Operator configuration for the mTLS/authentication toggle referenced in the Red Hat advisory (access.redhat.com/security/cve/CVE-2026-15044) and Bugzilla #2498039. 2) Apply Kubernetes NetworkPolicies to restrict which pods/namespaces can reach the orchestrator and guardrails service ports, treating them as sensitive internal services rather than open cluster resources. 3) Audit existing TrustyAI/NemoGuardrails deployments for the setting's current state — do not assume defaults are secure. 4) Monitor orchestrator/guardrails service logs for unexpected source pods or namespaces connecting without expected client identities. 5) Track the upstream TrustyAI Service Operator release notes for a patched version that enables this setting by default.

What does CISA's SSVC say?

Decision Track

Exploitation none

Automatable No

Technical Impact partial

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Auth Bypass Data Leakage Framework Inference AML.T0018 - Manipulate AI Model AML.T0040 - AI Model Inference API Access AML.T0075 - Cloud Service Discovery

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, robustness and cybersecurity

ISO 42001

A.6.2.6 - AI system security

NIST AI RMF

MEASURE 2.7 - AI system security and resilience evaluated and documented

OWASP LLM Top 10

LLM02 - Sensitive Information Disclosure

Frequently Asked Questions

What is CVE-2026-15044?

The TrustyAI Service Operator ships gorch (its guardrails orchestrator) and NemoGuardrails integrations without enforcing mutual authentication by default, so any workload that reaches these services on the cluster network — no credentials, no user interaction — can talk to them as if it were a trusted caller. This matters because these components sit in the control path between applications and the LLM: an unauthenticated caller with adjacent network access can read sensitive orchestration traffic (confidentiality impact high) and push limited configuration changes to the guardrails/model behavior (integrity impact low). There's no CISA KEV listing, no EPSS score, and no public exploit code or Nuclei template as of this writing, so this reads as a real but not currently weaponized risk — the CVSS 6.3 (adjacent network, low complexity, low privileges) reflects that it's easy to trigger once inside the cluster, but hard to reach from outside it. Enable the required mutual-TLS/identity-verification setting on TrustyAI gorch and NemoGuardrails deployments immediately, and in the meantime restrict east-west traffic to these services with NetworkPolicies so only authorized pods can reach the orchestrator's ports.

Is CVE-2026-15044 actively exploited?

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

How to fix CVE-2026-15044?

1) Enable the security setting that requires identity verification on gorch and NemoGuardrails communication channels — check the TrustyAI Service Operator configuration for the mTLS/authentication toggle referenced in the Red Hat advisory (access.redhat.com/security/cve/CVE-2026-15044) and Bugzilla #2498039. 2) Apply Kubernetes NetworkPolicies to restrict which pods/namespaces can reach the orchestrator and guardrails service ports, treating them as sensitive internal services rather than open cluster resources. 3) Audit existing TrustyAI/NemoGuardrails deployments for the setting's current state — do not assume defaults are secure. 4) Monitor orchestrator/guardrails service logs for unexpected source pods or namespaces connecting without expected client identities. 5) Track the upstream TrustyAI Service Operator release notes for a patched version that enables this setting by default.

What systems are affected by CVE-2026-15044?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, model serving, RAG pipelines.

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

CVE-2026-15044 has a CVSS v3.1 base score of 6.3 (MEDIUM). The EPSS exploitation probability is 0.27%.

What is the AI security impact?

Affected AI Architectures

agent frameworksmodel servingRAG pipelines

MITRE ATLAS Techniques

AML.T0018 Manipulate AI Model

AML.T0040 AI Model Inference API Access

AML.T0075 Cloud Service Discovery

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: A.6.2.6

NIST AI RMF: MEASURE 2.7

OWASP LLM Top 10: LLM02

What are the technical details?

Original Advisory

A flaw was found in the TrustyAI Service Operator. When deploying services like gorch or NemoGuardrails, if a specific security setting is not enabled, these services can expose their communication channels without requiring users to prove their identity. This allows any other program within the cluster to access the AI guardrails and orchestrator without proper authorization. An attacker could exploit this to gain unauthorized access to sensitive information and potentially make limited changes to the AI models.

Exploitation Scenario

An attacker first gains a foothold inside the Kubernetes cluster — for example, by compromising an unrelated, lower-privilege workload in the same namespace or network segment (via a separate vulnerability, leaked credentials, or a malicious container image). From that foothold, they enumerate cluster-internal services and discover the TrustyAI gorch orchestrator or NemoGuardrails endpoint listening without authentication enforcement. They connect directly to the guardrails communication channel, impersonating a legitimate internal caller since no identity verification is required. From there they can read intercepted prompts, responses, and policy decisions flowing through the guardrails layer (data exposure), and in some configurations push limited changes to guardrails/model configuration — potentially weakening the safety controls that were supposed to protect the downstream LLM application.