Skip to main content

Alert Types Reference

Stealthium turns the telemetry streamed from your hosts into alerts — the discrete findings its detectors raise when they observe an attack, a fault, or anomalous behavior. Alerts are stored and surfaced through the API and integrations, and each one carries a stable type that identifies what kind of finding it is.

This page documents every alert type Stealthium emits, what triggers it, and why it matters.

The type is the primary way to filter and route alerts. A single type can be raised by more than one detector — types are an attack-class taxonomy, not a one-to-one map to detectors — so the sections below describe the family of behavior each type covers.

Severities​

Alerts use two severity families. The first describes security findings and the second describes observability (health/fault) findings, so that security dashboards and counts don't mix with operational ones.

SeverityFamilyMeaning
CriticalSecurityActive, high-confidence compromise or exploitation. Investigate now.
HighSecurityStrong indicator of malicious activity or a serious exposure.
MediumSecuritySuspicious behavior worth review; may be benign in context.
LowSecurityWeak signal or a hardening/configuration concern.
InfoSecurityInformational; recorded for context and correlation.
CriticalObservabilityA fault actively degrading or threatening hardware/availability.
WarningObservabilityA health signal trending toward trouble.
InfoObservabilityInformational operational signal.

Many alert types span a range of severities — the same type is raised at High for an unprivileged process and Critical when the actor is privileged, for example. The per-type entries below note the range and what drives it.

GPU alerts​

Findings about the GPUs themselves — how work reaches the GPU, how its memory is used, the health of the hardware, and tampering with drivers or firmware.

GPU Command​

  • Severity: Info → Critical (security), plus Critical (observability) for crash chains

Anomalous GPU command-submission activity: unrecognized or unauthorized CUDA initialization and inference, CUDA callback registration, driver crash/race exploits (CVE-2025-23332, CVE-2025-23282, CVE-2025-23300), GPU reconnaissance (CUDA initialization and device-memory probing with no kernel launches), GPU-timing covert channels (command-submission cadence used as a C2 side channel — see the C2 Covert Channel entry under Network alerts for the network-side variant), and repeated GPU Xid crash chains (observability).

Why this matters: The command path is how work actually reaches the GPU, so abuse here is how an attacker runs unauthorized compute, probes for targets, or crashes the driver. Surfacing unrecognized CUDA initialization alongside known driver CVEs catches both rogue workloads and active exploitation.

GPU Shader​

  • Severity: Info → Medium

GPU device code produced on the host during a run instead of arriving as a precompiled module: a just-in-time GPU compiler on the Python caller stack that handed a module straight to the driver — Triton, NVRTC, CuPy, or torch.utils.cpp_extension (Info) — and the CUDA compiler toolchain (nvcc, cicc, cudafe++, fatbinary) running underneath a GPU job to compile device code from source (Medium).

Why this matters: Code generated on the host at run time never passed through build-time review or image scanning, so it is GPU code your supply-chain controls never saw. Just-in-time compilation is exactly what a legitimate Triton or CuPy job does and is recorded as informational for correlation, while a full CUDA toolchain compiling source underneath a running workload is the stronger signal that a job is building GPU code it did not ship with.

GPU Usage​

  • Severity: High → Critical (security), plus Warning (observability) for GPUs held without being used

Sustained high GPU utilization from an unapproved process relaunching a single CUDA kernel at a saturating grid size — the proof-of-work hashing pattern of unauthorized cryptomining. A privileged miner is Critical. As an observability signal, the same type also covers the opposite waste: a job that initialized the CUDA driver and then exited without ever launching a kernel, either because it aborted on a hardware requirement it could not meet or because it ran its whole workload on the CPU while holding a GPU.

Why this matters: GPU cycles are an expensive, metered resource, so a process quietly pinning them for its own proof-of-work siphons capacity from legitimate training and inference workloads, and a job that reserves a GPU and never touches it wastes the same capacity silently. Requiring sustained utilization, process attribution, and a mining-shaped kernel profile together keeps the security side narrowly scoped to hash-loop abuse rather than ordinary busy GPUs.

