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:NVDaccess.redhat.comATLAS

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.4K10 dependentsPushed 2d ago0% patchedFull package profile →

Do you use NeMo Guardrails? You're affected.

How severe is it?

CVSS 3.1

6.3 / 10

EPSS

0.2%

chance of exploitation in 30 days

Higher than 12% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Moderate

What is the attack surface?

AVAdjacent

ACLow

PRLow

UINone

SUnchanged

CHigh

ILow

ANone

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?

DecisionTrack

Exploitationnone

AutomatableNo

Technical Impactpartial

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

How is it classified?

Auth BypassData LeakageFrameworkInferenceAML.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.21%.

What is the AI security impact?

Affected AI Architectures

agent frameworksmodel servingRAG pipelines

MITRE ATLAS Techniques

AML.T0018Manipulate AI Model

AML.T0040AI Model Inference API Access

AML.T0075Cloud 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.

Weaknesses (CWE)

CWE-306Missing Authentication for Critical Functionality

CWE-306 — Missing Authentication for Critical Functionality: The product does not perform any authentication for functionality that requires a provable user identity or consumes a significant amount of resources.

[Architecture and Design] Divide the software into anonymous, normal, privileged, and administrative areas. Identify which of these areas require a proven user identity, and use a centralized authentication capability. Identify all potential communication channels, or other means of interaction with the software, to ensure that all channels are appropriately protected, including those channels that are assumed to be accessible only by authorized parties. Developers sometimes perform authentication at the primary channel, but open up a secondary channel that is assumed to be private. For example, a login mechanism may be listening on one network port, but after successful authentication, it may open up a second port where it waits for the connection, but avoids authentication because it assumes that only the authenticated party will connect to the port. In general, if the software or protocol allows a single session or user state to persist across multiple connections or channels, authentication and appropriate
[Architecture and Design] For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.

Source: MITRE CWE corpus.