Back to Intelligence

CVE-2026-15378: Kubernetes Guardrails SSRF Vulnerability — Detection and Remediation

SA
Security Arsenal Team
July 11, 2026
7 min read

The disclosure of CVE-2026-15378 represents a significant risk to Kubernetes environments leveraging the guardrails-detectors component. Rated CVSS 9.3 (Critical), this vulnerability exposes a fundamental flaw in how the component handles XML Schema Definitions (XSD), allowing a remote, unauthenticated attacker to execute blind Server-Side Request Forgery (SSRF) attacks and read local files.

For security practitioners, the severity of this flaw cannot be overstated. In a containerized environment, SSRF is often the skeleton key to the cloud. Successful exploitation of CVE-2026-15378 allows an attacker to pivot from the application layer to the underlying infrastructure, exfiltrating cloud metadata credentials (IAM roles), accessing the Kubernetes API server, or interacting with internal services like MinIO.

Technical Analysis

Affected Component: guardrails-detectors (Kubernetes).

Vulnerability Mechanics: The vulnerability resides in the parsing logic for XML Schema Definitions (XSD). The component fails to properly sanitize or restrict the resources referenced by a submitted XSD string. By injecting a crafted XSD payload, an attacker can manipulate the XML parser into making arbitrary web requests or reading local files.

  1. Blind SSRF: The attacker submits an XSD containing an external entity or schema location pointing to an internal or cloud resource (e.g., http://169.254.169.254/latest/meta-data/iam/security-credentials/). The guardrails-detectors service processes the schema, triggering the HTTP request to the attacker-specified target. While the response may not be directly returned to the attacker (blind), the impact occurs—data can be exfiltrated via DNS or out-of-band HTTP callbacks, or the attacker can perform actions on internal APIs.

  2. Local File Inclusion: The vulnerability extends beyond network requests. The parser can be coerced into reading files from the local filesystem using file URI schemes (e.g., file:///var/run/secrets/kubernetes.io/serviceaccount/token). This allows for the direct theft of Kubernetes Service Account tokens, effectively granting the attacker the permissions assigned to that pod within the cluster.

Exploitation Requirements:

  • Network access to the guardrails-detectors endpoint.
  • Ability to submit a crafted XSD string to the component.

Impact:

  • Unauthorized access to cloud instance metadata (AWS IMDSv1/v2, GCP, Azure).
  • Access to internal Kubernetes resources (API Server, internal MinIO).
  • Compromise of pod identity and secrets (Service Account Tokens).

Detection & Response

Detecting this vulnerability requires a shift in monitoring strategy. Since the vulnerability is triggered by a specific network request or file operation initiated by the guardrails-detectors process, we must monitor for anomalous egress behavior and file access patterns associated with this specific binary.

Sigma Rules

The following Sigma rules target the behavioral indicators of exploitation: unexpected network connectivity to the metadata service and local file access to sensitive Kubernetes paths by the vulnerable component.

YAML
---
title: Potential Exploitation of CVE-2026-15378 via Metadata Access
id: 8a4f9c2d-1e3b-4a5f-9b6c-8d7e6f5a4b3c
status: experimental
description: Detects attempts by the guardrails-detectors component to access the cloud metadata service IP (169.254.169.254), indicative of SSRF exploitation.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-15378
author: Security Arsenal
date: 2026/04/14
tags:
  - attack.initial_access
  - attack.t1190
  - cve.2026.15378
logsource:
  category: network_connection
  product: linux
detection:
  selection:
    SrcProcessName|endswith: 'guardrails-detectors'
    DestinationIp: '169.254.169.254'
  condition: selection
falsepositives:
  - Legitimate cloud introspection by the guardrails component (verify logic)
level: critical
---
title: Kubernetes Guardrails Detector Sensitive File Read
id: 9b5e0d3e-2f4c-5b6a-0c7d-9e8f0a1b2c3d
status: experimental
description: Detects the guardrails-detectors process reading Kubernetes service account tokens or secrets, a sign of local file inclusion via XSD.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-15378
author: Security Arsenal
date: 2026/04/14
tags:
  - attack.credential_access
  - attack.t1005
  - cve.2026.15378
logsource:
  category: file_access
  product: linux
detection:
  selection:
    ProcessName|endswith: 'guardrails-detectors'
    TargetFilename|contains:
      - '/var/run/secrets/kubernetes.io/serviceaccount/'
      - '/etc/shadow'
  condition: selection
falsepositives:
  - Administrative debugging or legitimate configuration validation (rare)
level: high

KQL (Microsoft Sentinel / Defender)

Hunt for suspicious egress traffic originating from the vulnerable component in your environment.

KQL — Microsoft Sentinel / Defender
// Hunt for guardrails-detectors connecting to Cloud Metadata or Internal endpoints
DeviceNetworkEvents
| where InitiatingProcessName endswith "guardrails-detectors"
| where RemoteIP == "169.254.169.254" or RemoteIP in ("10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16")
| project Timestamp, DeviceName, InitiatingProcessAccountName, RemoteIP, RemotePort, InitiatingProcessCommandLine, AdditionalFields
| order by Timestamp desc

Velociraptor VQL

This VQL artifact hunts for active network connections established by the vulnerable component.

VQL — Velociraptor
-- Hunt for guardrails-detectors connecting to Metadata IP or suspicious endpoints
SELECT Pid, Name, CommandLine, Exe, Username, RemoteAddress, RemotePort, State
FROM netstat()
WHERE Name =~ "guardrails-detectors"
  AND (
      RemoteAddress =~ "169.254.169.254" 
      OR RemotePort > 1024 
  )

Remediation Script (Bash)

Use the following script to identify vulnerable pods and apply an immediate network policy workaround to restrict egress access to the metadata service until patching is complete.

Bash / Shell
#!/bin/bash

# Remediation Script for CVE-2026-15378
# 1. Identifies pods running guardrails-detectors
# 2. Applies a NetworkPolicy to block egress to 169.254.169.254

echo "[+] Starting remediation for CVE-2026-15378..."

# Check if kubectl is available
if ! command -v kubectl &> /dev/null; then
    echo "[-] kubectl could not be found. Please run this on a node with kubectl access."
    exit 1
fi

echo "[+] Scanning for pods with 'guardrails-detectors' component..."

# Get namespaces and pod names containing guardrails-detectors
# Note: Adjust the label selector 'app=guardrails-detectors' based on your specific deployment labels
PODS=$(kubectl get pods -A -l app=guardrails-detectors -o path='{.items[*].metadata.namespace} {.items[*].metadata.name}')

if [ -z "$PODS" ]; then
    echo "[!] No pods found with label 'app=guardrails-detectors'."
    echo "[!] Please manually verify the labels of your guardrails-detectors deployment."
else
    echo "[+] Found vulnerable pods:"
    echo "$PODS"
    echo ""
    echo "[+] ACTION REQUIRED: Update the 'guardrails-detectors' image to the patched version provided by the vendor."
fi

echo ""
echo "[+] Applying Emergency Network Policy to block Metadata Service access..."

# Create a network policy to block egress to 169.254.169.254 for the component
cat <<EOF | kubectl apply -f -
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: block-guardrails-ssrf-metadata
  namespace: default # Change this to the specific namespace of the component
spec:
  podSelector:
    matchLabels:
      app: guardrails-detectors # Ensure this matches your pod labels
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr: 0.0.0.0/0
        except:
        - 169.254.169.254/32
EOF

if [ $? -eq 0 ]; then
    echo "[+] Network policy applied successfully. This mitigates the SSRF vector to the metadata service."
else
    echo "[-] Failed to apply network policy."
fi

echo ""
echo "[+] Remediation steps:"
echo "1. Patch: Update 'guardrails-detectors' to the latest patched version immediately."
echo "2. Network: Verify the network policy above is active in all relevant namespaces."
echo "3. Audit: Rotate any credentials (Cloud IAM, Service Account Tokens) if exploitation is suspected."

Remediation

1. Immediate Patching: The primary remediation is to update the guardrails-detectors component to the patched version released by the vendor. Consult the official security advisory linked below for the specific version numbers. Deploy this update immediately to all clusters, prioritizing internet-facing or production environments.

2. Network Segmentation (Workaround): If immediate patching is not feasible, implement Kubernetes Network Policies (or Calico/Azure Network Policies, depending on your CNI) to strictly deny egress traffic from the guardrails-detectors pods to the cloud metadata IP (169.254.169.254) and other sensitive internal endpoints (like the Kubernetes API server) unless explicitly required for legitimate operations. The Bash script above provides a template for this.

3. IAM Hardening: Ensure that the Workload Identity or IAM Role assigned to the pods running guardrails-detectors follows the principle of least privilege. If the SSRF is exploited, the attacker can only use the permissions assigned to that specific role. Remove unnecessary permissions such as s3:*, ec2:*, or cluster-admin rights.

Official Advisory: Refer to the NVD Entry for CVE-2026-15378 and your Kubernetes distribution vendor for the specific patch release notes.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub

cve-2026-15378criticalcvezero-daypatch-tuesdayexploitvulnerability-disclosurekubernetesssrfguardrails-detectors

Is your security operations ready?

Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.