GPU Memory​

  • Severity: Medium → Critical (security), plus Warning / Critical (observability) for VRAM exhaustion

Abusive GPU memory-allocation and transfer patterns: bulk and streamed memcpy abuse, the GPU Breach UVM eviction-storm signature, NVIDIA VMA counter-wraparound activity (CVE-2025-33219), cross-tenant VRAM residue reads (LeftoverLocals, CVE-2023-4969), and NVIDIA vmalloc memory corruption (CVE-2025-23300). As an observability signal, the same type also covers VRAM exhaustion: a CUDA allocation failing because the workload asked for more device memory than the GPU has (Warning), escalating to Critical when the process keeps retrying the same impossible allocation in a loop instead of shrinking its footprint or backing off.

Why this matters: GPU memory is where models and in-flight data live, so anomalous allocation or transfer volume is the signature of exfiltration, abuse, and memory-corruption exploits, while an allocation the GPU cannot satisfy stops the job making progress. On the security side the severity escalates with the volume moved and whether the responsible process is privileged.

GPU DMA​

  • Severity: High → Critical

Raw CUDA device-to-host memory copies that read large volumes out of GPU memory outside a normal compute pattern — the signature of exfiltration over the DMA path.

Why this matters: Copying VRAM contents back to the host in bulk is how proprietary models and in-flight data leave the GPU. Reads at full-VRAM scale or from a privileged process escalate to critical.

GPU Driver Access​

  • Severity: High → Critical

A process issuing raw ioctls directly to the NVIDIA driver (nvidiactl / nvidia-uvm) outside the CUDA runtime path.

Why this matters: Legitimate workloads reach the GPU through the CUDA runtime; raw driver ioctls are the technique firmware rootkits and exploit tooling use to bypass it. Privileged callers escalate to critical.

NVIDIA Local Privilege Escalation #1​

  • Severity: Critical

An NVIDIA GPU driver local-privilege-escalation primitive that the Hyperion agent fingerprinted at the driver ioctl boundary and auto-mitigated in-kernel, killing the calling process before the escalation ran.

Why this matters: A local privilege escalation through the GPU driver takes an ordinary tenant workload straight to root on the host, and from there to every other tenant sharing the machine. Because the agent already stopped the attempt, this is a confirmed finding rather than a suspicion — isolate the workload and its owner, and contact Stealthium, which is tracking this primitive under coordinated disclosure with NVIDIA.

NVIDIA Local Privilege Escalation #2​

  • Severity: Critical

A second, distinct NVIDIA GPU driver local-privilege-escalation primitive fingerprinted and auto-mitigated the same way — the calling process is killed at the ioctl boundary before the escalation runs.

Why this matters: The primitives are tracked as separate types because they are separate bugs with separate fixes, so which one fired tells you what a host is exposed to. Treat the process and its owner as hostile and contact Stealthium; the mechanism is withheld pending coordinated disclosure.

NVIDIA Local Privilege Escalation #3​

  • Severity: Critical

A third NVIDIA GPU driver local-privilege-escalation primitive, fingerprinted and auto-mitigated at the ioctl boundary before the escalation runs.

Why this matters: As with the other two, the alert is raised only after the agent has already killed the caller, so it is high-confidence evidence that someone ran GPU exploit tooling on this host. Isolate the workload and contact Stealthium.

NVIDIA GPU Cross-Tenant Memory Access​

  • Severity: Critical

A GPU driver primitive that reads or writes another tenant's GPU memory, fingerprinted at the ioctl boundary and auto-mitigated in-kernel by killing the calling process.

Why this matters: Cross-tenant VRAM access breaks the isolation that makes shared GPU infrastructure safe — it exposes another customer's model weights and in-flight data, and lets an attacker corrupt their results. Treat every workload that shared the card as potentially exposed and contact Stealthium.

Rare GPU Driver Primitive​

  • Severity: Medium → Critical, by which primitive was issued

A GPU workload that is not on the approved list issuing a driver primitive that is rare or never legitimate for a tenant: registering arbitrary system-physical memory as GPU memory or exporting GPU memory to a dma-buf descriptor with no ownership check (Critical), setting up a peer-to-peer mailbox from an unprivileged client or allocating a kernel event buffer (High), or issuing a perfmon sampling control prone to leaking kernel pointers (Medium). Approved GPU workloads and container-runtime infrastructure are suppressed.

