Container Runtime Security in 2026: Falco vs Tetragon vs KubeArmor

Every few months a container escape lands in my feed with a CVSS score and a logo, and the same question follows from someone on a platform team: would our runtime security tool have caught it? I run untrusted code for a living, so I care about the answer more than most, and the honest version is "sometimes, after the fact, if you wrote the rule". This post explains what container runtime security means in 2026, what the three main open source engines (Falco, Tetragon and KubeArmor) actually do, the difference between detecting an attack and preventing one, what the 2025 and 2026 escape CVEs in runc, the NVIDIA Container Toolkit and containerd teach us, and where the commercial CNAPP platforms fit in.

What is container runtime security, and why isn't image scanning enough?

Runtime security watches what workloads do while they run: which processes start, which files they open, which sockets they connect to, which kernel interfaces they poke. Everything before that point (image scanning, SBOMs, signatures, admission policy) is a judgement about what a workload might do. Runtime is the only layer that sees what it did.

That gap is not theoretical. Red Hat's 2024 State of Kubernetes Security report, a survey of 600 DevOps, engineering and security professionals, found 45 percent had experienced a runtime incident in the previous 12 months, roughly level with the 44 percent reporting build and deployment issues, and 89 percent had at least one container or Kubernetes security incident of some kind. A clean scan says nothing about a stolen token used through kubectl exec, a cryptominer pulled in at runtime, or a legitimate binary doing something illegitimate.

Almost every serious runtime tool today gets its data the same way: eBPF programs attached to kernel hooks (syscalls, tracepoints, kprobes, LSM hooks), streaming events to a userspace agent that applies rules. If you want the mechanics, I covered them in eBPF explained: Cilium and Tetragon. The interesting differences are what each tool does with an event once it has one.

The container escape CVEs of 2025 and 2026

Escapes are the scenario everyone pictures, so it is worth being precise about what happened recently. Most of these were not in the kernel. They were in the plumbing around it: the low-level runtime, the GPU hook, the CRI plugin.

Date	Component	CVE	What it allowed	Fixed in
5 Nov 2025	runc	CVE-2025-31133	Masked-path race leaves files such as /proc/sys/kernel/core_pattern writable, leading to escape	runc 1.2.8, 1.3.3, 1.4.0-rc.3
5 Nov 2025	runc	CVE-2025-52565	/dev/console mount race, escape or DoS	runc 1.2.8, 1.3.3, 1.4.0-rc.3
5 Nov 2025	runc	CVE-2025-52881	Writes redirected to arbitrary procfs files, bypassing AppArmor and SELinux	runc 1.2.8, 1.3.3, 1.4.0-rc.3
15 Jul 2025	NVIDIA Container Toolkit	CVE-2025-23266	LD_PRELOAD in the image hijacks a privileged OCI hook, root on the host	Toolkit 1.17.8
18 Jun 2026	containerd CRI	CVE-2026-53488	Image LABEL values passed unvalidated to containers, host command execution via a label-consuming plugin	2.3.2, 2.2.5, 2.1.9, 2.0.10, 1.7.33
1 Sep 2026	containerd CRI	CVE-2026-95837	Restoring an untrusted checkpoint keeps its own credentials, capabilities and seccomp state, ignoring the pod's	2.2.7, 2.3.4 (feature off by default)

A few details matter more than the scores. The runc trio, reported by Aleksa Sarai and announced on oss-security, needs the attacker to start a container with a crafted mount configuration, which in practice means a malicious image or Dockerfile. Sysdig's write-up recommends user namespaces because they block the worst paths. NVIDIAScape, per Wiz, was a three-line Dockerfile: the toolkit's createContainer hook runs on the host and inherited the image's environment. NVIDIA's bulletin is dated 15 July 2025. Every multi-tenant GPU platform should have reread its threat model that week.

The containerd advisories of 2026 are the newest, and I find the credit line the most interesting part: CVE-2026-53488 was found independently by Anthropic Research working with Claude, the GKE Security Team using Gemini, and a human researcher. The checkpoint restore flaw was serious enough that containerd turned restore via CreateContainer off by default in 2.2.7 and 2.3.4 and removed it entirely in 2.4.0. Meanwhile runc's only 2026 advisory so far, CVE-2026-41579, is rated low. AI-assisted bug hunting is filling the queue faster than before (I wrote about that in AI found the bugs), which makes boring patch discipline on node components more important, not less.

Falco in 2026: graduated, slimmer, and still detect-only

