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.
| Severity | Family | Meaning |
|---|---|---|
| Critical | Security | Active, high-confidence compromise or exploitation. Investigate now. |
| High | Security | Strong indicator of malicious activity or a serious exposure. |
| Medium | Security | Suspicious behavior worth review; may be benign in context. |
| Low | Security | Weak signal or a hardening/configuration concern. |
| Info | Security | Informational; recorded for context and correlation. |
| Critical | Observability | A fault actively degrading or threatening hardware/availability. |
| Warning | Observability | A health signal trending toward trouble. |
| Info | Observability | Informational 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
Anomalous GPU command-submission activity: unrecognized or unauthorized CUDA initialization and inference, CUDA callback registration, and driver crash/race exploits (CVE-2025-23332, CVE-2025-23282).
Why this matters: The command path is how work actually reaches the GPU, so abuse here is how an attacker runs unauthorized compute or crashes the driver. Surfacing unrecognized CUDA initialization alongside known driver CVEs catches both rogue workloads and active exploitation.
GPU Usage
- Severity: High → Critical
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.
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. Requiring sustained utilization, process attribution, and a mining-shaped kernel profile together keeps this narrowly scoped to hash-loop abuse rather than ordinary busy GPUs.
GPU Memory
- Severity: Medium → Critical
Abusive GPU memory-allocation and transfer patterns: bulk and streamed memcpy abuse, the GPU Breach UVM eviction-storm signature, and NVIDIA VMA counter-wraparound activity (CVE-2025-33219).
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. 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.
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 fleet 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.
GPU NVLink
- 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: Medium → 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: High → 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.
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.
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: Critical
A process inside a container calling setns() to join host namespaces.
Why this matters: Joining host namespaces from inside a container 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.
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 fleet. 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.
Network alerts
Findings about network behavior — data leaving the environment, attackers moving between hosts, and covert command-and-control.
Network Anomaly
- Severity: High → 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.
AI/ML infrastructure alerts
Findings about exploitation of AI/ML serving and orchestration infrastructure — frameworks and APIs that schedule and run distributed training and inference jobs.
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.
ML training-integrity alerts
Findings about tampering with model training.
Model Poisoning
- Severity: Medium → High
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, and freshly-written or scratch-directory loaders injected into an established training cgroup.
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.