Why this matters: These primitives are the building blocks exploit tooling needs — arbitrary physical memory, cross-device DMA, kernel pointer leaks — and ordinary CUDA workloads never reach for them, so a tenant issuing one is a strong signal of GPU driver exploitation well before anything crashes.

GPU Control-Plane Escape Storm​

  • Severity: High → Critical

A single client issuing more than 300 GPU driver control-plane operations — RM escapes, RM controls, or UVM ioctls — within 10 seconds. A privileged or root caller escalates to Critical.

Why this matters: Exploiting a use-after-free, an info leak, or a race in the GPU driver means hammering the control plane until the timing lands, so a burst of (usually failing) escapes from one process is the shape of an exploitation loop rather than of work being done. Catching the loop gives you the process before it succeeds.

GPU Escape Followed by Fault​

  • Severity: High → Critical

A GPU driver escape, RM control, or UVM ioctl immediately followed — within 5 seconds, from the same process — by a GPU or kernel fault: an NVIDIA Xid, a kernel oops, or a robust-channel fault. A privileged caller escalates to Critical.

Why this matters: A GPU control-plane operation landing right before a fault is the generic signature of driver memory corruption, needing no signature for the specific bug being exploited. That makes it the catch-all for GPU exploitation attempts nothing else recognizes yet, including new and unpublished ones.

GPU Ransomware​

  • Severity: High → Critical

GPU-accelerated ransomware: symmetric bidirectional GPU memcpy correlated with a fan-out of file rewrites and renames in a short window.

Why this matters: Attackers offload bulk encryption to the GPU for speed, so correlating that memory pattern with mass file rewrites catches ransomware before the filesystem is fully encrypted. A privileged actor or rename-to-new- extension marker pushes it to critical.

GPU PCIe​

  • Severity: High → Critical

Changes to the GPU PCI inventory: passthrough rebind, device identity swap or spoof, driver change, slot enable, and device addition or removal.

Why this matters: A GPU silently rebinding to a passthrough driver or changing identity at a fixed PCI slot is how a card is hijacked for another tenant or spoofed. These changes precede VM-passthrough handoffs and hardware-level tampering.

GPU Firmware​

  • Severity: driven by the matched CVE

A GPU component — driver, VBIOS firmware, NVML, or CUDA — running a version with a known CVE.

Why this matters: Vulnerable GPU firmware and drivers are directly exploitable from the host or a container. Flagging the exact CVE turns version drift into an actionable patch item.

GPU Thermal​

  • Severity: Warning / Critical

GPU temperature crossing slowdown or shutdown thresholds, or rising fast enough to indicate thermal runaway.

Why this matters: Thermal events throttle performance and shorten hardware life, and a steep temperature slope gives lead time before a card hits its shutdown limit. This is an observability signal for hardware health rather than a security finding.

GPU ECC​

  • Severity: Low / Medium (ECC disabled) and Warning / Critical (memory errors)

GPU memory-error conditions: uncorrectable and high-rate correctable ECC errors, row-remap failures, retired pages, and ECC being disabled or pending-disable.

Why this matters: Uncorrectable ECC errors corrupt computation and predict imminent card failure, while disabling ECC removes that protection entirely. Both are reasons to drain and inspect a GPU before it produces silently wrong results.

  • Severity: Warning / Critical

NVLink interconnect health degradation: a link entering the Fault state (Critical), or a link stuck in the Recovery state for over 90 seconds, or a sustained DL CRC error rate above baseline (Warning).

Why this matters: NVLink is the fabric multi-GPU training and inference jobs depend on, so a faulted or steadily erroring link starves every workload attached to it well before the job fails outright. Catching sustained recovery loops and rising CRC rates, not just outright faults, gives you a window to drain a degrading link before it takes a job down.

Process & host-integrity alerts​

Findings about what is running on the host and whether the host — and the monitoring agent itself — has been tampered with.

Process Anomaly​

  • Severity: Low → Critical