Falco is the default answer for open source runtime detection on Kubernetes. It graduated in the CNCF on 29 February 2024 and has shipped steadily since. The current release is 0.45.1, out on 19 October 2026, a bugfix on top of 0.45.0 from 21 September.

The 2026 releases slimmed Falco down rather than piling on features. 0.44.0 in May removed the legacy eBPF probe, the gVisor engine and the gRPC output, all deprecated in 0.43. What remains is the modern eBPF probe (bundled in the binary, CO-RE, needs BTF and the BPF ring buffer, so roughly kernel 5.8 and later per the driver docs) and the kernel module. 0.45.0 made a breaking change worth checking before you upgrade: rule conditions now evaluate on raw bytes, so rules that relied on matching the Unicode replacement character need review. The Helm chart source also moved into the main Falco repository; the published chart is 9.2.0.

The default ruleset is deliberately small. The falco-rules 5.2.0 artifact ships 25 stable rules, with 31 incubating and 39 sandbox rules in separate files you opt into (falcosecurity/rules). Stable rules cover the classics: a terminal shell in a container, reading sensitive files, contacting the API server from a pod, release_agent escapes, fileless execution via memfd_create, kernel module injection.

What Falco does not do is block anything. It sees the syscall after it happens and emits an alert. Response is a separate project, Falco Talon, which can label a pod, apply a NetworkPolicy or terminate it. Talon's latest release is still v0.3.0 from February 2025, so treat it as early software. I walk through the full install, custom rules, Falcosidekick and Talon in the companion Falco runtime threat detection guide.

Falco vs Tetragon vs KubeArmor: detection or prevention?

The real split in this market is not features. It is whether the tool can stop the action inline, in the kernel, before it completes.

Tool	Latest release	Governance	Primary mode	How it blocks
Falco	0.45.1, 19 Oct 2026	CNCF graduated	Detection	Does not; Talon reacts after the alert
Tetragon	v1.7.1, 25 Aug 2026	Part of the Cilium project	Observability plus enforcement	Override returns an error from a syscall or security hook; Sigkill kills the task (docs)
KubeArmor	v1.7.6, 15 Oct 2026	CNCF sandbox since Nov 2021	Enforcement	Generates AppArmor, SELinux or BPF-LSM policy from its CRDs (docs)

Tetragon's docs are refreshingly candid about the trade-off: Sigkill terminates the process synchronously but does not by itself stop the triggering operation (a write() may still land), so you pair it with Override when the operation must not complete. The 1.7.0 release in April added CEL expressions evaluated inside BPF, a matchParentBinaries selector and per-host policy selection. KubeArmor goes further toward allow-listing: you describe which processes, files and network operations a workload may use, and the LSM denies the rest.

Which one should you pick? Detection is cheap to roll out and safe: a noisy Falco rule wakes someone up, while a wrong KubeArmor or Tetragon enforcement policy takes production down. Prevention earns its keep on narrow, high-value paths where you know exactly what normal looks like: nothing in a payments pod should ever write to /proc/sys, load a kernel module, or exec a shell. Many teams run Falco broadly and add Tetragon or KubeArmor enforcement for a handful of such invariants. If you already run Cilium, Tetragon is the natural fit; if you want declarative allow-lists per workload, KubeArmor is the closer match.

Would eBPF runtime detection have caught the runc and NVIDIA escapes?

This is where I get sceptical of vendor marketing. For the runc masked-path race, Sysdig published an experimental rule that flags symlinks pointing at /proc/sys/kernel/core_pattern or /proc/sysrq-trigger, and said an official rule was in testing. When I checked the main branch of falcosecurity/rules this week, none of the stable, incubating or sandbox files contained a rule matching those paths. If you want that coverage, you write it yourself. Here is my version, plus the pod settings that remove most of the attack surface in the first place:

# custom-escape-rules.yaml: loaded after falco_rules.yaml (Falco 0.45.x)
# Adapted from the symlink pattern Sysdig described for CVE-2025-31133 / CVE-2025-52565.
- rule: Symlink Over Procfs Control Files
  desc: >
    A symlink was created pointing at core_pattern or sysrq-trigger, the shape of the
    November 2025 runc masked-path and /dev/console races.
  condition: >
    create_symlink
    and evt.arg.target in (/proc/sys/kernel/core_pattern, /proc/sysrq-trigger)
  output: >
    Symlink to procfs control file | target=%evt.arg.target linkpath=%evt.arg.linkpath
    process=%proc.name command=%proc.cmdline container_id=%container.id
    image=%container.image.repository
  priority: CRITICAL
  tags: [custom, host, container, mitre_privilege_escalation, T1611]