Suspicious process behavior: runtime patching of sensitive Python modules, malicious exec() payloads (reverse shells, credential theft, obfuscated loaders), writable-and-executable (W^X) memory mappings, drop-and-run execution from scratch directories, ELF-integrity violations, attempts to tamper with the Stealthium agent, and EQL-rule process/file matches.

Why this matters: This is the catch-all for host-level compromise behavior — code injection, in-memory payloads, and tampering with the monitoring agent. A cluster of these on a single host is a strong hands-on-keyboard signal.

Privilege Escalation​

  • Severity: Medium → Critical

A process gaining elevated UID or GID toward root/system, and exploitation of the Copy Fail kernel-crypto vulnerability (CVE-2026-31431). Escalation to root is Critical; a bare kernel-crypto socket bind with no matched exploit pattern is Medium.

Why this matters: Privilege escalation is the pivot from a foothold to full host control. Tracking credential transitions per process catches both misconfiguration and active exploitation of kernel CVEs.

Unknown Binary Execution​

  • Severity: Medium → Critical

Execution of a binary never before seen in the workspace, enriched with file-creation provenance and GPU-access context. Running as root is Critical; GPU access or execution from a sensitive path (/tmp, /dev/shm, …) is High.

Why this matters: A host's normal workload uses a small, stable set of binaries, so a brand-new one is a strong anomaly. Attackers dropping and running their own tools light this up immediately.

Rogue eBPF​

  • Severity: High → Critical

A non-allowlisted process loading a hooking-class eBPF program (kprobe, tracepoint, raw tracepoint, XDP, sched_cls, LSM). LSM programs and known-bad hashes are Critical.

Why this matters: eBPF runs in the kernel with deep visibility and control, and attackers increasingly abuse it for stealthy rootkits. Loading a hooking program outside your known set of agents is a high-signal event.

Kernel & system alerts​

Findings about the kernel and system firmware.

Kernel Oops​

  • Severity: Critical

A kernel oops — null-pointer dereference, memory corruption, or driver fault — with resolved symbols and addresses.

Why this matters: An oops means the kernel hit a serious fault, often a driver bug or an exploitation attempt, and it can precede a crash. The resolved fault location helps tell a flaky driver from an attack.

Kernel Exploit Mitigation​

  • Severity: Critical

A Linux kernel exploit primitive that the Hyperion agent fingerprinted at the syscall boundary and auto-mitigated in-kernel, killing the calling process before the corruption ran. It currently covers the Dirty Frag page-cache writes through the IPsec/ESP and AFS RxRPC paths (CVE-2026-43284 / CVE-2026-43500), the Fragnesia ESP-in-TCP keystream flip (CVE-2026-46300), and file-descriptor theft from an exiting setuid process via pidfd_getfd (CVE-2026-46333).

Why this matters: Each of these ends in root on the host — attacker-chosen bytes written into a protected file such as /etc/passwd, or a privileged program's open credential file handed to an attacker. The alert fires only after the agent has already killed the caller, so it is a confirmed exploitation attempt: isolate the account, container, or pod it ran under, and patch the host kernel, because the same exploit can simply be tried again.

System Info Change​

  • Severity: driven by the matched CVE

A kernel or system-firmware version that matches a known-vulnerable (CVE) version.

Why this matters: An out-of-date kernel or firmware with a known CVE is directly exploitable. Catching it on version change turns patch drift into a tracked finding.

Container alerts​

Findings about container configuration and container-escape behavior.

Container Escape​

  • Severity: High → Critical

A process inside a container calling setns() to join host namespaces, the host root filesystem reached through the NVIDIA Container Toolkit's mount handling, or an anomalous toolkit hook execution — a hook carrying an injected dynamic-linker variable such as LD_PRELOAD, a hook binary running from outside the toolkit's install directories, or a hook with no container runtime anywhere in its process ancestry. Direct escapes and linker injection are Critical; an unexpected hook path or invoker is High.

Why this matters: Joining host namespaces from inside a container, or steering a toolkit hook that already runs as root on the host, is a direct container-escape technique. It is one of the clearest indicators that an attacker is breaking out onto the host.

Container Cgroup Escape​

  • Severity: Critical

A container writing to dangerous cgroup configuration files (release_agent, notify_on_release, devices.allow).

Why this matters: These cgroup files are classic escape vectors that let a container run commands on the host or grant itself new device access. A write to them from inside a container is almost never legitimate.

Privileged Container​

  • Severity: High → Critical

A container starting privileged (Kubernetes privileged security context or PRIVILEGED=true) or running as root. Privileged is Critical; root is High.

Why this matters: Privileged containers bypass nearly all isolation, so an unexpected one massively widens the blast radius of any compromise. Knowing exactly which containers hold these privileges is core attack-surface hygiene.

Container GPU Access​

  • Severity: Info, and High → Critical for unauthorized use

A container started with GPU access (informational), and GPU workloads run by containers that don't match the operator-defined allowlist (image, namespace, or service account). Unauthorized use in a privileged container is Critical.

Why this matters: GPU access is a privileged, expensive capability, so a workload using it outside your allowlist may be crypto-mining or a rogue training job. The informational variant gives a baseline of which containers legitimately hold GPU access.

Container Sensitive Mount​

  • Severity: High → Critical

A container started with a dangerous host path mounted: host root (/), the Docker socket, /proc/sysrq-trigger, /etc/shadow / /etc/passwd, or /dev.

Why this matters: Mounting the Docker socket or host root into a container hands it a trivial escape to the host. These mounts are common misconfigurations and a frequent first step in container attacks.

Escapes out of an autonomous-agent sandbox container are raised as Agent Sandbox Escape under AI/ML infrastructure alerts, not as these types.

Virtualization alerts​

Findings about virtual-machine isolation — a guest attempting to break out of the hypervisor boundary and reach the host.

VM Escape​

  • Severity: Critical

A confirmed KVM guest-to-host escape attempt that the Hyperion agent auto-mitigated in-kernel by killing the offending vCPU thread — currently the Januscape shadow-MMU corruption path (CVE-2026-53359).

Why this matters: A successful guest escape hands whoever controls the VM code execution on the host and a path to every other VM it runs, making this one of the most severe outcomes possible in a virtualized cluster. Because the agent already auto-mitigated the attempt in-kernel, this alert is a confirmed, high-confidence finding — treat the guest as compromised and patch the host kernel.

Kubernetes & control-plane alerts​

Findings about Kubernetes control-plane health and security, sourced from scraped kube-apiserver, kube-scheduler, and etcd metrics. Availability varies by signal: apiserver-based signals reach managed clusters via the in-cluster scrape, while etcd- and scheduler-based signals require a self-managed cluster where the control-plane scrape is reachable — they are dark on managed services such as EKS, GKE, and AKS.

Control Plane Integrity​

  • Severity: High → Critical

Kubernetes control-plane availability and integrity loss detected in scraped etcd metrics: sustained loss of quorum (no etcd leader for over 90 seconds) is Critical; a proposal-failure rate above 0.5/s sustained for 60 seconds is High.

Why this matters: etcd is the authoritative store for all cluster state — lose quorum and the control plane can no longer schedule, update, or recover workloads. A sustained failure rate distinguishes active corruption or tampering from a routine leader election, which resolves in seconds.

Control Plane Credential Attack​

  • Severity: High

A spike in kube-apiserver authentication (HTTP 401) or authorization (HTTP 403) failure rates well above the host's learned baseline — the signature of credential stuffing or token abuse against the control plane.

Why this matters: The kube-apiserver is the single entry point for all cluster control, so a successful credential attack against it can precede full cluster takeover. Baseline-relative scoring filters out normal controller noise and pages only when the failure rate is genuinely anomalous.

Control Plane Saturation​

  • Severity: Medium → High

Kubernetes control-plane overload seen in scraped metrics: kube-apiserver shedding load through API Priority & Fairness rejections (High), and kube-scheduler falling behind with failed or unschedulable scheduling attempts or a growing pending-pod backlog (Medium). Each signal must hold past a sustained window (60s–300s) before it fires.