---
# Pod hardening that blunts the same class of bugs (Kubernetes 1.33+, containerd 2.x)
apiVersion: v1
kind: Pod
metadata:
  name: untrusted-build
spec:
  hostUsers: false              # user namespace: root in the pod is not root on the node
  securityContext:
    seccompProfile:
      type: RuntimeDefault
  containers:
    - name: build
      image: registry.example.com/build-runner:1.4.2
      securityContext:
        allowPrivilegeEscalation: false
        capabilities:
          drop: ["ALL"]

User namespaces have been enabled by default since Kubernetes 1.33, with hostUsers: false as the opt-in, though they need a recent kernel and runtime. NVIDIAScape is harder still for a detector: the malicious library runs inside a hook that the toolkit itself launches on the host, outside the container, so container-scoped rules never fire. You would need host-level rules on unexpected libraries loaded by nvidia-ctk hooks, and nobody has those tuned on day one. The fix was patching, or disabling the enable-cuda-compat hook.

The pattern is the same each time. Runtime detection is good at the behaviour after an escape (a shell on the node, a new privileged process, credentials read from the host) and weak at the exploit primitive itself. That is still valuable. It just is not a substitute for patching, which is why I would put more effort into knowing your runc and containerd versions across the fleet than into tuning one more rule. My own platform, PandaStack (I am the founder, and it is open source), runs untrusted code in Firecracker microVMs instead of containers precisely because a shared-kernel escape is the threat model; I explained that trade-off in container vs microVM vs gVisor.

Where do CNAPP vendors fit in runtime security?

Cloud-native application protection platforms bundle posture management, vulnerability scanning, identity analysis and a runtime sensor into one console, and in 2025 and 2026 the market consolidated hard. Google completed its $32 billion acquisition of Wiz on 11 March 2026; Wiz describes its own runtime sensor as eBPF-based. Palo Alto Networks folded Prisma Cloud into Cortex Cloud in February 2025, using its Cortex XDR agent for runtime. Sysdig, which created Falco, builds its commercial product on the same engine and claims in its 2025 usage report that customers get detections in under five seconds.

What you buy from a CNAPP is mostly correlation and curation: a runtime alert joined to the vulnerable package, the exposed load balancer and the over-privileged IAM role, plus a vendor team writing and tuning rules. What you do not get is a fundamentally different sensor. Under the hood it is eBPF on the same kernel hooks, with the same blind spots described above. If you have the people to own rules, Falco or Tetragon plus your existing SIEM covers detection well. If you do not, paying someone to own the rules is a reasonable decision, as long as you are clear that you are buying operations, not magic. For the broader threat picture, see Kubernetes security threats in 2026.

FAQ

Is Falco still the best open source runtime security tool for Kubernetes?

For detection, it is the most mature and widely adopted option, CNCF-graduated with a maintained ruleset. It does not block anything, so if you need inline prevention you pair it with Tetragon or KubeArmor, or accept after-the-fact response through Falco Talon.

What is the difference between Falco and Tetragon?

Falco is a detection engine with a rule language and a large default ruleset, designed to alert. Tetragon is an eBPF observability and enforcement agent from the Cilium project whose TracingPolicies can kill a process or override a syscall's return value inside the kernel. Falco is easier to start with; Tetragon gives you prevention at the cost of writing lower-level policies.

Does runtime security prevent container escapes?

Mostly no. Detection tools see the behaviour after an escape, such as a shell on the node or credential access. Prevention comes from patching runc, containerd and the NVIDIA toolkit, enabling user namespaces, dropping capabilities and using seccomp, or moving untrusted workloads to a stronger isolation boundary such as a microVM.

Do I need a CNAPP if I run Falco?

Not for detection itself. A CNAPP adds correlation with posture and vulnerability data and a team that maintains rules for you. Whether that is worth the price depends on whether you have engineers who will own Falco rules and triage alerts every week.

This quarter, I would do three things in this order: inventory runc, containerd and NVIDIA toolkit versions on every node pool and close anything older than the fixed versions in the table above; set hostUsers: false and RuntimeDefault seccomp on any workload that builds or runs untrusted images; and deploy Falco 0.45.x with the stable ruleset plus a few custom rules for the invariants I actually care about, routed somewhere a human reads. Enforcement with Tetragon comes after that, one narrow policy at a time.

Related: Container vs microVM vs gVisor: Choosing Agent Isolation, Isolation Is Not an Abuse Control: Lessons From My Fleet and Observability in 2026: OpenTelemetry Graduated, the Collector Is Still v0.162, eBPF Instrumentation Is v0.14, and Datadog Bills $1.12B a Quarter.