Why this matters: A control plane that starts shedding requests or falling behind on scheduling is minutes away from an outage, so catching the overload before pods stop scheduling buys time to intervene. Requiring a sustained breach, rather than a single noisy sample, keeps the signal reserved for genuine, ongoing saturation.

Control Plane SLO​

  • Severity: Warning (apiserver and scheduler latency) / Critical (etcd fsync and apiserver 5xx rate)

Kubernetes control-plane SLO breaches computed from scraped metrics: kube-apiserver p99 request latency and 5xx error rate, etcd write-ahead-log fsync p99, and kube-scheduler p99 scheduling-attempt latency. Breaches must hold across multiple scrapes before alerting.

Why this matters: These are the same latency and error budgets an SRE would page on, surfaced automatically instead of requiring a hand-built dashboard. Sustained breaches usually mean the control plane is degrading under load or contention well before it stops working outright, giving you time to act before the saturation-level failures above set in.

Control Plane Etcd Storage​

  • Severity: Warning → Critical

The etcd database size — read from kube-apiserver's apiserver_storage_size_bytes — approaching (Warning, past 80% of quota) or critically full (Critical, past 95%) relative to its quota, sustained over 60 seconds.

Why this matters: etcd rejects all writes and goes read-only once its quota is hit, stalling the entire control plane — the leading cause of etcd outages. Because it's read from an apiserver metric rather than etcd's own /metrics, this signal reaches managed clusters (EKS, GKE, AKS) via the in-cluster scrape, unlike the etcd-native integrity and fsync signals above.

Control Plane KCM​

  • Severity: Warning → Critical

kube-controller-manager health degradation seen in its scraped metrics: a sustained controller-workqueue depth backlog and a p99 queue-wait SLO breach are Warning, and a spiking apiserver-client 5xx rate is Critical. Self-managed clusters only — kube-controller-manager isn't reachable in-cluster on managed services.

Why this matters: kube-controller-manager reconciles nearly every cluster resource, so a growing workqueue backlog or slow queue processing means controllers are falling behind on deployments, scaling, and cleanup well before anything else visibly breaks. A spiking 5xx rate against the API server means it can no longer read or write the state it needs to reconcile — a step closer to losing control-plane function entirely.

Network alerts​

Findings about network behavior — data leaving the environment, attackers moving between hosts, and covert command-and-control.

Network Anomaly​

  • Severity: Low → Critical

Anomalous network behavior: data exfiltration (large outbound transfers, with severity raised by unusual destination ports and recently-seen domains), SSH brute-force and lateral movement, and EQL-rule network/DNS/HTTP matches.

Why this matters: This covers data leaving the environment and attackers moving between hosts — the network side of an active intrusion. Correlating volume, destination, and SSH patterns separates routine traffic from exfil and lateral movement.

C2 Covert Channel​

  • Severity: Medium → Critical

Command-and-control covert channels: periodic low-jitter beaconing, suspicious TLS framing, and beaconing correlated with GPU device-to-host memcpy (a GPU-resident implant). The strongest correlation (GPU plus C2-like framing) is Critical.

Why this matters: C2 beaconing is how compromised hosts take orders and stage data, and GPU-resident implants hide it from host-only tooling. Detecting the cadence and its correlation with GPU memory reads catches channels that evade signature-based controls.

Purely GPU-side covert channels — C2 signalled through GPU command-submission timing rather than network traffic — are raised as GPU Command alerts, not this type.

AI/ML infrastructure alerts​

Findings about exploitation of AI/ML serving and orchestration infrastructure — the frameworks, APIs, runtimes, and monitoring services that schedule and run distributed training jobs, serve inference, sandbox autonomous agents, and keep watch over the GPU fleet.

Ray Job RCE​

  • Severity: Medium → Critical

Exploitation of the Ray AI framework's unauthenticated Jobs API (ShadowRay, CVE-2023-48022): a job-submission request to the Ray dashboard carrying an attacker-controlled command, correlated with the post-exploitation activity it spawns — dangerous Python imports, shell or miner processes, mining-pool network connections or DNS lookups, and anomalous GPU compute by a Ray-descended process.

Why this matters: Ray's Jobs API ships unauthenticated by default, so a reachable dashboard is a direct remote-code-execution path onto the cluster's compute. Severity starts at Medium for a bare unauthenticated submission and escalates to High and Critical as independent stages of the kill chain — submission, payload import, process spawn, network C2, GPU use — accumulate, distinguishing a confirmed multi-stage compromise from a single probe.

Path Traversal​

  • Severity: Low → Critical

An inbound HTTP request whose path traverses outside the intended directory (.. segments reaching the server). Against NVIDIA Triton Inference Server this is CVE-2026-47627 — Triton through 26.05 does not neutralize .. in a request path, so an unauthenticated caller can crash it: Critical with no Authorization header, High with one. Against any other server it is Medium when the path resolves onto system or credential material and Low otherwise. Requests that arrive over TLS are read from the server's own plaintext, so they are caught even where network-level inspection sees nothing.

Why this matters: Clients resolve .. before sending, so one arriving at a server means a hand-built request — a scanner at the least, an active exploitation attempt at worst. On Triton the payoff is a denial of service against every model that server hosts, which is why an unauthenticated attempt is treated as critical even though the request itself looks trivial.

Agent Sandbox Escape​

  • Severity: Medium → Critical

An autonomous-agent sandbox doing what its policy exists to forbid: escalating privilege, manipulating namespaces or mounts (Critical), running container escape tooling (High), or reaching credential material such as /proc/<pid>/environ (Medium). It covers the NVIDIA OpenShell sandbox-provisioning flaws (CVE-2026-65083 and CVE-2026-65093), where crafted input to the provisioning API brings a sandbox up with an incomplete deny list.

Why this matters: OpenShell locks its filesystem and process policies at sandbox creation, so a sandbox created defective cannot be corrected at runtime and is indistinguishable from a healthy one until its agent does something the policy should have stopped — which is exactly what this alert reports. Running code is not itself a signal; that is what the sandbox is for. Credential reads weigh more heavily here than they would elsewhere because agent sandboxes are handed provider credentials through the environment rather than through files.

DCGM Exporter Profiling Endpoint DoS​

  • Severity: High → Critical

An inbound HTTP request to the Go profiling endpoints (/debug/pprof/...) of NVIDIA's DCGM Exporter. Releases 4.8.0 and 4.8.1 mount net/http/pprof on the public metrics port with no authentication and no way to turn it off (CVE-2026-47483). A single request is High — the endpoint is exposed and something is reaching it; a sustained burst escalates to Critical as an active memory-exhaustion denial of service. Whether the request carried an Authorization header is recorded on the alert alongside the running totals.

Why this matters: The pprof routes allocate large buffers on demand, and profile and trace hold a connection open for a duration the caller chooses, so a flood of cheap requests exhausts the exporter's memory and crashes it — taking GPU-health visibility down across every node it watches, exactly the blind spot an attacker wants before touching the GPUs themselves. The same endpoints also leak process memory, the command line, and symbols, so even the single-request case is reconnaissance against a service that should never have been answering. Fixed in 4.8.2, which gates the endpoints behind --enable-pprof (default off).

ML training-integrity alerts​

Findings about tampering with model training.

Model Poisoning​

  • Severity: Medium → Critical

Training-integrity violations: out-of-band writes to checkpoints and datasets by a process outside the artifact's owning cgroup, runtime monkey-patching of the training pipeline, freshly-written or scratch-directory loaders injected into an established training cgroup, and on-device weight tampering — a co-resident process bulk-overwriting a large in-VRAM weight buffer via kernel launches with near-zero host I/O (High, escalating to Critical).

Why this matters: Tampering with checkpoints, datasets, or the training pipeline silently corrupts the resulting model — a supply-chain attack on the model itself. First-writer-wins provenance flags writes from processes that don't own the artifact.

Resource & observability alerts​

Operational findings about resource usage.

CPU Usage​

  • Severity: Critical

A CPU-usage spike — a short-window load average well above the longer-window baseline.

Why this matters: A sudden CPU spike flags runaway or unexpected compute, from a misbehaving job to abusive activity. It is an observability signal for capacity and behavior rather than a confirmed security event.